Patch Vulnerabilities in Fortinet FortiClient, Palo Alto Networks PAN-OS, and VMware vCenter Server; Ensure MFA is Properly Implemented

FortiClient is a critical component to many organizations. If you are a Fortinet customer running this client you should upgrade. This can be abused as an LPE and attackers are constantly looking for these vectors on local devices.

Two flaws were discovered, CVE-2024-47574, authentication bypass, CVSS score 7.8, as well as a second flaw, no CVE assigned yet, allowing access to the plain text encryption key used to protect sensitive information. Both flaws are addressed in the updates. If you have Fortinet in your shop, updates to the management client are as important as updates to the firmware on the device. While you're looking at your Fortinet environment, make sure that your management interfaces are also protected, limited to authorized hosts only.

You should not expose firewall management interfaces to the open internet. It's still happening, and it's usually unclear why. There are many hotfixes to fix this issue, which should be installed immediately. The more pressing situation is around exposing those management interfaces. Palo Alto is offering help to individuals who believe they have been compromised already.

CISA/DHS got it right with BOD-23-02, make sure management interfaces are not exposed to the Internet. Even better, only allow authorized hosts access to those interfaces irrespective of the network; your future self will appreciate this change. If you're a Palo shop, make sure you not only protect the management interface but also update to the unaffected version of PAN-OS.

Interesting that Palo Alto knew about an exploit, but wasn't able to figure out the vulnerability exploited. Some pundits complained about the additional telemetry Sophos added to its products to trap recent attacks against its customers, but this is exactly what is needed to better protect users (and some halfway sane development practices).

Broadcom support for existing VMWare customers has been somewhat bad to mixed from anecdotal stories. One of the more glaring ones has been just getting VMWare Workstation / Fusion customers back. I would speculate it was easier to make it all accessible than to continue the disaster of getting support. How easy has it been for customers to get vSphere patches post-acquisition? One other note is that widespread exploitation during the patch does not mean it will not happen in the future. N-Days are more and more common than 0-days.

This flaw was initially discovered five months ago; the update can be tricky. Refer to the Broadcom update for the versions of VMware vCenter Server and VMware Cloud Foundation you should have deployed. Note the Cloud Foundation update is an Async patch. While you're at it, make sure your vCenter management interfaces are only accessible from authorized devices.

Use Passkeys, Use YubiKeys, Use Passwordless. You can use your Password Vaults on your phones. There are so many options now that we should be pushing SMBs and all businesses to more accessible and more secure mechanisms. This survey needs to clarify the delta from year to year in the password age. This is almost impossible to understand, so it will be complicated with a one or two-year lookback to see if businesses are genuinely secure. Considering that IOS Passkeys is new, we may not be capturing the move to these technologies yet.

With passwords we're swimming upstream against decades of human behavior. If you need to keep using passwords, implement a service which checks data breaches for exposed passwords as well as enforces 800-63-3. We all need to target stronger authentication mechanisms which move away from passwords entirely (MFA, FIDO, passkeys, etc.). Get those projects in the chute or they will never happen.

Yep, passwords are still a thing andÉ reuse is a problem given all the accounts that must be managed. Check. The best thing we can do is start an education campaign to move us along to adopt passkeys. The good news is all the major operating systems, browsers, and free email services have passkey options available. Seems like a global PSA is in order.

Any discussion of bad passwords makes me uncomfortable because it suggests that there is some problem that good passwords would solve. While there are attacks that good passwords would resist, they are useless against the social engineering and fraudulent replay attacks that we are seeing. Heed the advice of my colleagues and focus your efforts on strong authentication (at least two kinds of evidence, at least one of which is resistant to replay).

In 99% of this document, you could replace 'AI' with 'software' and see pretty much a standard secure development/operations framework. In the Developer section is the important part, analogous to early worries about digital fakes and the need for integrity and authentication support to what was called 'watermarking.' The cite: 'Distinguish AI-generated content: Where technically feasible and commercially reasonable, AI developers are encouraged to ensure that AI-generated or manipulated content, such as code, text, images, audio, or video, can be clearly identified at the time and point of origin, and therefore distinguishable from human-generated content.'

Guidance, regulation, and legislation of AI, at least in the short run, should be on an application by application basis. It should focus on holding users, both enterprise and individuals, accountable for the use and the results. The applications and risks are simply too broad to regulate at the technology level.

This is going to be critical in the future. I noticed a news article about using general-purpose AI in critical and sensitive areas such as healthcare. General Purpose AI is often giving incorrect information, and putting guard rails on this is going to be important. It's one thing being able to get around a chatbot to get free airline tickets, and another thing to be giving the wrong medical advice or worse because of AI that hallucinates. Imagine if you decide to use AI to regulate chemicals in the water, this could be not the wisest approach. I suspect we will see more and more language around this as technology advances.

AI, while still evolving and maturing, is pervasive, and we're all working to understand and secure the implementations in our shops. If you're in the critical infrastructure business, this is the droid you're looking for, at 35 pages it's not a bad read, and should drive some interesting conversations, both internally and with your suppliers. Even if you're not in that space, this is good input to consider relating to your AI deployments.

The intercepted communication included legal advice to congressional staffers from library research staff regarding confidential legislative issues. Beyond work you're doing to mitigate BEC, Phishing and other email scams, make sure that your SMTP services/relays are configured to use TLS to prevent MiTM message interception; this is already required for cabinet level agencies per BOD-18-01.

Not a lot of information on the incident. That said, suspect it to be a missed email server patch. What's troubling is that it took nine months to detect and mitigate the security incident. Lots of lessons learned that should, at the appropriate time, be shared with the cybersecurity community.

The relentless extortion attacks on healthcare deserve our attention. Certainly improved resiliency of our systems is both efficient and essential. However, these attacks continue to escalate in part because the perpetrators believe that there is little risk they will be investigated, indicted, or punished. The role of nation states is to so enforce the law so as to discourage these attacks.

The UN could call out nations that are harboring ransomware gangs and enforce a penalty on them. Or they could continue to issue statements and adjourn for cocktail hour. It looks like they chose the latter.