nohack-task-6-picoctf.md · 8.0 KiB · Markdown Raw

# Old Sessions
**Category:** Web Exploitation

**Flag:** `picoCTF{s3t_s3ss10n_3xp1rat10n5_efbf6d5f}`

> Proper session timeout controls are critical for securing user accounts. If a user logs in on a public or shared computer but doesn’t explicitly log out (instead simply closing the browser tab), and session expiration dates are misconfigured, the session may remain active indefinitely. This then allows an attacker using the same browser later to access the user’s account without needing credentials, exploiting the fact that sessions never expire and remain authenticated.

## Writeup

The application states: “Once you login, you never have to log‑out again!”.

After logging into the small social media platform called “The New Twitter”, I explored the comments section and found a comment mentioning a strange page at `/sessions`. Upon navigating to this endpoint, the server leaked sensitive user sessions:

```json
1) session:mL_C8lzVGrqTt1qiyIqiRnH0YyEPDqQMGEB-a_vrIsg, {'_permanent': True, 'key': 'admin'}
2) session:PzkDYsNCGgrNQYyrVObF2UvaQvMp_RU-dAfk4rPEFyM, {'_permanent': True, 'key': 'test'}
```

The application exposes active session tokens, relying entirely on the session cookie for authentication. Since the `_permanent` flag is set to `True`, the sessions never expire. By hijacking the admin session—swapping our session cookie with the leaked admin token (`mL_C8lzVGrqTt1qiyIqiRnH0YyEPDqQMGEB-a_vrIsg`)—and sending a new request to the root homepage, the server authenticated me as the administrator, and returned the flag on the homepage.

# Quizploit
**Category:** Binary Exploitation

**Flag:** `picoCTF{my_bIn@4y_3xpl0it_fL@g_825b59b7}`

> Solve the quiz.

## Writeup

1. Question 0x1: Is this a ‘32-bit’ or ‘64-bit’ ELF?

**Answer:** 64-bit

*Explanation:* Using `file vuln`, the output showed `ELF 64-bit LSB executable, x86–64`. This indicates a 64-bit binary using the x86–64 architecture.

2. Question 0x2: What’s the linking of the binary?

**Answer:** dynamic

*Explanation:* The program uses functions like `fprintf`, `fgets`, and `system`, which come from shared libraries. Dynamic linking loads these libraries at runtime rather than embedding them into the binary.

3. Question 0x3: Is the binary ‘stripped’ or ‘not stripped’?

**Answer:** not stripped

*Explanation:* A non-stripped binary retains symbol information like function names (`main`, `win`, `vuln`), which we could see using `nm vuln`. This helps in analyzing the binary and locating functions.

4. Question 0x4: Looking at the vuln() function, what is the size of the buffer in bytes?

**Answer:** 0x15

*Explanation:* The buffer is declared as `char buffer[0x15]`, which is 21 bytes in hexadecimal. This is the memory allocated on the stack for user input.

5. Question 0x5: How many bytes are read into the buffer?

**Answer:** 0x90

*Explanation:* `fgets(buffer, 0x90, stdin)` allows reading up to 0x90 (144) bytes. Since this exceeds the buffer size, it can overwrite memory beyond the buffer.

6. Question 0x6: Is there a buffer overflow vulnerability?

**Answer:** yes

*Explanation:* Because the input length (0x90) is greater than the buffer size (0x15), a buffer overflow is possible, potentially overwriting the stack and modifying the program’s control flow.

7. Question 0x7: Name a standard C function that could cause a buffer overflow.

**Answer:** fgets

*Explanation:* `fgets` can overflow the buffer if the number of bytes read exceeds the buffer size, as it does here.

8. Question 0x8: What is the name of the function which is not called anywhere in the program?

**Answer:** win

*Explanation:* `win()` exists in the source code but is never invoked by `main()` or any other function. This makes it a target for overflow-based exploitation.

9. Question 0x9: What type of attack could exploit this vulnerability?

**Answer:** buffer overflow

*Explanation:* Overwriting the buffer beyond its allocated size allows attackers to change the return address or other stack data, making this a classic buffer overflow attack.

10. Question 0xa: How many bytes of overflow are possible?

**Answer:** 0x7b

*Explanation:* Maximum overflow = bytes read — buffer size = 0x90 – 0x15 = 0x7b. This is the number of bytes that can overwrite memory beyond the buffer.

11. Question 0xb: What protection is enabled in this binary?

**Answer:** NX

*Explanation:* NX (No-Execute) prevents executing code on the stack. Despite the overflow, injected shellcode cannot run directly; the attacker must use techniques like ROP.

12. Question 0xc: What exploitation technique could bypass NX?

**Answer:** ROP

*Explanation:* Return-Oriented Programming (ROP) chains existing code snippets (gadgets) to perform desired actions without executing code on the stack, bypassing NX protections.

13. Question 0xd: What is the address of ‘win()’ in hex?

**Answer:** 0x401176

*Explanation:* Using `nm vuln | grep win`, the function’s address is visible because the binary is not stripped. This address can be used in a crafted overflow payload to jump to `win()`.

