Categories
Hacking News Opinions Security

Barking up the wrong tree

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.

The output from John the Ripper

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.

Categories
News Opinions Security

Namecheap and Phishers

Are they doing enough to protect victims? I don’t think they are.

I recently had a look at some of the Phishing websites I could find; mainly to see how these scammers are operating and what kind of Phishing campaigns they run.

It wasn’t too hard to find many Phishing websites by reviewing Twitter, Pastebin, and other sources. What did surprise me though is the sheer quantity of Phishing websites that are hosted by Namecheap. So much in fact that I believe Namecheap are largely responsible for a lot of the Phishing websites online. According to Petscams.com, 38% of scam domain names reported to them since 23rd August 2017 are sponsored by Namecheap. That’s insane! Their approach to dealing with these websites appears relaxed and under-resourced. Where they profit by selling these services, they have a responsibility to ensure they are not used inappropriately. I believe they are putting profit before this responsibility.

In my search for Phishing websites this morning, I identified the following URLs:

  • hxxps://ee-securebilling.com/ (198.54.115.105)
  • hxxps://netflixbilling-info.com/ (198.54.115.105)
  • hxxps://dvla.gov.uk-rebate.ltd/ (68.65.122.147)
  • hxxps://tickform-instagram.com/ (198.54.116.4)
  • hxxps://new-mythreepayment.com/ (198.54.116.224)

Every single one of these URL’s was/is hosted by Namecheap. Every new website I found continued with the same pattern. Namecheap Namecheap. Namecheap. Between them, they collected various bits of information from victims including dates of birth, credit card and bank details, e-mail addresses, and passwords.

Each of these URL’s were also reported to them between 9:00AM-11:10AM UK Time. A support representative replied to all tickets at 12:06PM advising they were investigating. At the time of writing this post, it is now 2:00PM and with the exception of the EE website which looks like it has been deleted by the phisher, all websites are still active actively phishing victims. I don’t feel it takes that much investigation from Namecheap for them to ascertain they’re not legitimate websites. I do not believe they are acting fast enough, and I think they have something to answer for. Real victims are being scammed. Real victims are losing their money. Namecheap do not seem to understand this.

Fraudsters are obviously using Namecheap’s services due to their relaxed approach at suspending them.

Interestingly enough, Facebook also litigated against Namecheap eariler this year.

The social networking giant claims that Namecheap has refused to cooperate in an investigation into a series of malicious domains that have been registered through its service and which impersonated the Facebook brand.

https://www.zdnet.com/article/facebook-sues-namecheap-to-unmask-hackers-who-registered-malicious-domains/

I have a few domain names registered with Namecheap, and whilst they probably make very little profit off of them, I cannot continue to support a company with such a relaxed approach to scams, and will be transferring them away shortly. I suggest you do the same.