Sunday, September 27, 2015

Derbycon CTF Crypto Challenge

I tried avoiding the Derbycon CTF. I really did. With more than 18,000 flags available, I knew that if I got sucked in, I'd have to go all in for the weekend. But the allure was too much. I dedicated a few hours on Saturday to checking out a few of the challenges and ended up nabbing about 65 flags (with the help of a few others). The majority of my points came from the crypto challenge, which is all I'll be writing up today.

Discovering the challenge took a bit. On one of the hosts in the /16 scoped network there was a mocked up university website, pwnedu. In a subdirectory of the site was a list of faculty pages. One og the faculty had a few subfolders in their personal directory. One of these wasa folder called 'crypto' in the 'homework' directory. There were 3 files of interest here:

1) Assignment.cipher.txt
2) Assignment.plain.txt
3) secret.txt.

Two of these files, Assignment.cipher.txt and secret.txt were encrypted and thus unreadable. The other file, Assignment.plain.txt contained readable text, but the layout was... interesting.

In order to solve the challenge, you needed to decipher the encrypted message in the secret.txt file. The problem was that you had no information on exactly what was used to encrypt the message, or any key information. You had to figure out how to use the two 'Assignment' files to extract the secret message. Let's start with what we can actually read, the Assigment.plain.txt file. As I mentioned previously, the layout was interesting at first glance. Each of the words in the file seemed to be laid out in columns, which made it difficult to read. So I made a copy and stripped it down to understand what was written inside.

Stripping out the extra whitespace yielded the following:

For this assignment your task is to take on the role of a code breaker. 
You will use what we learned in class about crypto analysis , and some comon 
cryptographic operations such as XOR. 

You will also need to utilize your knowlege of block ciphers such as AES and 
DES and the various modes these ciphers can be utilized in , especially ECB or , 
electronic code book. It will also help to understand other modes such as 
CTR , or counter. An encoded copy of this assignment is provided. You 
must use this plain text to perform a know plain text attack. Comparing the 
content of this message with the provided cipher text copy will allow you to 
discover enough information to enable you to decipher the contnet secret.txt. 

Follow the instructions in secret.txt to reveal the FLAG. Come prepared to 
identify the flag in class Tuesday. 


A Cryptographers tale. 

Once a upon a time Alice had a message she wanted to send Bob. Alice did not 
want Jim to be able to read the message. She also need to send a meesage to 
Jim , that ideally Bob would not read. Alice decided the best solution was 
to protect her message with AES. Unfortunitly for Alice her computer is very 
slow and has no dedicated cryptographic hardware. It was a wire wrap hand 
built affir using individual transistors and a number of toggle switchs for 
input. 

Alice 's father was convinced all integrated circuits were bugged with listening 
devices and would not all Alice to have anything in the house that utilized 
them. He had not been right since the war. Alice accepted this though because 
she felt all the tin foil clothing he provided her was quite stylish , she 
liked her Sunday hat in particular. Things are what they are she thought. 

The letter she needed to send Bob was very long. After several long afternoons 
writing out her AES implementation in assembly , desk checking it two times , 
she was tired. Alice knew she should probably implement CBC or CTR modes but 
the thought of many hours ahead of her converting her assembly to binary before 
she could even start entering the program on the toggles lead Alice to decide 
to just go with ECB and hope Jim would not be able to break the code. 
Jim was the sort of idiot who could hardly count anyway. 

Alice finished entering her program and letters one character at a time. 
clearing the register each time. Finally Alice was able to send her messages to 
both Bob and Jim in relative safety. She skipped a number of spaces and 
punctuation to save time. 

Alice was so excited by Bobs reply she could hardly put it down. 


Alright, so there's a bunch of information here, but the key pieces to solving it are as follows: Block Ciphers, Electronic Codebook, and known-plaintext attack. When you're encrypting something using and ECB cipher, each block of data is encrypted individually with the provided key. This is different from other types of encryption modes like Cipher-Block-Chaining (CBC), where the result of encrypting the previous block are used when encrypting subsequent blocks. This means that, in ECB mode, if you have two blocks of data that are identical, the resulting ciphertext will be the same if the key used to encrypt the plaintext blocks are the same.

The original formatting yields the first clue. Each of the words is padded to 16 characters (128 bits), which is a typical block size. Any space not utilized by the letters of the word are filled with spaces. That means that when the message is encrypted, each word then becomes a separate block. We can use the contents of the Assignment.plain.txt and Assigment.cipher.txt to map a plaintext word to it's encrypted equivalent. To verify, let's take a look at the Assigment.cipher.txt. Here, I read in the file and spat out the ciphertext in hexadecimal representation, separated into blocks so I could match up the plaintext word to the ciphertext output.

The first word in the plaintext file is "For". Using the first block of ciphertext from the encrypted file, the result was "e2ca86791386af2771f05dc2fcb15eac". Unfortunately the word "For", including the capital F, doesn't show up again in the plaintext. Case matters! So another block was needed to compare. There are multiple instances of the word "for" in all lowercase in the plaintext file. And in both cases, the corresponding encrypted block showed up in the ciphertext file as "9973ea1b6d5fdec957798914dce2b09d". Progress!

Using that information, each plaintext and ciphertext blocks were then mapped out so that I could do a lookup to determine what plaintext word was being represented by the ciphertext block. 

