Ctf on Mal Breaks Things

Long Distance 2

mal@sec.gd (mal) — Sun, 28 Jan 2024 23:00:00 +0000

This weekend I participated in the Real World CTF with WreckTheLine. Unlike many other CTFs, these challenges were all based on real applications and systems. It’s interesting being able to use (and gain) domain knowledge, and while contrived challenges are fun, exploiting a system that exists in the real world – on the real internet – is another level of engagement.

Challenge

This misc challenge consisted of a 290 MB WAV file named 486_375MHz-1MSps-1MHz.wav, an 8 MB flash_dump, and a mandate to recover the information contained in the transmission:

Of late, whispers doth persist behind mine back. Yesterday, under the studio tower, a peculiar contraption was found by me. I am most intrigued to discover the content of their discourse.

RF

The WAV file metadata showed 51 seconds, 2 channels, 24 bit resolution, and 1 MHz sample rate. Audibly, it was a mostly silent with several bursts of data, sounding like a pop followed by buzzing.

Audacity was in the mood for 3 hours of plugin updates, so I used Sonic Visualiser, which showed the bursts of data in the waveform. Zooming in, things became more interesting - FM? We can use the spectrogram tool to see the distribution of energy (color) across frequencies (Y axis) over time (X axis), with an interesting result… And further into the data section, discontinuities in the frequency sweeps - Probably the symbols that we needed recover data from.

A teammate, qwertboy, had linked a writeup of last year’s Long Distance challenge by the organizers team, where they had a similar file containing a RF capture, and found the flag by decoding the LoRaWAN traffic.

What I was seeing matched signals they found. Both had similar patterns in the waveform and demodulated FM, and after setting up GNU Radio, in the constellation display.

Flash Image

My first port of call with an unknown firmware image is usually binwalk. In this case the signatures and strings it found led me to believe that this was an image for an ESP32, used mesh networking, and (incorrectly) that it might be for an IoT lightbulb or lighting controller.

$ binwalk flash_dump

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
88595         0x15A13         Neighborly text, "neighbors a simple (0 id) broadcast"
109607        0x1AC27         HTML document header
109988        0x1ADA4         HTML document footer
113954        0x1BD22         Neighborly text, "Neighbor Info module config: Ambient Lighting"
114583        0x1BF97         Neighborly text, "Neighbor Info module config: Ambient Lighting"
118036        0x1CD14         Neighborly text, "NeighborsKET from Node 0x%x to Node 0x%x (last sent by 0x%x)"

[...]
155668        0x26014         Unix path: /home/runner/.platformio/packages/framework-arduinoespressif32/libraries/SPI/src/SPI.cpp
173532        0x2A5DC         AES S-Box
[...]

Extracting the identified files with binwalk -e found assorted HTML and CSS, along with a JSON blob from 0x3A7000:

{
  "name": "Meshtastic",
  "short_name": "Meshtastic",
  "start_url": ".",
  "description": "Meshtastic web app",
  "icons": [
    {
      "src": "/icon.svg",
      "sizes": "any",
      "type": "image/svg+xml"
    }
  ],
  "theme_color": "#67ea94",
  "background_color": "#67ea94",
  "display": "standalone"
}

So I knew early that we’re working with Meshtastic, but didn’t yet understand LoRa vs LoRaWAN. Reading through the site found radio settings to help with decoding, the Meshtastic packet header format to help with parsing, and an overview of the encryption. I later found a diagram of a LoRa Meshtastic packet which was useful, but note the backwards flags field.

LoRa

I spent quite a while trying to get rpp0/gr-lora set up (it officially requires the long-dead python2) and working, and a while more seeing if tapparelj/gr-lora_sdr or its fork martynvdijke/gr-lora_sdr (as used by the AUR package) were any more cooperative. In the end, I replaced the python2-foo dependencies with python3-foo, and it didn’t complain. Still, the correct configuration for the decoder eluded me.

Saturday morning started with another teammate, tcode2k16, finding a potential signal decoding result before I’d finished breakfast. We individually chased our tails for a while on this, and it turned out to have two issues - The decoded data was incorrect, and we were confusing LoRa (physical layer) with LoRaWAN (a communication protocol built on LoRa) and trying to parse the payload as the latter.

We Need to Go Deeper

Once tcode was making progress on decoding and parsing, I went back to the firmware image. The source for this build, less any CTF modifications, is at meshtastic/firmware@v2.2.14.57542ce, and tcode found a default AES key there, but we should check for a custom one in flash.

To start, I dropped the image into a hex editor, which wasn’t particularly useful until I looked into how ESP-IDF partitioning works. The default partition table isn’t at the beginning of flash, but at 0x8000.

Rather than spend time parsing the partition table correctly, I guessed the layout based on the hex dump:

00008000  aa 50 01 02 00 90 00 00  00 50 00 00 6e 76 73 00  |.P.......P..nvs.|
00008010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00008020  aa 50 01 00 00 e0 00 00  00 20 00 00 6f 74 61 64  |.P....... ..otad|
00008030  61 74 61 00 00 00 00 00  00 00 00 00 00 00 00 00  |ata.............|
00008040  aa 50 00 10 00 00 01 00  00 00 25 00 61 70 70 00  |.P........%.app.|
00008050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00008060  aa 50 00 11 00 00 26 00  00 00 0a 00 66 6c 61 73  |.P....&.....flas|
00008070  68 41 70 70 00 00 00 00  00 00 00 00 00 00 00 00  |hApp............|
00008080  aa 50 01 82 00 00 30 00  00 00 10 00 73 70 69 66  |.P....0.....spif|
00008090  66 73 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |fs..............|

