Thice.nl

Thice Security

De Star 6, 1601 MH Enkhuizen
Thice Security

HitB 2015 CTF write ups

04/06/2015, by Thice, category Code, CTF

header

During the Hack in the Box Amsterdam 2015 conference (28,29 May 2015) we participated for the 3rd time in a row with team Hack.ERS in the CTF game. Once again the team included both me and Gijs from the Eindbazen team and Riley as the 3rd player. Multiple other Eindbazen members organized the CTF just as in the past years. This write-up contains some of the challenges we solved during the CTF, I only created write-ups of the challenges for which I had enough notes, but I did include the challenge descriptions and files for all the challenges where possible.

We ended on the 3rd place with the same amount of points as the second place (but just slightly later submitted the last solve). Which results in getting a top 3 position for 3 years in a row (2nd in 2013, 1st in 2014)

 

Scoreboard after day 1:

Day1

Final scoreboard of the CTF:
Day2

BINARY

 

BIN100

MISSION
WE DISCOVERED A SATCOM MODULE ACTIVATOR PROGRAM RUNNING ON 145.111.166.246:8200. OUR UNDERCOVER AGENTS MANAGED TO GET HOLD OF THE BINARY. EXPLOIT THE PROGRAM TO GET THE FLAG.
Mirror: server

In this challenge we received a binary file and the information that this binary is running on a remote system. Sounds like we need to create a remote exploit for this system.

The file is a 64-bit Linux ELF:

We use checksec.sh to check the security of this binary:

It seems the program has NX disabled, meaning that the stack is executable. This will enable us to exploit the program without having to ROP. However, we also see that the program makes use of a Stack Canary.

When we run the program it does not give any output, but it is listening on a port as we can see in netstat:

Connecting to this port we get the following reply:

Normal behaviour of the program:

We tried multiple things with the program to see if we could identify the vulnerability. We seem to get lucky when we send a larger amount of channels than the 1 till 8 it accepts:

After this the connection gets closed and we see that the server gets killed:

Good, it looks like we are on to something here. Another thing we notice is that if we make the channels number pretty large we get some kind of memory leak with the moduleinfo command:

memleak

Let’s see what is happening under the hood here. The “stack smashing detected” message is a result of the stack canary (or stack cookie) being overwritten, which gives us a good pointer where to look next. Since we get this result after using the transmit function let’s look at that function.

We get the assembly code of the program by using objdump:

Within server.asm we now find the full assembly of the program. The part we are now interested in is:

The part where the stack canary is checked is:

We can also see this stack canary being set at the beginning of main:

Location 0x400d8f would be a good location to break on to see what happens with the stack canary:

The stack smashing message appeared, but the program did not hit our breakpoint. The reason for this is that the program forks on each connection and we are debugging the parent program. To be able to debug the child program we need to use the following setting in gdb:

With this option set we now do hit the breakpoint:

The program is now waiting on the instruction we are interested in, where it gets the stack canary from the memory:

This instruction gets the stack canary from the memory location RBP-0x8 and copies it to RAX. The values before the instruction:

The values after the instruction:

With the correct stack canary the XOR instruction after that will result in RAX being 0:

Now let’s see how this values change when we get the stack smashing message (with large amount of channels as input). Hitting our breakpoint:

Loading the stack canary from memory:

Instead of the previous value of “0x583a016687a2e700”, the stack canary is now “0x0”, the result is that the program will give the stack smashing message and quit:

We know the stack canary can be found in memory on the location RBP-8 (-0x8(%rbp)) when we hit our breakpoint. So we can get it from that location:

Another thing we see at this breakpoint is that the transmit input we gave is currently in RAX:

So, let’s see how the stack canary overwrite works. From the program we understand that it seems to support 8 channels, all with 32 bytes space:

That would make 256 bytes of space (8×32). What would happen if we try to put more bytes in this space. To test this we send a string longer than 265 bytes, to create this input we use a simple Perl print command:

Sending the command:

When hitting our breakpoint we see:

Only the A’s ended up in the memory, all bytes over 256 were ignored. Also the Stack Canary still seems to be intact:

To make things more interesting we now change to 9 channels, one channel more than the intended 8. Which means we now got 288 bytes space (9×32), which should overwrite our stack canary at the end of the buffer of 256 bytes:

