Archive for July, 2010

That’s a quote I love, you hear it all over the net. Most people reversing software/hardware or people penetrating highly secure (or at least claimed) networks, state that most of today’s applications/hardware/networks can be compromised. Normally you see the vicious circle of stuff being released….hackers attempting to pwn it, vendors claiming it can’t be hacked, hackers publishing the hack. I might be exaggerating a little bit, but usually that’s the general consensus. Of course there are exceptions to the rule and there is hardware/software out there that hasn’t be hacked yet and maybe it really is NOT hackable. Today I wanted to write about one of those exceptions: Unidirectional networks. This post will cover the devices and answer the question if I believe their 100% claim, it will also cover some of my midnight thoughts on how to use alternative ways to maybe get data back even when such a device is in place. These ideas DO NOT BYPASS the device, so don’t get your hopes up, it are just possible ideas to use other vectors instead of routing your traffic through the secure device.

So this is one of those things that you don’t stumble upon until you are playing with it. When writing sniffers you can use libpcap or it’s win32 version winpcap. Now that doesn’t really do the job in all circumstances, since sometimes you don’t want to install an additional library. Lucky for us you can also sniff traffic by using raw sockets(I’m assuming win32, for the rest of the blog entry). Usually when sniffing with raw sockets you are looking for something specific in the stream of data and can just output it to a good old plain text file…however sometimes you’d just like to capture everything that comes through the network interface. That’s when it becomes interesting to save packets in the PCAP format, so I decided to write my own quick & dirty implementation.

Now here comes the fun part, when sniffing the packets you get everything above the Physical Layer. This means that the Ethernet header is lost and you directly receive the IP header. I did not realize this until I had written the packets into a PCAP file. When trying to open the file with Wireshark, it tries to interpret the first bytes as a Ethernet header which fails horribly. So I came up with two possible solutions:

Tried this for a while, then decided to go for the second option just for fun.

Add a fake Ethernet header to each packet.

As previously stated this was the final choice

Well it worked like a charm, Wireshark correctly interpreted the packets and dissected the rest of the contents just as I was used to with normal captures. If anyone knows how to correct the problem WITHOUT writing the fake Ethernet header, by just configuring wireshark correctly DO share.

Here is one last and small warning/readme, before I post the src, for those wanting to play with raw sockets…I’ve noticed some weird behavior myself when testing the sniffer on Win7.

Under Windows 2000/XP (or greater), SmartSniff also allows you to capture TCP/IP packets without installing any capture driver, by using ‘Raw Sockets’ method. However, this capture method has some limitations and problems:

Outgoing UDP and ICMP packets are not captured.

On Windows XP SP1 outgoing packets are not captured at all – Thanks to Microsoft’s bug that appeared in SP1 update…
This bug was fixed on SP2 update, but under Vista, Microsoft returned back the outgoing packets bug of XP/SP1.

On Windows Vista with SP1, only UDP packets are captured. TCP packets are not captured at all.

On Windows 7, it seems that ‘Raw Sockets’ method works properly again, at least for now…

Well this is new for me, further developing a working POC. Like you all know, I love new ideas and POC development, but hate the further development of POCs. This time the Firewall DNS POC just didn’t cut it, it did what I wanted it to do, but it lacked some “usability” features. These are the added features: