Patch Now: SharePoint, Winsock, and VMware vCenter Flaws Exploited; Zoom Vulnerabilities

The SharePoint authentication flaw was addressed in the July Patch Tuesday update, and there was a POC exploit published. Make sure that your on-premises SharePoint 2016 and 2019 servers were patched. It's August, so the July patches should be ancient history, but make sure. Then, after you've had your coffee, see if there is (still) a valid reason you're hosting your own SharePoint servers. If you really still need them, then don't expose them to the Internet — put some layer of application security control in front of them.

For organizations beginning to pilot VulnOps programs, it helps to pick real vulnerabilities as exercises for the process: identify exposure, assess context, prioritize, remediate, validate, and learn from the cycle. These actively exploited SharePoint and Winsock flaws would make pretty good candidates for your VulnOps pilot to address quickly. But don’t worry if you miss this particular opportunity. At the current pace of vulnerability discovery and exploitation, we’re going to have hundreds more examples to practice on in the coming weeks. Sigh.

We’ve reached a point where software patches must be deployed immediately upon release. Waiting for a CISA KEV catalog entry is no longer a viable strategy — cybercriminals are actively reverse-engineering patches and weaponizing vulnerabilities in real time. Organizations must prioritize automated patch management to stay ahead of the threat.

If you have vCenter, you have two tasks. First, apply the update, Second, make sure that you don't have the reverse_ssh in your environment. After that's set, make sure that you're restricting access to your vCenter management services, and verify the cron entries are clean and accounts are all legit. Consider that your vCenter server is as critical as a Domain Controller, a prime resource for lateral movement when compromised. Have a DR tabletop with that as an entry point.

Five days. That is how long defenders apparently had between Broadcom releasing the fix and compromised systems communicating with the attackers' infrastructure. Within another two days, approximately 95% of the victims identified in this campaign had appeared. The lesson is simple and reinforces many other recent stories covered by SANS NewsBites: Patching critical internet-facing infrastructure cannot operate on a monthly timetable. Your vulnerability management programme needs a fast-track facility for vulnerabilities affecting critical and exposed systems.

Good ol’ directory traversal rears its ugly head yet again, this time in a particularly valuable target: VMware vCenter. Five or so days from patch release to widespread exploitation is a painfully short window, especially for a product that serves as a control plane for virtualized infrastructure. This should jump to the front of the remediation queue. Patch urgently, but also investigate for compromise. Once exploitation is occurring, installing the fix closes the door but doesn’t tell you whether someone walked through it yesterday. For high-value management planes, accelerated patching and post-patch threat hunting should go together.

Hey look at that, another AI-discovered vulnerability. Come on, I heard that eyeroll, it's still cool. But now we need to do something — Zoom made the updates, so you're going to want to make sure the updates have been applied. Don't assume someone will stop and install the update when they're trying to get connected to a meeting, or that they did the “restart Zoom” part of the update. Beyond finding a good outage window, you're likely going to have to send out an announcement as a CYA. This could be a good time to get everyone to Zoom 7.1.5.

Gosh, this edition of NewsBites feels like an endless series of high-CVSS flaws. Welcome to the new normal. At Black Hat and DEF CON last week, I asked many people associated with patching and software security at major vendors and in the industry more generally how long they thought this storm would last. Every single person said, "I have no idea." I followed up by asking, "Do you think we might get lucky, and it’ll be short, like 3 or 6 months?" Each one said, "No way… this will be at least a year, and maybe two or three." I was hoping for another answer, but it looks like we're in for quite a slog.

And here was me thinking that the risk in using Zoom was leaking of meeting content. (I use the Apple iOS client, but I will update it anyway).

421 vulnerabilities in one month is an extraordinary volume for defenders to absorb, prioritize, test, and remediate. AI-assisted vulnerability discovery is helping us uncover flaws at a remarkable pace, which makes beginning to build VulnOps processes increasingly important for deciding what needs attention first and validating that remediation actually worked. I also want to thank the Microsoft security and engineering teams doing the hard, often invisible work behind these releases. They are draining a very large swamp of vulnerabilities accumulated over decades of software development, while simultaneously trying to produce patches that are safe, reliable, and deployable across an enormous installed base. That is a formidable undertaking, and the sheer scale of Patch Tuesday gives us a glimpse of just how much work is happening behind the scenes.

I am not sure the actual numbers matter these days — focus on getting the updates deployed, as POCs aren't far behind. With the current volume of patches, your grouping/prioritization of systems is how you're going to keep your head above water. The majority have to be in the auto-update category; then you can focus on more sensitive systems with regression testing and defined outage windows. Make sure these have other security layers to help deflect unwelcome advances. Remember, those defenses need to be top tier in terms of updates and security posture, but they will save your bacon if done right.

