Kaspersky Industrial

Kaspersky Lab's fourth international industrial CTF to test the security of smart devices and industrial systems

November 23 - November 24 2018

Kaspersky Industrial

This was a real bear, and a greatly misguided idea for the Mohawk Cybersecurity Club to take on as their first CTF. Not only were the challenges beyond our beginner knowledge, there were a lot of server issues that prevented us from accessing many of the challenges for more than a minute or two at a time. The site is no longer accessible, so the challenges described here are from my memories of them.


This challenge was a webpage with a couple of text fields for a “number or token”, an operator, and another number or token. A test of 1+1 resulted in a token being generated, which was a Base64 encoded expression of the 1+1 using the variables $x, $op, and $y. I did not recognise the (unencoded) language for the expression, but searching for the “stringify” element in the expression pointed towards JSON. Putting that token into one of the number/token places, used that expression in that position (e.g. (1+1) + 1). I tried a few nerdy expressions – 6x9, 6x7, 7x191 – without success. The URL contained ?action=calc and the javascript did contain a reference to a “flag”.


This webpage suffered from a lot of server issues, and not surprisingly since one of the few times that we got something other than a spinning reload sign we got a 429 error referencing “too many requests” and mention of a limit of 2 per 1 second. The HTML for the page showed a form with a password, with a maximum input size of only 6 characters. I expect that many people were simply hammering at the server with brute-force password checks in that 6 character range – at 2/s that was going to be a long day, but maybe they got lucky. The HTML also contained a “KLCTF{Whoo,hoooo}” flag that turned out to be a red herring. When things were working, though, there was a picture of an owl and a text field with a submit button. The image was a normal PNG (confirmed looking at hex and using pngcheck). Entering any wrong password caused a new unique scrambled image (just a wild spattering of pixels) to replace the owl image. Even after confirming the PNG nature of the file (hex and pngcheck), I tried string and binwalk on the pixel-scramble image with no good results. One thing that I did notice was some rotational streaking in the pixel-scramble image, and my suspicion is that the correct password is required of an algorithm to unscramble the image and that there is some reversible rotational component (sort of like reversing laminar flow). That was beyond our collective coding ability that day.


This was an ELF binary file for Ubuntu 7.3 and a webserver was referenced in the challenge. I started with scanelf, but my only note on its results is “dynamically linked shared library”. My next step was rabin2 (rabin2 –qz), which showed password insertion to passwd.db, options to TCP connect to a server, and the specific number of registers or bytes required (for connection?). The most encouraging find was “SELECT P FROM K WHERE P=?”, which I thought would open up an opportunity for SQL queries or injection. I think the procedure required was to get it to open a new connection, access the passwd.db, and INSERT a new password using “INSERT OR IGNORE INTO K(P) SELECT ‘%s’” – my notes include an idea about fixing what I though was a typo (“INSERT IGNORE “ rather than “INSERT OR IGNORE”).

This did, however, get me looking a bit more at how to view the contents of ELF and other binaries and executables:

readelf –a lets you look at the structure and data, in particular the headers scanelf and execstac show stack details objdump –x provides more details on the program headers ldd and lddtree can show dependencies of dynamic (externally linked) libraries radare2 (particularly rabin2) came up as the most useful for the analysis I could do so far.
 rabin2 –qz ./filename extract information from binaries (somewhat similar to strings)
 rasm2 is an assembler/disassembler tool that allows movement and editing throughout the binary
 s = move to a memory address
 x = hex dump a block of memory
 wx = write hex pairs
 ? = help
 q = quit


We took a poke at these with no real leads, and my notes are sparce for them.


Final Score: 0/???
Final Rank: ??? out of ???