We indeed seem to have overwritten the Stack Canary:

If we now continue the program it will stop because of the Stack Canary change:

Ok, now that we know where the Stack Canary is and can manipulated it, we can try to overwrite it with it’s original value. But how do we find out this value? One of the bugs we found in the program was a memory leak, let’s go back to that one.

Since the output of the memory leak seemed gibberish we want to look at it in Hex. To make this easier we switch from netcat to a simple Perl script and pump this output through xxd:

When we run the Perl script against the server and hit our breakpoint we can check the stack canary in the running server program:

Now we can compare this Stack Canary against the memory leak we just got and it seems we can find the stack canary in it:

Stack Canary from gdb: “0x45943400 0xb43bfe5a”, stack canary from the memleak: “0034 9445 5afe 3bb4”, the endianess is different, but it is the same value.

The Stack Canary is found on location 0x1340 (4928) in our output. Since we output a lot of other stuff we need to substract 600 bytes from this after which we get the location of the stack canary in the memory leak (4328). The Perl code to get the stack canary:

Output:

Let’s see what happens when we add this Stack Canary after our buffer:

We seem to bypass the Stack Canary now, and the program crashes after that. Let’s see where it crashes:

So, after the instruction 0x0000000000400da4, the program segfaults:

We can see we indeed successfully bypassed the Stack Canary and that the program has a problem with returning. Looking at the memory we can see we also overwrote RBP:

And RSP points to our buffer as well:

The buffer we used for this was: [256 x A] [8 x B ][Stack Canary][16 x C], so the RBP overwrite is done with the bytes after the Stack Canary.

If we investigate a bit further we can see we also control RIP, if we send a buffer with [256 x A] [8 x B ][Stack Canary][8 x C][6 x D] we overwrite RIP:

Note that we overwrite RIP with 6 bytes, and not more, if we overwrite RIP with [8 x D] the result is:

We end up not overwriting RIP at all, because the value will then be outside of the ‘canonical‘ address space. If we want to overwrite more of the buffer we need to add two null-bytes after our RIP overwrite: [256 x A] [8 x B ][Stack Canary][8 x C][6 x D][\x00\x00][buffer].

Now that we control RIP we can look at what we want to overwrite it with. We see an interesting location in RDI:

If we look at the location of RDI we can see that it contains the beginning of our buffer:

Since this memory location quite likely will be dynamic we will need to find a way to be able to find it. Luckily we got the memory leak, in the memory leak we can find a memory location right after the stack canary:

The memory location in this case is: 20df ffff ff7f (0x7fffffffdf20). The memory location of the beginning of our buffer is 0x7fffffffcb30. The difference between the two memory locations 0x7fffffffdf20 – 0x7fffffffcb30 = 13F0 (5104). With this leaked memory location we can now calculate where the memory location of our buffer is. We can use this value as the last 6 bytes of our buffer and take control of the execution of the server. Our buffer now looks like:

It seems we got everything for our exploit now, we got a buffer of 256 bytes, a leaked stack canary and memory location and we control RIP which we can point to our buffer. We can combine this all in to the exploit for this challenge. Getting a working shellcode for this write up proved a bit challenging. Mostly because in the write up I somehow ended up testing the shellcode at the end of the buffer (with nops in front of it), which resulted in corrupted code. After putting the shellcode at the front of the buffer I got much better results. There are three shellcodes in the exploit which worked for future reference. To debug the shellcodes strace can be a great tool. But note: To be able to debug the forked child programs with strace you will need the -f option (strace -f ./server).

Shellcodes used:

1. dup2 & binsh shellcode from moneyshot

This shellcode needs the file descriptor (fd) which it needs to take over for the shell. In this case the fd is 4, to find the fd, we could use strace:

Or check the process info of a child process:

 

2. Socket searching shellcode by brainsmoke

This shellcode will find the correct socket descriptor itself and execute a shell.
3. fd search and protected shellcode by isislab

This shellcode will only spawn the shell when it receives a ‘secret’ string (0xcafef00d).

 

The full exploit:

Output of our exploit:

Flag: HITB{0ec76beb6c3cdae817042e3207353448}

 

BIN200

