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
So, I learned that if you show @sman a query that works he'll say you don't have proof since he doesn't understand SQL.
Congratulations showing us you can post a query. Now show us that you can change tbladmins password hash using the AES_ENCRYPT exploit in whmcs 5.2.7.
@sman
Who said anything about "changing" a password? I've already described a situation where admin access could be obtained.
It seems like you're trolling anyway, and not really furthering the conversation.
I rely on whmcs every day to earn an income. I'm sure that won't stop you from believing whatever so feel free if it makes you happy.
Since the exploit allows arbitrary SELECT statements, SELECT programminglanguagecode INTO OUTFILE '/publiclyaccessibledirectory' would likely be able to be done.
So once again, you have no proof this is possible with this exploit. All I am asking is to prove it and I will admit I am wrong.
Let me clarify for you then, it is possible.
This thread doesn't even deserve to be open anymore
So you are not willing to prove it? Did you or did you not imply that this exploit allows someone to get admin access to WHMCS?
It's possible to write code to do stuff. There I said it. You win. Now that we got that out of the way please show me that you can get admin access to whmcs using this exploit.
yawn. go get yourself a hobby. start by reading up on sql injections. it's not up to me to prove it to you.
i've already explained how to get admin access, maybe you should spend more time appreciating what people are saying rather than finding the first opportunity to be confrontational. im done as this is just a time suck.
How about this. How about I set up a server with whmcs and you show me how I can get admin access using the exploit? Let's call it my hobby project to learn about sql injections.
clearly you have too much time on your hands. read the thread again.
@sman
He just wants people to show him stuff so he learns. He understands the concept but he does not know how to do it himself so he provokes people into showing him stuff and "Proving" it to him.
Regarding the impenetrability of the password hashing, they use a per-row salted md5 hash. The hashing only protects against eyes-over-shoulder and people who actually have cryptographically strong passwords. Since the salts are embedded in the password hash field, a salted dictionary attack on a GPU can still easily rip through a list.
On the flipside, the authentication method makes it easy to inject your own precomputed hash. They even document the hash composition in their API docs.
That said, there's no need to take control of someone's account since the list itself is worth more. It's a gold mine for getting email/password sets. Probably even better than most others out there since these are 'business owner' grade idents. Only skids who repeated ask for injection templates on a public forum would be interested in destroying or commandeering other people's whcms installations.
Yea that must be it. Clearly nobody here is talking out of their ass. They have all actually tested all these claims they are making. I mean, of course right. Why would anyone say something like that otherwise. I'm the bad guy for asking if it's true. I mean, of course it's true and why even ask right?! That's how code works. Just talk about hypotheticals and don't actually...you know...test it. That would be silly. Better to just whine about it, and ignore all evidence to the contrary. Just believe some posts from random internet people. That is were the truth lies.
rotflmao
Cool, so how exactly do I get the 'email/password set' which by your explanation is the easiest thing to do? Please provide the exactly procedure. You clearly have worked it out. I'm not smart enough so if you can explain the exact procedure it would be greatly appreciated. I know you said a "salted dictionary attack on a GPU" so you must have that setup just lying around right. Maybe a reusable Bitcoin miner? Ignoring the teeny tiny possiblity people don't use dictionary words for passwords anymore and that whmcs has a password strength checker who's default setting won't allow just dictionary words. We will just assume that's not the case because...why would it be right?!
Let me summarize and correct me if I am wrong. Your simple hypothetical (there is that word again) is this.
If A+B+C+Salted dictionary Attack on GPU....then...full access. So simple a baby could do it.
@sman That is what it looks like from here. If you are half as competent as you claim to be you can do all of these tests yourself instead of asking everyone for proof. Everyone's time is valuable and putting theory into practice takes time. @serverian already took some of his very valuable time to show you a proof of concept and even made you a video and it is not enough? Ok, here is some thing just for you: WHMCS has absolutely no problems and is the most secure billing system on the planet. If you use WHMCS you have nothing to worry about.
ATTN Everyone else: Please disregard the last two sentences in this post because they are only meant for a single individual.
I am asking a simple question that not one person here can answer which is my whole point. That most of this talk is nothing but noise. IMHO if you are going to say these things you should have the proof to back it up.
For changing all client passwords to an attacker's password, it's already in practice, all you need to do is test it. Download http://localhost.re/res/whmcs.py set up WHMCS 5.2.7, uncomment the last line in the Python script, configure it with a client account username/password and run it. Then watch all the passwords (of clients, not admins) be set to that client's password.
But seems like you're too lazy to do this?
You are asking for an implantation. Do it yourself.
Looking at it. Will probably give it a try. I know php a lot better than python.
That's the spirit!
Let's get this straight. WHMCS's password strength doesn't prevent dictionary attacks. It merely asks for 'least 3 numbers, 2 lowercase & 3 uppercase letters and 3 special characters' at the highest setting. You can use PassWorD!234 to get a 100% strength pass on most systems, despite the fact that it would be one of the first few substitution variants in any dictionary.
Then there's also the character limit, in which case abc123! was enough to register an account. That 7 character password can be brute-forced in 30 mins on a single 7970.
Basic stats (at least from the Sony database): 93% of passwords are between 6-10 characters. 36% are in a common password dictionary.
Source:
http://www.troyhunt.com/2011/06/brief-sony-password-analysis.html
The salt will protect against rainbow tables, but any password less than 8 characters long (~50%) is trivially recoverable. And chances are, 36% will also be recoverable relatively quickly.
>
If a baby could type 'google: oclhastcat' then yes. And no @sman, I'm not going to demonstrate it for you. Go learn.
TL;DR
If your WHMCS is leaking the password database, that IS a serious security breach - no matter how much whitewash-fluff gets blown up your behind about how "it's salt-hashed so it's safe."
How about walking me through the math of how many possible combinations. What exactly would be involved in terms of hardware cost. What sort of bandwidth would be required. Statistics on the amount of average time it would take. Just so I understand...mmmkay.
No demonstrations. Just the math. Math about real things like clock time, cost, bandwidth, man hours.
You are going on and on about salted hash. Why does anyone use it if it's useless according to you?
http://en.wikipedia.org/wiki/MD5#Security
Yes I can google too. Reminds me of another debate I had with some guy who said I should only use passwords with 20+ characters then showed me the math saying that a supercomputer could go through every possible combination in x amount of time.
Then I asked him how much bandwidth that would require and his head basically exploded. His math assumed infinite bandwidth, infinite CPU, 0 latency. Even with a 100MB internet connection that always provided 100MB to anywhere in the world with 0ms latency and a server that always dedicated 100% CPU just to serving log in attempts, it would take a supercomputer something like 200 years to go through every possible combination of x characters or something like that. Didn't need anywhere near 20 characters either.
Not saying this is the same thing. If you can dump the database and then restore it to a local copy of WHMCS and then if [insert whatever to make your math work] and then [insert whatever else to make your argument work] and then [more ramblings] and than maybe just maybe because you don't have anything better to do then spend all this time trying to get joe blow hosting passwords...so we are still not really talking realty but whatever. Serves me right for getting into these same theoretical arguments about security where all practical considerations fall by the wayside.
Cut your internet connection and put your computer in a super secure bunker...because...MATH!
Oh but wait. That is not secure either.
If you want to hack whmcs then you don't need a infinite bandwidth, just subscribe to loscalhost.re with a sms alert and once they release a exploit then start hacking whmcs..
Let's use Gibson Research's calculator for brute force search space analysis
https://www.grc.com/haystack.htm
abc123! comes in for a search space of 7.56E12 combinations. Offline attack scenario comes in at 1.26 minutes assuming 100B c/s; oclHashcat+ on an AMD hd7970 is rated at 5.144B c/s (courtesy http://hashcat.net/oclhashcat-plus/) so roughly less than 30 mins per account row.
And you're mistaken that you need an install of WHMCS to actually test against. You already have the hashed password with the salt appended exposed. oclHashcat will let you compute md5($salt.$password)=$hash directly in the GPU returning the $password that satisfies the formula. That can run at full speed offline.
Cost $320
Just for giggles though, here's a 24 GPU in-production cluster that does 180B c/s.
https://securityledger.com/2012/12/new-25-gpu-monster-devours-passwords-in-seconds/
To get a better handle on what's the reasonable security threat level, a skid in their mom's basement could chew through a strong 8 character mixed-alphanumeric password in about 15 days. A professional could get a strong 10 character password in about two months (realistically less).
Because it's still better than storing unsalted hashes which are extremely vulnerable to rainbow tables (precomputed coverage hashes). There are easily available rainbow tables for 1-10 characters and consider that most passwords fall in that range, a quick and simple index lookup will suffice. A salt is only effective because it extends a 7 character password into a 12 char password (assuming a 5-character salt). So at least props to WHMCS for doing that bare minimum.
However, I refer to it because you've been relying on WHMCS's word that a leaked database table is not a security threat because it's hashed - and which I assume they implicitly meant its not a concerned because its also salted. But salts are not a panacea if you understand basic infosec. Knowing the salt, which is appended to the password field, a combined 12-character $salt.$password is reduced back to a 7-character problem.
The fact that they use MD5 means it doesn't take much effort to brute force it. If they had used a slower hash algorithm like bcrypt, then things would have been different.
>
MATH is only correct when your knowledge-assumptions are correct - which in this case, aren't.
moderated discussion
it is always useful :-)
You forgot about the sharks with frikin "laser" beams.
@sman