Kitty
Map? Where we are going, we don't need maps.
Last updated
Map? Where we are going, we don't need maps.
Last updated
Let's start with a nmap scan
We can see two ports open . SSH on port 22 and a HTTP server on port 80.
We know that we are working with PHP. Let's do some directory enumeration.
Let's visit the website and see what we have.
Some default and common paswords did not work. Let's try SQL injection.
we are informed that SQL Injection has been detected and logged. Maybe we can try some more injection or bypassing this check. Let's sign up for an account and see what we have.
Let's try injection with an account created.
It bypasses and logs us in. Let us check for how many columns the table has. We can do this by using UNION SELECT
.
After trying few inputs ' UNION SELECT 1,2,3,4-- -
worked. Going any further would give us an invalid login error.
We can also use SQLmap to simply this and make this process easier.
Although with SQLmap we will have to go through quite some trial and error.
We first started with:
After soem trial and error we can find the database as MySQL so we can append --dbms=mysql -p username
to both restrict to MySQL and just focus on the username field.
Also --skip-heuristic
will limit noise, since we already know this field is vulnerable (although SQLMap thinks it isn't).
Because there is a cookie that won't change when a successful bypass happens, and which SQLmap by default takes into account, we need to ignore the set-cookie flag: --drop-set-cookie
:
We know there is know injection is possible but there is no feedback given. So this is Blind injection. In this case, false cases returns a 200 code (invalid username or password) while true redirects with 302: --code=302.
We will tell SQLMap to consider 302's as a success message.
In most cases most of the above wouldn't be needed except -u
and --forms
. But we want to limit the noise down and get quick results because the SQL Injection filter is of trial and error. Finally after lot's of trial and error and some researching.
These can be specified by script name with
--tamper
. And fortunately there are three that solve the specific problems above:
hex2char.py
replaces0x20
withChar(32)
ifnull2ifisnull.py
replacesIFNULL()
withIF(ISNULL(),)
ord2ascii.py
replacesORD
withASCII
With these three tamper scripts, specified
--tamper=ord2ascii,ifnull2ifisnull,hex2char
we can effectively avoid the WAF filter the site has.
The above query will give us the kitty user's password, which can be used to SSH in.
When we run SQLmap it will ask you some questions on how to proceed with the injection. Most of them will work with default, but just make sure to not follow any redirects and we need to edit the form field values to include the valid username and password created earlier.
do you want to test this form? Y
Edit POST data [default: username=&password=] (Warning: blank fields detected): username=BuN&password=Bun123
got a 302 redirect to 'http://10.10.229.44/welcome.php'. Do you want to follow? n
are you sure that you want to continue with further target testing? Y
do you want to (re)try to find proper UNION column types with fuzzy test? N
injection not exploitable with NULL values. Do you want to try with a random integer value for option '--union-char'? Y
POST parameter 'username' is vulnerable. Do you want to keep testing the others (if any)? N
do you want to exploit this SQL injection? Y
We can login and get our first flag.
Let's do some enumeration. We can use linpeas.
First setup a python server on the attack machine.
On the kitty’s machine :
After a quick enumeration (manual and linpeas), we can see a few things :
There is other web content stored in /var/www/development/
instead of /var/www/html
There are few localhost port occupied :
The /opt
directory isn’t empty and contains a script that belongs to root
(remember that):
This script log_checker.sh
is owned by root.
Checking the source code of the development server at /var/www/development
, it is similar to the first webserver, with the only difference being the logging of SQL injection attempts on /index.php
.
If it detects a SQL injection attempt, it writes the value of the X-Forwarded-For
header in the request to the /var/www/development/logged
.
Sending a request with the header mentioned and a payload that will trigger this logging using curl
.
The script log_checker.sh
reads the /var/www/development/logged
line by line and calls /usr/bin/sh -c "echo $ip >> /root/logged"
for every line, with the read line being the $ip
parameter, and after that, it clears the /var/www/development/logged
file.
Since we are able to control what is written to the /var/www/development/logged
file with the X-Forwarded-For
header, we can control the $ip
parameter and inject commands.
Creating a reverse shell at /tmp/test
and making it executable.
Starting our listener.
Sending our command injection payload: ;/tmp/test #
;
to escape the echo command.
/tmp/test
: command we want to inject.
#
: to comment out the rest of the command.
On our listener, we receive a shell as root and can read the root flag.