MISSION
WE FOUND AN INTERNET CONNECTED TI-83 CALCULATOR AND MANAGED TO DUMP THE FIRMWARE. THIS DEVICE SEEMS TO BE USED AS A COMMAND & CONTROL FRONTEND FOR MALICIOUS ACTIVITIES. HOWEVER, THE SOFTWARE SEEMS PROTECTED WITH A 8 CHARACTER PASSWORD. CAN YOU HELP US RECOVER IT? FIRMWARE DUMP CAN BE FOUND HERE. MAYBE THIS MACRO WILL HELP TOO: 0015,0015,0015,0054,0033,0001,0001,0001,0001,0001,0001,0009,0031,0009,0021,0009
Mirror: challenge.8xp

The challenge description tells us that the file we received is some kind of TI-83 calculator dump. Looking at the fileheader we get some info on how the file was created:

 

We tried multiple different emulators, but the emulator that worked in the end was TilEm. For TilEm (and all other emulators) we need to have a ROM file to load in to it. Luckily for us the emulator Wabbitemu can generate ROM files. The ROM file we created for this challenge can be found here. After starting TilEm with this ROM file it seems to not do anything at all. But we can send the challenge.8xp file to it via the right mouse menu or Ctrl-O:
ti1

To get the program to start we can run the macro from the challenge description:

We save this macro as a text file and load it via the right mouse button menu, Macro –> Open Macro File.
ti2

After loading the macro the program will start and we can start analyzing it.
ti3

It seems we have to crack the Key to get access to the program. Since we know nothing about the program we start by trying various input. After 8 chars the program seems to do some check and then returns to the begin screen.

We can start the debugger of TilEm (right mouse menu –> Debugger, or the Pause key, which my MacBookPro does not have.. *shakes fist at Apple*). In the debugger we can look through the large amount of code in the debugger, the registry values and memory contents. Some info on the assembly in use can be found here.

ti4

If we put in “00000000” as key we can find it back in memory at this location:

ti5

The location of our plaintext input is FFBB-FFC2. In the debug menu (or Ctrl-B) we can set breakpoints on memory locations (or ranges):

ti6

ti7

When we put a breakpoint on the memory location of the plaintext input (FFBB-FFC2) we can see when the program interacts with it. One of the things we notice is that the program is copying the plaintext to the memory location after it FFC3-FFCA (in this screenshot we used 555555555 as input):

TI-memory

The program then encrypts the string in memory, when we put in “00000000” as key we get:

ti5bThe part of the code where the encryption happens:

TI-XOR

In the above screenshot we can see the hex values 36, E0 and 6F which are used to XOR against the plaintext. The full list of XOR values found is:

The encrypted hex values we see in memory:

If we XOR the two values together we end up with the plaintext of 8 times 0x30 which is 00000000. So we got the crypto key (36 E0 6F FB A5 11 BE 84) to encrypt and decrypt the Key. The next part is to find out what Key the program wants to see. With a breakpoint on the encrypted string in memory we see that the memory is being used in the following piece of code:

TI-Check

The program loads the encrypted value from memory in to D and the value 75 in to HL. It then calls function AAE3:

TI-SBC

The routine AAE3 uses the SBC instruction to substract the two values loaded in memory. The SCF command then sets the C flag (0 when the SBC result is 0, 1 if the SBC result is not 0), after which the routine returns. Returning to the precious code, the jump on line A7FB will be taken if C is 1. So in case the values are not the same the program will jump to A947. When this happens the key failed. There are two options we can follow now, we could adjust the code so our input is accepted, but then we might run in to other checks. Or we could recover the Key. To recover the key we note down all the check values in the code. Which are:

If we XOR these against the crypto key (XOR works both ways) we get:

The HEX values translate to the following password for the challenge: C4LCULUZ

Which seems to be a l33t style version of the word calculus. If we put in this password in the emulator (use the ALPHA key for A-Z) we get the screens:

TO-Solve

We can now get the flag:

Flag: HITB{fd8da53e7b50017987a838e337042b20}

 

BIN300

