Openssh 7.9p1 Exploit
Melony Kai
Today Qualys's security team has disclosed a remotely exploitable vulnerability in OpenSSH server. It was assigned CVE-2024-6387 number and nicknamed "regreSSHion" because its cause is an accidental removal of code that fixed a much earlier vulnerability back in 2006. It affects OpenSSH versions older than 4.4p1 and versions between 8.5p1 and 9.8p1. VyOS 1.3.8 includes OpenSSH 7.9p1 and thus isn't vulnerable. VyOS 1.4.0 includes 9.2p1 and will need a patch to remain secure.
The vulnerability is potentially dangerous because it allows an unauthenticated, remote attacker to gain a root shell on any vulnerable system. However, don't panic just yet. The cause is a race condition in signal handling, and it's not enough to just send a specially-crafted packet like in the famous scene from Matrix Reloaded. Successful exploitation requires a lot of luck, and the condition is so unlikely that it took the researchers 6 to 8 hours of constant attempts to compromise a target.
The second factor is that it was only successfully exploited on 32-bit x86 systems with much weaker ASLR (Address Space Layout Randomization) than modern x86-64 machines, and there is no working proof of concept for 64-bit machines yet.
VyOS hasn't supported 32-bit x86 in a long time, so it's not practically exploitable yet. Still, we made a hotfix archive that automatically installs updated openssh-server, openssh-client, openssl, and libssl3 packages (anyone with a subscription can access it through the knowledge base) and we will include the fix in the upcoming 1.4.1 release. Rolling release images will automatically pick up the fix from Debian updates in the next nightly build.
Jewel is a Medium difficulty rated machine at HackTheBox. This machine will challenge your enumeration skills. It will start with finding a Git repository that is browsable over http on port 8000. We also find that there is a Blog hosted on port 8080. We are able to confirm that the files in the Git repo are the same used for the blog. This leads to us fingerprinting the Ruby on Rails version that is running the Blog site. We are able to find that this version of Rails has an insecure data deserialization vulnerability that leads to our foothold. Through enumeration we are able to find the password as well as the secret to the two-factor authentication that is enabled on the foothold account. This leads to us being able to sudo the gem binary to get a shell as the root user.
We see that OpenSSH 7.9p1 is open on port 22, there is an Apache 2.4.38 deployment on port 8000 that has a reference to Git in the title, and the may be a blog found on a Nginx 1.14.2 server on port 8080.
When browsing the repository, this seems to be the source of the site that we are likely about to find on port 8080, based on the title listed in our nmap scan. This may indicate that this will be a Whitebox penetration test and that we will have the opportunity to read through the source to find a vulnerability to exploit. We might also be able to take advantage of this Git repository, and if the site is pointing directly to the repository, we may be able to upload a malicious file. We should go checkout the site on port 8080.
We can confirm this by looking through some of the code on the Git site, for example, the application.js sends a string of As to the console, console.log("AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA");, and when we look at the browser console, we see the string of As.
Knowing that this is likely the source code of the site on 8080, we can look at configuration files to better understand the site we are working with. For example, this site is built up of mostly files with the .rb extension, and so it is safe to say that this is a Ruby based web application, and likely running on Rails. We can also look in the Gemfile and see that this is using Ruby 2.5.5 and Rails 5.2.2.1.
Before digging into the source and the site more, it is worth Googling for exploits of these versions of Ruby and Rails. When searching for Ruby on Rails 5.2.2.1 Exploits we find a lot of details on an RCE exploit, but everything about it points to it having been patched in this version. However, when opening the search a bit to Ruby on Rails 5.2 Exploits We find CVE-2020-8165, a much more recent CVE that effects versions of rails before 5.2.4.3. This appears to be an untrusted data deserialization vulnerability that we may be able to exploit for RCE.
Doing a Google search for CVE-2020-8165 POC, we find this page on GitHub. The exploit process shown here is just using the rails console to generate a serialized payload that contains a command to create a file named rce in the /tmp directory on the target. We may be able to crate out own payload, with a reverse shell command, and then find a place to put in on the site. This may result in us getting a reverse shell.
To try exploiting this, we need to find a place where we can submit the payload, and that we can load a page that will attempt to deserialize it. There is a signup page that allows us to create an account on the blog. Once we create an account, we do not have the ability to create posts, or add comments. However, we do have the ability to update one thing, our username. Seems like the likely candidate if this vulnerability can be exploited considering it is the only location that we can do it. This can be done by clicking the Profile button in the right side of the top navigation.
Once you get it working correctly, you will create a new rails project in your working directory, change to the project directory and then start the rails console. Then you can proceed to step though the commands that are listed on the GitHub page. Your commands will look something like this.
Now we can try to pass this payload as the username when updating our account. However, we are going to get an error stating that the Username is invalid and that it is too long and must be under 26 characters.
This validation may only be happening on client side and so we may be able to avoid this by catching this request with Burp and then sending it to the repeater and preparing it with the payload there.
When we send the request to the Burp Repeater and update the payload back to our already encoded format, we can send the request a couple of times, and each time we will receive a 500 Internal Server Error response.
However, something interesting happened here. When we navigate back to the home page, where our Username used to be listed in the top right hand side of the page ([idiot]), we now just see empty brackets.
It would seem that at the very least we have managed to break something. It is worth starting a Netcat listener on the port that we sent in the payload to see if we get a shell when refreshing the page.
Success! Once we start a listener and then refresh the page, the result is that we do indeed receive a reverse shell request. We now have a foothold as the bill user and this also gives us access to the User Flag /home/bill/user.txt. We now need to find a path to root.
NOTE: I am unsure why this worked. I would have expected that our updating the username would have updated its storage location that is referenced by the profile page. But it would seem that the error we saw that stopped this from happening, happened after updating a place that the username is referenced in the page masthead/navigation.
When we cat out /var/backups/dump_2020-08-27.sql We find what appears to be a dump of a PostgreSQL database. When looking through it, we find what appears to be bcrypt hashes for the bill account and another account named jennifer.
There is no jennifer account on the machine, and we already have access to the bill account. However, it is worth trying to crack these hashes as this may result in a password that has been reused for root. It also may result in us having a password for bill that we can use to get pass the password prompt for sudo -l.
This very quickly results in the hash for the bill account being cracked as the password spongebob. We are unable to crack the other hash with the rockyou wordlist. We can try to su to root with this password, but as expected this does not work. However, when we check sudo this time, we are able to get past the password prompt, and this appears to be the password for the bill account.
However, we have run into another problem. The account is setup for multifactor authentication, and we are being prompted for a verification code after entering the password successfully. Now we need to find a way to get through this.
I have downloaded a Firefox plugin named Authenticator. If you are using Chrome, the same plugin is also available. Install the plugin and then a new manual entry, entering the ID that we found as the secret. This should result in something like this.
If it worked for you, you are one of the lucky ones! This is failing because these codes are based on time. That means that in order for us to have the correct code, we must request it from a machine that has the exact same time as the machine that is verifying it. You can check the time details of the machine with the following command.
The machine is in the Europe/London time zone. If you run the same command on your own machine, and the time zone is different, or the local time is even so much as a second off, you will need to run the following commands to get your machine time in sync with the Jewel machine.
If you felt my walkthrough helped you, please take a couple of seconds to visit my HTB Profile and tap that respect button. Also, if you would like to receive a notice of new walkthroughs being posted, follow me on Twitter. If you have any questions or run into any problems as you walk through this, please feel free to reach out to me on Twitter or Discord (idiothacker). Have fun hacking!
e59dfda104