French Telecom and Train Service Sabotaged; VMware ESXi Hypervisor Vulnerability; Patch ServiceNow Now

Distributed infrastructure like trains, power lines and communication lines are very susceptible to physical attack. As it is impossible to prevent these attacks, detection becomes even more important to prevent accidents. Luckily, it appears that the detection part worked, and nobody was injured due to the sabotage events.

Sometimes the weakest link in the IT security chain is low-tech physical attack. It's hard to defend against as you have buried cables, junction boxes, and buildings that house the IT equipment. In this case it appears to have been a coordinated attack for reasons yet to be disclosed.

Sabotage in the form of demonstration. Was this part of your risk assessment?

These fibers were not easily reached, the vandals did their homework on the location and impact of the cuts. Regardless of the motivation, make sure you donÕt still rely on security by obscurity, that even hard to find locations are as secure as those which aren't. Then assess your ability to affect service restoration in these areas to make sure you can still meet RTO.

This attack was intended to disrupt the opening of the Paris 2024 Olympics. Speculation is that it took place outside of Paris because of the security measures in place in Paris. In the modern world, one cannot rely exclusively on perimeter security. The further out one pushes the perimeter, the more porous it becomes. Think layered security.

It turns out that if you take your control plane (or Tier 0) infrastructure and hook it into your Active Directory (in most cases Tier 1), you could have problems. In this case, according to Documentation dating back to 2012, all you need to do is create an AD Group called ESX Admins, anyone in this group is automatically an ESXi Admin. Being an ESXI Admin effectively means your infrastructure can be completely taken over. Your EDR? It isn't going to help you here.

There are three flaws being addressed, CVE-2024-37085, CVE-2024-37086, CVE-2024-37087, and they affect ESXi 7 & 8 as well as center cloud foundation 4 and 5 as well as vCenter 7 & 8. If you're not on the current versions, (ESXi 8, vCenter 8, Cloud Foundation 5) you're not going to have fixes for all three flaws. Note there only workarounds for CVE-2024-37085, which are applied after your ESXi host is joined to the AD domain. Deploy the updates.

The updates were applied to the hosted instances of Service Now, (Utah, Vancouver and Washington DC) and released for self-hosted instances to apply. Verify which category you're in, and that the patches are applied, you may be done. If you're on a SN version older than Utah, you need to update. The KEV due date for the updates is August 19th.

AssetNote conducted some interesting research and disclosed vulnerabilities in ServiceNow. Threat actors are taking no time to exploit these issues or find new ones. https://www.assetnote.io/resources/research/chaining-three-bugs-to-access-all-your-servicenow-data

The lessons learned from the Solar Winds compromise five years ago still apply - highly privileged apps (like system management, directories, etc.) will always be targets and will always need expedited patching and anomaly monitoring.

It's Apple update Tuesday, they released visionOS 1.3, tvOS 17.6, macOS 12.7.6, 13.6.8 & 14.6, watchOS 10.6, iOS/iPadOS 16.7.9 & 17.6 and Safari 17.6. The fixes are being back-ported to all the supported versions. You should be moving the macOS 12 systems forward as support ends when macOS 15 releases this fall.

Apple rarely makes patches available for older devices, creating a culture amongst users to upgrade as new OS versions become available. It's also worth noting that the table stakes must be sufficiently high for Apple to patch its third oldest OS version.

There is a natural conflict between backward compatibility and security. For this reason, Apple does not commit to backward compatibility. If you get it, it's a gift. On the other hand, Apple encourage users to stay current. (I am going to upgrade to iOS 17.6 as soon as I press send on these comments.)

Acronis is critical infrastructure. Monitor it closely, just like ESXi.

Hardcoded and default passwords are the gift that keeps on giving. We need to change the culture to cease using them. Add asking about their use to your vendor qualifications process, ensuring they can be changed or avoided. Also, make sure your team is changing/setting these for any install, Including a demo or POC. Per the KEV, you need apply the updates by August 19th.

Ugh, a vendor that still uses default passwords, a clear violation of Secure by Design principles. Users should change the default password, as they look to update the product. Separately, the company should move to instance-unique set-up passwords for all future versions of the product.

Not a lot of detail out to explain the over 3 month time to detect, but it sounds like the vendor may never have detected being compromised. Contracts with vendors handling sensitive/regulated information need to include terms of service around key security performance indicators.

It appears to be a simple 'smash and grab' using compromised logon credentials. What's troubling is that it took almost 90 days to determine that PHI/PII data was taken and another month for the data breach notice to be filed. It's also disconcerting that the data taken was stored outside our core systems, a failure of the company's data protection control.

In the light of SolarWinds, Crowdstrike, this and other recent events, many organizations need to rethink their management culture, philosophy, policies, methods, and procedures. Give special attention to where multi-party controls may be essential and efficient. Do single individuals have authority to execute transactions or make changes that put the mission, health, or life of the enterprise at risk?