NSEC21 - Goldsmiths' Guild

Magicians, please sit down and read the tale of that time where I provided assistance to the Kingdom by solving their money problem.

Once upon a time, in the Kingdom of North Sectoria, a new era of technology began and a group had to learn how that technology worked to protect the Kingdom and its villagers. That group was the magicians and I was part of them during last week-end.

Check out the event's website to learn more about it. For now, here's the challenge's description :

Magician, please sit down. The Kingdom has a money problem and the King requires your assistance for a delicate operation.

The Goldsmiths are suspected of creating a new, physical currency based on Goat Pieces, the new crypto currency which is becoming popular among citizens.
This has a risk of devaluating the power of the King's treasury and ruin our economy.

We have a series of field operation that will require you stealth and technical prowess on the physical security devices.
One such device is the card reader on the guild door. We need you to go set a sniffer that can grab Access Cards Captures .

We have some technical elements for you to decrypt.

Flag 1
What is the model number of the device reading the access cards?
Format: flag-card_[MODEL]

Flag 2
What's the odd username used to breach into the guild?

Flag 3
What's the name of the attack used to breach into the guild?
Format: flag-card_[attack]

As a magician, the first thing you need to do is understand what needs to be analyzed. For this specific challenge, we are given a capture file (access_card.pcap) that should contain enough information to identify: - the model of the scanner - the username used to breach into the guild - the name of the attack used

Let's take a look at the file in Wireshark.

The first thing I noticed was unusual: the protocol is... USB?? Oh well, that's a first for me! Luckily, as a magician, I was heavily trained in Google Fu by my mentors during my early years, so searching for documentation proved to be the easiest part . After some reading, I came to understand what the first few packets meant. Here's the gist of it.

When a USB device is connected, power will flow through and a process called USB Device Enumeration will start. That process has many steps, but only the last three are important for us to understand the six packets. In order, the computer asks the USB port: 1. To send its device descriptor (request in packet #1, response in packet #2); 2. To send all its configuration descriptors (request in packet #3, response in packet #4); and 3. To set a specific configuration (request in packet #5, response in packet #6).

If you were observant, you probably realized that a similar enumeration happen twice: from packet #1 to 6 and from packet #7 to 12. If I understand correctly, this means that we have two USB devices that were just connected.

The first flag

According to the documentation, the DEVICE descriptor contains the information we are looking for in the idProduct field. This field is a two byte digit that needs to be looked up online . Hopefully, this won't be needed this time because Wireshark translate it for us. How convenient!

If we look at the first device descriptor (in packet #2), we can see that this is a USB hub. This is probably not the device we are looking for.

Looking at the second device descriptor (in packet #8), we see that this is a Barcode Scanner! We can take the model number and submit it to the scoreboard.

Flag #1: flag-card_EVHK0012

The second flag

For this one, we are looking to extract the data that was read by the scanner. To understand better how the scanner talks over USB, let's go back to the CONFIGURATION descriptor.

The barcode scanner is actually just a glorified keyboard. Interesting. This makes me want to use barcodes to type my long passphrases, but it would be about as secure as using a post-it so let's forget about that idea.

Don't take that idea seriously.

For your own good.

Please.

Anyway, now that we know that a barcode scanner is just a glorified keyboard, we can make sense of what is sent by the device to the host. A keyboard is a Human Interface Device (usually written short as HID ) and we found some juicy information about it earlier.

If you've played with Wireshark before, you might already know this, but you can extract a field from each packet using its commandline counterpart, tshark . To learn the name of a field you can look at the bottom left side of Wireshark and you'll see its name:

The field named usbhid.data is the one we are interested in. This field contains the data that the scanner is sending us in each interrupt. To extract all the HID data that came from the barcode scanner, I used the following command :

tshark -r access_cards.pcap -Y 'usb.src == "2.2.1"' -T fields -e usbhid.data > access_cards.data

The output is a bunch of 9-bytes hexstring, each representing a packet. The first byte is called the Report ID and is used to tell which Report Descriptor should be used to understand the format. Unfortunately, it seems like the GET_REPORT exchange is missing from the pcap, so we'll need to do without it. Since we have no use for the Report ID , let's just drop it and focus on the other 8 bytes.

According to page 70 of this document , it is plausible that the keyboard uses the so called boot protocol . The 8 bytes would have the following meanings:

On page 66 of the same document, we have the definition of each bit for the modifiers byte:

And last but not least, pages 53-59 of this other document describe the value that is represented in key codes. Here's the first few values:

At this point, I think a magician has everything they need to parse the data, so I went ahead and made a little script to speed up the translation from key codes to ASCII:

The script needs a dump of all the usbhid.data in a file named access_cards.data to run successfully. This is CTF code, so I did not bother for a cute interface this time. The data is the same that was extracted with tshark earlier, scroll up a bit if you missed that part.

When I ran the script, magic happened and I was able to see the name of those who scanned their badges (and the flag of course!):

From the context, I understood that flag-card_faraday_backdoor was the username created by the malicious magician to enter the Goldsmiths' Guild.

Flag #2: flag-card_faraday_backdoor

The third flag

From the output of the script, I recognized the typical SQL injection and submitted that as the third flag. When I looked at the output of the script, I recognized the third line as a typical SQL injection and submitted that as the third flag.

Flag #3: flag-card_sqlinjection

And now what?

The Kingdom appreciated my help, but it is not over yet. We only gained access to the building of the Goldsmiths' Guild, we still need some more efforts to gather proof that the Goldsmiths are creating that new currency before we can take a break.

You can take a look at another write-up by Magician Émilio .