With the hard part done, the decryption of the secret message was now possible. The process was something like this: read in each encrypted ciphertext block from secret.txt, and match the ciphertext hex output with the mapped file above. Which ever word matched the encrypted block was the same word in secret.txt. The plaintext content's of secret.txt were:

"count the number of times Bob, Jim and Alice are in the tale. the FLAG is Alice Jim Bob and the count of each with no spaces."

Therefore, the flag was AliceJimBobxyz where x y and z represent the number of times the words Alice, Jim and Bob appear in the Assignment.plain.txt file. A quick search yields the following: 12 instances of the word Alice, 5 instances of the word Jim, and 5 instances of the word Bob, resulting in the final flag of AliceJimBob1255 netting a cool 350 points.

Thanks to Anthony (@amillerrhodes) for helping me with the Python-fu required for parsing all the text for this challenge.

Wednesday, April 29, 2015

BSides Rochester Crypto Challenge

I suppose it's time to recap this year's crypto challenge from the BSides Rochester conference. One of my main goals this year was to solve the crypto challenge for the third straight year. As usual, there were a handful of us working together throughout the day. I was a bit concerned since we got started pretty late, plus I was presenting so we all took a break for that hour. In the end, we managed to solve it just as closing ceremonies started and I have to say, this was probably my favorite of the challenges so far.

Before I begin, I want to acknowledge that I didn't do this alone. It was a group effort, and I want to acknowledge everyone that helped contribute to cracking the code. In no particular order, this includes Anthony Miller-Rhodes (@amillerrhodes), Mike Burke (@securechef), Matt Lapinski (@_the_colossus), Colin O'Brien (@InsanityBit), and Austin Karn (@SynthVerity).

Darth Null (@darthnull) threw out some new stuff at us, and somehow we managed to skip a step along the way using some creative thinking. This one gets a little weird, but that's probably my favorite part of the whole experience. Anthony (@amillerrhodes) came through in a big way with his Python-Fu to script up some of the more tedious aspects of the challenge which is a big reason why were were able to solve it in time.

So, without further ado, I give you this year's walkthrough:

After some initial confusion as to where the first clue resided, we were told that to look at the main BSides Rochester webpage, which is shown below.

Our adventure begins!

Clearly, we're being pointed toward the large red "V" on the right side of the page. Clicking on the image just opened the image in a separate tab, but there was nothing that immediately stood out here.
What secrets do you hold?

My first instinct was to determine whether there was any information appended to the file that would point us toward our next clue. Running 'strings' on the image yielded the following:
$ strings 2015-02.png
IHDR
bKGD
pHYs
tIME
IDATx
--snip--
bsidesroc.com/D0noV4n

Bingo! A URL was hidden within. Following the link brought us to this next page:


We have our next clue stating that a very important message awaits us, but in order to do that, we have to first find out how the Resistance has been communicating. We can see from the Communication Record at the bottom that there are 6 messages that we're going to need to locate to move forward. Great, but what now?

Next I checked out the webpage source code to see if there was anything that was hidden from the final markup, shown below.
Sneaky, sneaky
At the very bottom of the page was a link to a 5 pixel wide image with a name of drop.png. Maybe this was our next clue? The hidden image ended up being some sort of barcode.
What are you?
We first tried scanning this with our various barcode scanner/QR scanner apps. Nothing seemed to be working. Being wholly unfamiliar with bar codes, it was off to Google to find out exactly what type of barcode this was. Unsurprisingly there was a website all about barcode information: barcodefaq. After reviewing the options listed there, we decided that the barcode was a PDF-417 barcode and located an app on our phone that could properly scan it. The result was another URL:  bsidesroc.com/D0noV4n/1429963200.png

Following that link we received this beautiful gray pixel image:




Alright, so what next? This is only one of six required messages. Well the image name looked a little interesting to me, very similar to a Linux epoch time. But what time and date does it result in? The command line will help us here:

$ date -r 1429963200
Sat Apr 25 08:00:00 EDT 2015

So the result showed that it was today at 08:00:00 EDT. But wait, we saw that time once before, in the Communication Record back on the /D0noV4n/ page where we started!
Moving right along now
So this is where the first leap came in. If the first message matched up to the current date and the first time entry on the Communication Record, perhaps the rest of the messages could be similarly retrieved. First we calculated the epoch for the second message based by using the current date and the second time entry from the Communication Record.

$ date --date="Apr 25 08:15:00 2015" +%s
1429964100

Then we attempted to retrieve the second image from the same directory using the resulting string using the following URL: bsidesroc.com/D0noV4n/1429964100.png

Message 2 / 6

It worked! The next step was to retrieve the rest of the messages using the same process. The resulting epoch strings were:
1429965000, 1429977900, 1429978800, and 1429990625. Which resulted in the following images:
Message 3 / 6

Message 4 / 6

Message 5/6


Message 6 / 6
Clearly message 6 was was different from the rest, but we opted to try and solve the messages in the order in which they were sent. But what to do next? My initial thought was to pull the RGB values from the pixels, and convert to hex and see what happened. Each of the boxes was set to a repeating RGB value, which with Anthony's help we extracting using a fairly simple image processing script. I had to modify it a bit for my system since I still use Python 2.7.9 but it's essentially the same. By running the script and providing it an image file, the resulting hex will be output.