MISSION
CRYPTOCURRENCIES ARE BOOMING BUSINESS! WE DECIDED TO INVEST A BIT IN THIS NEW ECONOMY AS WELL AND CREATED “HITBCOIN”. OUR CURRENT MINING ARCHITECTURE IS NOT QUITE ASIC READY YET AND THE DEVELOPER RECENTLY LEFT US. ALL WE HAVE LEFT IS THIS BINARY WHICH HAS SOME PERFORMANCE ISSUES .. WE HAVEN’T BEEN ABLE TO MINE A SINGLE COIN YET BEFORE THE LIFETIME IS DEPLETED (48 HOURS).. CAN YOU HELP US OUT?

Mirror: hitbcoinminer.elf

No write up available for this challenge.

BIN400

MISSION
WE CAME ACCROSS THIS INTERESTING PIECE OF SOFTWARE FOR LINUX/32BIT. IT ASKS FOR AN INPUT BUT WE HAVE NO CLUE WHAT IT WANTS.. HELP! LINK TO BINARY .. CHECK YOUR INPUT HERE: HTTP://145.111.166.226/CHECKER.PHP
Mirror: binary.elf

No write up available for this challenge.

 

NETWORK

There were no NET300 and NET400.

NET100

MISSION
SOMEBODY CRACKED THE KEY MANAGEMENT SYSTEM TO ONE OF OUR MAIN ATTACK APPLIANCES. WE MANAGED TO CAPTURE SOME SUSPICIOUS NETWORK TRAFFIC THAT MAY HELP IN UNCOVERING HOW THIS HAPPENED. PERHAPS IT CAN EVEN BE USED TO RECOVER THE SKELETON KEY IT WAS CONFIGURED WITH. IT WAS SAVED IN A FILE CALLED FLAG.TXT. THE NETWORK CAPTURE CAN BE FOUND HERE.
Mirror: network100.pcap

We got a PCAP file in this challenge, so the first thing we do is loading it in to Wireshark:

Wireshark1

Wireshark shows us that this seems to be some GIT related network traffic. If we follow the TCPstream of the packets we see more information on what is happening:

Wireshark2

We can see that a GIT PACK file is being downloaded in this PCAP. The PACK file can be found from packet 17 on. We can save this file from Wireshark (saving it as Raw and cutting off the extra data not part of the file). To open this file with GIT we first need to init a GIT repository with the git init command.

After this we can unpack the exported file we created:

We seem to get some errors on the command, but it seems to have unpacked 27 objects. A list of all the objects:

It seems that GIT stores objects by their hash value, but uses the first two characters of the hash as the directory, as can be seen above. However, to read the files with the cat-file command we need the full hash value:

Reading these files with the cat-file command we find the flag in file 9ec9e97e0830d6cd8c15cab8bb8c5091413d497a:

Flag: HITB{60668aab6899a3961f16e51888ab6609}

 

NET200

MISSION
WE RECEIVED INTEL FROM ONE OF OUR AGENTS THAT OUR ENEMY USES A HIDDEN SERVER TO SHARE SECRET LOGIN CODES. THOSE LOGIN CODES ARE ESSENTIAL TO GAIN ACCESS TO THEIR INFRASTRUCTURE AND MUST BE RETRIEVED AS SOON AS POSSIBLE. FIND THE CORRECT PORT SEQUENCE IN ORDER TO RETRIEVE THE FLAG. 145.111.166.245:[8080-8126]

This challenge was a port knocking challenge. However, when we portscan the range we find that all ports are open. Normally with port knocking the ports are opened one by one when the sequence is correct. In this case we need to look at something else. If we open the first port (8080) we do not get any reply, but when we send an enter we see the following reply:

The numbers 1f91 and 1f92 are the hex values for 8081 and 8082. When we connect on these ports the replies are:

It looks like the server replies can be 0000 0001 or 0000 0002, when we get the 2 we get the following ports, and when we get the 1 we seem to fail. It seems we have to choose one of the two ports we receive. If we choose correctly we get two new ports, if we choose the wrong one we need to start over. The port we need to connect on each time seems to be random, and we need to connect to too many ports to be able to brute force and get lucky. So we needed to find the trick we needed to perform in this challenge. It seemed that the state reset only happened when the wrong port was closed. So the trick was to connect to both ports and only start sending data when both ports were open. We could then try one port first, and if we get the 1 reply quickly send data to the second port. Since the ports did not send anything till we send first we could open them at the same time. This way we were able to get the next two ports each time without failing. We did run in to some problems with the timing, we needed a short sleep in our code after the opening of the ports, if we would not have that the script was not stable enough. Sadly enough finding this bug took us quite some time.

