Five Eyes kills Russia’s Snake after FSB used weak crypto

Western intelligence and law enforcement agencies cracked a network of compromised computers running sophisticated malware for Russia’s FSB – which handles counterintelligence, internal and border security, counterterrorism, and signals intelligence – compromising the “Snake” cyberespionage implant, reverse engineering it and writing a tool called “PERSEUS” that effectively turned the malware against itself.

The multi-agency, multi-nation campaign stripped the FSB of a core toolkit developed over 20 years and a network that US officials said Russia had used to “steal sensitive documents from hundreds of computer systems in at least 50 countries, which have belonged to NATO member governments, journalists, and other targets of interest” and which it had “exfiltrated… through a covert network of unwitting Snake-compromised computers.”

The advisory was published May 9 after a court-authorised operation backed by nine Five Eyes agencies.

The FSB had deployed Snake “through nearly constant stages of upgrade and redevelopment” since 2003 it revealed. Investigators have spotted FSB operators “using Snake to its full potential, as well as FSB operators who appeared to be unfamiliar with Snake’s more advanced capabilities. These observations serve to illustrate the difficulty in using such an advanced toolset across various geographically dispersed teams…” it noted.

There’s probably lessons for CISOs here…

Developer error and cryptographic weakness gave the Five Eyes partners a “foothold into the inner workings of Snake and were key factors in the development of capabilities that have allowed for tracking Snake” the US’s Cyber and Infrastructure Security Agency (CISA) said in a  joint advisory published  May 8, which deserves close attention not just for those with an interest in geopolitics but in securing critical enterprise operations too….

CISA explained: “Snake’s top layer of encryption, called the enc layer, utilizes a multi-step process to establish a unique session key. The session key is formed through the combination of a Diffie-Hellman key exchange mixed with a pre-shared key (PSK) known to both parties… The overall establishment of the session key requires 12 communication steps, six in each direction, which involve sharing the pseudo-random values used in the Diffie-Hellman exchange process as well as custom aspects of the Snake session key derivation method.

“The session key is used to encrypt the command headers and (inner) encrypted payloads.”

But, the agencies explained, “the Diffie-Hellman key-set created by Snake during the key exchange is too short to be secure. The FSB provided the function DH_generate_parameters with a prime length of only 128 bits, which is inadequate for asymmetric key systems. Also, in some instances of what appeared to be rushed deployments of Snake, the operators neglected to strip the Snake binary. [Ed: When a program is compiled, the compiler adds extra information to the binary that make it easier to troubleshoot. This can be stripped out.]

“This led to the discovery of numerous function names, cleartext strings, and developer comments.”

A "large pre-computation for a prime"? NSA can help...

As Shaun Whorton, CTO, training firm Capture the Talent, puts it to The Stack: “The security of the DH protocol depends on the size of the prime number used in the process, i.e. if an attacker uses a prime number with a small bit length, the protocol becomes more vulnerable to exploitation. So, if the prime number used is only 128-bits, as it is in the case of the Snake malware, attackers can easily exploit the vulnerability and obtain the shared secret key used to decrypt messages and break the protocol. This is done by solving the discrete logarithm problem for a specific prime number, which attackers can do using tables they’ve pre-computed….”

Or, per an earlier write-up by the EU’s Computer Emergency Response Team (CERT-EU): “The current best technique for attacking Diffie-Hellman [DH] relies on compromising one of the private keys by computing the discrete log of the corresponding public value in the DH group. As mentioned above, this group – or the parameters to generate it – are previously shared in clear as part of the FCC domain parameters.

“However, an adversary who performs a large pre-computation for a prime p can then quickly calculate arbitrary discrete logs in that group, amortizing the cost over all targets that share this parameter. This attack takes advantage of the fact that an adversary can perform a single enormous computation [presumably not a problem for the NSA] to crack a particular prime and then easily break any individual connection that uses that prime. The attacker can start with the phase of the attack which only depends on the prime. This can be done in advance, which leaves only the second phase to be done on-the-fly for any particular connection…”

Snake malware network protocols reverse engineered...

Five Eyes response to the campaign was ultimately to reverse engineer the sophisticated network protocols used by the malware family, signature what network traffic looked like, and issue certain commands to malware implants on victim networks that met that criteria to nullify them (or, per the advisory, tell the “Snake implant to disable itself without affecting the host computer or legitimate applications on the computer.”)

CISA’s highly detailed advisory includes IoCs and guidance on detecting the highly elusive malware for potential targets. As the advisory notes: “Capturing and analyzing the memory of a system will be the most effective approach in detecting Snake because it bypasses many of the behaviors that Snake employs to hide itself. “With a memory analysis tool, such as Volatility, detection of a Snake compromise may be possible. Snake’s principal user mode component is injected into a chosen process via a single allocation of PAGE_EXECUTE_READWRITE memory. The starting offset is generally 0x20000000, however the module does allow for relocation if needed. Additionally, since the user mode component is not obfuscated in any way, a valid PE header can be located at the beginning of the allocated memory region. Further validation can be performed by confirming the presence of strings known to exist in the user mode component also within the memory region.”

Further details and guidance are available for security teams here.