$ python image_to_hex.py ./1429963200.png 
cf 87 ba 22 1c 16 50
69 db 73 16 34 42 48
14 30 6a 30 e1 73 51
ab 26 35 00 63 42 6d
02 82 30 df 25 6e 40
34 12 6b 7b 73 46 1f

2c f1 0e 1d 55 15 47

For the rest of the images, the process was the same and resulted in the following:

Message 2:
c0 8e d9 df 25 78 0c
71 bc 82 64 19 40 05
de 0c 40 1e 58 0b ad
86 78 68 01 61 0b 4d
0f 3c c7 b6 c8 57 7c
12 68 7b a6 1c ae 45
46 5d 28 7f 7f ef 16

Message 3:
56 06 c6 ff a2 82 8c
1e aa ba a2 9d 97 0a
e6 37 c7 26 6c ca 90
33 14 ed 02 06 28 86
76 00 c9 b7 f5 c6 e4
8a b1 12 83 d5 92 c1
63 41 e3 98 4e df 46

Message 4:
a2 e1 91 18 c9 86 5a
e9 fe ee bb e2 67 96
ca 19 a5 6e 01 fa 51
e3 82 29 03 a2 8e 1a
93 32 d4 fd 65 b9 d5
86 ea bd fa be f0 32
a0 60 55 cf 57 8f ac

Message 5:
d9 9a 52 43 16 e4 00
07 3a 1d 7c 63 cb f0
cc 8d 73 c7 f7 19 63
ab 42 63 04 04 ee f6
6b 96 76 33 01 36 11
75 a0 0a a9 80 fe 30
de f8 8e 6b bf 65 36

Notice that the center block of each image increments. I've bolded it in the output above. Since this this is the case on all of the messages, we decided not to include it as part of the key or ciphertext. We hit our first block here for a bit trying to figure out how to decrypt the text with no discernable key. Back to the main Resistance Page to hunt for another clue.

One thing that we found interesting on the Resistance page was the red V at the top. It was different from the initial V that we found on the BSides homepage, it was more... pixelated. 

As it turned out, the image above was 7 "pixels" wide and 7 "pixels" tall, which matched directly with our gray blob images. Our first mistake where was assuming that the blocks in red were our key and the rest were the ciphertext (excluding the predictable middle block). The initial math seemed to workout too, 49 blocks - center block = 48, of those, 12 were red and 36 were white. Using that, Anthony came through again with another script that would extract the red blocks to create a key, and decrypt each ciphertext block with the next red block. By repeating the key three times this should work! But it didn't

Darth provided another clue which referenced that the puzzle had some influences from a PoC || GTFO article. Digging back through the archive, we came across PoC || GTFO 0x03 which contained an article which detailed how to create a PDF file that could also be a valid JPEG. Further research showed that this could also be done using a PNG and ZIP file. So we downloaded the above PNG, renamed it as a .ZIP and extracted it. Yes, really. Try it with the image above.

By unzipping the image file we get an extracted img.png which looks like this:

A bit garbled, no?

It was a bit garbled, but gave us the information we needed to decrypt each of the gray blob messages. By using the information that we can read, we can logically deduce the proper order of the ciphertext and key blocks. As a visual reference, I've reconstructed what the original image likely looked like.

That's better
Note that using this method, there were 32 blocks of ciphertext in the four colors shown above along with 16 blocks which made up the decryption key. Here we ended up scripting the decryption of the first 5 messages by extracting the key and ciphertext blocks, XORing them and outputting the resulting plaintext. Running this on the five encrypted message resulted in the following plaintext:

Plaintext 1:
HaveContactedLeaderOfResistance.

Plaintext 2:
NeedExtendedChanForImportantMesg

Plaintext 3:
PleaseReplyWithReqdMethodAndKeyX

Plaintext 4:
Cols:0541378629.Alpha:AI.RST.ONE

Plaintext 5:
Checkerboard.Extra 0x2e and 0x21

Progress! But we were running out of time. We had that odd sixth message which consisted all of numbers, and the information in the five messages above provided the final clue as to how to extract our important message. In the fifth message there is a reference to a Checkerboard Extra. We all hit Google to try and figure out how to handle this. We came across information relating to a "Straddle Checkerboard Cipher" which is located here. We were fairly certain this was the proper method, but since no one was familiar with it, it took some time to figure out how to properly configure our board. All the information we needed was in the five plaintext messages.

With a Checkerboard you first create the top column layout, which consists of the digits 0-9 and can be in any order. Decoded message 4 above shows that this order is 0541378629. The next step is to determine how the rest of the checkerboard should be laid out which requires a key to make it unpredictable. Message 4 again shows how the alpha key row is configured: AI.RST.ONE

If we lay out the first two rows, they'd look like this:

0541378629
AI.RST.ONE

But what about the rest? Well with checkerboard ciphers, the spots in that first alpha row that don't contain letters become row identifiers for the rest of the alphabet. In this case column 4 and 8 didn't contain any of our A-Z letters, so they would become the next two rows in our checkerboard. We then populated the rest of the board with our remaining letters.

  0541378629
  AI.RST.ONE
4:BCDFGHJKLM
8:PQUVWXYZ

