On the SolarWinds Breach
Where to begin. It’s almost impossible to comprehend what the fallout of this breach will be in the immediate to medium term; in fact, there isn’t enough information out there yet to conduct an effective post-mortem so to speak.
One thing is for certain - organisations are going to be wary of trusting ‘technology solutions’ from vendors. This isn’t to say that SolarWinds (and FireEye) did not have adequate measures in place; just that breaches are inevitable and organisations that rely on technology vendors are also dependent on these vendors having adequate controls in place alongside stringent self-audits. Organisations out there that trusted SolarWinds to push Orion to their networks in effect trusted that SolarWinds had a strong handle on their security posture. In Australia, CPS 234 mandates that APRA-regulated entities will need to have information security measures in place and includes cybersecurity assessments by independent assessors. Obviously, the effectiveness will boil down to the thoroughness of the assessor.
All this gets more complicated when you start to look into how the breach occurred in the first instance. It is starting to increasingly seem like hackers leveraged widely-used protocols and solutions. Ars Technica has a fascinating report referencing security firm Volexity, who encountered the same attackers in 2019; at the time, they bypassed MFA protections for Microsoft Outlook Web App (OWA) users.
Toward the end of the second incident that Volexity worked involving Dark Halo, the actor was observed accessing the e-mail account of a user via OWA. This was unexpected for a few reasons, not least of which was the targeted mailbox was protected by MFA. Logs from the Exchange server showed that the attacker provided username and password authentication like normal but were not challenged for a second factor through Duo. The logs from the Duo authentication server further showed that no attempts had been made to log into the account in question. Volexity was able to confirm that session hijacking was not involved and, through a memory dump of the OWA server, could also confirm that the attacker had presented cookie tied to a Duo MFA session named duo-sid.
Krebs on Security has a great write-up with a sobering quote from the DHS’s Cybersecurity and Infrastructure Security Agency.
CISA’s advisory specifically noted that “one of the principal ways the adversary is accomplishing this objective is by compromising the Security Assertion Markup Language (SAML) signing certificate using their escalated Active Directory privileges. Once this is accomplished, the adversary creates unauthorized but valid tokens and presents them to services that trust SAML tokens from the environment. These tokens can then be used to access resources in hosted environments, such as email, for data exfiltration via authorized application programming interfaces (APIs).”
The CISA goes on to advise that if an org identifies ‘SAML abuse’, mitigating individual issues might not be enough; you’ll need to consider the entire identity store as compromised. And unfortunately, the only remedy to that is building back identity and trust services from the ground up.
Additional Reading:
VMware Flaw a Vector in SolarWinds Breach?
SolarWinds hackers have a clever way to bypass multi-factor authentication
[FireEye Threat Research