The dirty code we used for this challenge:

 

Output of our script:

The script outputs the flag in hex, so we need to convert that:

Flag: HITB{3901bce33f65b19e4cb168641ee8220d}

 

MISC

MISC100

MISSION
WE BUILD A NEW LOGIC ANALYZER. IT ONLY HAS TWO CHANNELS, BUT A RIDICULOUS SAMPLERATE. (WELL, FOR A HOMEGROWN LOGIC ANALYZER ANYWAY..). WE MANAGED TO CAPTURE THE CLOCK AND CMD SIGNALS OF A SDMMC BUS. CAN YOU TELL US WHAT THE CID OF THE DEVICE IS? FLAG FORMAT IS “HITB{” + CID + “}”
Mirror: challenge.txt

No write up available for this challenge.

MISC200

MISSION
ONE OF THE SATTELITES CRASHED, WE MANGAGED TO BEAT THE OWNER IN RECOVERING THE SATTELITE AND WERE ABLE TO DUMP THE MEMORY AND A RANDOM FILE. ARE YOU ABLE TO FIND THE SECRET?
Mirror: misc200.tgz

In this challenge we got two files: a memory dump and a file which looked like an encrypted file because of the randomness in it. The memory dump contained some strings related to Windows and we saw strings related to VeraCrypt. The memory dump, encrypted file and VeraCrypt reference gives the idea we need to recover the encryption key from the memory dump to decrypt the VeraCrypt container file. VeraCrypt is a fork of TrueCrypt, and works mostly in the same way. This is a challenge you typically would do with Volatility or like described in this write up of a previous CTF. However from experience we know there is also a much easier way to solve this challenge (like also described in a different write up for the previous CTF). There is a commercial tool available which makes this challenge much easier, being Passware Forensics Toolkit. Even though the challenge uses VeraCrypt, the TrueCrypt option in this software will work fine. Using this software it was just the case of putting everything in and let it crunch for a while:

PasswareVeraCrypt

The decrypted file can then be opened with a tool such as FTK Imager:

FTKMSC200

Flag: HITB{3a33ebda691e64eec43a18ffcd8772c4}

MISC300

MISSION
ONE OF THE SATTELITES CRASHED, WE MANGAGED TO BEAT THE OWNER IN RECOVERING THE SATTELITE. THE SATTELITE CONTAINED SOME DISK, OUR FORENSICS TEAM THINK IT MIGHT CONTAIN A JOURNAL OF THE SATTELITES ACTIVITIES
Mirror: misc300.tgz

We got a disk image in this challenge and some kind of hint about a ‘ journal’. Loading the disk in FTK Imager we see that it contains a NTFS file-system. We also noticed there was a log file in the Unpartitioned Space, being a KLOG file, a file which should contain a journal of the changes to the disk.

klog

However, this logfile seemed to be empty, so we had to look further. NTFS seems to keep a journal of changes to the filesystem in $LogFile. When we look at this file in FTK Imager, one of the things we notice is that it contains a reference to FLAG.TXT:

 

FTKScreenshot

It looks like we are on the right path now. To look at the inside of the $LogFile we make use of two tools. LogParser and MFT2CSV. To be able to use the tools we export the files $MFT and $LogFile with FTK.

The first step is to convert the $MFT file to CSV:

mft2csv
After we get the $MFT file in CSV format we can use that as input in the LogParser tool together with the $LogFile:

logfileparser

The LogParser tool created multiple files in the output directory. Analyzing these files we find in both LogFile_INDX.csv and LogFile_UndoWipe_INDX.csv the flag we are looking for (it just misses the last } in the second file).

The flag in the output file:

LogFileFlag

Flag: HITB{b875ac63e0f769b90e9524af74a23c5c}

MISC400