# Stegorsa
**Category:** Forensics

**Flag:** `picoCTF{rs4_k3y_1n_1mg_d8526dc3}`

> A message has been encrypted using RSA. The public key is gone… but someone might have been careless with the private key. Can you recover it and decrypt the message?

## Writeup

The private key was hidden as a hex-encoded string in the Comment field of the image metadata (`image.jpg`).

After decoding this hex string, I recovered the RSA private key:
```
-----BEGIN PRIVATE KEY-----
MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQDq3mThsuMFoG3/
...
UwkkM+srAQK+sVVR0Qbl0yU=
-----END PRIVATE KEY-----
```

Using this key to decrypt `flag.enc`, I recovered the flag text.

# Shared Secrets
**Category:** Cryptography

**Flag:** `picoCTF{dh_s3cr3t_1bcf19a9}`

> A message was encrypted using a shared secret... but it looks like one side of the exchange leaked something. Can you piece together the secret and get the flag?

## Writeup

The encryption process uses a Diffie-Hellman key exchange. Based on the provided files:
1. `A` is the server's public key ($g^a \pmod p$).
2. `b` is the client's private exponent (leaked in `message.txt`).
3. The shared secret is calculated as $shared = A^b \pmod p$.
4. The encryption is a simple XOR: `enc[i] = flag[i] ^ (shared % 256)`.

Since we have `A`, `b`, and `p`, we can compute the shared secret and decrypt the flag using some quick Python code:

```python
A = 1526574324125129961259732303672830205567002421896137...
b = 5091601777301979449211554306830574032517408427341702...
p = 2005489796935137589652536709215421227413474900115477...
enc_hex = "2a333935190e1c213e320529693928692e056b38393c6b633b6327"

# Step 1: Compute shared secret
shared = pow(A, b, p)

# Step 2: Extract the key byte (shared % 256)
key_byte = shared % 256

# Step 3: Decrypt by XORing each byte with the key_byte
enc_bytes = bytes.fromhex(enc_hex)
flag = bytes([x ^ key_byte for x in enc_bytes])
print(flag.decode())
```

Running this logic yields the flag.

# Binary Digits
**Category:** Forensics

**Flag:** `picoCTF{h1dd3n_1n_th3_b1n4ry_8e65b559}`

> This file doesn't look like much... just a bunch of 1s and 0s. But maybe it's not just random noise. Can you recover anything meaningful from this?

## Writeup

The provided file `digits.bin` contained a sequence of binary digits. Recognizing this, I wrote a quick script to convert the binary data back into raw bytes and saved it into an image container:

```python
>>> bits = open("digits.bin").read().strip()
>>> data = bytes(int(bits[i:i+8],2) for i in range(0,len(bits),8))
>>> open("real.jpg","wb").write(data)
```

Opening the resulting image (`real.jpg`) visually displayed the flag text string.

Old Sessions

Category: Web Exploitation

Flag: picoCTF{s3t_s3ss10n_3xp1rat10n5_efbf6d5f}

Proper session timeout controls are critical for securing user accounts. If a user logs in on a public or shared computer but doesn’t explicitly log out (instead simply closing the browser tab), and session expiration dates are misconfigured, the session may remain active indefinitely. This then allows an attacker using the same browser later to access the user’s account without needing credentials, exploiting the fact that sessions never expire and remain authenticated.

Writeup

The application states: “Once you login, you never have to log‑out again!”.

After logging into the small social media platform called “The New Twitter”, I explored the comments section and found a comment mentioning a strange page at /sessions. Upon navigating to this endpoint, the server leaked sensitive user sessions:

1) session:mL_C8lzVGrqTt1qiyIqiRnH0YyEPDqQMGEB-a_vrIsg, {'_permanent': True, 'key': 'admin'}
2) session:PzkDYsNCGgrNQYyrVObF2UvaQvMp_RU-dAfk4rPEFyM, {'_permanent': True, 'key': 'test'}

The application exposes active session tokens, relying entirely on the session cookie for authentication. Since the _permanent flag is set to True, the sessions never expire. By hijacking the admin session—swapping our session cookie with the leaked admin token (mL_C8lzVGrqTt1qiyIqiRnH0YyEPDqQMGEB-a_vrIsg)—and sending a new request to the root homepage, the server authenticated me as the administrator, and returned the flag on the homepage.

Quizploit

Category: Binary Exploitation

Flag: picoCTF{my_bIn@4y_3xpl0it_fL@g_825b59b7}

Solve the quiz.

Writeup

Question 0x1: Is this a ‘32-bit’ or ‘64-bit’ ELF?

Answer: 64-bit

Explanation: Using file vuln, the output showed ELF 64-bit LSB executable, x86–64. This indicates a 64-bit binary using the x86–64 architecture.
Question 0x2: What’s the linking of the binary?

Answer: dynamic

Explanation: The program uses functions like fprintf, fgets, and system, which come from shared libraries. Dynamic linking loads these libraries at runtime rather than embedding them into the binary.
Question 0x3: Is the binary ‘stripped’ or ‘not stripped’?