Back when Microsoft Windows (and most software) was riddled with simple (such as buffer overflow, etc.) vulnerabilities, waves of successful attacks forced Microsoft to both improve security focus in its software development process and move to monthly patch releases, which was vigorously resisted by CIOs. This AI-assisted wave points out the need for the software industry to make big leaps forward in ease of patching legacy software and vulnerability avoidance in new applications.

Echoing John Pescatore's words to also point out a "...need for the software industry to make big leaps forward in" initial software quality. Patching transfers the cost of quality from the developers to the customer and multiplies that cost by the number of customers. CIOs would have to be blind not to resist it. The use of AI in software development and testing is necessary and efficient. Because AI tends to be literal, rigorous specification is necessary.

NIST is on the right track, seeking to improve their process and leveraging the gains seen in other areas by the use of AI. Now is your chance to provide guidance from your experiences to help them choose wisely. Comments need to be entered through the federal e-Rulemaking portal. Go to www.regulations.gov and enter NIST-2026-0100 in the search field. Don't wait — October 13 is a hard deadline.

For all of its shortcomings, the NVD is a critical resource for many vulnerability management programs. Authoritative, standards-based enrichment of vulnerability data is a critical service to the community, and I hope NIST can form an alliance between industry and academia to continue supporting NVD, even amid the current surge in vulnerabilities.

AI is going to change vulnerability management far more profoundly than simply helping us find more bugs. In my 30-minute SANS webcast on VulnOps on August 12, I discussed some of the growing strain on the NVD as vulnerability discovery accelerates. So, I’m very heartened to see NIST taking on this modernization effort. In our VulnOps work, some of the biggest gains come from tightening the entire loop: discovery, validation, contextual prioritization, remediation, retesting, and deployment, with humans reviewing and steering throughout. The NVD can be enormously valuable in that work, but only if its data is timely, machine-consumable, trustworthy, and rich enough to support decisions beyond a static severity score. This looks like a noteworthy and useful project for the community. As vulnerability discovery accelerates, the rest of our vulnerability management ecosystem needs to evolve right along with it.

https://www.sans.org/mlp/vulnops-cisos-guide-to-starting-implementation

NIST’s take on vulnerability management in the age of AI hits the mark. The ultimate goal for the security industry must be end-to-end patch automation. Once achieved, it will force us to rethink the value proposition of the NVD altogether. But until full automation is a reality, the NVD remains essential, and applying AI to its internal operations is critical to keeping pace.

The recent attacks against water utilities and these incidents involving local governments expose a common underlying problem: Small public-sector organizations are being asked to defend increasingly complex systems with limited technical staff and resources. There are differences in impact, of course — attacks against water systems can disrupt physical processes, while attacks against local governments can affect public safety and essential services. I think that the common lesson is what we call community resilience. While protecting computer systems remains important, leaders need to plan for keeping communities and facilities functioning when those computers are not available.

Take a look around at your city, county, and state's adoption of technology for what used to be a lot of manual processes. It's pretty amazing. It also raises the likelihood of disruptions close to home. Meet the IT staff behind these systems, heck, buy them a beer or something, then see how they are with cyber security. Some have amazing programs — I love hearing my local folks talk about Operation Cyber Idaho or election security — while others are stuck. We need to help the stuck ones get hooked up with the right ISAC, apply for grants for services, locate needed talent, or maybe just brainstorm and vet ideas. The goal is to help them raise the bar, not to interfere or cause harm.

Only healthcare and schools rank ahead of municipalities as ransomware targets of choice. Strong authentication, layered network, and least-privilege access control are necessary and efficient.

This feels like an extension of the violent physical attacks on the facility, which makes me sad as those same attackers are likely to have to turn to this facility when they are in need of healthcare. For the rest of us, it is a reminder that OT hacks and attacks are real, so don't make things easy to reach. Sure your systems are hardened and isolated, but if I can turn off your data center's CRAC units, or prevent physical access by locking your doors or changing the access list, you're not going to be happy. Make sure that you've got this, and that handling compromise of your OT systems is part of your incident response/DR playbook.

Cyber resilience is not just about keeping IT systems running. When a cyberattack affects doors, ventilation, and air conditioning in a hospital, cybersecurity quickly becomes an operational and potentially physical safety issue. Particularly in this case where the centre is under threat of physical violence, losing the ability to control their doors is a major safety concern. This is exactly why the EU NIS2 places such emphasis on resilience and incident preparedness. Organisations operating essential services need to regularly test whether they can continue delivering those services when technology fails, rather than discovering the answer during an actual attack.