But wait, there are still two spots available? The fifth plaintext message explains what to use there, ASCII 0x2e and 0x21 which are . and !, respectively. Our final checkerboard cipher is as follows:

  0541378629
  AI.RST.ONE
4:BCDFGHJKLM
8:PQUVWXYZ.!

This is where I started cursing Darth's name. The sixth message contained 209 digits which mapped to a plaintext letter using our checkerboard cipher. One by one (or two by two), we went through the decryption to get our plaintext. As an example, the first row of number in the sixth message was: 

7 942428298191886298274707

Decryption works as follows. If the digit matches a letter in the first column, then take the resulting plaintext letter. Our first digit is 7, which maps to the T plaintext letter. This is highlighted below for clarity.

  0541378629
  AI.RST.ONE
4:BCDFGHJKLM
8:PQUVWXYZ.!

7 942428298191886298274707

We then move to the next digit, 9. Again, this matches the first row, so we can take the resulting plaintext letter, E.


  0541378629
  AI.RST.ONE
4:BCDFGHJKLM
8:PQUVWXYZ.!

7 9 42428298191886298274707
T E

That means our final message begins with "TE". But we hit a snag on the next number, it's a 4 and there's nothing that maps to a 4 on the first row, it's empty! In this case we go to the second row labeled with the 4 and use the next digit from our ciphertext, in this case it's a 2. Our resulting plaintext is an "L". 


  0541378629
  AI.RST.ONE
4:BCDFGHJKLM
8:PQUVWXYZ.!


 7 9 42 428298191886298274707
 T E L  

The next ciphertext digit is again a 4 followed by a 2, so we'll end up with an "L" again.



  0541378629
  AI.RST.ONE
4:BCDFGHJKLM
8:PQUVWXYZ.!


 7 9 42 42 8298191886298274707
 T E L  L

The next ciphertext digit is an 8, so here we need to go to the third row, and match up to column 2. The plaintext here is "." which we interpreted as a space in the plaintext.


  0541378629
  AI.RST.ONE
4:BCDFGHJKLM
8:PQUVWXYZ.!

 7 9 42 42 82 98191886298274707
 T E L  L  .  

The process continues in this fashion until our final, super important message is revealed:

TELL EVERYONE THAT THE LEADER IS A RED LECTROID FROM PLANET TEN! ITS A COOKBOOK! SOYLENT GREEN! YOU MANIACS! YOU BLEW IT UP! ROSEBUD

We were very happy to win the challenge again. Many thanks to Darth for creating the puzzle. With any luck he'll travel up to Rochester next year. We're looking forward to it.

See you all next year!

Saturday, April 25, 2015

BSides ROC 5 - Follow Up

First off, I really wanted to thank everyone that stopped by to check out my talk. I think I finally understand how to properly use the microphone, and I apologize for anyone that had trouble hearing me. That being said, I 'm posting below a number of references I've come across relating to helpful talks, videos, CTFs, Books, as well as hands on practice and challenge resources. In no particular order:

Talks:

Videos:

CTF Info:

Hands On Practice / Challenges:
Reference Materials:
If you know of other things that should be added to this list, let me know!

See you all next year!

Sunday, April 6, 2014

2014 BSides ROC / Crypto Challenge Write-Up

It's crazy to think that a year's gone by already since last year's BSides Rochester conference. I attended again this year, this time it was located at the German House, which I thought it was a solid venue to host the conference. And, while there were no remote control flying sharks, there was an A.R Parrot drone being flown around the auditorium most of the day (which a few spectacular crashes along the way). I had planned on going to a few talks this year, but I was again wrapped up in DarthNull's (@DarthNull) crypto challenge and Jason Ross's (@rossja) Hacker Battleship, so I was only able to see the keynote by Dave Kennedy, CEO of TrustedSec. I enjoyed Dave's talk about how people on the defensive side of IT need to be more well-versed in the things that the offensive people do, which would allow them to better understand how they might be able to lock down their networks more effectively. I also liked his method of sitting down with the "Blue Teams" during an engagement so that they can see what's going on and determine how their defenses are holding up, and, if an issue is found, how they might be able to address it. It would definitely be nice to integrate this technique on some of the future assessments and engagements I do.

As the conference drew nearer, I was looking forward to take place in the Hacker Battleship CTF, hoping that some of the issues last year were resolved. (About halfway through the competition last year someone seemingly found a SQL injection weakness in the scoreboard and took the game down for everyone.) It seemed to go more smoothly this year, but there are still some suggestions I would make for the future. It was difficult to determine which challenges were open for answer submission, even though the challenge itself was accessible to solve. I gave up attempting to refresh to see if I was able to submit an answer, and was busy anyway jumping back and forth between that at the crypto challenge. It's still a unique style CTF and would like to see it in future years at the conference.

One of my goals this year was to duplicate last year's success in solving the crypto challenge. I was happy to hear that Darth would again be creating the challenge as it was fun and challenging to solve last year. I wasn't able to partake much in attempting to solve his Shmoocon badge challenge, so I was really looking forward to this one. I was also curious to see how far I've progressed in the ~9 months or so that I've been looking into the history of crypto. This challenge, it turned out, was perfect for that.
During the opening ceremonies, we were given a link to get started: http://www.bsidesroc.com/KrYpT14/ On that page there was a single image, which I've copied below.



