Patch Cisco IOS XE Wireless Controllers Now; Microsoft Authenticator Deprecating Autofill; Chrome Rescinds Trust in Certificates from Chungwha Telecom and Netlock

This now puts us into a "fix it now" scenario as the information is now publicly available to create an exploit. At its core CVE-2025-20188 stems from a hard coded authentication token, which can only be addressed by applying the update.

It's been a while since I've been at Cisco looking at the Wireless Controllers, but the last time I remember, the IOS XE one is built into the switches themselves and is not part of the WLC core product line. It's challenging for me to estimate how many of these are deployed in the wild like this. I would have assumed most companies are still using the WLC Controller model. Either way, it's not a bad idea to patch.

Ugh, hard-coded credential, found, and soon to be exploited. It sure seems like a poor secure-by-design choice by the folks from Cisco, who know better. Given the CVSS rating, 10.0, it's a must-fix with a patch being available for almost a month. Let's hope that by now, everyone affected has downloaded and patched. Hey, a person can hope canÕt they?

You should already be getting a prompt in MS Authenticator to move those stored passwords. Regardless of where you move them to, make sure that you click the passwords tab and ensure they are all migrated. Make sure you've communicated a path to users now as July 1st will be here before you realize it.

This is most likely part of Microsoft's long-term strategy of moving to a 'passwordless' environment, i.e. Passkeys. While I think this is a fantastic concept (everyone hates passwords) I'm finding Passkeys much more confusing to manage than expected. I've been accepting Passkeys from almost every website that offers them. Every time, I find myself confused: is it saving it to my operating system, to my password manager, somewhere else? Each device and each website handles it differently. I've literally had apps 'arguing' on my system which app will store the passkey. How do I handle devices that do not support biometrics? Different organizations can also implement Passkeys internally different ways, making what should be simple complex and hard. I know we are all excited with Passkeys as the way to simplify and strengthen authentication, my concern is we are going to make the process just as painful as passwords/MFA in the past.

This one, honestly, sucks. If you used Authenticator as an Autofill system, you will lose access. When features like this are deprecated, users sometimes lose access to their data. Keeping your users informed is what I recommend.

Good on MSFT for pushing folks to embrace MFA and to use modern, more secure, browsers. Bad on MSFT for steering folks to their Edge browser as the preferred solution.

Over the last few years, Google's influence has substantially improved the security of the certificate authority ecosystem. The CA/Browser forum's requirements have become substantially more stringent, and enforcement, as seen here, has been swift. Chungwha Telecom did not properly enforce the CAA DNS records, and Netlock issued unpublished intermediate certificates. It is important to note that both could have remained in 'good standing' if they had responded quickly and revoked the issued certificates. Certificates issued before August 1st will remain trusted for both CAs. Any certificates issued after July 31st will no longer be trusted. Each CAÕs market share is less than 0.1%, according to w3tech. But keep in mind to not only enumerate certificate authorities you are using, but also CAs used by your business partners to avoid disruption in connectivity should a certificate authority no longer be trusted.

If you're using certificates issued by Chunghwa Telecom or Netlock, you have two options. Either replace these certificates with ones from a different CA or add the corresponding root CA certificate as a trusted root CA, vi profile, GPO, or manually. For anything public facing, you probably want to just go to different issuer to avoid any disruptions relating to Chunghwa/Netlock's process to regain that trust.

Back in March, Google issued needed updates for the security requirements of CAs to be trusted in Chrome. Certificate management processes should be in place to know where and from which CAs certificates are in use to enable dealing with CA trust revocation.

I've never actually looked into what happens to a company after you get delisted from the Chrome Trust Authority. Do they rebrand and reapply? It's kind of an odd thing about what happens after this occurs. I would strongly doubt they close their shop and rm -rf all their tech.

The requirement is designed to target Australia's largest companies, and failure to report after the grace period results in a fine of 60 penalty units, currently $12,700 USD, and this is expected to increase. Paying the ransom in Australia is not illegal. Indications remain that despite guidance to the contrary as many as 90% of companies pay the fine, and as many as 40% of those who paid are provided a corrupt decryption key. Further, there are starting to be cases where ransomed data is not actually removed. Make sure when considering your ransomware payment response to include both reporting requirements (US reporting requirements are expected this October) and legality of that payment, e.g., OFAC in the US.

This should be interesting as we have many multinational companies with businesses registered in Australia. If, say, a US registered company that also has a registration in Australia gets a part of its operations in another country ransomwared, do they have to let the ASD know? This is an interesting one to watch for sure as it will impact all manner of companies.

For most enterprises and the vast majority of incidents, the vulnerability exploited is way more important than who did the exploiting. It is kinda like weather - we don't name 100,000 thunderstorms that hit the US each year, or even the 10,000 or so severe ones. But we do name the 25 or so hurricanes that reach certain levels of dangerous winds and pose danger to large numbers of people. For 'cyber weather,' harmonizing naming threat actors is better than confusion but will only be meaningful for a small number of organizations where more than lack of basic security hygiene was the root cause.

A consistent naming standard is helpful, and Palo Alto's Unit 42 and Google/Mandiant are joining the collaboration. This new standard includes common designations, such as all threat actors from China will have a name followed by Typhoon, while Ukraine-backed organizations will end in Frost.

When every incident write you see includes things like: SOMETHING BEAR aka APT42 aka VOID TAKE ME, it's hard not to say, ok, can we just agree to call them BANANA HACKERGROUP instead.

This had been a vetted person in the insider threat division of the agency who was motivated by the change in administration. Foreign agents are leveraging dissatisfaction with the change in administration as well as recent layoffs to obtain sensitive information, posing as headhunters, consulting firms, think tanks, etc. to target government workers. Consider that as you look at staff handling your sensitive information and assess the continued protection of that information, are you prepared to not only vet them initially and periodically but also to detect any untoward information sharing?

The colloquial, 'If you do the crime, you do the time' seems appropriate here. IT professionals by their job description are trusted. If they violate that trust, they should be held accountable. Good sting operation by the men and women in Blue.

Well, back to the Cold War we go with spies and all that.