Under the EU GDPR and UK data protection legislation, personal data relating to criminal convictions and offences is subject to additional protections. As a result, a breach involving this type of information could have a particularly serious impact on the people whose data ACRO is meant to protect. Outsourcing a security function does not mean outsourcing responsibility for it. ACRO had third parties providing security services, yet responsibility for identifying and monitoring critical security updates was unclear. "We thought the supplier was doing it" is not a convincing explanation to a regulator after a breach.

Outsourcing patch management does not outsource accountability. Every third-party security service needs an unambiguous owner on the customer side who knows what must happen, how quickly, and how completion is verified. Sadly, "the vendor handles that" is not a control.

When you outsource security/patching, you do need to allow improvements to be made. Even if you just hire an assessment, that report isn't intended to just look good on the shelf; you need to act on it. Business system owners don't like downtime, but they like having their data exfiltrated or altered even less. Work together to find a palatable way to do regular updates, and your credibility will build over time with a smooth experience. Avoid unnecessary fire drills; play to win the long game.

Network segmentation saved the day here, but it doesn't replace the need for critical hygiene like patch management. If you outsource patching to a third party, auditing their work is non-negotiable. Secure configuration is another vital control — while not highlighted in the report, system misconfigurations remain a top initial access vector for attackers. Hopefully this reprimand serves as the necessary catalyst for ACRO to uphold an appropriate standard cyber duty of care for the sensitive records they protect.

It's really tempting to go apply the tools and techniques you just learned at a conference or class, and an airplane feels like a target-rich environment/opportunity. It's also a bad idea: We're talking a closed box with no exits that is heavily regulated and involves real consequences for disruption, including fines, prison times, arrest, and the possibility you could wind up on TSA's No-Fly List. As the rogue hotspot was itself online, and as they have a validated list of passengers, it shouldn't be too hard to see which accounts were (still) online during the incident and track back to the hacker. Remember those sessions on ethical hacking? I'm having flashbacks of my instructors like Ed Skoudis and Larry Pesce reminding me about approved scope, permission, and keeping activities legal.

I was very disappointed to hear about this incident. I was at DEF CON myself, and one of my Counter Hack teammates was actually on this flight heading home, although he didn’t notice the Wi-Fi issue at the time (he was probably catching some much-needed sleep after the con!). Some people may dismiss this sort of thing as silly hacker hijinks, but deliberately interfering with communications aboard an aircraft is a serious matter. Beyond the immediate disruption, incidents like this damage the reputation of the hacker community, reinforcing exactly the stereotypes that so many ethical hackers have worked hard for decades to overcome. Curiosity, experimentation, and pushing boundaries are wonderful parts of hacker culture. Messing with systems on a commercial aircraft crosses a line, in my estimation.

It does not help when major AI companies just the week before bragged about breaking all the rules of ethical testing. But remember that you will probably never be a better pentester than AI. So let's focus on being better humans, and not violate the universal "don’t be an idiot" rule.

To quote Spiderman's uncle Ben, "With great power comes great responsibility." There is an important difference between security research and interfering with systems you do not own or have permission to test. Being able to do something does not mean you should do it. Responsible security research requires clear boundaries, permission, and, occasionally, the common sense to know when to leave the laptop in the bag.

Obvious stupid behavior, but also a good indicator to both DEF CON (a $10M+ revenue event) and the airlines who charge hefty Wi-Fi fees to do a better job both protecting their customers and having logging/auditing capabilities to support law enforcement efforts to go after vandals and criminals.

Testing cyberattack theories on a privately owned network — especially an aircraft in mid-flight — is reckless. Attending a top-tier hacking conference and wanting to apply what you’ve learned is understandable, but that experimentation belongs strictly in a controlled lab environment. Hopefully they face the full legal consequences for their actions.

This is a good proactive step by Mozilla. Even with nominal exposure, revoking and replacing the signing key immediately renders the use moot. So, make sure that you've got the new signing key in your GPG signatures — if you're using RPM packages or manually verifying GPG signatures, this means you. The steps are pretty simple and easy to push out/automate: erase the key from rpm, import the new one, and clean up the caches.

The disruption should be minor. This will only affect users installing Firefox and Thunderbird from source, and maybe some users using RPM. Everybody else should be good. Mozilla did the right thing by rotating the key when it was exposed, rather than waiting until it was proven compromised.

Revoking the exposed key was a smart, necessary move by Mozilla to prevent potential harm. Thankfully, most users won't notice a difference, and updating to the new key is a simple fix for those who do. Hopefully Mozilla releases an after-action review so the community can learn how to prevent this moving forward.