WHMCS SQL Injection Vulnerability in the Wild

  • October 7, 2013

A few days ago, a zero-day SQL injection vulnerability in WHMCS was disclosed by localhost.re, along with the exploit code. It was quickly patched by the WHCMS team and rated as critical since it allows an attacker full access to the database hosting WHMCS:

The vulnerability allows an attacker, who has valid login to the installed product, to craft a SQL Injection Attack via a specific URL query parameter against any product page that updates database information.

Creating a valid login is very easy and allowed by default through the registration page.

WHMCS is very popular amongst hosts, and if you use it, you need to update/patch it ASAP!

Attacks in the wild

Due to its severity, we knew it wouldn’t take long before attackers started to use it in the wild. Yesterday we detected the first cases of servers getting compromised due to it. This is an example that was triggered on our honeypots:

First Name: 'USERX' to 'AES_ENCRYPT(1,1), firstname= (SELECT GROUP_CONCAT(id,0x3a,username,0x3a,email,0x3a,password SEPARATOR 0x2c20) FROM tbladmins)'
Last Name: 'LASTNAME' to '1'
Company Name: 'COMPANYNAME' to '1'
Address 1: 'USA' to '1'

As you can see, it is leveraging the SQL injection (by modifying the first name) to dump the user database along with hashed passwords from the database.

If you are using WHMCS, you have to update it now! Our users running our CloudProxy WAF are already protected by it, but we still recommend the update.

Daniel B. Cid is Founder of Sucuri and the VP of Engineering for the GoDaddy Security Products group. He is also the founder of OSSEC and CleanBrowsing. You can find more about Daniel on his site dcid.me or on Twitter: @danielcid

Related Tags
8 comments

  1. I believe that is trying to retrieve the admin username(s) and password hash(s). Not dumping the user database although they can easily do that by changing tbladmins to tblclients.

    These password hashes, in themselves, are not sufficient to allow the attacker to authenticate into your admin or client area. The attacker must find the text which equates to the same hash value as your password. That is not trivial.

    1. Not in your Client area, but this vulnerability exposes all your database and all registrars information data are included ( user and passwords) , those guys can nmade chanc¿ges in registrar , ( delete, edit domains ). Pay pal and others payment methods are vulnerable too

      1. Once again, it does not expose the ‘passwords’. It exposes the ‘password hashes’ which are NOT the same thing. Passwords are not stored in plain text in the DB. It is very important to understand that difference if you want to fully understand the risk.

        1. … and hashes can be compared with enormously big databases of already precomputed hashes for millions of common words and combinations of words with letters used as passwords (Hashcat, john the ripper, elcomsoft, online databases, etc) So is it in clear text or hashes is not really so important since they will find most of the credentials, it’s just a matter of time.

  2. Hello Daniel,

    Even after applying the patch and upgrading WHMCS version, what other security steps can we take to lower down the attack’s possibility even if we don’t try Sucuri’s CloudProxy ?

    1. Check out the WHMCS wiki which has a series of steps on “hardening WHMCS”. Also, googling for that should find you a series of tutorial articles from around the net. See my brief comments above.

  3. I’m assuming it’s reasonable to think that standard WHMCS defence works against this?
    – SQL injection WAF rules (Sucuri’s Cloudproxy product or ASL)
    – renaming the WHMCS admin area
    – putting the WHMCS admin area under basic auth

    Info on renaming the WHMCS area is available in the WHMCS wiki. I’d assume that if you’re serious about your business you’d be running under all three of these?

  4. Hi,
    Is this bug still active? I’m running whmcs 5.3.7. I read the ” update/patch it ASAP! ” link you provided, based on that link this bug should not apply to my version but I have noticed a bogus client account I’m assuming was
    created with malicious intent. I searched the username and IP of the account and it lead me to this article.. I noticed the username and postal code on the account was 404/403 referring to the error I guess? Does this exploit or did this exploit somehow target 404/403 to perform the injection? I’m new to whmcs and I’m trying to protect my clients the best I can. I would love to here your thoughts on this subject!

    Thanks
    R. Phillips

Comments are closed.

Related Categories
You May Also Like