MISSION
THE LATEST SET OF ATTACKS SEEMS TO BE ROUTED THROUGH ONE OF THOSE NEW NETWORK ENABLED SMART TOASTERS. INITIAL SCANS OF THE DEVICE SHOW THAT IT HAS A DNS DIAGNOSTICS PAGE THAT IS PUBLICLY ACCESSIBLE, BUT NOT MUCH ELSE. IT’S A LONG SHOT, BUT MAYBE YOU CAN USE THIS PAGE TO COMPROMISE THE DEVICE AND LOCATE ANY STOLEN DATA THAT STILL LINGERS ON THE DEVICE. THE DATA WOULD PROBABLY BE STORED AS A FILE CALLED FLAG.TXT. THE DNS CONFIGURATION PAGE CAN BE FOUND HERE.
http://145.111.166.239/

screenshot_DNS

No write up available for this challenge.

 

SPECIAL

SPC100

MISSION
PHYSICAL SECURITY IS A PAIN IN THE ASS. WE HAVE THIS NEAT VAULT WHICH STORES SOME OF OUR BELOVED SECRETS, BUT WE LOST THE KEY. OOPS. THE VAULT IS LOCATED OVER AT THE TOOOL VILLAGE. CAN YOU RECOVER ACCESS TO THE VAULT? ASK TOOOL FOR MORE INFO.

NOTE: AT LEAST TWO PLAYERS ARE REQUIRED TO PARTICIPATE IN THIS CHALLENGE.

This challenge consisted of a suitcase with an (obviously) fake bomb in it. The goal was to disarm the bomb before the timer would run out, which was set on 5 minutes. There were three parts to this challenge, the first part was picking a wafer lock, a pretty easy challenge, however, as soon as you would turn the lock it would trip a magnetic reed sensor.  When this sensor (or one of the others) would be tripped, the bomb would go off. To bypass the reed sensor you were given a magnet (a strong one from a harddisk),  which is shown on the photo below in box 1. With the lock unlocked and the sensor disabled the first part was done. The second part of the challenge was to open the Plexiglas lid (which is standing up on the photo), however, as soon as you would open it, two pressure sensors would be tripped. These sensors are shown in the boxes on the sides off the photo. By wiggling a piece of metal between the Plexiglas rim we could hold the sensors down while opening the lid, and thus avoid the sensors from tripping. The last part of the challenge was figuring out in which order we would have to press the six yellow buttons (box 3 on the photo). These buttons were blinking in some random order, and it took some time to figure out what we needed to do. But after watching the buttons for a while we could see one of them blinked a bit shorter than the rest. After pressing this button one of the others blinked a bit shorter. One by one we pressed the buttons and were able to defuse the bomb and get the SUCCESS message on the timer. The flag for this challenge was given on a piece of paper by the organizers after solving the challenge.

bomb1

 

Flag: HITB{1a58e3c81b7ba6b34fb130494d0df267} 

 

SPC200

MISSION
WE INVEST A LOT OF RESOURCES INTO MALWARE SANDBOXING NOWADAYS. ONE OF OUR INTERNS HAS SET UP A REMOTELY ACCESSIBLE (OVER HTTP) INSTANCE OF CUCKOO SANDBOX, NIFTY! CAN YOU VERIFY IF HE DIDN’T LEAVE ANY CONFIDENTIAL INFORMATION IN THE SANDBOX VIRTUAL MACINE? THE WEB INTERFACE CAN BE FOUND HERE.

SPC200_Screenshot

This challenge involved using the Cuckoo sandbox, where we needed to get information out of the sandbox VM. We started by trying to upload executable files with a reverse shell so that we could connect to the sandbox VM directly. However, this did not work, it probably was not possible to create outgoing connections. We decided to take smaller steps and upload some Windows batch files to see what that would do. We notices that batch files would open up a Command Prompt window which would be shown on the screenshots that Cuckoo shows in the reports they provide.

One of our scripts was a dir lisiting of the C drive:

SPEC200_screen1

 

 

From the screenshot in the report we learn that there is a file calles flag1.txt in C:\, so the next script we try is:

The output of this script:

SPC200_flag1

We got part of the flag, but it seems the flag is split in multiple parts. The challenge now was to find the rest of the flags. The script we used to find the flags was:

This script showed us the location of flag 3 and 4:

SPC200_flag134

Because of the /p option we used in the batch file the script pauses after each full screen, so we do not see the last flag. Our new script to just find flag2:

This script shows us the location of the last flag (flag2):

SPC200_flag2

Now that we have the locations off all the parts of the flag we can send our final script to receive all parts:

The Cuckoo report from our final batch file can be found here. Which includes the following screenshot with the full flag:

SPEC200_solve

Flag: HITB{397a2be567dcc8e4eaf6403f98b1cf29}

 

SPC300

MISSION
YOU GOT A NICE PIECE OF PAPER WITH SOME LETTERS ON IT. THAT’S HOW YOU MANAGED TO GET INTO THIS PORTAL. RUMOUR HAS IT OUR PRINTERS HAVE BEEN BACKDOORED. CAN YOU MAKE SURE THAT NO ADDITIONAL CONFIDENTIAL INFORMATION LEAKED ON THE PIECE OF PAPER YOU RECEIVED FROM US?

At the beginning of the CTF we got a piece of A4 paper with our login credentials. It seemed that this piece of paper also contained some very hard to see yellow dots, we only noticed the dots after reading the challenge descriptions. The yellowish light of the CTF area did of course not help at all. We tried seeing them better using the lighting of a 3D printer in the 3D printer area, some teams used the blue led of the water cooler. But the best result we got was when walking outside the venue and looking at it in daylight. The dots on the paper were found as horizontal lines, which were repeated around every 4 cm. We took three photos of one of the lines (left, middle, right) to have a high enough resolution. We then loaded these photos in to out favorite image editor. After trying some options we found that the dots represented binary data. The dots were 1’s the spaces were 0, only the first dot was a bit higher than the rest and was in fact a 0 instead of a 1. To be able to count the 0’s we had to find the spacing of the dots, which we did by adding a second line under the printed line where all dots were present (by copy pasting a series of dots from the photo). With this we could write out the 0’s and 1’s like we did on the sample photo below:

dots2

The full binary code we recovered: 01001000 01001001 01010100 01000010 01111011 00111000 01100010 00110110 00110011 00110001 00110101 00110110 01100010 01100001 00110111 01100101 01100010 01100011 00110011 01100110 00110001 00110000 00110101 01100110 01100101 00110100 00110110 01100110 00110100 01100110 01100110 01100100 00111000 01100110 01100100 01100110 01100101 01111101 00

This translated to the flag.

Flag: HITB{8b63156ba7ebc3f105fe46f4ffd8fdfe}

 

SPC400