The briefing, from one Maj. C Hacker, alerts us that two bumbling spies, Yuri and Chris, have left a number of messages throughout the venue via their dead drops. Thankfully, they're not terribly well versed in crypto, and have made some serious mistakes while attempting to protect their communications. Alright, challenge accepted. The first goal was to find the messages, in order, and then attempt to decrypt them and figure out what these two were discussing. There were 10 messages in all, five "purple" messages depicting a message from Chris to Yuri, and five "red" messages from Yuri back to Chris. Once the opening remarks and keynote were over with, we went to work. The first message we found was Purple 1, which technically wasn't the first message in the communication stream, but it's what we had to go with. The message was as follows:

Jmvwx, ythexi csyv gmtliv - ex piewx gsqi mrxs xli wmbxiirxl girxyvc. Xlir ai ger xepo efsyx JVIRGL LSZIVGEJX sv alexiziv csy pmoi. - GLVMW

This immediately jumped out as a Caesar "encryption" due to the spacing looking intact, so I threw it into a Caesar decoder to see how easily this challenge would be starting out. Luckily, this turned out to be correct. The decoded message was:

First, update your cipher - at least come into the sixteenth century. Then we can talk about FRENCH HOVERCRAFT or whatever you like. - CHRIS

At first, I thought we had found the correct message, but after decrypting it, it seemed more like a response to another message. To find out, we would need the Red 1 message, which we didn't have yet. Thankfully, Chris capitalized "FRENCH HOVERCRAFT" which gave us some clues on the second message. I had a hunch that these messages would use more advanced techniques as time went on, but wouldn't know for sure until more messages were received. The second message we found was luckily right next to where I was sitting. The dead drop was located next to a number of electrical outlets but there was no apparent message in sight. It turned out that the message was stuck to the bottom of the spotlight used to illuminate the stage. We snapped a picture and got to work:



The encrypted message was:

AVZFZ IXEXM JOIRF PZKSH DCALL TCSUN TDFME UFVJK HADPV VYEDK LWIHV NRWFK LWNXY CKSZI LFZRF WXHUL AIMRJ QLTHB HQVRT TRCPM OWNGZ RYEWT WDVVV PKLDB AGPWV FFNFL JIGTK WIENG AVZMI NLNHA YCJQK JVYON ZHYSE VGLFR MODV

Again, my initial hunch would be a progression from Caesar to Viginere cipher. So this message was run with a key of FRENCHHOVERCRAFT but to no avail. Then we tried just FRENCH by itself and the HOVERCRAFT by itself. It turned out that HOVERCRAFT was correct and we had our second message!

THE BIGGEST CANNON I KNOW OF HURLS PUMPKINS OVER A MILE THEYRE IN DELAWARE IS THAT SUPER ENOUGH PS TURNS OUT CIA CAN CRACK THIS CIPHER APPARENTLY ITS USED ON A SCULPTURE IN THEIR LUNCH ROOM THEY JUST DONT PLAY FAIR

Again, this doesn't seem to make any sense after the first message, but we continued on. The second half of the message mentioned a CIA sculpture and something about playing fair. This was, of course, referring to the Kryptos encryption sculpture located at the CIA headquarters (more: here). The last two words stuck out for me, since I had done a project last semester about encrypting and decrypting messages using the Playfair cipher (here). My logical assumption was a Playfair encryption using a keyword of Kryptos. However, we were missing the Purple 3 message so I couldn't test my theory quite yet. We were also missing the Red 1-4 messages and we were all getting hungry. At this point we took a break to grab some food and hunt down some more messages. After a delicious sandwich, we had located Red 1 & 2 as well as Purple 3 & 4. Time to get back to work.
Since we had already cracked Purple 1 & 2, we decided to break messages Red 1 & 2 so that we could start piecing together the conversation. The Red 1 message was: 

Lipps. Tpiewi xs viwtsrh amxl qiwweeki hixempmrk csyv eggiww. - CYVM

Again, this looked similar to the Purple 1 message and was broken just as easily, yielding a decryption of:

Hello. Please to respond with message detailing your access. - YURI

The second Red message was:

ZDVWZ DFNTP DSVVV UVCZK LWVQE GVDTY KOOEJ QESZI LFXEE PFNX

Using the Viginere decrption and our special HOVERCRAFT key, this yielded a decrypted message of:

SPASIBO NOW WE ARE SECURE I AM NEED OF DATAS ON SUPER CANNONS

Now we were getting somewhere. The conversation between our two super spies started with Yuri, and then went to Chris. Since we had found the third purple message, I decided to test out my Playfair encryption / decryption tool. Here was the encrypted message:

CBEB ADYB LQKQ HYDF CBEB OBQG BMEI HRDF BOSH VLYS KQBI OVSL BRHS MDPK PTDS GABF KPRG ADYB LQYQ FSMX DQVL VFCE DKIE AVQK HQOQ TGLS ABFB LQAS AAAM SKCQ HVND WCEB


After decryption, which again was indeed a Playfair with a key of KRYPTOS, we had this decrypted message:


BAGS OF PAINT IF THE BAGS CAN HANDLE THE ACCELERATION SURE SPECIFY TYPE OF BAG TYPE OF PAINT MEANWHILE WE SHOULD SWITCH CIPHERS AGAIN SORRY FOR THE ZIG ZAGS


