Recent Atlassian Confluence and VMWare Vulnerabilities being Exploited; Updated Ivanti Guidance; Microsoft Breach

We have been seeing these attacks starting this weekend and quickly escalating since then. Luckily, I do not believe too many Confluence instances are still on-premise and active. Most customers have moved to Atlassian's cloud-based solution.

Attackers, seeing yet another Atlassian vulnerability, are actively hunting for vulnerable Internet-exposed servers. There are no workarounds on this one; you have to apply the update. Don't stop with the fixed version, go to the latest versions - Confluence Data Center and Server 8.5.5 (LTS) or Confluence Data Center 8.7.2 (Data Center Only). CVE-2023-22527 should be considered critical/CVSS Score 10.0, don't wait for the addition to the KEV catalog.

CVE-2023-34048, out-of-bounds write vulnerability, CVSS score of 9.8, has been exploited as far back as 2021. The detected threat actors target vulnerabilities on systems/services that don't typically have EDR. Aside from updating vCenter Server immediately, make sure that you're isolating access to only come from trusted systems and don't enable direct access from the Internet. You may want to do a check to make sure you don't have any vCenter Servers exposed. Services like Shodan, which are already scanning, make it easy to check.

We now know the vulnerability has been lurking around since 2021. VMware did the responsible thing by including patches for affected end-of-life products. That said, organizations should go ahead and update to the latest version of vCenter.

Patches should be available this week for the more recent versions of Ivanti Connect "Secure" VPN. Be careful if you rely on the mitigation provided by Ivanti. It works but is overwritten/disabled once you push a new configuration.

Secure CISA is asking agencies to report compromised services, requiring them to be removed from agency networks, initiate incident forensicating, as well as providing guidance for restoration of those services: reset the device, import the mitigation, then follow Ivanti's guidance for all compromised products. Leverage that process if you have a compromised device, regardless of being in the public or private sector.

Consider terminating encryption on the application, not on the perimeter, not on an operating system. Once set up, it is more convenient. Limits risk to one application rather than the enterprise. Hardware is cheap.

Last November Brad Smith, President of Microsoft, announced Microsoft’s Secure Future Initiative. A “Secure Future” can *not* include paths to corporate office email that relies only on reusable passwords for security. In the SFI announcement, Smith promised that “…over the next year we will enable customers with more secure default settings for multifactor authentication (MFA) out-of-the-box.” Replacing passwords with strong authentication has been done by many (though in this case, apparently not Microsoft) but needs the major IT platforms to make it easier to do and harder NOT to do.

This is similar to the attack on INL's Oracle HCM system. The lesson here is to make sure that you've got equivalent security on your non-production cloud services/tenants so information/access to them cannot be used to access your production services. Consider raising the bar higher by severely restricting access to those systems to only systems and users who are actively needed to perform that testing. Protect those environments as if they have production data, regardless of efforts to use de-identified/dummy or otherwise fake data; at some point developers will need to perform tests with live data.

We should remember that Microsoft are the victim of a crime here but it is disappointing that Microsoft fell victim to a password spray attack and the affected account did not have MFA enabled. This seems like a case of "Do as I say, not as I do."

What’s troubling about this report is that Microsoft appears to have failed in its most basic security practices. First, connecting non-production tenants to live services. Second, not addressing legacy accounts. It certainly looks like their new initiative, “Secure our Future,” is timely.

One more instance of an enterprise that offers strong authentication to its customers and users but fails to use it internally. Do not be one of those.

This is a tough one as the common denominator between the three councils is the use of Civica services for their IT and HR services through an East Kent Services partnership, whose website is currently down, and who claim the incident is not related to their systems. Consider how you'd resolve a similar situation. Do you have services identified to investigate outsourced services to run these sorts of claims to ground while still having sufficient resources to put your house back in order?

Managed Service Providers (MSPs) are being targeted as part of supply chain attacks. As such, MSPs have increased their awareness of cybersecurity as part of IT services offerings. While Civica claims it's unrelated, it ultimately comes down to the SLA established for outsourced services.

While Tietoevry immediately isolated the affected system and has prevented the spread of the Akira ransomware to other parts of their infrastructure, this still leaves many customers impacted until services are restored. Tietoevry is communicating to affected customers, and leveraging a well-defined recovery process. Even so, some customers, such as the Grannagården grocery stores were forced to close their doors, at least temporarily. This begs the question of having an operational plan for when critical outsourced services are offline, including how long you can continue with business as usual versus shutting the doors and hunkering down.

Both of the stories relating to the three UK councils in Kent and this attack in Finland how dependent many organisations are now on third-party providers. While this dependency may provide many business benefits it also introduces significant business risk. The days of managing security risk using supplier questionnaires are over and we need to look at more proactive ways to manage our reliance on third parties, how to better respond incidents that impact them, and how to ensure our business can continue in the event a third party provider is the victim of an attack.

Modern Solution claims the researcher worked for a competitor and was not doing independent research. Initially, the German courts upheld the researcher's claims, but ultimately agreed with the company. Two lessons here. First, read the fine print when doing vulnerability disclosure to make sure you're not going to have issues when you report. Second, don't store connection credentials in plain text. The 1990's are calling and want their code back. There are many frameworks for managing connections securely, there is no need to write your own.

In this case, two wrongs don’t make a right. First, it’s never a good security practice to store secrets (password in this case) in program files. Second, the researcher claimed to have insider information in the legal complaint. The IT services company should do the right thing, own the vulnerability, and praise the researcher for responsibility reporting it.

In addition to patching a number of vulnerabilities, Apple introduced a new "stolen device protection" feature with this update. The feature is not enabled by default. If enabled, additional authentication will be required if using security relevant features while the device is not in one of the usual locations. This prevents thieves taking over devices after they observed the victim entering the PIN/Password. Recently, many victims reported having their devices stolen in public places like bars after the thief observed them entering the passcode.

I get these messages and envision gathering all the devices from around the house and hit update and grab a cup of coffee, then I remember the enterprise. You're going to want to push these updates as soon as your MDM has the updated content. iOS/iPadOS 17.3 addresses 16 CVEs, iOS/iPadOS 16.7.5, addresses 12, iOS/iPadOS 15.8.1 addresses only 2 CVEs. If you're not already, subscribe to Apple's Security-announce mailing list to get all the details in your inbox.

Apple users should enable automatic updates.

MFA disabled “…because staffers were having trouble accessing the account” indicates an enormous failure in Risk Assessment and Risk Management at the SEC. Any meaningful analysis would have prioritized fixing the implementation problems that was causing the problems. See the Microsoft item above, attackers are now surely spraying compromised passwords across SEC email accounts.

MFA using SMS is often argued as being better than no MFA. But if your organisation is a high profile one and therefore likely to be a target, then you need to move your MFA to more secure means such as using an authenticator app on a phone or using a hardware token.

Make sure you have policies about disablement/bypass of MFA. While troubleshooting is sometimes required, make sure it's understood that MFA must be operating as soon as possible, doubly so with VIP and company accounts.