Detailed Analysis of Ghostcat Vulnerability (Cve-2020–1938) in Apache Tomcat Servers

And Using It to Compromise a Tomcat Machine on Tryhackme

Cyber Defecers
Apr 7 · 10 min read

Today we are talking about recently came vulnerability discovered by Chaitin Tech security researchers in Feb 2020 it was named ghostcat by the researchers

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 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.

Image for post
Image for post

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

, a well-known security researcher from Brazil, identified the prerequisites needed for Ghostcat to become an RCE

Link -

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

Image for post
Image for post

lets first deploy the machine

Image for post
Image for post

now lets do some recon on the machine using nmap

$ nmap -A -Pn [machine-ip]

Image for post
Image for post

they are exposing AJP to everyone,we can see that on port 8009 Perfect!!!!!!!!!!!

now lets find the publicly available exploit for ghostcat vulnerability

Image for post
Image for post

link-

Lets download the exploit and run this

Image for post
Image for post

$ python2 48143.py -p 8009 [machine-ip]

Image for post
Image for post
Image for post
Image for post

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]

Image for post
Image for post

and we are in

Image for post
Image for post

okay lets go for user.txt (user flag)

Image for post
Image for post

wait what! probably there are more user this is not the user we require for user.txt file so lets go the /home directory

Image for post
Image for post

okay so there is one more uer called merlin lets see the permissions on the merlin directory are we allowed to go into that

Image for post
Image for post

okay we are allowed so lets go into that directory

Image for post
Image for post

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

Image for post
Image for post

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

Image for post
Image for post

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

Image for post
Image for post

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]

Image for post
Image for post

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

Image for post
Image for post

lets use gpg2john to get the secret key

$ gpg2john tryhackme.asc > hash

Image for post
Image for post

now lets crack the hash format using john the ripper by using rockyou.txt wordlist

link to the wordlist-

$ john --wordlist=rockyou.txt hash

Image for post
Image for post

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

Image for post
Image for post

now run the following command to decrypt the pgp key

$ gpg --decrypt credential.pgp

Image for post
Image for post

now you will get the password for the merlin

Image for post
Image for post

now we are going to change the user in our SSH session

$ su merlin

Image for post
Image for post

now we are our desired user means merlin

lets check what commands he can run as root

$ sudo -l

Image for post
Image for post

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-

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”

Image for post
Image for post

huraay!!!!!!!! we are now root kudos to the hacking article blogs

now we can get the root flag in /root

Image for post
Image for post

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

Image for post
Image for post
Image showing Commit , which disables the AJP connector by default

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

Image for post
Image for post
mage showing Commit , which forces the AJP protocol to listen to the loopback address by default instead of 0.0.0.0.
Image for post
Image for post
Image showing Commit , which checks if the parameter secretRequired is set to “true” and there is a defined “secret”
Image for post
Image for post
Image showing Commit , which blocks requests to the AJP Connector with a 403 Forbidden message response if it contains any arbitrary and unrecognized attributes

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 for awesome information

InfoSec Write-ups

A collection of write-ups from the best hackers in the…

Cyber Defecers

Written by

We are a group of passionate information security researchers and CTF players who likes to learn more about hacking.

InfoSec Write-ups

A collection of write-ups from the best hackers in the world on topics ranging from bug bounties and CTFs to vulnhub machines, hardware challenges and real life encounters. In a nutshell, we are the largest InfoSec publication on Medium. Maintained by Hackrew

Cyber Defecers

Written by

We are a group of passionate information security researchers and CTF players who likes to learn more about hacking.

InfoSec Write-ups

A collection of write-ups from the best hackers in the world on topics ranging from bug bounties and CTFs to vulnhub machines, hardware challenges and real life encounters. In a nutshell, we are the largest InfoSec publication on Medium. Maintained by Hackrew

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight.

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox.

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store