Solid progress, and so far each message pair used the same technique. The reference here to ZIG ZAGS implied a rail fence cipher. Since we had the Purple 4 message, this should be easy enough, but here we ran into our first problem, it didn't work! It appeared as though our spies were getting more cautious? Again, without the Red 3 and Red 4 message, we were stuck. Back to the hunt!


We managed to locate the rest of the messages with a little assistance from the BSides crew (as time was quickly running out). Armed with the rest of the messages, it was now a race against the clock. The third Red message also looked like a Playfair encoded message, due to the ciphertext being grouped in sets of four characters. Plus, we had already decrypted the third Purple message, so we knew that Yuri's response would probably use the technique that Chris mentioned in the Purple 2 message. The Red 3 ciphertext was:


EFMS YFSL LOLG SYIA QPBM OMML RDIA QPBM GGIG YSHH QKCR LVMN HSBM CQLE IBMG LKLV SYHF CBEB ADYB LQPZ


Which decrypted to: 


delaware is near montana i like montana and rabbits tell me can these on fire large bags of paint x

Six down, four to go!

Now that we had the fourth red message we could test the rail fence technique. The Red 4 message was an absolute pain to transcribe, but we did it. Here's the ciphertext:

P*h*tanlmIe**rIsE**e*uo*astte.FaeotAgcaba*slm-adbeiSTutL*oe.Is*rnort*ES.iio**kir*c**e*sur.*b?*mlypoOIm*Bctft*oceoY*piHUSn**epnr*t*Lslsssiepo*S*o*urPO*DUrpfrcoihw*cysTXRtbieooe*nrPts*NOyohp.r*O

We used a tool that would quickly take the ciphertext and number of rails and spit out the decrypted text. With 5 rails we had our message:


Paint*is*to*be*the*pink.*Fire*rate*to*coat*Los*Angeles*class*submarine.*Is*problem?*PS*-*am*told*by*superior*POSITION*must*DOUBLE*crypto*effort.*I*choose*cipher*now.*Your*crypto*is*THE*SUXORS.


This helped verify our previous thoughts. It looks like Yuri and Chris decided to change things up a bit. The clues to take from this one are DOUBLE POSITION, and THE SUXORS. Conveniently, in caps for us. Since the Purple 4 message didn't decrypt with a rail fence,we decided, thanks to Yuri to try a double transposition decryption. The Purple 4 ciphertext was: 


ATIOISHEHTUYPEPNGMENETRACYOLISDBREESVOEUWTPSVCIHENYRHTATFLTANKOEUHNEYMOHEIHCETDTIIUONAOHSOSHCLXRXCDFRGIEELO


This took a few attempts to decrypt, since we needed the keywords in the right order. It turned out that we needed to transpose based on SUXORS first, then THE. Our resulting plaintext message was:


HAVE PHOTOGRAPHED CANNON SEND SIXTEEN BYTE KEY VIA THE CIPHER OF YOUR CHOICE DONT TELL ME WHICH ILL FIGURE IT OUT THE SUXORS MY ASS


Now things were getting interesting. Here Chris asked Yuri to send a 16 byte key without Yuri telling him what method he was using. The response from Yuri was as follows:
Greetings, comrade! Is great day for breakfast! Please to tell is bacon considered extravagant? I would very much like to be having a big breakfast with bacon. Send link to good restaurant?
Much different "ciphertext" than we had received up to this point, and definitely no apparent 16 byte key contained therein... Lots of references to bacon though. To quote one of the guys working on this, "We need to figure out the bacon cipher." This would be that point in an episode of House where he has his epiphany and then magically saves the day. As it turned out, there is a Baconian cipher. And while it didn't help us for this message, it did help us solve The final message from Chris (Purple 5). The ciphertext from that message was: 


I HIGhly REcOmMEND THe wAFfLE hOUSe oN SOUTh pOpLAR sT FOR bREakFaSt But I WOulD Not eaT THE dAIlY sPeciAl aS IT Is mADe frOm LaST NIGHtS lEftOverS


The Baconian cipher can be used as a type of steganography, where a message can be encoded using font decoration or uppercase/lowercase to denote which letters should be assumed to be an A or B. Since the message was both uppercase and lowercase, we opted with the latter. To decode, we grouped the message into 5 character chunks and replaced all capital letters with A and all lowercase with B. Here's what the process looked like:


IHIGh lyREc OmMEN DTHew AFfLE hOUSe oNSOU ThpOp LARsT FORbR
aaaab bbaab abaaa aaabb aabaa baaab baaaa abbab aaaba aaaba
b     s     i     d     e     s     r     o     c     c       


EakFa StBut IWOul DNote aTTHE dAIlY sPeci AlaSI TIsmA DefrO
abbab ababb aaabb aabbb baaaa baaba babbb abbaa aabba abbba  
o     m     d     h     r     t     z     n     g     p          

mLaST NIGHt SlEft OverS
babaa aaaab ababb abbba
w     b     m     p 

