New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Please, don't show @sman how to drop tables.
How do you do it? Impress me with your google skills. I do command line stuff with mysql daily but thanks for the amusement just the same.
So far serverian has been the only person to man up and walk the talk. Although he still hasn't shown me what he claims is true he has done a lot more than anyone else here.
We need to waste our time proving you, the ignorant unbelieving expert, that the exploit is capable of dropping a simple table (something that could be extracted from WHMCS' blog post and some SQL 101 knowledge)
Who are you? President Obama?
Alright, I wasn't sure what kind of SQL that update_query generates. I've enabled sql logging and see.
The SQL code it creates starts with this:
UPDATE tablename SET
Then based on the array, it generates foo='bar'
So if we put (SELECT GROUP_CONCAT(id,0x3a,username,0x3a,email,0x3a,password SEPARATOR 0x2c20) FROM tbladmins)
It becomes this:
UPDATE tablename SET firstname=(SELECT GROUP_CONCAT(id,0x3a,username,0x3a,email,0x3a,password SEPARATOR 0x2c20) FROM tbladmins)
So, it's a subquery.
It doesn't seem to be working for statements other than SELECT. So yeah, DROP cannot be used.
However, this does not change the fact that you said:
And
The vulnerability does not only get you the admin accounts. It can SELECT everything in the database. Just not UPDATE, DELETE, INSERT, DROP.
This also doesn't change the fact that WHMCS developers don't know jack about security. What they wrote there is simply "If you send me something starts with AES_ENCRYPT, I'll let it pass" which is a mistake even PHP beginners shouldn't make. We are talking about a commercial product that's being used by millions.
I was incorrect about stating it was only tbladmins they had read access to. You have shown that to me so thanks for that. That is the kind of info I want to know because I rely on whmcs for my business. There are too many people throwing out all kinds of unsubstantiated bs about it. Makes it hard to separate the signal from the noise.
There should probably be a big effort to update all that old WHMCS code. I'm guessing it's a big expensive project and economics have a lot to do with it.
I would still be interested to know if Settings>General Settings>Other>Locked Client Profile Fields and checking first/last name would prevent them from reading tblclients.
The SQL query is an UPDATE, so obviously you can exploit it to execute an UPDATE, at least on the tblclients table (possibly others if you're creative). The whmcs.py included in the localhost.re page even includes an example, commented out at the bottom, where it sets the password of every client to be the same as a specific account's password (defaulted to the account you use for the exploit).
It may be possible to edit other tables with JOIN. But who cares? Because once you can set every client's password, you can login and cancel all their services immediately, order random services if they have credit, set their root password, etc. etc.??
Edit: well I suppose it'd be even worse if you can set admin password.
Edit2: UPDATE .. JOIN isn't possible in MySQL I think.
What makes you think so?
The query is UPDATE table1, table2, not UPDATE table1 .. JOIN table2
WHMCS is Incredible in term of security.
No limits on maximum character in Firstname/etc field, If you want then you can put 1000k characters in name field
Allow to put anything in firstname like $ [ _ % &* *&^ << (WHMCS Matt think some peoples use this character in their name.)
Not trying to defend anyone and I'm not a professional coder myself but it is pretty easy to sit in front of a keyboard doing your post exploit analysis and say "they should have never done that".
If you have it all worked out why don't you code your own billing system?
WHMCS has a lot of old code and in those days there wasn't as much awareness of these sorts of exploits as there is today. These are standard php functions we are talking about here. Only recently deprecated. So why not go on the php websites and whine about how php is poorly written if you are looking to point fingers?
Having said that, there should be an effort to go through all that old WHMCS code and bring it up to modern coding security standards. Economics probably have a lot to do with why that hasn't been done yet. Probably a lot of man hours needed.
Because of I am not a programmer and I am customer of WHMCS so I have a full rights to fsck whmcs owners.
I already applied this patch bust still receive a name change request.
Address 1: 'asd asd' to 'AES_ENCRYPT(1,1), firstname=(/!sEleCt/ GROUP_CONCAT(id,0x3a,username,0x3a,email,0x3a,password SEPARATOR 0x2c20) /!FroM/ tbladmins /!wHeRe/ roleid='1')'
IP Address: 85.102.44.53
First Name: 'AES_ENCRYPT(1,1), firstname=(SELECT GROUP_CONCAT(id,0x3a,username,0x3a,email,0x3a,password SEPARATOR 0x2c20) FROM tbladmins)' to 'aaaa'
IP Address: 197.2.66.74
@DewlanceVPS People can still try to use the exploit but it will do nothing if you applied the patch so there is nothing to worry about... Until the next 0day that is.
Sure, they will have priorities but it's trivial just to hack every instance they can find by port scanning the entire web for WHMCS standard port, it takes about 40 minutes on a 1Gbps connection.
... No. Scanning for (vulnerable) WHMCS installations, especially given the flexibility in where to install/run them, would take significantly longer than an asynchronous TCP SYN scan.
Sure, if the port can be customised then it's not as trivial. There are loads of web-based fingerprints to find them though. I'm fairly sure there will be 'a list' of installations for people who are in the business of using these exploits.
I ran a similar port scan a while back for finding cpanel installations to generate a web hosting list. 6 million found, pretty trivial to work from a smaller list. I'm not saying it's easy to find every installation, but finding 80% of them is fine for most purposes, with a scattergun approach.
It's trivial to find them, I was just pointing out that it's not as fast as you implied (the '45 minutes on 1Gbps' thing refers to running ZMap with TCP SYN fingerprinting as far as I know).
Yes, that's what I was referring to.
Using the zone files for gTLDs and a fetch of each home page would also reveal a lot, but indeed would take a lot longer.
Original point being: don't assume because you're not large business that these exploits won't affect you via automation.
While it will take longer, this is one of the reasons I like IPv6. scanning those will take a LOT longer. I think hundreds of years or more.
I had a dev WHMCS install laying around that I forgot about. Recieved an email with a username change to the AES_ENCRYPT. He really got me! No one could guess my ultra secret login
admin
password
gg hackers
obviously this just proves they are scanning the internet for installs
Btw, this hack does not get them any passwords and does not let them do anything destructive as far as I know. Some FUDdsters would have you believe it's as simple as changing the name to that AES_ENCRYPT...and they suddenly have access to everything and can do whatever they want. They can get a copy of the db but that only has password hashes. They CANNOT log into your system and do real damage. If you store credit card info locally I'm pretty sure those are hashed as well.
You could disable name changes in General>Other.
Another possibility is to add a couple lines to your .htaccess that I saw posted somewhere else.
RewriteCond %{QUERY_STRING} AES_ENCRYPT RewriteRule ^(.+) /sorry.html [L]I haven't tried that to see if it works but I personally would want to make it more useful and add their IP to a blacklist or something more active like that.
Yes, continue to ignore the proof that an attacker can easily change all client's passwords to his or her own password. So easy that they can just uncomment a line from the exploit script from localhost.re.
#exploit("'DISASTER', password=(SELECT * FROM (SELECT password FROM tblclients WHERE email='%s' LIMIT 1) as x)#" % user_email)Notice that this forms a query like:
Wait nevermind, this probably doesn't work when used on WHMCS of people who don't understand SQL!
This prevents the specific attack used by the exploit example. The AES_ENCRYPT bug, where any call to SQL escaping with a string that begins with AES_ENCRYPT will result in no escaping (only stripping of AES_ENCRYPT), is a problem common to the entire software. So there's a high likelihood that the same exploit can used on a different vector.
Just because an example of an attack doesn't exist doesn't mean that the attack doesn't exist. This is a common excuse used by companies that fail at security.
Currently the best solution is to upgrade to the latest WHMCS. Your rewrite is useless because the payload is sent as POST data. A simple mod_security rule was posted on WHT that theoretically solves the problem, but upgrading is still safer.
Show me the proof that will work. I only deal with facts not hyperbole. Once again WHMCS says you can only get the password hash and still need to reverse that. Unless someone can show me proof on a working system I will believe WHMCS.
SQL injections are a slippery slope. Since the exploit allows arbitrary SELECT statements, SELECT programminglanguagecode INTO OUTFILE '/publiclyaccessibledirectory' would likely be able to be done. You can guess the rest. One example would be to read other files on disk, perhaps a file that contains the salt for passwords.... then all that's needed is some gpgpu magic....
It's not uncommon for these exploits providing a vector to root access.
FWIW failure to adequately secure customer details is also illegal in the EU. Bottom line is it's in the interests of almost everyone to patch this asap.
You're right, you don't know so stop talking like you do. It certainly doesn't let them launch a nuclear attack against North Korea so it really depends on your definition of "destructive".
No, I won't give you any examples, go to hackforums for that.
Seriously, this is getting ridiculous. WHMCS is a joke, how is it even possible there are no decent alternatives?
There's no hyperbole. There's only the fact that mod_rewrite does not handle POST data. If you don't know what POST data is, and are unwilling to do a tiny bit of research to find out what it is, then that's not my problem.
I doubt running WHMCS and not having 24/7 monitoring of exploits could possibly be considered, legally, failing to adequately secure customer details.
Edit: not saying WHMCS doesn't (or does) fail at security here.
Thank you for that lesson on SQL injection hypotheticals. Now please show me that you can change tbladmins passwords by changing the password hash on 5.2.7
So you have no proof that you can change the password hash with this exploit? That is what you are saying. I am not interested in hypotheticals that do nothing but inject more noise into the converstation.