Much later I realized the partition table, human-readable with extra info, is also available right in the firmware repository as partition-table.csv. Here’s that version, to save at least one of us some squinting at hex:

# Name,   Type, SubType, Offset,  Size, Flags
nvs,      data, nvs,     0x009000, 0x005000,
otadata,  data, ota,     0x00e000, 0x002000,
app,      app,  ota_0,   0x010000, 0x250000,
flashApp, app,  ota_1,   0x260000, 0x0A0000,
spiffs,   data, spiffs,  0x300000, 0x100000,

“NVS” is used by the ESP-IDF Non-Volatile Storage Library, which seemed like a good place to store settings. Carve out 0x5000 bytes starting at 0x9000 in the image with dd if=flash_dump bs=$((0x1000)) skip=9 count=5 of=nvs.bin, and parse it with nvs_tool.py from the ESP-IDF repository: python nvs_tool.py -i nvs.bin. Unfortunately none of the data it held looked like a 128-bit or 256-bit AES key, or for that matter, any of the other configuration parameters I was expecting.

Where else would the firmware store its configuration? Looking back at the partition table, “nvs” was a bust, “otadata” seems update-related, “app” is probably the running code, “flashApp” may be for in-progress updates, or “spiffs”. The “SPI Flash FileSystem” sounded promising, so I extricated it with dd if=flash_dump bs=$((0x100000)) skip=3 count=1 of=spiffs.bin, but igrr/mkspiffs didn’t like it. file wasn’t familiar. hexdump showed this at the beginning of the file:

00000000  03 00 00 00 f0 0f ff f7  6c 69 74 74 6c 65 66 73  |........littlefs|

Ah. littlefs on a partition named spiffs. Probably some backwards-compatibility thing…

Regardless, the littlefs readme had a lot of useful tools. tniessen/littlefs-disk-img-viewer is a webapp with a live demo, which after some block size guessing (4096) was able to read the filesystem. static/ held the Meshtastic webui resources, and prefs/ had channels.proto, config.proto, and db.proto, which I downloaded.

Protobuf

Protobuf (protocol buffers) is a relatively common data interchange system, which Meshtastic uses for both preferences and over-the-air communication. At first I tried to use protoc with the Meshtastic protobuf definitions to produce Python code to read the files, and then protobufpal, but they weren’t parsing the prefs files, so in the interest of time I ended up using mildsunrise/protobuf-inspector.

