English [Hack The Vote 2016] [Forensics 300 – More suspicious traffic] Write up

Description

We think our voting computers might be compromised! The Clinton campaign claims Trump is working with the Russians to rig the election. Our tech got a packet capture right before strange things started happening and isolated these packets. Our IDS didn’t flag anything, but take a look and see if you can find any hidden communications channels the Russians could use for command and control (C2). It would make the leaders of the free world look pretty bad if the Russians were the ones picking our president!

securefloridavotingboothtraffic

author’s irc nick: LtDan

Resolution

This challenge was really funny. It wasn’t a chall like “oh-no-another-pcap-where-we-need-to-extract-some-file-and-that’s-all”. As you can see, some russians are trying to to steal something, and we need to know what.

As usual, the first thing to do with a pcap challenge is to open it with Wireshark and to check what king of traffic we can have. Easy to do with the Statistics menu

protocol hieracrchy
protocol hieracrchy

There is almost only raw UDP packets. DNS and ARP packets are really useless here, because :

  • DNS is actually some MDNS packets
  • ARP and MDNS can’t be forwarded by routers
  • The attackers are from Russia
  • THERE IS AT LEAST ONE ROUTER BEETWEN USA AND RUSSIA

So, we can clearly forget it (altough the fact that we checked them, just to be sure 🙂 )

Well, now, let’s begin the fun part : analysing the raw UDP !

The request
The request
And the response
And the response

Every request and response are the same, so once we checked one, we checked them all. What can we see here:

  • The source is 192.168.2.1 and source port is 62056
  • The destination is 192.168.2.4 (which is NOT a russion IP, but nevermind 🙂 ) and destination port is 23284
  • The checksum is correct.
  • The request data is the base64 of “nottheflag” and response is the base64 of “ACK”
  • What you can’t se here (in order not to have huge screenshot) is that IP headers are correct (TOS, size, etc)

So everything in these packets is good, there is no hidden message in the structures.

The question is : “WHERE IS THE FLAG?!”.

Well, rapidly, we saw that there are actually two (and half) kind of messages:

  • Some times we have three requests followed by three answers (req/req/req/ans/ans/ans)
  • Some times we have six requests followed by six answers (req/req/req/req/req/ans/ans/ans/ans/ans/ans)
  • And only a few times, we have five requests followed by five answers (req/req/req/req/ans/ans/ans/ans/ans) or one requests followed by one answer (req/ans)

We tried multiple things with that, like transform it to binay (req = 0, ans = 1 or the contrary for example), but nothing worked.

After some time (and some beers fruit juice), we ran out of idea… until we saw a really really strange thing!

Timestamp for fun
Timestamp for fun
and profit
and profit

Did you see that? The timestamps are really weird aren’t it? In network communication, packets are supposed to be transmitted fastly, one after an another. But if you look closely at the first picture, you can see that packets #1 to #6 are sent at (about) 0 second. We have a 0.5 second delay, and then, packet #7 to #12 are send at 0.5 second. It’s actually everything but not a normal situation in networking (otherwise, you have some serious networking issues in your lan!)

Let’s now check the second picture: packets #25 to #30 are sent at 1.5sec, and there is a huge gap of 1.5sec before packet #31 is sent. Too weird to be normal.

And if… And if these gaps are related to the kind of sent and received messages? Like you know… MORSE CODE!

The (simple) idea is as follow:

  • 3*req/3*ans is considered as a dot
  • 6*req/6*ans is considered as an hyphen
  • 5*req/5*ans and 1*req/1*ans are considered as… bugs?
  • the 0.5 second delay is a dot/hyphen delimiter
  • the 1.5 second delay is a character delimiter

We began to decode it manually, just to be sure, and we saw the letters “FLA”. Like in “FLAG”!

Scripting some pcap parser was a bit too long and annoying, even if you know the power of Wireshark 🙂
Just go to the statistic menu to show the IO Graph!
After setting some values (Tick Interval to 0.1 sec and the pixel per tick to 1), we saw a very cool graph:

The best pcap graph ever!
The best pcap graph ever!

 

We then transcripted the short picks to dots and long picks to hyphens, translated from morse to ascii, and…

Flag was flag{h4ck7h3pl4n37}

 

Oh, and the 5*req/5*ans and 1*req/1*ans were actually bugs 🙂

5 thoughts on “[Hack The Vote 2016] [Forensics 300 – More suspicious traffic] Write up”

  1. Hello LtDan,

    Thanks for you answer, it’s always nice to have some author reviews!

    If you wan’t to make other pcap challs, please don’t hesitate, fun networking challenges are so uncommon 🙂

    Enjoy

    The lsd

  2. The 5*req/5*ans and 1*req/1*ans were not bugs. There’s some mdns and arp packet, wireshark calculate all. You need add filter such as “!(mdns) && !(arp)”.

  3. tshark -nr TH-CTP-Quiz09.pcapng -q -z io,stat,0.3 | grep “>” | cut -d”|” -f3 | sed ‘s/12/-/g’ -| sed ‘s/6/./g’ – | tr -d ” \n” | sed ‘s/00/ /g’ | sed ‘s/0//g’| sed ‘s/8/./g’ | sed ‘s/ / /g’| sed ‘s/1//g’| sed ‘s/2//g’

Leave a Reply

Your email address will not be published. Required fields are marked *