Get Busy Patching Everything Windows and Mitigating One Serious Flaw With No Patch; SonicWall and Fortinet Products Have Critical Flaws That Require Immediate Patching

Nine of the updates are rated as critical, six of which are being actively exploited in the wild. Realistically, it's long past cherry-picking which updates to apply. Focus instead on rapid deployment to commodity systems and regression testing for mission impact systems, reserving a small interval for patches which are pulled back or updated.

I am somewhat alarmed by the number of patches this month and the breadth of how many products. There are a lot of RCEs in this one, and one is related to Azure AD, which is interesting. How much testing is this going to require? I’ll leave it at that; we are not writing less code. More code, more likelihood of bugs.

Back in 2021, there were several months where Microsoft had to release patches for over 100 security issues. While it would be great to see a long-term trend of fewer flaws in production software, we really are not yet near hitting the knee in that curve – as evidenced by the number of times browsers update themselves, how frequently cloud services are updated, and all the vulnerabilities being found now in security products. Just like fleet owners have to forever budget and plan for maintenance, repair and down time, the same is going to be true for software for a long time to come.

An above average patch Tuesday for Microsoft. If you haven’t done so already, prioritize patching of the actively exploited vulnerabilities first, followed by the remainder of the critical vulnerabilities. As always, review Microsoft advisories for additional mitigation details.

The number of patches per unit time is a useful measure of software quality. It is also a measure of the developer's ability to find vulnerabilities. One would expect the number to go down over time. It is not. Moreover, patching is a very expensive way to achieve quality. We are doing something wrong.

Review the recommendations in the Microsoft blog. In essence, making sure that your EDR is both getting real-time updates and in full blocking mode, as well as making sure that your office suite is set to deliver updates with a required install date automatically. If you’re not there, ask the why questions and set a resolution date.

Interestingly, this vulnerability was not included in this month’s Patch Tuesday. One can only presume it’s a more serious vulnerability and the company needs to time to fully investigate and develop a comprehensive patch. Don’t be surprised to see Microsoft issue an out-of-cycle patch for this actively exploited vulnerability.

But wait, there is another bug, an RCE in Word this time. I would say patch, but there is no patch yet.

Good security must not rely exclusively upon good user behavior.

Neither the Microsoft, nor the CISA report, answer the most important question: How did the cryptographic key get into the hands of the attacker? Will Microsoft notify victims who did not pay for additional logging features? Is there any concern about additional keys that may have been leaked?

This is a major failure by Microsoft to keep its cloud services secure and a good reminder that using cloud services does not eliminate the need to monitor them continually for abnormal activity.

Stack the deck in your favor. Make sure that you're ingesting all possible logs from your cloud service provider, just as you would for on-premise services. Ask questions about delays and if there are different logs with different service levels. Historically, Microsoft delays some security logs 24 hours, on the premise time is needed to separate other tenant activity from yours. Next make sure that the incident contact information is current on both sides for all your service provider. Make sure it's not a single POC, or an internal only mailing list. Don't wait for the chips to be down to discover the information is inaccurate or outdated.

This one is alarming. Very Alarming. From how this reads, and this is extremely vague right now, a forged token was used to access what appears to be very sensitive orgs Exchange accounts. The problem is the only token I can think of right now are the tokens relating to Azure AD JWTs. Does this mean that someone could sign their JWTs? Did they create an access token or refresh token? The actual writeups are very scant and slightly disturbing. I’m sure that we will know more as this unfolds.

There are several things of note relating to this attack: Firstly, Microsoft and other cloud service providers need to provide their clients with access to security logs and not have this as a feature that is an additional charge. The organization that detected this attack did so because they subscribed to the E5 licensing model for Microsoft 365 which provides logging capability; customers on less expensive subscriptions do not have access to logs and therefore could not detect this or any other attack. Secondly, Microsoft need to be transparent as to how the attackers managed to get to the compromised keys and what steps they have in place to precent a reoccurrence of this type of attack. Finally, the report from Microsoft mentioned some consumer accounts were also targeted; Microsoft should provide details on how many of these accounts were targeted and if those accounts match a certain profile such as journalists, dissidents, etc.

An egregious lapse in security by Microsoft. This should serve as a reminder for organizations that use cloud services that they still share cybersecurity responsibilities. Kudos to the FCEB entity that detected and reported the anomalous activity.

While there is a workaround, you really don't want to disable SSL inspection, even if only for HTTP/2. Double check to see if you're running an affected product, FortiOS 7.2.0-7.2.3 & 7.0.0-7.0.10 or FortiProxy 7.2.0-7.2.2 & 7.0.0-7.0.9, then get that update rolling. If you're still running the older product versions, you really need to make plans to move to current versions.

Another Fortinet RCE Vulnerability. This one appears to impact traffic proxied through the Firewall and not the admin interfaces. By now, you should just be used to patching.

I’m going to skew a bit old here, but I’m pretty sure tulip-related crime saw a similar downswing after the tulip bubble burst in 1637. The values of virtual currencies and the valuations of startups that were based on use of virtual currencies have plummeted and criminal use has dropped – except for ransomware! Still need to prioritize moving to 2FA to defeat phishing and continuing security awareness and education to maintain low scam click rates.

No surprise here, ransomware continues to be lucrative. Even though many resources have decryption keys available for free, the ransom still gets paid, particularly when coupled with threats to sell exfiltrated data. The drop in cryptocurrency crime seems to be tied to two large scale scams: VitiLook and Chia Tai Tianqing Pharmaceutical Financial Management seemingly calling it quits. Both of these were investment scams, promising crazy returns, reminiscent of old scams involving fiat currency. Beyond just social engineering awareness, users investing in crypto need to do their homework.

The success of ransomware suggests that, both collectively and individually, the cost of attack against our systems is much lower than the value of success of the attack. Fortunately for us the measures that we need to implement to raise the cost of attack, e.g, strong authentication, structured networks, are efficient. At least collectively and over time, they will reduce the cost of losses many times their cost of implementation. Get on with it.

Apparently, Apple adding a letter to the OS version in Safari's User Agent may have caused issued with various websites. As a web developer, when parsing user agents, be careful to allow for some simple format changes like this. Of course, Apple may want to rethink how they number OS versions with rapid security response fixes applied.

This is quick to deploy and requires a reboot. You need to deploy the updated fix even if you already pushed out the initial update. (16.5.1 (a) etc.) Note there wasn't a released version b of the update you missed. If I'm tracking, the issue with some websites not rendering properly was changes to the user agent string to include the version of the update. Note to self: don't be that tightly tied to the user agent string.

Not unexpected as Apple is still working out some of the kinks with RSR updates. The challenge will always be between full test coverage for different implementations and the need to make the update available soonest. Apple will get better as they continue to push Rapid Security Response updates.

If you search the document for “password,” “authentication” or “privacy”, you get zero hits. Many valid initiatives in this list of projects but still a lot of “public/private cooperation” and “information sharing” and no real game changers, nothing where the government is using its buying power to raise the bar in any major way.

Expect more cybersecurity hiring in the federal space and supporting industries. This is a 57-page “living document,” so I suspect we will see more of this.

Pulling information from about 65 initiatives into a single overall reference should help de-mystify the goals for the White House Cybersecurity direction. The document breaks this into 5 pillars, with objectives and activities, to include responsible agencies, and expected completion dates. Beware, this is acronym rich territory – they are listed on pages 55 & 56 – you may want to keep those handy as you read, as has been said: “You keep using that word, I do not think it means what you think it means.”

The highly anticipated implementation plan has dropped. My takeaways: 1) revamping cyber intelligence-sharing with industry (owners of the bulk of critical infrastructure); 2) a continuation of efforts to disrupt the ransomware ecosystem; and, 3) a continuation of the administration’s effort to create an international coalition of cybersecurity expertise. For the first takeaway, we’ve been admiring the problem for far too long. You’re not going to create seamless cyber intelligence sharing by simply expanding security clearances. The focus has to be on making the intelligence usable in an unclassified manner.

“Anything worthy of being called a plan says who will do what and when.” By naming responsible agencies, this document does that, where all too many government documents pretending to be plans fail.

Even if you don't have the AIOS plugin, it's a good time to make sure that your automatic updates are working, that you've enabled MFA for all your WordPress accounts; don't forget that user who will enable it "soon," and never quite does, and you've got visibility to security events. By you I mean your SOC, not just your inbox. If you've got a public facing WP site and you're not seeing (fake and valid) login attempts, pull that thread. Have a conversation about what other security options you should be implementing.

Yet another vulnerability in a WordPress plugin. It’s curious as to why AIOS didn’t patch earlier as their initial response described it as a ‘known bug in the last release.’ A slight quibble with their security best practice recommendations: yes, users of the plug-in should change their passwords in this instance, but regular password change is no longer considered a security best practice. Bottom line: download the patch and update.