The decoded message looked like some sort of a hyperlink with a URL of bsidesroc.com/dhrtzngpwbmp. Attempting to access that page returned a 404 and we went through the process of decoding the message again to make sure we didn't miss anything. Then, one of the other guys noticed that the last three characters represented a bitmap image file format. So, the correct URL would be bsidesroc.com/dhrtzngpw.bmp. Success! We had an image! Kinda of. It wouldn't open and looking at it under a hex editor showed that it definitely didn't look right. We still had to figure out the proper key and decryption method and we were almost out of time. Looking at the hex, it wasn't universally random, as would be expected using something like AES-CBC encryption, so we figured it must either be XORED with the key or encrypted using something like AES-ECB. The 16 byte key reference in Purple 4 alluded to the latter, but we still needed a key... 

Greetings, comrade! Is great day for breakfast! Please to tell is bacon considered extravagant? I would very much like to be having a big breakfast with bacon. Send link to good restaurant?


Greetings = 9 characters K[1] = 9
comrade = 7 characters K[2]= 7etc.

Final key: 972533962425ab15444226139454424a


By this point the closing ceremonies had started and in order to get credit we needed to decrypt the key. Scrambling with the command line, we used Openssl do do the decryption for us:


openssl enc -d -aes-128-ecb -in dhrtzngpw.bmp -out win.bmp -K 972533962425ab15444226139454424a


Just as Jason Ross was walking up to discuss the crypto challenge, we opened the decrypted image and showed it to him. Success! We had won with only seconds to spare. Here's the final image:





We were severely short on time. Darth was giving out a few final hints and we were so close... Then, another one of our group members figured it out! Yuri's message was exactly 32 words long, enough to create a 16 byte hex key (32 hexadecimal characters). By taking the length of each word (since no word was longer than 16 characters) we could create a valid key. Again Yuri's message was:


Overall, I had a great time at the conference and enjoyed working on this puzzle. Thanks again to all the BSides volunteers that put on a great conference in Upstate New York and of course to Darth for taking the time to put this whole thing together.

Monday, March 3, 2014

Thoughts on ISTS 11

Somewhere around the middle December, I was asked by my coworker Anthony (@_s1lentjudge) if I wanted to participate in RIT SPARSA's Information Security Talent Search (ISTS) competition, which I had heard of but wasn't entirely familiar with. I agreed, and spent some time in January and February preparing. I wasn't able to do as much as much as I'd like, with project deadlines, my grad class, leisure activities and such, but I did spend some time trying to figure out what I was getting myself into. In a nutshell, the ISTS competition pits "blue teams", each made up of five college students, against one another to defend a set of machines entrusted to them while attacking and gaining access to other team's machines. All the while, a dedicated red team, made up of event sponsors and industry professionals, is also attempting to break into all of the blue team machines. My job, as part of the SUNY Institute of Technology team was to work the offensive, and complete items on the "bucket list" provided by the white team to score points. In addition, I would support the team in other ways that I could. Here are my thoughts from the competition.

The Good:
  • The night before the competition, Raphael Mudge (@armitagehacker) gave a presentation about Cobalt Strike and some advice on how to use it to score some access to machines early on. He kept referring to the "Penetration Testing Machines" as though they would be running some obscure system and I was worried that I would have Kali Linux available with all its related tools. Thankfully, once the competition started I found that we had two dedicated Kali machines.
  • For the most part, the environment set up by RIT SPARSA ran pretty well. I would have enjoyed a few less cables running under my chair but the machines they provided for vSphere and the network seemed to work while the competition was underway.
  • There was a number of things to accomplish, which helped keep things interesting. I really enjoyed the bucket list, since that gave teams a set of things to focus on after the initial access was obtained. Sure, it's easy to just destroy the machine (and it happened quite a bit) but thinking about how to complete the challenges to score more points for the team was a nice addition. At one point, our asterisk binaries got wiped, but using access we had to another teams asterisk machine allowed us to exfil out the required binaries and get our machine back up and running without having to revert. Alternative to the attack/inject/defense checklist, there were lockpicking challenges, crypto and reversing challenges, and a new mobile security challenge that offered teams even more methods of gaining points than through service checks and injects alone. Honestly, there was more stuff to do during the competition than could realistically be completed.

The Bad:
  • I stated in "The Good" that the environment that was set up ran pretty well. This is true, except for one thing. The vSphere environment used was frustratingly slow for the first few hours of the competition. It took a solid few minutes to even open up a vsphere console window for the machines, and longer still to actually attempt to login. I gave up even trying to load Cobalt Strike after letting it sit for 15 minutes attempting to start up. It would also have been nice to have had the vmware tools already installed on the machines so that the werent limited to the default resolution (800x600?). One of the Kali machines got rebooted and it took nearly 30 minutes to accomplish. This did get better as time progressed but during a competition like this, the first moments are critical, and being unable to do anything set the teams up for failure from the beginning. This was especially the case since the red team had their own equipment and were informed of the default credentials for all machines during the briefing on the first night. In addition to that, the scoring engine seemed to have some trouble, so it was difficult to determine whether our services were compromised or actually working properly.
  • There were relatively few rules, which could be considered good I suppose, but it was tough to gauge what was in score or out of scope. Our vSphere creds were compromised at one point, and this was later determined to be against the rules but all too late for us. I have to give credit to the team that did this, since there was little we could to do combat it, except wait for the white team to reset it. I remember frantically switching ttys and CTRL-C'ing on one box to prevent one of our machine's boot partition from being overwritten from /dev/urandom.
