Coming up this week on Breaking Badness. Today we discuss: A brief PSA. Netflix Autoplays Hacky SACK with Linux and FreeBSD, and Turns Out OilRig and Waterbugs Don’t Mix.
PSA: It has been widely reported from several news organizations, such as Yahoo News, Washington Post, and New York Times, that the U.S. Cyber Command launched a cyberattack against Iran. We are choosing to avoid a deep discussion on this topic because we really don’t know a lot about the attack itself. Having said that, if this attack has zero-days and attack designs that are anything like Stuxnet, then we all need to be ready for the proliferation of these TTPs to other actors across the Internet. I hope you didn’t plan any vacations this summer, because you could be busy.
Here are a few highlights from each article we discussed:
Netflix Autoplays Hacky SACK with Linux and FreeBSD
- These vulnerabilities are all in the TCP/IP stack. TCP/IP, Transmission Control Protocol/Internet Protocol, is the suite of communication protocols used to interconnect network devices on the Internet. These issues are not in the protocol design, per se, but in the implementations in the Linux and FreeBSD kernels.
- TCP sends data in “segments.” These segments are numbered so that they can be connected together when received. TCP SACK is short for “Selective Acknowledgement” and is a way that a data receiver can tell the sender about the data segments that they successfully received and those that were missed or dropped. SACK helps the sender be able to resend only the specific segments that receiver missed. SACKs are used to make TCP communication more efficient especially over noisy transmission channels.
- In SACK Panic, a malicious data receiver could send back specifically crafted SACKs to the data transmitter, claiming to have lost many segments. If a Linux box susceptible to SACK Panic receives too many of these requests, a buffer overflow will happen inside the kernel, specifically in the TCP/IP SocketBuffers data structure. The machine Kernel Panics and crashes. Hard.
- This means that a remote attacker can arbitrarily crash a Linux server by sending it a small number of specially crafted SACK messages. To be clear: there is no privilege escalation or information leakage associated with SACK Panic, it just causes crashes and slowness.
- All versions of Linux greater than 2.6.29 (released in 2009) are vulnerable. If you have Linux in your environment that you sent up any time in the last 10 years, you probably care.
- SACK Panic is the worst of these vulnerabilities as it causes the machine to crash, but the two other related vulnerabilities are also nasty.
- In the first variant, called “SACK Slowness”, maliciously crafted SACKs don’t crash the machine. Instead they fragment the TCP queue in the Kernel. This fragmented queue is very inefficient to process, causing the machine’s CPU to work harder on networking tasks than it normally would. This can lead to a slowdown of the machine as a whole and a potential Denial of Service condition.
- In the second variant, called “Excess Resource Consumption Due to Low MSS Values”, the attacker again sends maliciously crafted SACKs. The difference here is the use of artificially low MSS values. MSS, as a reminder, is a parameter set in the TCP header of a packet that specifies the total amount of data contained in a TCP segment. So, by setting this value low, the attacker is saying, “Hey, I need all of this data transmitted again, and I need it all in very small chunks”. The means the server has to send many small packets to handle the SACK request. This dramatically increases the required bandwidth needed to send the same amount of data, creating load on the CPU and NIC, causing a Denial of Service condition.
- While it seems that SACK Panic is worst of the three in that it causes the machine to crash, don’t discount the effectiveness of these two variants. When attempting to diagnose these issues, one could be fooled into thinking it’s bad network equipment forcing the retransmissions and not a bad actor trying to degrade your network.
- Netflix has a dedicated cybersecurity/information security team. How cool is that?
- It’s estimated in the Global Internet Phenomena Report from Sandvine that Netflix consumes 15% of the total downstream volume of traffic globally, and can spike upwards of 40% during peak watching hours, especially in the US and Europe. Given the sheer volume of traffic involved, it’s not surprising that Netflix cares very much about TCP/IP, streaming data over TCP/IP, and using SACK to transmit data efficiently. It’s easy to imagine them being bitten by these vulnerabilities and investigating them.
- Netflix themselves created patches to fix these vulnerabilities (again, Netflix FTW! First we get new Voltron, Stranger Things, and the network testing framework ChaosMonkey, and now linux kernel patches?).
- Versions of these patches have been reviewed and merged into recent stable Linux kernel releases. RedHat, Ubuntu, FreeBSD and others have all released patches.
- As a side note, macOS is based on FreeBSD, but with a different kernel. It is not currently known if it is susceptible to this attack. Also, Linux-based firewalls and load balancers are susceptible as well. Patch early, patch often.
- For mitigation pre-patching: SACK is optional; one mitigation strategy is to turn it off. This is done at the cost of network efficiency, however, as many more retransmissions of data are required to complete the transmission stream.
- Netflix has their original write up on the issues. CVEs also have been issues for these vulnerabilities with links to discussion and mitigation techniques. Finally, RedHat has an excellent writeup and summary of these issues.
Turns Out OilRig and Waterbugs Don’t Mix
- Russian La la la Guy
- First of all, Turla is a very well-known APT group likely associated with Russia. They’ve been around since at least 2014 and are known for targeting the government sector. They’re also known for having really sophisticated tools and for being crafty in their methods, including using satellite link internet for their C&C infrastructure and spreading campaigns across multiple methods (ie, spear phishing and watering holes) to ensure the widest distribution of malware. Turla has actually been so active over the past 5 years that I have to gloss over the highlights of their work in order to spend time deep diving into their most recent campaigns – but just know that Turla is no stranger to conducting high-level espionage campaigns.
- So now to the story at hand from Symantec – the first wave used a new backdoor called Neptun, which is installed on Microsoft Exchange servers and is designed to passively listen for commands from the attackers. It can also download tools, upload files, and execute shell commands. During this campaign, Turla seems to have actually taken over and used infrastructure previously used by the Iranian APT OilRig (APT 34).
- The second campaign used Meterpreter, which is a tool that Turla has been known to use in the past as well. This version of Meterpreter was disguised as a .wav file to try to avoid detection.
- The backdoor used in the third campaign seems to have been derived from PowerShellRunner, which is a publicly available tool used to execute PowerShell scripts without using powershell.exe. Like Meterpreter in the second campaign, this backdoor was designed to evade detection.
- Besides the three tools used in the aforementioned campaigns, Turla has been using a lot of custom or modified, publicly available tools. Symantec noted that the group had made a shift towards “living off the land,” using sysinternal tools like PowerShell. This is a trend that seems to be popular among many APT groups.
- Of note, Turla used a few new tools including: “A custom hacking tool that combines four leaked Equation Group tools (EternalBlue, EternalRomance, DoublePulsar, SMBTouch) into a single executable. A USB data collecting tool that checks for a connected USB drive and steals certain file types, encrypting them into a RAR file. It then uses WebDAV to upload to a Box cloud drive. Publicly available tools such as IntelliAdmin to execute RPC commands, SScan and NBTScan for network reconnaissance, PsExec for execution and lateral movement, and Mimikatz for credential theft, and Certutil.exe to download and decode remote files.”
- One thing I really loved about the Symantec report on this activity was that there was a whole section devoted to identifying victims. I’ve noticed a trend in infosec reports that just talk about the technical aspects of malware, which is cool, but seem to leave out a lot of intelligence information like victims, etc. So I was happy to see that from Symantec this time.
- It looks like these campaigns from Turla were targeting government organizations, as well as the IT and education sectors. This is in line with previous Turla campaigns – they’re known for targeting government organizations In particular, since 2018, it looks like Turla has targeted the following:
- The Ministry of Foreign Affairs of a Latin American country
- The Ministry of Foreign Affairs of a Middle Eastern country
- The Ministry of Foreign Affairs of a European country
- The Ministry of the Interior of a South Asian country
- Two unidentified government organizations in a Middle Eastern country
- One unidentified government organization in a Southeast Asian country
- A government office of a South Asian country based in another country
- An information and communications technology organization in a Middle Eastern country
- Two information and communications technology organizations in two European countries
- An information and communications technology organization in a South Asian country
- A multinational organization in a Middle Eastern country
- An educational institution in a South Asian country
- It is certainly interesting that Turla seems to have taken over some of OilRigs infrastructure for this campaign, especially since they then used that infrastructure to infect OilRig’s network. Since Turla is associated with Russia and OilRig is associated with Iran, it doesn’t seem likely that these two were working together (if the whole “infected network” thing didn’t scream that loud enough), so it really does just seem like Turla was being opportunistic in this takeover. That doesn’t really surprise me so much coming from Turla, since they’ve consistently put the “A” in “APT” for the past 5+ years.
- This isn’t the first instance of APT-on-APT violence— there’s been instances of two APTs from the same country tripping over each other unknowingly trying to hack the same targets (this has happened to North Korean and Russian groups), and notably there is evidence that a Chinese group one time took over Russian infrastructure in a campaign to get information from that group. This particular instance though seems less targeted and more opportunistic than these other examples, so it’s fun to see APT groups being creative in their work.
This Week’s Hoodie Scale
Netflix Autoplays Hacky SACK with Linux and FreeBSD
[Emily]: 1/10 Hoodies
[Sean]: 2/10 Hoodies | 4/10 Goodies for Netflix
Turns Out OilRig and Waterbugs Don’t Mix
[Emily]: 7/10 Hoodies
[Sean]: 7/10 Hoodies
That’s about all we have for this week, you can find us on Twitter @domaintools, all of the articles mentioned in our podcast will always be included in our blog. Catch us Wednesdays at 9 AM Pacific time when we publish our next podcast and blog.
*A special thanks to John Roderick for our incredible podcast music!