Answer: not stripped

Explanation: A non-stripped binary retains symbol information like function names (main, win, vuln), which we could see using nm vuln. This helps in analyzing the binary and locating functions.
Question 0x4: Looking at the vuln() function, what is the size of the buffer in bytes?

Answer: 0x15

Explanation: The buffer is declared as char buffer[0x15], which is 21 bytes in hexadecimal. This is the memory allocated on the stack for user input.
Question 0x5: How many bytes are read into the buffer?

Answer: 0x90

Explanation: fgets(buffer, 0x90, stdin) allows reading up to 0x90 (144) bytes. Since this exceeds the buffer size, it can overwrite memory beyond the buffer.
Question 0x6: Is there a buffer overflow vulnerability?

Answer: yes

Explanation: Because the input length (0x90) is greater than the buffer size (0x15), a buffer overflow is possible, potentially overwriting the stack and modifying the program’s control flow.
Question 0x7: Name a standard C function that could cause a buffer overflow.

Answer: fgets

Explanation: fgets can overflow the buffer if the number of bytes read exceeds the buffer size, as it does here.
Question 0x8: What is the name of the function which is not called anywhere in the program?

Answer: win

Explanation: win() exists in the source code but is never invoked by main() or any other function. This makes it a target for overflow-based exploitation.
Question 0x9: What type of attack could exploit this vulnerability?

Answer: buffer overflow

Explanation: Overwriting the buffer beyond its allocated size allows attackers to change the return address or other stack data, making this a classic buffer overflow attack.
Question 0xa: How many bytes of overflow are possible?

Answer: 0x7b

Explanation: Maximum overflow = bytes read — buffer size = 0x90 – 0x15 = 0x7b. This is the number of bytes that can overwrite memory beyond the buffer.
Question 0xb: What protection is enabled in this binary?

Answer: NX

Explanation: NX (No-Execute) prevents executing code on the stack. Despite the overflow, injected shellcode cannot run directly; the attacker must use techniques like ROP.
Question 0xc: What exploitation technique could bypass NX?

Answer: ROP

Explanation: Return-Oriented Programming (ROP) chains existing code snippets (gadgets) to perform desired actions without executing code on the stack, bypassing NX protections.
Question 0xd: What is the address of ‘win()’ in hex?

Answer: 0x401176

Explanation: Using nm vuln | grep win, the function’s address is visible because the binary is not stripped. This address can be used in a crafted overflow payload to jump to win().

Stegorsa

Category: Forensics

Flag: picoCTF{rs4_k3y_1n_1mg_d8526dc3}

A message has been encrypted using RSA. The public key is gone… but someone might have been careless with the private key. Can you recover it and decrypt the message?

Writeup

The private key was hidden as a hex-encoded string in the Comment field of the image metadata (image.jpg).

After decoding this hex string, I recovered the RSA private key:

-----BEGIN PRIVATE KEY-----
MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQDq3mThsuMFoG3/
...
UwkkM+srAQK+sVVR0Qbl0yU=
-----END PRIVATE KEY-----

Using this key to decrypt flag.enc, I recovered the flag text.

Shared Secrets

Category: Cryptography

Flag: picoCTF{dh_s3cr3t_1bcf19a9}

A message was encrypted using a shared secret... but it looks like one side of the exchange leaked something. Can you piece together the secret and get the flag?

Writeup

The encryption process uses a Diffie-Hellman key exchange. Based on the provided files:

A is the server's public key ($g^a \pmod p$).
b is the client's private exponent (leaked in message.txt).
The shared secret is calculated as $shared = A^b \pmod p$.
The encryption is a simple XOR: enc[i] = flag[i] ^ (shared % 256).

Since we have A, b, and p, we can compute the shared secret and decrypt the flag using some quick Python code:

A = 1526574324125129961259732303672830205567002421896137...
b = 5091601777301979449211554306830574032517408427341702...
p = 2005489796935137589652536709215421227413474900115477...
enc_hex = "2a333935190e1c213e320529693928692e056b38393c6b633b6327"

# Step 1: Compute shared secret
shared = pow(A, b, p)

# Step 2: Extract the key byte (shared % 256)
key_byte = shared % 256

# Step 3: Decrypt by XORing each byte with the key_byte
enc_bytes = bytes.fromhex(enc_hex)
flag = bytes([x ^ key_byte for x in enc_bytes])
print(flag.decode())

Running this logic yields the flag.

Binary Digits

Category: Forensics

Flag: picoCTF{h1dd3n_1n_th3_b1n4ry_8e65b559}

This file doesn't look like much... just a bunch of 1s and 0s. But maybe it's not just random noise. Can you recover anything meaningful from this?

Writeup

The provided file digits.bin contained a sequence of binary digits. Recognizing this, I wrote a quick script to convert the binary data back into raw bytes and saved it into an image container:

>>> bits = open("digits.bin").read().strip()
>>> data = bytes(int(bits[i:i+8],2) for i in range(0,len(bits),8))
>>> open("real.jpg","wb").write(data)

Opening the resulting image (real.jpg) visually displayed the flag text string.