Cатсн²² (in)sесuяitу / ChrisJohnRiley

“Built around a fictional average company network, we will tell the story of an attack making use of subtle bugs across the layers all of which are as of yet undisclosed. This will include a bug in an Ethernet-driver, which allows an attacker to bypass MAC- and IP-based filters, bugs in TCP-implementations that are assumed to be fixed but aren’t, a web-cache which confuses itself and an instant-messenger, which was fooled by the protocol specification.

All of these bugs share a common property: They are a consequence of insecure coding-practices.”

Alone these bugs don’t achieve much, but when chaining them together and creating a jigsaw puzzle of attacks, it’s possible to construct an effective attack.

Stage 1: Attacking the clients

The client offers a huge variety of attack possibilities. However you need to target the attack to the specific system. What application do you want to exploit, how, what host system, what shellcode to use…. The first phase is information disclosure.

The application of choice for this demo is Pidgin emoticons. Using the MSN-SLP protocol, a client receiving an emoticon is able to request the graphic from the client by specifying the file to download. By replacing the name of the emoticon to fetch with a more interesting file (/etc/passwd springs to mind), an attacker can remotely retrieve the file. Adium suffers from the same issues as Pidgin as the issue replies on the underlying protocol and not the application itself.

This issue is less of an implementation issue, and more of a protocol issue due to the complexity of the protocol (for no reason).

Stage 2: Bypassing the internal packet filter

When trying to attack layer n, it’s always best to look at the lower layers to see if you can control or exploit them. Looking at  the link layer protocol for example, you see the typical MTU value of 1500 Bytes. Now that gigabit ethernet is coming to the enterprise, jumbo frames are supported (alongside the older 1500 MTU values). So what happens if somebody sends 2000 Bytes to a system that only supports 1500 ? Typically a controller will take the data and make it spam more than one receive buffer. However in some instances this might be the case. For example the e1000 Linux driver from earlier this year. It was fixed, but not really fixed !

When sending a frame that would normally be checked (i.e. a firewall) only the first part is checked, the second isn’t. This means that you can bypass the firewall rules, and send packets (and attacks) to systems behind it. 0-day !!!

Stage3: Poisoning the cache

Squid webcache, is also a DNS cache. This means that it’s vulnerable to the typical issues that standard DNS suffers from. Squid implements it’s DNS features independently of other DNS servers. Even though it randomizes the source port, the port is then statically assigned for the lifetime of the cache. Many layers of security are handed off to other systems (i.e. layer II protections).

By using NAT’s build in source-port protections it’s possible to fingerprint the port used by Squid.

When waiting for a DNS response, Squid constantly queries the next received packet. When it’s not expecting a response it caches responses until it makes a request. You can then put responses into the cache before even asking Squid to resolve. The first response wins, and you’ve given answers before the DNS server has even asked the question.

Squid is automatically setup to wait 2 minutes for a response. By performing a DoS on the firewall, you have enough time to poison the cache.

Stage 4: Denial of Service the Firewall

In 2009, a fix was implemented to the RTL Linux driver to re-enable the previously disabled hardware filtering on the NIC. By scanning possible MTU lengths, you can find the exact value that triggers the NIC to throw an error saying that multiple fragmented packets have been received, both of 8000 Bytes (this isn’t really possible). This will also cause garbage to be sent up the stack, instead of the packet contents. Lucky for us, the attacker can specify this garbage and control where the crash takes place.

More than just a Denial of Service, control over the remote machine.

Conclusion

• The security of a network component relies on the environment
• Security issues do not live in isolation – You never know the impact of a vulnerability until you see how it can be put to work

More information can be found on the CCC wiki