MISSION
WELCOME TO THE CLOUD BABY! WE FINALLY MANAGED TO TIMESHARE OUR HARDWARE DEVELOPMENT PLATFORM USING THIS NIFTY WEB INTERFACE. ENGINEERS CAN UPLOAD HEX FILES HERE (HTTP://145.111.166.241) TO INTERFACE WITH THE PLATFORM AND GET FEEDBACK. WE’VE HEARD RUMOURS SOMEONE IS BROADCASTING SECRET INFORMATION ON 2.4GHZ RF USING THE MAC ‘HVWEB’.. CAN YOU SNOOP THIS INFO FROM THE AIR?

INFO: HTTPS://GITHUB.COM/ARDILLO/HITBADGER

 

SPC400_screenshot

redbadge

 

While we did make some progress on this challenge, we did manage to solve it because we ran out of time.

 

CRYPTO

No description, mirror or write up available for CRY100.

CRY200

MISSION
WE HAVE ONCE MORE INTERCEPTED COMMUNICATION THAT SEEMS TO HAVE BEEN ENCRYPTED WITH WHAT WE HAVE BEGUN TO CALL THE SLOW COOKER ALGORITHM. UNFORTUNATELY, THEY SEEM TO HAVE FIXED THE STATIC DIFFIE HELLMAN PRIVATE KEY WE WERE ABLE TO ABUSE LAST TIME. WE NEED YOU TO FIND ANOTHER WEAKNESS SO WE CAN DECRYPT THEIR COMMUNICATION. YOU CAN FIND THE IMPROVED SOURCE CODE <HERE>. A CAPTURE FILE OF THE INTERCEPTED TRAFFIC CAN BE FOUND HERE.

Mirror: No mirror available for this challenge.

No write up available for this challenge.

CRY300

MISSION
WE HAVE FOUND AN ENCRYPTED MAIL ON ONE SYSTEMS WE RECLAIMED. LUCKILY, THE SYSTEM ALSO CONTAINED THE CERTIFICATE OF THE RECIPIENT AND THE CUSTOM SOFTWARE THEY USED TO GENERATE THE RSA PARAMETERS. THIS CUSTOM SOFTWARE LOOKS LIKE NOTHING WE HAVE SEEN BEFORE, PERHAPS YOU CAN USE IT TO RECOVER THE MAIL’S CONTENT. YOU CAN FIND THE MAIL, THE CERTIFICATE AND THEIR CUSTOM SOFTWARE HERE.
Mirror: No mirror available for this challenge (chal.tgz)

No write up available for this challenge.

CRY400

MISSION
THE ATTACKERS ARE TOYING WITH US! THEY FLAUNT THEIR POSSESSION OF ONE OF OUR SKELETON KEYS BY OFFERING IT AS SOME SORT OF PERVERTED GUESSING GAME. THEY EVEN PUBLISHED ITS SOURCE CODE! CRACK THIS ABOMINATION AND RETRIEVE OUR KEY! YOU CAN FIND THEIR GAME @ 145.111.166.238:8101. YOU CAN FIND THE SOURCE CODE HERE.
Mirror: guess.py

No write up available for this challenge.

WEB

 

WEB100

MISSION
ONE OF OUR REMOTE SATELLITE CONTROL STATIONS HAS BEEN COMPROMISED AND DEFACED BY SOME SCENE KIDS. THEY HAVE LOCKED US OUT AND PUT UP SOME KIND OF ACCESS CONTROL PAGE, SO WE CAN NO LONGER ACCESS THE CODES TO OUR GDS SATELLITES. CRACK THEIR CODE AND GET RID OF THIS CHILDISH CRY FOR ATTENTION, WE NEED THOSE SATELLITES UP AND RUNNING! YOU CAN FIND THE PAGE IN QUESTION HERE.
http://145.111.166.227/

No write up available for this challenge.

WEB200

MISSION
WE WERE ABLE TO TRACE SOME OF THE RECENT MALICIOUS ACTIVITIES TO A COMPROMISED FLYSWATTER. AFTER DOWNLOADING THE FIRMWARE, WE BELIEVE THE ORIGINAL POINT OF ENTRY WAS THE FIRMWARE UPDATE PAGE, WHICH WAS PUBLICLY ACCESSIBLE FOM THE INTERNET. WE BELIEVE THE DEVICE MAY STILL CONTAIN SOME STOLEN DATA IN THE FORM OF A FLAG.TXT. FIND THE WAY THE MACHINE WAS COMPROMISED AND RETRIEVE THIS FILE. YOU CAN FIND THE FLYSWATTER HERE. YOU CAN FIND A COPY OF THE SOURCE CODE FOR THE PAGE WE EXTRACTED FROM THE FIRMWARE SOURCE
http://145.111.166.228/
Mirror: source.php.txt

No write up available for this challenge.

WEB300

MISSION
OUR RECENT SUCCESS ON THE OYSTER FARM HAS LEAD TO NEW BREAKTHROUGH. APPARENTLY, ONE OF THE OYSTER SCANNERS WAS COMPROMISED BY THE SAME ATTACKER, AND IT MAY STILL CONTAIN SOME OF THE STOLEN DATA. FIND THE FILE FLAG.TXT, WHILE THE TRAIL IS STILL HOT. YOU CAN FIND THE OYSTER SCANNER HERE.
http://145.111.166.229/

No write up available for this challenge.

WEB400

MISSION
WHOEVER HAS BEEN ATTACKING US, THEY HAVE MANAGED TO LOCK IN UNITS 401-403 BY OVERWRITING THE CONFIGURATION OF THE BUILDING’S ELECTRONIC LOCKS. LUCKILY, WE FOUND THE CONFIGURATION RESTORE PAGE FOR ONE OF THE LOCKS IN QUESTION. PERHAPS YOU CAN USE IT TO RECOVER THE NEW MASTER SECRET, SO WE CAN FREE OUR IMPRISONED BROTHERS.

Mirror: index.cfm.txt

No write up available for this challenge.

One Comment

So, what do you think ?