Blockchain Platform Vulnerability Used to Steal $300M of Cryptocurrency; DHS Cyber Safety Board to Look at Log4J; Open Source Security Foundation Initiates Open Source Vulnerability Detection and Mitigation Project

This is a fascinating vulnerability demonstrating how difficult it is to properly secure cross chain transactions. It is believed that threat actors noted a security fix being uploaded to GitHub that had not yet been deployed to the network. Most decentralized architectures will suffer from this issue where the publication of a security fix can lead to exploitation before the fix can be deployed to the network. One fix used previously has been to publish closed source patches, though this flies in the face of the open source movement (and probably violates licensing). It also exposes additional risk since the code can't be inspected. Think of how hard vulnerability management is in an organization where you own all the systems. Organizations underpinned by so-called decentralized networks will need to game plan out how they can securely provide updates to a network they do not control before this technology can be more widely adopted. Note: The varying totals for loss amounts can be attributed to fluctuations in the price of Ethereum at different times of reporting.

Jake Williams

This article is not surprising to me. At Neuvik, we are getting more requests to perform assessments on crypto platforms and marketplaces. We generally find that the bugs are not solely in the blockchain or the protocol stack, such as multi-sig attacks. Instead, the platforms suffer from the same bugs that standard web applications can have around authorization and the like. The major difference? There is a lot of money at stake, and the risk for loss is much higher than in traditional financial environments. Expect to see more of these as time goes on.

Moses Frost

This cross-chain bridge allows interoperability while maintaining the value of the Ether and Solana blockchains, in a one-to-one ratio. This means the recovery of the lost funds impacts the value of cross-chain tokens. In other words, no funds, no value. This is one of the riskier models for cryptocurrency exchange and may not be viable in the long haul. It will be interesting to see if the attempted laundering of the stolen currency can be detected.

Lee Neely

Good to see the CSRB get started but the first initiative (looking back at how Log4j vulnerabilities happened and were handled) while valuable does stray from the original vision to model the program after the National Transportation Safety Board and the Department of Transportation Office of Accident Investigation and Prevention that does hands on investigation of airline, train, bus etc. crashes. That approach has been very successful in determining root cause of incidents and driving, not just suggesting, real policy changes to avoid repeat incidents. Many good names on the board; I’d hate to see it turn into another government effort that issues high level reports vs. doing rapid response, hands-on incident analysis and forcing change.

John Pescatore

DHS has pulled in some heavy hitters, as listed in the DHS press release below, clearly positioning board for a successful outcome. One hopes the analysis of past events will lead to timely & relevant actions for future events. While Log4j is truly a huge deal and will take a very long time to truly put behind us, other issues such as ransomware, health care, and supply chain security may warrant priority due to their active and continued exploitation.

Lee Neely

This has the potential to become a fantastic resource. I hope the reports are similar to the 2018 congressional report on the Equifax breach. That is to date one of the best public write-ups I know of detailing the how and why of a breach. What made that report so effective is that it addresses not only the technical details, but also the human, strategic, and leadership issues that led to the problem - which is the root cause of so many breaches today.

Lance Spitzner

I like the approach: a very focused hands-on approach for a small number of critical open-source projects (Alpha); and a more scalable lighter weight approach to finding and remediating vulnerabilities in the large number of “long tail” open source software efforts (Omega). The predecessor to the Linux Foundation OSSF was their Core Infrastructure Initiative which back in 2014 did a good job of funding fixes for OpenSSL after Heartbleed but then fizzled out. Maybe this approach will avoid the previous problems.

John Pescatore

This will be interesting. Having greater awareness of issues for your open-source software can be both a boon and a burden as you figure out how to repair discovered issues. If your project meets the Alpha requirements, services provided will include analysis of security gaps, threat modeling, automated security testing, and supporting remediation activities. If you’re an Omega project, the focus is on automated tools for mass detection, even so, resources will be available for finding efficient ways to implement security best practices. This means you may see more updates in your CI pipeline, with the hoped tradeoff of fewer security issues overall.

Lee Neely

I am reminded that one of the root causes for the Colonial Pipeline breach was a VPN user reverting to a discoverable non-unique password. Is your scenario when your MFA tokens are lost/stolen/broken subject to similar risks? The actions taken by the German companies include invoking the “force majeure” clause in their contracts to free them from liabilities arising from the interruptions of services to customers. This is because with the level of automation involved, manual operation is not practical except on a very limited scale. Consider the scale of operations in a similar attack on your business and verify you have sufficient contract language or other agreements with your customers to manage side-effects of radically impacted service delivery.

Lee Neely

Analysts are claiming BlackCat is a rebrand of BlackMatter which was a rebrand of DarkSide (that ransomed and extorted Colonial Pipeline). Attribution matters and I am looking forward to more details on these attacks.

Jorge Orchilles

Routers/VPN appliances like this have been popular targets. Please expedite patching. These devices are often deployed in smaller branch offices which can make patching difficult to some.

Johannes Ullrich

There are no workarounds here; you need to update the software. Review the Cisco alert page for information on your product. As these are boundary control devices, you really need to jump on this. While interruptions to remote access services are never appreciated, neither is a successful intrusion. Make sure you have an active support contract so that you can not only apply security fixes but also keep them updated to current versions. Make sure that you are subscribed to Cisco security bulletins, and that they are tracked/acted upon.

Lee Neely

There are no workarounds here; you need to update the software. Review the Cisco alert page for information on your product. As these are boundary control devices, you really need to jump on this. While interruptions to remote access services are never appreciated, neither is a successful intrusion. Make sure you have an active support contract so that you can not only apply security fixes but also keep them updated to current versions. Make sure that you are subscribed to Cisco security bulletins, and that they are tracked/acted upon.

Moses Frost

The exploit leverages the SeImpersonatePrivilege user right (think run-as) which is available to local administrators and local service accounts, which means the attacker already has one of these accounts on your system. The best fix is to upgrade to a non-vulnerable version of ESET. There is a workaround to disable the advanced scanning via AMSI feature, which seems ill-advised in an endpoint security product. Use this only in situations where you cannot upgrade and can monitor those systems for maleficence.

Lee Neely

While the US and others are lining up to condemn the actions against the ICRC, the ICRC have taken impacted servers offline and are conducting forensics and remediating the issue. They have engaged outside security resources to help, and are also tracking for any data release, particularly on the dark web. The support from these agencies should help restore any loss of trust ICRC suffers because of the breach. More from the ICRC here: https://www.icrc.org/en/document/cyber-attack-icrc-what-we-know

Lee Neely

Not sure what the fuss is about here. NSO provided capabilities to be used by ethical governments. The general beef with NSO is how its capabilities have been used, not the fact that they exist. It is crazy expensive to develop implants and exploit capabilities against platforms like iOS and WhatsApp. If the federal government can buy those capabilities cheaper than they can develop them, they absolutely should. None of this should be taken to excuse the obviously vacant oversight by NSO on who its technologies were sold to and how they were used.

Jake Williams

We have all deployed pilots of software we’re investigating for broader use, and they don’t always work out. Make sure you clearly document the scope of the pilot, including any needed authorization from the provider, outcomes, and discoveries, closing it out fully if implementation doesn’t go forward to protect yourself from any claims of impropriety.

Lee Neely