{"id":17812,"date":"2020-02-25T07:21:07","date_gmt":"2020-02-25T15:21:07","guid":{"rendered":"https:\/\/www.palada.net\/index.php\/2020\/02\/25\/news-11545\/"},"modified":"2020-02-25T07:21:07","modified_gmt":"2020-02-25T15:21:07","slug":"news-11545","status":"publish","type":"post","link":"http:\/\/www.palada.net\/index.php\/2020\/02\/25\/news-11545\/","title":{"rendered":"\u2018Cloud Snooper\u2019 Attack Bypasses Firewall Security Measures"},"content":{"rendered":"

Credit to Author: Sergei Shevchenko| Date: Tue, 25 Feb 2020 13:30:43 +0000<\/strong><\/p>\n

\n

In the course of investigating a malware infection of cloud infrastructure servers hosted in the Amazon Web Services (AWS) cloud, SophosLabs discovered a sophisticated attack that employed a unique combination of techniques to evade detection and that permits the malware to communicate freely with its command and control (C2) servers through a firewall that should, under normal circumstances, prevent precisely that kind of communication from reaching the infected server.<\/p>\n

We have published an in-depth report on the attack<\/a>, which we have named Cloud Snooper<\/strong>.<\/p>\n

Though we discovered the technique in use on AWS, the problem is not an AWS problem per se. It represents a method of piggybacking C2 traffic on a legitimate traffic, such as normal web traffic, in a way that can bypass many, if not most, firewalls.<\/p>\n

The complexity of the attack and the use of a bespoke APT (Advanced Persistent Threat) toolset gives us reason to believe that the malware and its operators were an advanced threat actor, possibly nation-state sponsored.<\/p>\n

The compromised systems were running both Linux and Windows EC2 instances.<\/p>\n

Anomalous traffic raises alerts<\/h2>\n

As often happens with incidents like this, our investigation started when someone noticed an anomaly. While the AWS security groups (SGs) were properly tuned, set up only to allow inbound HTTP or HTTPS traffic, the compromised Linux system was still listening for inbound connections on ports 2080\/TCP and 2053\/TCP.<\/p>\n

An analysis of this system revealed the presence of a rootkit that granted the malware’s operators the ability to remotely control the server through the AWS SGs. But this rootkit’s capabilities are not limited to doing this in the Amazon cloud: It also could be used to communicate with, and remotely control, malware on any server behind any boundary firewall, even an on-premises server.<\/p>\n

By unwinding other elements of this attack, we further identified other Linux hosts, infected with the same or a similar rootkit.<\/p>\n

Finally, we identified a compromised Windows system with a backdoor that communicated with a similar C2 as other compromised Linux hosts, using a very similar configuration format. The backdoor is apparently based on source code of the infamous Gh0st RAT malware.<\/p>\n

At this point in the investigation, we still have some open questions. For example, it is still unclear how the attackers managed to compromise the client’s system in the first place. One of the working theories is that the attackers broke into a server through SSH, protected with password authentication.<\/p>\n

High-level illustration<\/h2>\n

Before we start our technical description, let us provide a high-level view of the Cloud Snooper attack. Doing so might help the reader to get an overall idea of how its elements are related to each other.<\/p>\n

\"\"<\/a><\/p>\n

In the illustration above, our castle represents the targeted server infrastructure; In the case of the incident we investigated, the server was hosted by Amazon Web Services (AWS). At its perimeter, the AWS Security Groups<\/em> (SGs) – a set of firewall rules that provide security at the protocol and port access level \u2013 limit the inbound network traffic.<\/p>\n

For example, you might typically set up an AWS Security Group that only allows web traffic \u2013 that is, TCP packets that arrive at ports 80 or 443 \u2013 to reach your server. Network traffic with any other destination port never makes it past the SGs.<\/p>\n

The infection involves a rootkit that inspects network traffic, and a backdoor that the attackers leverage the rootkit to send commands to, and receive data from, the backdoor.<\/p>\n

In order to get around the firewall rules, depicted here as guards, the attackers communicate with the rootkit by sending innocent-looking requests (depicted in the illustration as a wolf in sheep’s clothing) to the web server on the normal web server ports. A listener that inspects inbound traffic before it reaches the web server intercepts the specially-crafted requests, and sends instructions to the malware based on characteristics of those requests.<\/p>\n

The listener sends a “reconstructed” C2 command to the backdoor Trojan installed by the rootkit. Depending on the commands included into C2 traffic, the attacker may use the backdoor to steal sensitive data from the target.<\/p>\n

The collected data is then delivered back with the C2 traffic. Only this time, the rootkit has to masquerade it again in order to bypass the guards: the wolf dresses itself in sheep’s clothing once again. Once outside, the C2 traffic delivers the collected data back to the attackers.<\/p>\n

During an entire operation, the normal web traffic, depicted as sheep, keeps flowing to and from the web server through the allowed gate. Visually, the C2 traffic stays largely indistinguishable from the legitimate web traffic.<\/p>\n

Dismantling the Cloud Snooper tools<\/h2>\n

As you will see from the description below, some samples that we collected are directly related to each other, while others belong to a completely different malware family. Nevertheless, all these samples were collected from the same infrastructure, and thus, we consider them part of the same toolset.<\/p>\n

The description starts with the Linux malware, then progresses into its Windows counterpart that is apparently based on Gh0st RAT.<\/p>\n

Overall, we discovered and studied 10 samples in the course of the investigation, which can be broken down as:<\/p>\n

The Cloud Snooper communications handler<\/h2>\n

The central piece of the attack is a file named snd_floppy<\/code> \u2013 a kernel module that sets up a network packet filter, using a Netfilter hook (NF_INET_LOCAL_IN<\/code> and NF_INET_LOCAL_OUT<\/code>).<\/p>\n

This component was instrumental in giving the malware’s operators the ability to communicate with the malware, despite the firewall protecting the AWS EC2 servers.<\/p>\n

The NF_INET_LOCAL_IN<\/code> is a type of hook that is triggered before the packet reaches the destination port.<\/p>\n

The installed hook handler inspects the socket buffer of every IPv4 packet, looking for a command concealed within a header \u2013 the command being the source port number of the packet originating from the attacker’s machine. These commands\/source ports can be one of the following port numbers: 1010<\/code>, 2020<\/code>, 6060<\/code>, 7070<\/code>, 8080<\/code>, 9999<\/code>.<\/p>\n

Firewalls typically prevent machines behind the firewall from receiving traffic sent to arbitrary destination<\/em> ports, but they don’t pay attention to the source<\/em> ports, because source ports are normally ephemeral, and not relevant to the server or the services it is hosting.<\/p>\n

In a typical cloud instance, the server may be set up to receive traffic from any IP address on port 80\/TCP (for HTTP) and on 443\/TCP (for HTTPS), so the firewall will let any traffic to those ports through to the server. So long as the traffic coming in to one of these standard ports fits the pattern the communications handler is looking for, it will execute one of its built-in instructions. Anything else will be ignored, and the server will serve web pages as normal to browsers.<\/p>\n

For example, if the communications handler receives a TCP SYN packet with an origin port of 6060<\/code>, the malware will decrypt an embedded file that has been encrypted with RC4 (the key is ‘YaHo0@’<\/em>).<\/p>\n

It will then drop that decrypted file as \/tmp\/snoopy<\/code>, wait for half a second, and then execute it as a usermode application with the call_usermodehelper()<\/em> syscall. Immediately after that, it deletes the \/tmp\/snoopy<\/code> file, so the snoopy application remains running in memory with no physical file present.<\/p>\n

If the command is 9999<\/code> as a TCP SYN packet, the \/tmp\/snoopy<\/code> process self-terminates (in case killall<\/code> is supported by OS), by passing the following commands to call_usermodehelper()<\/em> syscall.<\/p>\n

\/bin\/sh -c \/tmp\/snoopy  rm -rf \/tmp\/snoopy  killall \/tmp\/snoopy  <\/pre>\n
NOTE: executing snoopy<\/code> again while it\u2019s already running has no effect; by using a file lock mechanism, snoopy<\/code> makes sure only one instance is running. If that happens, it will output:<\/p>\n
[ERROR] there is already a instance.  <\/pre>\n
Here is the logic of the NF_INET_LOCAL_IN<\/code> hook handler, which listens for SYN packets sent to the server, using the various source ports:<\/p>\n
if<\/span> tcp:      if<\/span> tcp.src_port == 6060:          if<\/span> tcp.flags == SYN:              drop_payload()        # drops\/runs snoopy<\/span>              return<\/span> NF_STOP      elif<\/span> tcp.src_port == 7070:          tcp.dst_port = 2080          adjust_tcp_checksum()          return<\/span> NF_STOP      elif<\/span> tcp.src_port == 9999:          if<\/span> tcp.flags == SYN:              kill_payload()        # kills snoopy process<\/span>              return<\/span> NF_STOP      elif<\/span> tcp.src_port == 2020:          return<\/span> NF_STOP      elif<\/span> tcp.src_port == 1010:          tcp.dst_port = 22          adjust_tcp_checksum()          return<\/span> NF_STOP      else<\/span>:          return<\/span> NF_ACCEPT  elif<\/span> udp:      if<\/span> udp.src_port == 8080:          udp.dst_port = 2053          adjust_udp_checksum()          return<\/span> NF_STOP  else<\/span>:      return<\/span> NF_ACCEPT  <\/pre>\n
And here is the logic of the NF_INET_LOCAL_OUT<\/code> hook handler:<\/p>\n
if<\/span> tcp:      if<\/span> tcp.dst_port == 7070:          tcp.src_port = 443        # or, 80 in another variant<\/span>          adjust_udp_checksum()          return<\/span> NF_STOP      if<\/span> tcp.dst_port == 2020:          return<\/span> NF_STOP      if<\/span> tcp.dst_port == 1010:          tcp.src_port = 443        # or, 80 in another variant<\/span>          adjust_udp_checksum()          return<\/span> NF_STOP      else<\/span>:          return<\/span> NF_ACCEPT  elif<\/span> upd:      if<\/span> udp.dst_port == 8080:          udp.src_port = 53          return<\/span> NF_STOP  else<\/span>:      return<\/span> NF_ACCEPT  <\/pre>\n
The Snoopy Module<\/h2>\n
snoopy<\/code> is a backdoor trojan that can be executed both as a command line tool and as a daemon (though it needs to be launched with the -d<\/code> flag for that). The backdoor’s internal version is 3.0.1-2.20170303.<\/p>\n
It opens HTTP and\/or DNS services on a compromised system, and allows tunneling of the traffic, operating both as a reverse SOCKS5 proxy server, and client.<\/p>\n
For example, the incoming control traffic can also be relayed to a different server.<\/p>\n
When run with -h<\/code> option, the tool prints the following syntax:<\/p>\n
Usage: rrtserver [OPTIONS]  OPTIONS:  \t-h  \t-d  \t-s IPv4[:PORT:{udp|tcp}:{dns|http|none}]  <\/pre>\n
Where:<\/p>\n
Explanation<\/h2>\n
To trigger the payload (snoopy<\/code>) activation, an attacker would send the following packet:<\/p>\n
\"\"<\/a><\/p>\n
Next, the snoopy<\/code> module would be accessed by the C2, using source port 7070 for TCP-based or 8080 for UDP-based control:<\/p>\n
\"\"<\/a><\/p>\n
On the way back, the NF_INET_LOCAL_OUT<\/code> hook handler rebuilds the packet again, to make sure its source port is restored back to the original port where the incoming packet was destined for. This way, the C2 traffic transparently flows through the port(s) allowed by AWS SGs:<\/p>\n
\"\"<\/a><\/p>\n
No other Netfilter hooks within the chain, such as iptables INPUT\/OUTPUT rules, will process the packet if the hook returns NF_STOP<\/code>. This appears to be the purpose of the TCP command 2020: to bypass other Netfilter hooks.<\/p>\n
In instances where the Netfilter receives inbound traffic with a source port of 1010\/TCP, it directs the contents to the Secure Shell (SSH) port, 22\/TCP. For outbound traffic we have seen two variants using either port 80 or port 443. This will allow for an SSH connection to step around an AWS SG with IP restrictions on traffic to port 22.<\/p>\n
Hence, the ultimate purpose of the snd_floppy<\/code> rootkit is to provide a covert control channel for the snoopy<\/code> usermode process, running on a compromised host.<\/p>\n
Such covert control channels can be established via any port allowed by AWS SGs, be it 80, 443, 22, or any other port.<\/p>\n
From the outside, the compromised system will show an unusually large volume of traffic that comes from the remote ports 6060, 7070, 8080, and 9999.<\/p>\n
But what is the snoopy<\/code> module? What does it do?<\/p>\n