$ protobuf_inspector <channels.proto
root:
    1 <chunk> = message:
        2 <chunk> = message:
            2 <chunk> = bytes (1)
                0000   01                                                                       .
        3 <varint> = 1
    1 <chunk> = message:
        1 <varint> = 1
        2 <chunk> = message:
            2 <chunk> = bytes (32)
                0000   CE F8 DB 8E 8E 60 17 FD 6D CC A2 1D B8 A1 47 6D 45 14 80 AC D7 F4 F9 F7  .....`..m.....GmE.......
                0018   69 A7 63 F5 28 C0 11 F7                                                  i.c.(...
            3 <chunk> = "Buddies"
            4 <32bit> = 0x00000001 / 1 / 1.40130e-45
        3 <varint> = 2
    1 <chunk> = message(1 <varint> = 2, 2 <chunk> = empty chunk)
    1 <chunk> = message(1 <varint> = 3, 2 <chunk> = empty chunk)
    1 <chunk> = message(1 <varint> = 4, 2 <chunk> = empty chunk)
    1 <chunk> = message(1 <varint> = 5, 2 <chunk> = empty chunk)
    1 <chunk> = message(1 <varint> = 6, 2 <chunk> = empty chunk)
    1 <chunk> = message(1 <varint> = 7, 2 <chunk> = empty chunk)
    2 <varint> = 22

The leading number associates a value with its attribute in the protobuf definition. The root seems to be an array of Channel objects, so within each of those we should be able to look for the attribute numbers in channel.proto. Channel->2 is a ChannelSettings settings, and ChannelSettings->2 is bytes psk. We’ve found our channel key!

Since then I’ve realized that prefs/channels.proto isn’t a Channel from channel.proto, it’s a ChannelFile from deviceonly.proto, so here’s the interesting parts in a more readable format:

{
  "channels": [
    {
      "index": 0,
      "settings": {...},
      "role": "PRIMARY"
    },
    {
      "index": 1,
      "settings": {
        "channel_num": 0,
        "psk": [
            206,248,219,142,142,96,23,253,109,204,162,29,184,161,71,109,
            69,20,128,172,215,244,249,247,105,167,99,245,40,192,17,247
        ],
        "name": "Buddies",
        "id": 1,
        "uplink_enabled": false,
        "downlink_enabled": false
      },
      "role": "SECONDARY"
    },
    [followed by 6 empty role: DISABLED channels]
  ],
  "version": 22
}

And the LoRa part of prefs/config.proto:

{
  "lora": {
    "ignore_incoming": [],
    "use_preset": true,
    "modem_preset": "LONG_FAST",
    "bandwidth": 0,
    "spread_factor": 0,
    "coding_rate": 0,
    "frequency_offset": 0,
    "region": "CN",
    "hop_limit": 3,
    "tx_enabled": true,
    "tx_power": 19,
    "channel_num": 66,
    "override_duty_cycle": false,
    "sx126x_rx_boosted_gain": true,
    "override_frequency": 0
  }
}

We no longer have to guess our LoRa settings, we can just copy the LONG_FAST parameters from the radio settings page!

Back to Decoding

With known radio settings we could revisit the GNU Radio flow graph with gr-lora. Here’s what I ended up with: download grc

And its output: full log

Bits (nominal) per symbol: 	5.5
Bins per symbol: 	2048
Samples per symbol: 	8192
Decimation: 		4
 2d 31 e0 bc 4b 6c fa c4 c0 6d fa 66 26 d2 02 0b 08 a7 92 b3 78 fb 63 77 d7 e0 54 d7 4f 67 1e c0 2d f1 8c 7d 04 66 c9 31 bb 22 40 0f c9 ec 25 c8 71 33 (Klmf&xcwTOg-}f1"@%q3)
[...]
 22 31 70 ff ff ff ff c4 c0 6d fa 5f 8a 54 22 02 04 a7 92 53 1f 89 a3 6f ea 30 18 c9 ce b7 e7 1f a3 cd 72 71 ed a7 3a (m_T"So0rq:)
 09 11 40/usr/include/c++/13.2.1/bits/stl_vector.h:1125: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](size_type) [with _Tp = unsigned char; _Alloc = std::allocator<unsigned char>; reference = unsigned char&; size_type = long unsigned int]: Assertion '__n < this->size()' failed.

The crash may have been because of my python2/python3 change. I hoped it wasn’t preventing decoding of the message with the flag, and it turned out fine.

This still looked a bit nonsensical consider the Meshtastic header format. When aligning the first part of each message, I would have expected to see repeated source and destination IDs, channel hash bytes, and padding, and flag bytes with the high nibble empty.

DEST_NODEID SRC_NODEID_ PKT_UNIQ_ID FL CH PAD__ DATA...
2d 31 e0 bc 4b 6c fa c4 c0 6d fa 66 26 d2 02 0b 08 a7 92 b3 78 fb ...
1b 31 e0 c4 c0 6d fa bc 4b 6c fa 29 5d 91 38 03 08 a7 92 12 19 7e ...
49 31 20 c4 c0 6d fa bc 4b 6c fa a6 41 be 1e 0b 08 a7 92 b9 4d 99 ...
1b 31 e0 bc 4b 6c fa c4 c0 6d fa 0f 21 39 44 03 08 a7 92 b8 56 c7 ...
5f 30 00 ff ff ff ff c4 c0 6d fa a3 f3 0f 12 03 08 a7 92 aa c1 8d ...
5f 30 00 ff ff ff ff c4 c0 6d fa a3 f3 0f 12 02 08 a7 92 aa c1 8d ...
...

There are some columns that do have the properties I would expect, though… Let’s shift the column headers over a byte at a time and see if they line up:

?? ?? ?? DEST_NODEID SRC_NODEID_ PKT_UNIQ_ID FL CH PAD__ DATA...
2d 31 e0 bc 4b 6c fa c4 c0 6d fa 66 26 d2 02 0b 08 a7 92 b3 78 fb ...
1b 31 e0 c4 c0 6d fa bc 4b 6c fa 29 5d 91 38 03 08 a7 92 12 19 7e ...
49 31 20 c4 c0 6d fa bc 4b 6c fa a6 41 be 1e 0b 08 a7 92 b9 4d 99 ...
1b 31 e0 bc 4b 6c fa c4 c0 6d fa 0f 21 39 44 03 08 a7 92 b8 56 c7 ...
5f 30 00 ff ff ff ff c4 c0 6d fa a3 f3 0f 12 03 08 a7 92 aa c1 8d ...
5f 30 00 ff ff ff ff c4 c0 6d fa a3 f3 0f 12 02 08 a7 92 aa c1 8d ...
...

That looks better, the fields all had the properties I expected. The leading 3 bytes ended up being the LoRa header, as seen in the diagram - Payload length, coding rate, CRC flag, header CRC, padding.

On to Parsing

Disassembling the headers in python was relatively straightforward, but decrypting the Meshtastic payload was aggravating. The encrypt and decrypt functions are the same for AES-CTR, and for us are in ESP32CryptoEngine.cpp. I should have looked at the relevant bits for other platforms, since they must all be compatible and others are more straightforward, but I didn’t. The problem boiled down to me chasing endianness issues before double checking that I was putting the parts of the nonce together in the wrong order or trying to decrypt other messages.

While I worked on building a custom Counter for PyCryptodome, tcode used my parsing and the python-mbedtls¹ library to successfully decrypt it. A few minutes later I got mine working, using the PyCryptodome, the default Counter, and the correct nonce ordering and message.

#!/usr/bin/env python3

from Crypto.Cipher import AES
from Crypto.Util import Counter


pkt = bytes.fromhex(
    "683060ffffffffc4c06dfa8899c2020304a7925001502e35d73ab793c3e9ad6acc9da6a4955bc56b8054e9989d76f5355cf2868b90bffae321d51077be4e1774fc074f63a4c0af6ba38f33a829b0784bdadbcc738b16e930e741c48f4d6c0cab012e5605122dce40eaeb7b7626"
)
psk = bytes.fromhex(
    "CEF8DB8E8E6017FD6DCCA21DB8A1476D451480ACD7F4F9F769A763F528C011F7"
)

lora_header = pkt[0:3]
has_crc = (lora_header[1] >> 4 & 1) > 0
lora_payload = pkt[3:]
lora_payload_crc = lora_payload[-2:] if has_crc else None
if has_crc:
    lora_payload = lora_payload[:-2]
lora_payload_len = lora_header[0]
if len(lora_payload) != lora_payload_len:
    print(
        "Warning: Incorrect payload length. expected {}, got {}".format(
            lora_payload_len, len(lora_payload)
        )
    )
mt_header = lora_payload[:16]
mt_dest = mt_header[0:4]
mt_src = mt_header[4:8]
mt_packet_id = mt_header[8:12]
mt_flags = mt_header[12]
mt_flags_hop_limit = mt_flags & 0b111
mt_flags_want_ack = (mt_flags >> 3 & 1) > 0
mt_channel_hash = mt_header[13]
mt_header_padding = mt_header[14:16]
mt_payload = lora_payload[16:]

nonce = mt_packet_id + b"\0" * 4 + mt_src
cipher = AES.new(psk, AES.MODE_CTR, initial_value=0, nonce=nonce)
mt_payload_decrypted = cipher.decrypt(mt_payload)

open("decrypt.out", "wb").write(mt_payload_decrypted)
print(mt_payload_decrypted)

Victory!

b'\x08\x01\x12Talright alright. the key is rwctf{No_h0p_th1s_tim3_c831bcad725935ba25c0a3708e49c0c8}'

Fully parsed:

{
  "portnum": "TEXT_MESSAGE_APP",
  "payload": "alright alright. the key is rwctf{No_h0p_th1s_tim3_c831bcad725935ba25c0a3708e49c0c8}"
}

Conclusion

Thanks to tcode for working with me on this challenge. At one point during decoding they said “I was doing something silly”. In my experience, that’s all of programming, CTFing, and many other technical endeavors. I hope this post was worth the read despite its length, but I think it’s important to not gloss over the challenges and mistakes instead of reinforcing anyone’s imposter syndrome.

WreckTheLine finished in 7th place of 2291 teams. This challenge was worth 320 points out of our 1662 (19%), and was solved by a total of 9 teams.

I would recommend against using Synss/python-mbedtls for real cryptography. It has basically no documentation I can find besides examples, and what is there (docstrings) is scary. For example, AES.new(key, mode, iv, ad) (note that iv=nonce+counter, effectively):

iv: The initialization vector (IV). The IV is required for every mode but ECB and CTR where it is ignored. If not set, the IV is initialized to all 0, which should not be used for encryption.

AES-CTR must never use the same (key, nonce, counter) twice or its security properties are broken. Luckily failing to specify an iv parameter does produce an error. Additionally, the ad (Associated Data / Additional Authenticated Data, I assume) parameter is not even in the docstring. ↩︎

]]>

Hacker's Playground: Legonigma

mal@sec.gd (mal) — Tue, 27 Sep 2022 04:00:00 +0000

I recently participated in Samsung’s Hacker’s Playground CTF with Wreck The Line. We finished with 1592 points, in 26th place of 1075 teams. Most of my time was spent on Legonigma, an interesting 500 point challenge based on two renders of a Lego cryptography gadget.

The Challenge

Decipher ciphertext: 59x8wl9pjsava3grn0il79aoq307f20a6huc3xnos289cd8xv1fn2znuoa2bq8959chbktwfow8c3azpvo3c59jz4

First Impressions

Cool!

I had a limited selection of possible parts, assuming it was built with production Lego pieces. The only moving parts were gears and a differential, so I suspected the relationships between input and outputs were just a series of ratios.

Why were there three outputs? Maybe it produced 3 ciphertext characters per plaintext character? No, the ciphertext was 89 characters total, which isn’t divisible by 3… I must need to guess the order?

Pieces in Play

Using the images and information from a blog post about Lego gears I listed the pieces I might face, by type, tooth count, and features:

Regular gears (no bevel)
- 8 (axle)
- 16 (axle and small spaces)
- 24 (axle and four round post holes)
- 40 (axle and a bunch of axle and post holes)
Double Bevel
- 12 (axle)
- 20 (axle, spaces)
- 28 (axle and four post holes)
- 36 (axle plus two posts and two axles)
Differential
- Three identical single-bevel inside, so ratios don’t matter
- Outside: 16 and 24 tooth

Attempt One: Procedural

My first instinct was to follow the gearing through, noting each number of teeth:

36 (input, green)
hard link to 20 (grey)
rotates 12 (blue)
rotates 20 (grey)
splits to A

A1:
rotates 12 (blue)
hard link to 36 (grey)
rotates 12 (blue)
hard link to 36 (yellow, out1)

A2:
hard link to 28 (blue)
...

I intended to turn this into a simple procedure that would just do the math for each step, keeping track of the angle of each gear, but I realized there’s a much easier way to simplify it…

Attempt Two: Mathematical

If I pretend I’ve turned the input one full rotation clockwise, how does each gear – and therefore each output – behave?

input 1 CW
grey 1 CW
blue (irrelevant) CCW
grey 1 CW (split A)

A1 (left):
blue 20/12=5/3 CCW
grey 5/3 CCW
blue 5 CW
yellow 5 CW (out1)

A2:
blue (irrelevant) CCW
grey 1 CW
blue 20/12=5/3 CCW (split B)

...

Following this through, I arrived at the following ratios between input and output:

1:5 for the front left output
1:5/3 for the front right output
1:38/9 for the rear output

Having made up simple ciphers in the past, after finding the 1:5 output I was kind of expecting the others to also be prime numbers. Oh well, the math doesn’t lie… Right?

But after writing some python code to show outputs for every possible first couple characters of input, I couldn’t get the outputs to match the ciphertext. Notably, for lots of valid inputs, the rear and right-side outputs sat between letters. Unless this machine would be provided to users with specific instructions, that seemed odd.

I spent a long time chasing guesses about what those instructions might be - “Keep turning until the outputs are all exactly at a tooth/letter”? “Keep turning until the one output for this step is exactly at a tooth/letter”? After some rubber duck debugging and a gentle nudge from the challenge author, I re-examined my understanding of the machine, but still couldn’t find anything wrong.

The Nuclear Option

If I couldn’t logic it out, I’d try to rebuild the device’s mechanics using a tool.

There were several relatively simple tools for Lego gear ratios, but besides them being a bit difficult to build a complex machine in, it didn’t seem they would be able to handle the differential, or possibly even the splits.

I ended up finding the Technic Brick Power Gearing Ratio Calculator, which seemed to do exactly what I needed! …when provided with a “Lego Technic .ldr file”. Okay, it seems I need to use something like LeoCAD to build that…

A lot of twiddling and building later, I had reproduced the machine:

But when I loaded it into the gearing ratio tool, attaching a motor, and running it, the entire model turned red, indicating a jammed motor.

I assumed the tool just didn’t know how to handle the differential, and removed the gear before the rear output to let both sides of that branch run separately, then combined the adjacent gears’ motion myself. The results matched my original calculations perfectly, and I was lost again.

After many more lines of code and attempts to figure out how the machine would be used, I eventually arrived at a realization: In a row of three gears, turning the first clockwise at 1 RPM and the third clockwise at 2 RPM does not cause the middle one to rotate counterclockwise at 3 RPM. Don’t ask how I had arrived at my original understanding – I do not know, and it is as obviously wrong in retrospect as it is to you. The resulting conclusion was that the branch through the front-right output and the differential was not modifying the ratio of the rear output. The simulation was correct. My understanding of the machine actually was a deadlock.

I stared at the challenge’s renders more, and eventually found the problem: There was in fact no motion going through the front-right output’s axle, and the direction of control through the differential is the opposite of what I thought.

See it? I sure didn’t.

After some logic, some trial-and error, and a lot of staring at close-ups of small details in the original render, I moved a few elements around. Here’s a bottom view of the change, with the front-right output gear at the top center:

Then I loaded the amended model into the simulator:

Your browser does not seem to support this video.

And got some much nicer ratios for the outputs…

So I updated my code to use these much more reasonable ratios, aaaaand… No valid input produced an output matching the first three characters of ciphertext.

Reaching further

Lacking any idea how the outputs were meant to be read, I figured it was time to investigate the challenge name’s call-out to the German Enigma machine to look for hints.

Enigma

Known-plaintext attack
Not ECB (advances rotors by each character)
Random mapping in each code wheel and on plugboard
Never encrypted a letter to itself
Decryption == encryption (if a->r, r->a)
Key is rotor selection, rotor position, reflector position, plugboard config

This machine

No known-plaintext available
ECB (all rotors end up back at A when input is rotated back to A)
Probably not enough ciphertext to do statistics for random mappings
Encrypts A to A,A,A
How to decrypt, besides “turn input til all three outputs match your ciphertext block”?
If there’s a key, how is it configured? 4 pointer positions * 4 rotors * 6 output rotor orders = 96 possibilities?

Maybe I was missing an instruction like “Advance the input by n teeth, where n is the index of the next plaintext character”? I couldn’t figure out how to turn the three outputs into a ciphertext.

Feeling Dumb (Again)

There’s no galaxy brain instructions, I just needed read the outputs in a particular order, trivially discovered. 1:13 first, then 1:5, then 1:7.

I achieved the second solve for Legonigma, for 460 points, 17 minutes after the first team. SCTF{th3w0rld1sadang3rou5placeno7becau5e0fth0sewh0do3v1lbutbecau5eofth053wh0l00konandd0n0th1ng} (“The world is a dangerous place, not because of those who do evil, but because of those who look on and do nothing”)

Conclusion

I wish the ratios hadn’t been whole numbers, so the “no reversing” instruction meant something!

Thanks to “Your expectations are reasonable” Cybrosis for a really neat challenge and a couple nudges, rebuilding the machine was fun. Thanks also to Samsung for organizing this event, and my teammates at WreckTheLine for all of their work and for putting up with my rubber ducking.

Downloads

My Python code, including a lot of commented-out wrong attempts, and overbuilt since I originally expected one full input rotation to not return to the starting state: legonigma.py

The .ldr model of the machine I built in LeoCAD: legonigma.ldr

]]>

ImaginaryCTF 2021

mal@sec.gd (mal) — Tue, 27 Jul 2021 04:00:00 +0000

This weekend I participated in ImaginaryCTF 2021 with WreckTheLine. We finished third out of 1018 entrants, the final team to complete all 55 challenges and hit 11330 points, missing second place by 3.5 minutes.

System Hardening 5

“CyberPatriot but run by roo fanatics… What could go wrong…”

At 450 points, System Hardening 5 was in the highest value category of challenges. It was in the pattern of CyberPatriot, where teams download and run a VM, find and fix all of the vulnerabilities. A scoring engine checks the scored items every minute or so and reports to the scoreboard.

As with CyberPatriot, we start with the readme. The major constrants today are:

No updates at all. Makes sense, that’s time-consuming and uninteresting.
Critical services: Remote desktop, print spooler.
Don’t disable SMB or the scoring engine may break

Forensics

Let’s start¹ with the Forensics questions, as the readme says, so we don’t accidentally destroy artifacts we’ll need to answer them.

An [sic] user on this system was compromised, allowing rooReaper to break in. What is the username of this user?

Well, let’s look around. Event log? Exploit artifacts? Let’s check this other file on the desktop first, text-messages-from-mom.txt.txt [sic].

MOMtotallynotrooreaper: hi roo! this is definitely mom here
rooYay: oh hi mom didnt see you there all too well
MOMtotallynotrooreaper: ?
rooYay: nvm, what did you text me for
rooYay: and is this a new number? i dont see the message history
MOMtotallynotrooreaper: uhh yea this is a new number
rooYay: oh ok
MOMtotallynotrooreaper: can you disable your firewall? and enable smb pls and disable your antivirus
rooYay: ok whatever you say mom…
rooYay: ill look up some tutorials
MOMtotallynotrooreaper: NO DONT LOOK AT TUTORIALS
rooYay: ok i wont what do i do
MOMtotallynotrooreaper: ill show you
MOMtotallynotrooreaper: btw what is rooPOG’s password
MOMtotallynotrooreaper: i heard he loves sharing
rooYay: its just password1337 nothing fancy
MOMtotallynotrooreaper: thanks!
…

Looks like rooYay fell for the classic “hi this is your mother” phish, and gave out rooPOG’s password.

Forensics Question 1 correct - 7 points

That also gives us the answer to the next forensics question:

What is the password of the compromised user from the previous question?

password1337 nothing fancy

Forensics Question 2 correct - 7 points

The other forensics questions require some research.

What is the CVE ID of the vulnerability that allowed rooReaper to escalate privileges?

I poked around in rooPOG’s home directory for a bit, finding xconsole.exe and vlib.dll in Downloads\foobar. The latter was detected as Win32/Mamson.A!ac, which doesn’t obviously use any exploits. I enabled Windows Defender and started a scan, and before I had found anything in the event viewer, it had found C:\temp\PrintNightmareLPE.exe.

Print Nightmare, CVE-2021-34527, is a recent vulnerability that allows a remote attacker to install a malicious printer driver configuration DLL to gain arbitrary code execution as SYSTEM. A variant, CVE-2021-1675, is useful for local exploitation, and was accepted as the answer.

Both of these drop the payload, in this case vlib.dll, in C:\Windows\System32\spool\drivers\x64\3\, where Defender found it alongside reverse_64bit.dll which it detected as Win64/Meterpreter.B. I removed the whole folder, along with C:\temp\ and the contents of rooPOG’s Downloads folder.

Forensics Question 3 correct - 7 points
Removed privilege escalation payload - 5 points

The final forensics question seemed like a steganography problem, but referred to another challenge in the CTF:

The background image on the Desktop contains a secret message. What is it?
HINT: It’s related to another challenge in this CTF, a reversing challenge.

The wallpaper was background.png in rooYay’s Pictures folder. It consisted of a grid of tiles, in a repeating pattern Axxxx, where there were 3 options for x. No obvious pattern was shown by stegsolve, and it wasn’t clear how to decode information in the tile pattern. I put it aside until a teammate, JaGoTu, solved roolang, which seemed potentially-related. Sure enough:

JaGoTu: roolang was just a vm that was calculating fibonacii very slowly
JaGoTu: can you send the raw png somewhere?
JaGoTu: cause the roolang basically runs png files

They ran their roolang solution on the PNG, and sent back the output: Hello, and welcome to the roos’ server!

Forensics Question 4 correct - 7 points

PUPs (Not the Fun Kind)

With the forensics questions out of the way, let’s continue through the readme. We have a list of needed services and software, so let’s remove anything that’s not on it, starting with the faux-Clippy in the corner of the screen.

First, the Startup folder for All Users in C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup\. Two shortcuts:\

chksec - Shortcut.lnk to C:\Windows\System32\chksec.exe
essential - Shortcut.lnk to C:\Windows\System32\essential.bat

Delete the shortcuts, kill the processes, delete the Clippy executable. essential.bat printed some ascii art text, copied itself to the current user’s start menu Startup folder, opened a video, and then paused. Delete the batch file from System32 and from rooYay’s %AppData%\Microsoft\Windows\Start Menu\Programs\Startup\.

Removed PUP Clippy - 3 points
Removed rickroll malware - 4 points

Installed Programs

There’s a couple shortcuts on the desktop to software that wasn’t mentioned as required in the readme, so let’s remove those. I replaced Chrome with Firefox portable, since the roos prefer IE and I very much do not. Nothing else in add/remove programs looked relevant.

Removed unauthorized program Minecraft Launcher - 3 points
Removed unauthorized program SuperAntiSpyware - 3 points

I also looked through the running processes, but nothing else there raised suspicion.

Users

Next, let’s deal with users, which is easiest from compmgmt.msc/lusrmgr.msc.

Create roocursion as requested in the readme
Rename the local administrator account as requested (can be done here or in group policy)
Make sure nobody unauthorized is in Administrators or other privileged groups
Make sure no non-builtin users exist who aren’t mentioned, poking through their home folders before deleting
Disable the Guest account, and rename for good measure
Change the password for all users

I’ll mention here that CyberPatriot often uses significantly outdated best practices and ignores how things would be done in the real world, and we also don’t know what this challenge will score on, so a lot of the things I check and changes I make to this machine are excessive, paranoid, annoying, or otherwise just weird. If we lose points for something we can easily undo the change.

Removed unauthorized user rooReaper - 3 points
Removed unauthorized user rooDevil - 3 points
Removed unauthorized user rooRage - 3 points
User rooFrozen is not an administrator - 3 points
User roocursion has been created - 3 points
Administrator account renamed - 3 points
Guest account is disabled - 4 points

Services and Firewall

Interspersed with everything else, I poke around services.msc and the control panel to make sure everything is sane. Enable the firewall MOMtotallynotrooreaper told us to disable, then make sure there’s no nonstandard or scary rules enabled. Enable cloud protection and sample sumbission for Defender, make sure the scan finished. Right click My Computer and click Properties, check $PATH and other environment variables for anything weird, make sure Data Execution Prevention is enabled for all applications, and disable NetBIOS.

Windows Firewall is enabled - 5 points

Group Policy

Before I forget, let’s make sure we’ve mitigated Print Nightmare. The MSRC post about it recommends updating (oops, can’t), disabling the print spooler (oops, can’t), or disabling inbound remote printing with Group Policy.

I fire up gpedit.msc, open Computer Configuration -> Windows Settings -> … Where’s Security Settings?

This is where I spent about half my time on this challenge. When launching gpedit.msc, Security Settings was missing. secpol.msc would show the tree starting at Windows Settings instead of Security Settings, and also omit the latter. Many answers on the internet offered a simple regsvr32 wsecedit.dll, which doesn’t work as the DLL doesn’t have the correct entrypoints for that. This is where I ran dism /online /cleanup-image /restorehealth and sfc /scannow, which didn’t find any problems.

I never did figure out what was done to break that, as I eventually gave up and tried importing an exported policy, and later started setting the policy registry entries by hand. After a while, I opened the mmc snapin again, and Security Settings was there!

It seems that it’s only broken for the rooYay user, and after setting UAC to require a password, I was unintentionally elevating as rooAstro, for whom it worked correctly. Something in my profile was breaking it. Some windows LD_LIBRARY_PATH type thing? Something in HKEY_CURRENT_USER? It didn’t directly affect security, so I put it aside again.

From there, I could much more easily continue with group policy, basically just going through every option in Security Settings -> Account Policies and Local Policies and some folders in Administrative Templates -> Windows Settings, setting everything to the most paranoid sane option.

Remember 24 passwords
60 day maximum password age
10 day minimum password age
14 character minimum length
Must meet complexity requirements
No reversible encryption
15 minute account lockout duration
10 attempt lockout threshold
15 minute counter reset timer
Enable all auditing
Go through User Rights Assignment and restrict everything as much as possible
Hey, why is Everyone allowed to take ownership of files??
You know what, let’s just disable the Administrator account
I don’t like Microsoft account signin
More audit everything
Prevent users from installing printer drivers (well… try to)
Restrict CD-ROM access to locally logged-on users
Require CTRL+ALT+DEL, force inactivity limit, require strong encryption
You get the idea.

Everyone is not allowed to take ownership of files and other objects - 5 points

Critical Services

And let’s not forget to secure our critical services. The MSRC Print Nightmare article points me to Administrative Templates -> Printers to disable “Allow Print Spooler to accept client connections”. There have been a few RDP vulnerabilities, but none with straightforward workarounds besides patching, so let’s just be sure to flip on all of the RDP server security policies. Lastly, we weren’t disallowed from disabling old versions of SMB, so use the powershell command in the docs, to check for SMBv1 and see it’s already disabled.

Inbound remote printing is disabled (PrintNightmare mitigation) - 9 points
Remote Desktop uses network level authentication - 4 points

Other Stuff

In an advanced challenge, in addition to sfc and dism to look for “creatively modified” system files, hijackthis can be helpful. In case of a well-disguised network backdoor, it’s also good to check open sockets.

Conclusion

And with that, I had 91 points, 20/21 items, and the flag appeared in the score report. There was one scored item I never found, worth 9 points. I’ll be waiting for a writeup from tirefire, the only person with 100 points, to see what I missed!

Unique ID: 8edd464b
Flag: ictf{th4nks_s0_much_f0r_s3cur1ng_0ur_s3rver!_h3r3s_4_fl4g!!!}

Update

First, Eth007, one of the challenge authors, let me know that the last scored item I couldn’t find was LSA protection.

Second, thank you to the iCTF team for selecting this as a prize-winning writeup!

New Technology

“If it’s not Windows New Technology, what else could NT stand for?”

This was a 300pt cryptography challenge in the form of a python script. It generates a random key consisting of 5 tuples, each a 512-bit prime p and an integer exponent $1 \le e < 4$.

def gen():
    private = []
    for _ in range(5):
        p = getPrime(512)
        e = getRandomRange(1, 4)
        private.append((p, e))
    return private, normalize(private)

The public key is derived by the normalize() function, which multiplies together p**e for each private key component.

def normalize(fac):
    n = 1
    for p, e in fac:
        n *= p**e
    return n

Since these are 512-bit primes, the resulting public key isn’t easy to factor.

The private key is put through the deriv() function, which has a nested loop based on divs().

def deriv(priv):
    res = 0
    for d1 in divs(priv):
        for d2 in divs(d1):
            res += normalize(d2) * phi(d2) * phi(div(d1, d2))
    return res

divs() takes the same List[Set[prime: int, exponent: int], ...] private key format and yields the cartesian product of them based on the range 0..e of their exponents:

def divs(fac, pre=None):
    if pre is None:
        pre = []
    if not fac:
        yield pre
    else:
        p, e = fac[0]
        for i in range(0, e + 1):
            yield from divs(fac[1:], pre + [(p, i)]

>>> priv = [(167, 1), (149, 2)]
>>> pprint(list(divs(priv)))
[[(167, 0), (149, 0)],
 [(167, 0), (149, 1)],
 [(167, 0), (149, 2)],
 [(167, 1), (149, 0)],
 [(167, 1), (149, 1)],
 [(167, 1), (149, 2)]]

For each entry in this list, d1, deriv() again calls divs(), and loops on that d2, adding normalize(d2) * phi(d2) * phi(div(d1, d2)) to a running total.

def phi(fac):
    res = 1
    for p, e in fac:
        if not e: continue
        res *= (p**(e - 1)) * (p - 1)
    return res

def div(a, b):  # a=d1, b=d2
    b = dict(b)
    res = []
    for p, e in a:
        assert e >= b[p]
        res.append((p, e - b[p]))
    return res

At some point here things started to smell funny - we’re collecting the sum of some math done on every divisor of every divisor… Just for fun, let’s see how this behaves when run all the way through with more manageable numbers, maybe 12 bits.

def gen_custom(count=5, size=512, max_exp=3):
    private = []
    for _ in range(count):
        p = getPrime(size)
        e = getRandomRange(1, max_exp+1)
        private.append((p, e))
    return private, normalize(private)

>>> priv, pub = gen_custom(5, 12, 3)
>>> priv
[(3251, 1), (3863, 1), (2917, 2), (3761, 3), (3989, 2)]
>>> pub
90459172118968888949999762493557
>>> key = deriv(priv)
>>> key
8182861820449238390507452368725018700352715647046709310466512249
>>> from sage.all import *
>>> factor(pub)
2917^2 * 3251 * 3761^3 * 3863 * 3989^2
>>> factor(key)
2917^4 * 3251^2 * 3761^6 * 3863^2 * 3989^4

If you don’t have sagemath installed, you can also use a handy dandy webassembly ECM factorization tool.

The factors of the public key aren’t surprising, that’s the exact math we used to derive it from the private key, but possible to reverse since we used small numbers. On the other hand, what’s up with the private key? Each factor just has double the exponent? And since $x^2 * y^2 = (xy)^2$, and $(x^3)^2 = x^6$… Our private key is just the square of the public key??

>>> key == pub**2
True

Well then! Let’s assign those commented output values to variables, square the public key, get a new AES instance for decrypting, and…

pub = 0x281ab467e16cdedb97a298249bdd334f0cc7d54177ed0946c04ec26da111...
ciphertext = bytes.fromhex("d2463ccc52075674effbad1b1ea5ae9a9c8106f1...")
key = pub**2
cipher = AES.new(
    hashlib.sha256(str(key).encode("utf-8")).digest(),
    AES.MODE_CBC,
    iv=b"\0" * 16,
)
plaintext = cipher.decrypt(ciphertext)
print(plaintext)

And, drumroll… b'ictf{Would_number_theory_be_new_technology?}\x04\x04\x04\x04'! For good practice, let’s clean that up a bit by removing the padding and turning it back into a unicode string:

from Crypto.Util.Padding import unpad
print(unpad(plaintext, 16).decode("utf-8"))

And there we have it!

Flag: ictf{Would_number_theory_be_new_technology?}

Thanks

Thank you to my team for a friendly place to be the dumbest person in the room, and to the ImaginaryCTF platform folks and challenge developers for the interesting and challenging … challenges.

The header image is from the ImaginaryCTF 2021 site (repo), used with permission from Astro.

I’ve taken some liberties with the order I present objectives here, since a writeup that followed my actual path would be impossible to follow. ↩︎

]]>