If you’re a regular reader of Naked Security and Sophos News, you’ll almost certainly be familiar with Cobalt Strike, a network attack tool that’s popular with cybercriminals and malware creators.
For example, by implanting the Cobalt Strike “Beacon” software on a network they’ve infiltrated, ransomware crooks can not only surreptitiously monitor but also sneakily control the network remotely, without even needing to login first.
Indeed, if your network tools come up with a “Cobalt Strike” alert, we recommend that you investigate immediately, even if your cybersecurity software reports that it blocked and removed the rogue software automatically.
That’s because a Cobalt Strike intrusion means that someone was trying to establish a beachhead inside your network, perhaps for a ransomware attack, perhaps for a data heist, or perhaps for both…
…and if they got in once, it’s reasonable to assume that if you don’t find and close the door on them, they (or someone else) will break in again, because that’s quite literally what cybercrooks do for a living.
Unassumingly fitting in
The Cobalt Strike Beacon tool unassumingly pretends to be a web client, just like a browser or an official software auto-updater, and regularly calls home to a designated server using innocent-enough web requests, just like a browser or a legitimate auto-update tool.
But those call-home requests aren’t innocent at all: the computers they’re connecting to are known in the jargon as C&C servers, or C2s for short, where the Cs in the name stand for Command and Control.
Software implants that work in this way are generally referred to as bots (short for robots) or zombies, and they work well even on networks that have strict firewall rules to block incoming connections.
That’s because zombies don’t need to listen out for incoming requests, like web servers or SSH (remote login) servers do.
Instead, they use their innocent-looking outbound requests not only to upload data stolen from inside the network, but also to download the latest command and control instructions from their aptly named C&C servers at the same time.
Hotcobalt, the botnet beheader
Well, researchers at Sentinel One have just announced a brand new BWAIN – our shorthand for Bug With An Impressive Name – entitled Hotcobalt, which is a command processing bug in the Cobalt Strike server code.
The Hotcobalt bug means that a beacon that misbehaves – whether by accident or design – can crash the C&C server it’s talking to…
…thus stranding the botnet of zombies that are currently reporting to it, leaving them at least temporarily unable to take further commands.
Botnet, short for robot network, is the collective noun for a related group of bots or zombies that are all under the control of the same botherder or botmaster.
Bug or feature?
At this point, you’re probably wondering whether this should really be called a bug, given that it could be used to crash someone else’s server, or a feature, given that it could be used to disrupt cybercriminality by temporarily “beheading” an entire botnet in a single strike.
In fact, it’s officially a bug: it has the designation CVE-2021-36798, and was patched by the vendor on 2021-08-04 in Cobalt Strike version 4.4.
That’s because Cobalt Strike, for all its popularity with cybercrooks, is actually a commercial software package that’s sold as “threat emulation software” and is widely used by legally approved penetration testers and legitimate researchers.
(Cobalt Strike is not openly available for download, and not just anyone can buy it, but that hasn’t stopped the cybercrime community from acquiring it via theft or subterfuge and using it anyway.)
Trusting other people’s data
The bug was apparently caused by an easy-to-make programming error: putting too much trust in data received from someone else.
When exfiltrating a stolen screenshot, the Beacon program would transmit the image data as a 4-byte image size, followed by that many bytes’ worth of raw data.
The server would read in the size specification, allocate enough memory to handle the request, and then download the exfiltrated data into the memory block that it just created.
What the server didn’t do was to decide in advance whether the specified memory allocation size was reasonable or safe to use.
So, with 4 bytes (32 bits) to play with, a miscreant could create a battery of unofficial “here comes a screenshot” requests, each one asking the server to reserve up to 232-1 bytes (4GBytes).
Although 4GBytes isn’t considered a lot of memory these days (contemporary mobile phones, for instance, typically have 6GB to 8GB each), multiple requests to allocate 4GB will quickly bog down your server-side code, even on the beefiest hardware.
In 32 bits, you can’t represent the number 232 directly, because you can only represent 232 distinct values, one of which is 000..000, or zero. You can therefore count only as far as one less than 232 before your addition wraps back round to zero. To visualise this, think of the Y2K bug, where the year AD1999 was followed not by AD2000 but by AD1900 all over again. With just two decimal digits to play with, you could store 100 different values ranging from 00 to 99, representing 1900 to 1999. When you computed 99+1, you didn’t have the three digits you needed to “carry one” and represent 100, so you jumped back to 00, dramatically losing a century in the process.
What to do?
- If you’re a programmer, check untrusted inputs carefully. In networking protocols, many data fields are large enough to represent values well outside a sensible range for your program. Whether you’re checking for dates that are unrealistically long ago, iteration counts that would last unfeasibly long, or memory or file sizes that just won’t fit into reality, always remember to validate your input carefully.
- Assume that all inputs are untrusted. Apply the doctrine of zero trust, and assume that even inputs that come from what appears to be a trusted source, such as a computer on your own network (or a Beacon that’s calling home to your own server), may have been generated by software that contains bugs, or that has itself been compromised.
- Never ignore security alerts that indicate possible C&C activity. Few cyberattacks these days are caused by self-spreading, standalone computer virus attacks, where the virus itself is both the threat and the intruder. Automatic detection and remediation is no longer enough on its own. Aim to investigate any threat detection that could be the side-effect of an attacker who is already inside your network, in order to ensure that you address both the symptom and the cause.
- If you are a legitimate Cobalt Strike customer, you’d better update. The version that fixes this bug was released on 2021-08-04 and is numbered 4.4.