Opinions – Bootlesshacker's Cybersecurity Blog

Investigating what I thought could be an SQL Injection in WHMCS

For those of you who haven’t heard of WHMCS before, you may have heard of cPanel/WHM? cPanel is a very popular control panel installed to many web servers worldwide (WHM is the administration panel that sits behind it).

WHMCS is a very popular billing system which integrates seamlessly with cPanel and WHM for automatic account creation. In my opinion, it hasn’t had a great security history. It’s probably better these days, but I recall reporting an XSS vulnerability to them a few years ago and I wasn’t particularly happy with the way they prioritised it.

Recently, I was logged onto a WHMCS instance used by one of the hosting companies I use. For reasons that aren’t relevant, I tried to disable two factor authentication on my account. When you try to do this on WHMCS, it asks you for your password. I input my password, but the system said my password was wrong? It certainly wasn’t – I put it in straight from my password manager.

I observed my password contained a quote, and wondered whether this could be triggering some sort of SQL issue.

To test this, I changed my password to the same value, but removed the single quote. This time, disabling Two Factor Authentication worked fine, without error.

Have I just discovered an SQL Injection in WHMCS? This seemed serious enough for me to investigate – it was certainly behaving in a way it shouldn’t.

I purchased a monthly license, and installed WHMCS to my local machine. Further testing needed to be done.

The source code of WHMCS is closed source and obfuscated, so it’s not as easy as looking at the source code to see what it’s doing.

I registered a new client account, ensuring to put a quote in my password, and I was able to replicate the issue locally. The version I installed was 8.0.4 – I haven’t tested other versions.

I decided to load Burpsuite to try and capture the registration request before it was passed onto the server. From here, I exported the request and loaded it into SQLMap – a useful tool for automatically testing for SQL vulnerabilities. To my surprise, SQLMap didn’t find any SQL vulnerabilities.

I wasn’t going to leave it there though – this code was misbehaving and I wanted to find out why. When quotation marks cause errors in user inputs, it is often indicative of an SQL error and potential SQL Injection risk. If SQLMap couldn’t identify any SQL injection risks, why was this code misbehaving?

After much discussion and help from atthacks, we identified the issue we were dealing with wasn’t an SQL Injection risk – disappointing, I thought I was onto something here!

As part of our analysis, we registered an account with the following password: password’

We then took the hash from the database and cracked it using John.

As we can see, the quote has stored in the database as '. Therefore, as far as the system is concerned, my password was actually password', not password’. The quote seems to have been represented as the ASCII code for a quote, rather than the quote itself.

The question is, why would they do this? Technically, you can limit SQL Injection risks by removing quotes, but it certainly shouldn’t be relied upon. There are potential ways around this. They should be using proper parameterised queries to fully mitigate SQL injection vulnerabilities. I can only assume they’re doing both, as I found no way to leverage this into an SQL Injection.

This is completely unnecessary – parameterised queries will eliminate the SQLi risk. Encoding the quotation marks offers no further protection and breaks functionality.

The thing that bothers me most about this though is how this bug hasn’t been picked up on a penetration test? This bug isn’t a security bug, but a penetration test would have easily identified this. Do they not pentest their software before they make the software available? Was this tested but missed? Or, was it identified during testing, but added to the pile of bugs not worth fixing? Who knows – it does highlight serious concerns though at the level of security testing they do prior to releasing their software though. I’ve used WHMCS myself in previous jobs – I can’t say I have enough trust in its security these days, especially when you consider the type of data it should be securing.

RIP CentOS

How IBM and Red Hat are killing off CentOS

Opinions and views expressed in this post are entirely my own.

For those of you who don’t know, CentOS is a popular Linux distribution which is a binary compatible clone of Red Hat Enterprise Linux. The idea of Red Hat Enterprise Linux is that it offers a stable production-ready environment with Long Term Support (typically, a version of RHEL/CentOS will remain supported for years before you need to upgrade).

However, RHEL is a commercial product whereas CentOS is a free, community-supported operating system. As RHEL is open-source, it is perfectly permissible for projects such as CentOS to clone and re-release the source, as long as they remove any potential trademarks. After all, RHEL itself benefits from many free things, such as the Linux Kernel.

In January 2014, Red Hat Inc acquired the CentOS trademark and became a primary sponsor of the project. Ever since, they have been investing in the CentOS project and maintaining the project as a community driven operating system, mirroring RHEL. In July 2019, IBM acquired Red Hat. Can you see where this is going?

Concerns were naturally expressed by the community through these various acquisitions as to whether the CentOS project would continue as a community driven project. Time passes by, and a new product was announced (alongside CentOS Linux) called CentOS Stream. CentOS Stream is different to traditional CentOS Linux in the sense that it is considered a rolling release distribution, and will receive more regular updates than CentOS Linux, making it potentially unsuitable for production environments which need to retain stability. In essence, CentOS Stream sits upstream from RHEL (almost like a testing distribution/sandbox), whereas CentOS Linux sits downstream (and mirrors the same stability we know and love from RHEL).

Again, this raised concerns from the community over the future of the CentOS Linux project. The Chief Technology Officer of Red Hat provided reassurance to the community that CentOS as we know it isn’t going anywhere.

Old school CentOS isn’t going anywhere. Stream is available in parallel with the existing CentOS builds. In other words, “nothing changes for current users of CentOS.”
The lying words of Chris Wright, CTO of Red Hat, as seen on ZDNet.

Roll on the 8th December 2020, and Red Hat announce they are shifting all investment away from the CentOS Linux project and focusing entirely on CentOS Stream instead, ending the life of traditional CentOS Linux. Not only that, the already-published end of life date for CentOS 8 was changed from 2029, to 2021 – removing 8 years off of the product support life span. For those who have already migrated to CentOS 8, they now have until the end of 2021 to upgrade instead of the previously promised 2029.

This is a huge breach of trust and unsurprisingly has drawn huge criticism from the community (and rightly so!). It is a colossal dick move by IBM and Red Hat who clearly have no regard for the community which is built up of many people who ironically probably work for companies all over the world that lines their pockets.

Their motive? Who knows? Maybe they want people to shift from CentOS to RHEL and pay an arm and a leg for the privilege.

This is the day in which CentOS as we have known and loved for 16 years dies. Red Hat have truly found a way to make 2020 that little bit worse. Rest in peace.