Someone get the mop, we have a data leak!

Corny titles aside, you might be surprised all of the ways that your “secure” internal corporate data can become unsecured public information by one disgruntled employee. Data leakage is when your internal corporate data is released to the public or anywhere else that is not in your control. This can be performed mainly in two ways, where the number of variants of each method can be virtually limitless.

• Physical removal of the data via hardcopy or softcopy on removable media
• Transfer of the data over the internet via email, FTP, SCP, etc..

Did I say limitless variants?! Yikes! So how do we prevent this? Well it’s rather unlikely that all of your employees will go under a strip search to validate that they do not have any paper shoved down there pants, but if we don’t allow access to those documents in the first place, and if we make sure they are properly disposed of (i.e shredded) when they are printed, it might be possible to limit some of our exposure

These physical threats are tricky issues that may never be fully solved, but they are extremely important to mindful of. In this post, we’ll focus on the non-physical side of data leakage. Right off the bat, lets disable the easy stuff:

• Discontinue the use of writeable CD/DVD drives on your client systems. There’s normally no reason for the average user to burn CD/DVDs. It might be a good idea that a manager or someone with a higher privilege to first filter this data before burning the data to disk. That is of course, you trust your managers.
• Disable USB/Firewire storage and removable media. You can disable USB all together if your company is not USB keyboard/mouse dependent.

These two basic things will force our mischievous friends to look at the internet as a means of transfer. On nearly every firewall/architecture review, I have one finding that states “Inadequate Egress Filtering”. Egress filtering is controlling the traffic leaving your organization, or traversing from a trusted to untrusted zone (i.e internal network to internet).

Although most companies I work with may or may not have a proxy server to scrutinize outbound traffic, they also have a ton of additional services permitted through the firewall, thus the “Inadequate Egress Filtering” finding. An additional problem that compounds this issue is the separation between the security staff and the firewall staff. This problem makes it hard for the security staff to accurately assess the firewall policy, and thus forces them to test these things on their own. To address this issue security staff can simply set up a host which has all ports open and place it on the internet. Use nmap to portscan the host:

nmap –sT –p 0-65535 [host]

What this will do is check which ports are allowed out through the firewall. There are some online services that will let you do this as well and even some messaging programs will have all ports open on their login servers. With the information presented by nmap, we can then get an idea of the existing potential areas for data leakage.

It’s extremely important to understand that any service can run on any port, which means that even the smallest allowance can permit someone to transmit data out to the internet. Let’s look at some common methods:

SSH Tunneling: Attackers can easily tunnel anything they’d like over SSH and as we mentioned, just because the default port for SSH is TCP/22, doesn’t mean it can’t run it on any other one. SSH can also be proxied, so application filters are even more important. Bottom Line: If an attacker can get SSH outbound, they can do anything!

DNS Tunneling: OzymanDNS (http://www.doxpara.com/ozymandns_src_0.1.tgz) can tunnel SSH over DNS! Yes, over DNS. So think twice about that permit udp any any eq 53, internal users should hit an internal DNS server which is responsible for its outbound queries.

ICMP Tunneling: If all else fails, attackers my try PingTunnel (http://www.cs.uit.no/~daniels/PingTunnel/), which as the name implies, allows SSH over ICMP! This kind of thing may make you think twice about allowing ICMP outbound to any host. If your network engineering staff really needs that as a tool, consider allowing ICMP only to particular hosts.

In an ideal situation, you’d have no outbound allowances without first being forced through a proxy server with application layer filtering. Even then, you only allow HTTP/HTTPS. You can then use a variety of software that will look for certain strings in HTTP/HTTPS or instant messaging sessions then ultimately notify you or prevent them from sending the data that matches. This is an excellent solution and should be deployed everywhere, for more information, Google “Data Leakage” and those applications will present themselves to you.

This isn’t meant to be fully comprehensive, but to just show the risks associated with the smallest allowance. If you can limit traffic outbound and scrutinize it where ever possible, you should be ok. Well”¦ that’s if you try not to think about employee EVDO cards or test DSL lines that terminate at employee cubicles. =]