The Hilarious:
  • I loved the idea of compromising/reasoning with the red team to get control of your box back and I think that blue teams should use the same tactics with each other. The song and dance routines that the blue teams had to do to get access back to their domain controllers was quite enjoyable (See: 12, 3).
  • I also was quite amused by many of the tactics and techniques that were shown off during the event. From the nyan cat bootloader, to the IRC botnet, to the random wall conversations that were had with the red team on another teams box, it was highly amusing and helped alleviate some of the stress.
  • Raffi (@armitagehacker) was graciously donating shells from the many, many boxes he had access to which was great for completing some of the other challenges that we hadn't finished yet. It was unfortunate that some of these were to our own machines :(
  • Lastly, the second day of competition seemed to bring out the most malicious in people. Boxes were going down left and right as teams were trying to knock each other out in hopes to score some extra service checks. There were so many casualties. We did our share of rm -rf'ing things, partially out of retaliation, and partially because it's not something that you have the opportunity of doing too often. And you know what? It was kinda fun.

Monday, October 28, 2013

Playfair Encryption/Decryption

I'm currently in the middle of a Grad course in Secure Protocols. In the first weeks of the course, we discussed a number of encryption methods used over the years to secure messages passed between entities. These included the Caesar Cipher, the Affine Caesar Cipher, The Hill Cipher, and the Playfair Cipher. Each of these were fairly unique in the way that they were implemented to create an encrypted message from the original plaintext. 

Since most of my time outside of work these days has been finding ways to break encrypted messages (Matasano Crypto Challenges, Codebreaking Puzzles, etc). Our instructor allowed us to do a programming project as part of the Midterm so I figured I would flip things around and write a program that does that encryption and decryption instead. So I wrote one to handle Playfair encryption and decryption. As with the other crypto stuff I've been working on lately, I decided also to write it in Python.


The program would be designed to generate a Playfair matrix, obtain either the plaintext or ciphertext message, and either encrypt or decrypt the message as necessary using the generated matrix. Finally, the program would return the resulting ciphertext in the case where the message was encrypted or the plaintext when the message was decrypted.

The rules of the Playfair Cipher were as follows:
1.     Repeating plaintext letters that are in the same pair are separated with a filler letter, such as x, so that balloon would be treated as ba lx lo on.
2.     Two plaintext letters that fall in the same row of the matrix are each replaced by the letter to the right, with the first element of the row circularly following the last. For example, ar is encrypted as RM.
3.     Two plaintext letters that fall in the same column are each replaced by the letter beneath, with the top element of the column circularly following the last. For example, mu is encrypted as CM.
4.     Otherwise, each plaintext letter in a pair is replaced by the letter that lies in it own row and the column occupied by the other plaintext letter. Thus, hs becomes BP and ea becomes IM (or JM, as the encipherer wishes).

Stallings (2013-03-22). Cryptography and Network Security: Principles and Practice, 6/e (Page 40). Prentice Hall. Kindle Edition.

Using these rules, I created the Playfair Cipher encryption program, the course code for which is included in the Appendix. The letter J was purposely left out of the Playfair matrix generated using the program I developed, as per rule 4 above. All instances of the letter ‘I’ and the letter ‘J’ in the ciphertext are denoted as the letter ‘I’. Otherwise, all rules are followed as described in the text. 


Run-time Program Output:

Message Encryption

$ ./playfair.py


Initial PLAYFAIR matrix:

A B C D E
F G H I K
L M N O P
Q R S T U
V W X Y Z


Enter a key:
this is a test key

Keyed PLAYFAIR matrix:

T H I S A
E K Y B C
D F G L M
N O P Q R
U V W X Z


Would you like to encrypt or decrypt a message?
1 - Encrypt message
2 - Decrypt Message

Decision:
1

Encrypt Message:
Enter the message you would like to encrypt.
The only valid characters are the letters A-Z.
Periods may be denoted with an X
i am encrypting a message here x this is the original message

The message you entered was: IAMENCRYPTINGAMESSAGEHEREXTHISISTHEORIGINALMESSAGE

Your encrypted message is: STDCREPCNITPMIDCBSATDYTKNCUSISASAHTKPNYPTPSMDCBSATDY

Message Decryption:

$ ./playfair.py

Initial PLAYFAIR matrix:

A B C D E
F G H I K
L M N O P
Q R S T U
V W X Y Z


Enter a key:
this is a test key

Keyed PLAYFAIR matrix:

T H I S A
E K Y B C
D F G L M
N O P Q R
U V W X Z


Would you like to encrypt or decrypt a message?
1 - Encrypt message
2 - Decrypt Message

Decision:
2

Decrypt Message:
Enter the message you would like to decrypt.
The only valid characters are the letters A-Z.
STDCREPCNITPMIDCBSATDYTKNCUSISASAHTKPNYPTPSMDCBSATDY

The message you entered was: STDCREPCNITPMIDCBSATDYTKNCUSISASAHTKPNYPTPSMDCBSATDY


Your decrypted message is: IAMENCRYPTINGAMESXSAGEHEREXTHISISTHEORIGINALMESXSAGE

The overall program was pretty small, only taking up 275 lines including all of the comments, examples, and documentation. In all, it was a fun experiment and I ]'ll be looking into some more of these as the class continues.

Source code can be found here: