Monday, December 14, 2015

On The Topic of Being Too 'Careful'

Hey everyone - We have seen a number of data exfiltration methods that hide data in plain sight.  Things like Twittor, IRC, Facebook, domain fronting, et cetera. Using services and protocols for purposes other than they were intended is nothing new (that last link was published in 2010).  As a network defender, your first reaction may be to block the protocol or service.  However, as more otherwise legitimate services and protocols are being used in this way, how do you draw the line?  If you are worried about Amazon Web Services (AWS) as a command and control (C2) channel, do you block all of AWS?  That could be problematic for your organization.  So where do you draw the line?

This post was inspired by yet another technique for exfiltrating data: via ICMP Echo Request and Reply.  The original article is here if you are interested.  The author uses scapy to listen for specially crafted ICMP echo requests that contain the interesting data.  You might not have known that there is any data in ICMP messages.  Let's take a brief look at how ICMP works.

The Internet Control Message Protocol is defined in RFC792.  It is mainly used for diagnosing connection problems, sending error messages back to a transmitting host, among other things.  Today, we care about Echo Requests and Replies (page 14 of the RFC):

Echo or Echo Reply Message

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   |     Type      |     Code      |          Checksum             |
   |           Identifier          |        Sequence Number        |
   |     Data ...

We see there is a data field which, if sent in the initial Echo Request message, must be sent back with the reply.  If you have ever done a ping, you might be wondering what it means when it says it is sending data, like this:

You can send whatever you want in the data field.  The data field allows the sender to make sure data is getting to the destination and coming back in tact.  Different operating systems have different default values for the data field.  Here is what it looks like on Linux:

As you can see, the data is mostly a keyboard walk across the number row of the keyboard.  On Windows, it is the alphabet:

To defend against arbitrary data leaving your network via ping messages, the authors of the article suggest:
We recommend that organizations block ping (i.e., ECHO_REQUEST and ECHO_REPLY packet types) all together. If that’s not possible, then at least block outbound pings to the Internet and Low security zone networks.
Other options are to limit the network/endpoints that can ping and/or limit the destinations that can be pinged at. This makes it harder for an attacker to just send pings to a random servers.
As far as compensating control goes, tracking ping packet sizes for anomalies and checking that data loss prevention products that are in place are capable of detecting assets within ICMP packets are good security best practices.

You could disable ping, but then you might lose an important diagnostic tool.   You probably do not need to be able to ping any host anywhere, so limiting the destinations of pings might not be a bad idea.  However, ICMP is just one protocol that someone could use.

Imagine a scenario where instead of ICMP, the attacker uses DNS.  It would probably not go over well if you disabled outbound DNS in your organization.  You could try blacklisting known C2 servers that are receiving the attacker's DNS requests with your data, but that is a cat and mouse game that could on forever.

Even though the protocols and services are standard, there is usually something anomalous about the implementation that can make these types of exfiltration techniques a bit more obvious.  In the ICMP example, if your organization only has Linux computers, Windows computers, and Cisco routing equipment, you could isolate the standard ping data and only allow that out.  If someone wants to ping from their OS/2 Warp machine or mobile device, they are out of luck.  For protocols where there is not a standard, you need to know what the protocol or service looks like in normal operation.  For example, abnormally large or small DNS queries might be a red flag.  DNS queries in rapid succession to the same server for the same host name might be strange.  Queries with non-alpha numeric characters (other than '-', '.' and the like) might indicate encrypted or base64-encoded data which is not normal for a DNS request.  Rules like this will not prevent all methods of exfiltration using DNS.  The attacker could use an 'average' amount of data that looks normal enough to fool your rules.

Defending against all such protocols is much easier said than done, and it requires an approach that goes beyond monitoring network traffic.  You might need to look at DNS queries or ICMP traffic to totally new places and isolate the source of that traffic instead of trying to go after the destination.  This requires having a base line of what 'normal' traffic is in your network.  I am not saying to log every DNS query  or every ICMP echo, but you could bin DNS queries leaving your network and log ICMP traffic that is coming from a place in your network that it should not be coming from.  Your users should not need to ping from their workstations, whereas your IT team might.  If you create bins of DNS queries, you do not have to log every query, but rather every unique host.  That still might be a lot, but over time, it will become obvious which hosts are part of normal traffic and which are new.

The decision to block services and protocols ultimately depends on how much risk you are willing to accept and how much you need that protocol.  No one can know that except those in your organization, and that is why knowing your network and its users is vital.

What do you think?  Have you ever run into a situation where you needed to block something you otherwise needed?  What did you do?

Thanks for reading!

No comments:

Post a Comment