The first hint that something might be a problem actually occurred when the ftp accounts to the server were compromised, which resulted in the shutting off ftp. At that time while cleaning up I noticed an admin account had been used to create a style (not publicly available) that had a script similar to the second set of scripts that I found on the server. When I asked the admin he said he didn't know anything about styles and it hadn't been him. I thought it was part of the ftp hack, deleted the style and life went on.

Fast forward to June 18. I came on in the evening to find the Pop up advertising thread. At the same time Asty had PM'd me that there was strange behaviour with a tech staff account and the same admin account that had previously been used. After checking admin logs it quickly became clean it wasn't the admin in question. I PM'd GED and other tech staff members that I thought an admin account had been compromised. The admin account and a second compromised tech staff account had their admincp access removed, were temporarily suspended and the people notified by email that their accounts were compromised. I proceeded to clean up the pop up ads.

On June 20th a second admin account was compromised. I again removed all admin permissions from the account until it was under the admin control again. At this point we started to guess as to what the vulnerability was as it was no longer the one admin account causing problems. It appeared the hacker was at the least able to access the hashed values of members password, the thought was there was some injection or xss vulnerability. That evening most admins had their admincp access significantly reduced and most tech staff were temporarily removed from tech staff as the hacker was subverting more and more accounts.

On June 21st Sim disabled off all but a few plugins as he suspected the hole in security was in the plugins. Late on the 21st it was confirmed there was an injection vulnerability in the code.

On June 22nd the vulnerability was patched and all plugins were enabled again and all tech staff were restored and admin rights restored.

At this point we highly recommend that everyone change their password as its likely that the hacker had access to all or at least part of the password hashes and could brute force your password if it remains unchanged.

Thank you Squid. Kind of wish we could do something about the bastard.

I don't know much about hacking, but wouldn't thread like this or user titles help into targetting accounts with access?

Looking at this page, whose account would a hacker go for, mine, Bolkonsky or Squid's?

That information is already readily available on the leaders page and so its irrelevant whether or not hex/moderators/tech staff are otherwise identifiable. The benefits of our being identifiable are greater than the drawbacks. That being said accounts with access were targeted but the attack was successful because of a weakness in the code, which as I said has been corrected. Without that weakness no attack could have occurred. The only reason the attack was possible was because the attacker gained access to the hashed version of passwords and without interacting with our site could recover the password using a brute force attack.

Well, thank you guys for your work in supressing the attack.

John Doe said:

I don't know much about hacking, but wouldn't thread like this or user titles help into targetting accounts with access?

Looking at this page, whose account would a hacker go for, mine, Bolkonsky or Squid's?

Click to expand...

What you are referring to is security through obscurity, which only works up to a point. If we didnt publish Tech Staff user names, you are correct nobody would know which accounts to attack. One downside of that is that nobody would know who to PM when there was a problem. But it doesnt really matter if we publish names like that or not, anyone who spends 5 minutes browsing the forums can figure out who is who. For instance if there is someone out there right now looking to hack the forum, and they happen to read this thread, who do you think they go after? Myself and Squid of course. Anyone reading the Tech Bazaare or just about any thread in the Q & S will know who is who.

Also it should be explained what password hashes are. It is NOT your password. Passwords are not stored in clear text, even if I manually go into the database and look at your password, I do not know what it is. vBulletin runs passwords through an algorithm and combines that with a random number and generates a hexidecimal number.

Now if someone knows the algorithm used (vBulletin uses MD5 which is quite well known and also quite old) and the salt value, they can attempt to brute force the password. Basically they try every possible combination of key strokes until they generate the same hex code. Notice in that article that it says:

US-CERT says MD5 "should be considered cryptographically broken and unsuitable for further use,"[9] and most U.S. government applications now require the SHA-2 family of hash functions.[10]

Click to expand...

Hopefully vBulletin will change that and use something more current.

It can probably be changed, to at least SHA-1 right? Just a simple line, php will do the rest, or so I'm led to believe.

We looked at it, its a pretty intrusive rewite to do it, there are calls for it all over the place. And it would have to be done all over again when we switch to 4.0.

Bolkonsky said:

It can probably be changed, to at least SHA-1 right? Just a simple line, php will do the rest, or so I'm led to believe.

Click to expand...

Yes and no. The real problem is that no one would be able to login and everyone would need to reset their passwords. As GED said the database stores the hash of your password and not the actual password, and if we change the hash function the hash stored in the database is now invalid.

Example: Your password was password (don't actually use that as a password). The current hash function might hash it to 761f6da3c (in reality the hash is 128-bits or 16 hex digits not the 9 I'm using) and 761f6da3c is what would be stored in the database. If I changed the php to use another hash function then when you typed in password the new hash function might hash it to 907fbe8ac45d, which of course does not match what's in the database so you couldn't log in.

True. Maybe when we reach 4.0 something could be worked out. Or maybe there's a way of rehashing the hash?

Unrelated question: If I had a password "pass" and so did someone else, would they be the same hash?

No. There is a random number called $salt combined with your password before it is hashed.

Makes sense. Thanks.

GrnEyedDvl said:

What you are referring to is security through obscurity, which only works up to a point. If we didnt publish Tech Staff user names, you are correct nobody would know which accounts to attack. One downside of that is that nobody would know who to PM when there was a problem. But it doesnt really matter if we publish names like that or not, anyone who spends 5 minutes browsing the forums can figure out who is who. For instance if there is someone out there right now looking to hack the forum, and they happen to read this thread, who do you think they go after? Myself and Squid of course. Anyone reading the Tech Bazaare or just about any thread in the Q & S will know who is who.

Click to expand...

A secret alt accounts for work on the system and your current accounts for PMs and public task?

John Doe said:

A secret alt accounts for work on the system and your current accounts for PMs and public task?

Click to expand...

That's already in place, everyone who has direct server access, which isn't very many people, have an entirely separate account, with a, hopefully, different password to access the server. For stuff on the site that would be problematic as you'd want anything moderation related to be conducted with the public account not a behind the scenes admin/moderation account as that is too confusing. "Who's this XYZ editing my posts" would be a common complaint. In theory we could do it, but any admins and tech staff would be maintaining 2 accounts and 3 if they had server access.

kudos tech. staff! going to change my password and email right now for security purposes.

My account isn't in the same language so I should be fine. But I haven't been logged on far awhile so I don't know if he accessed mine or not. Either way if it does get hacked I know about 50 or 60 people in hackers anonymous that could counterhack it, and this entire site if they wanted lol.

Good job on getting it fixed though

I'll let all the guys in the RTW community know.

GrnEyedDvl said:

Now if someone knows the algorithm used (vBulletin uses MD5 which is quite well known and also quite old) and the salt value, they can attempt to brute force the password. Basically they try every possible combination of key strokes until they generate the same hex code.

Click to expand...

Isn't there a limitation on the number of attempt to enter passwords? Because it would defeat brute force/ rainbow tables right?
Also, is it possible to monitor if someone tries to enter a lot of passwords really quickly?

Squid said:

a second admin account was compromised.

Click to expand...

Oh script kiddies - if only they got out more - they might actually get laid.

I've changed my password too - +1000xp defence against rainbow trickery such password changes employ .

Paedric said:

Isn't there a limitation on the number of attempt to enter passwords? Because it would defeat brute force/ rainbow tables right?

Click to expand...

Yes there is, but as I noted in the description they exploited a hole in the code that allowed them to access the password database. That access gave them the password hashes, once they had those they could crack the passwords off-site and not worry about the login attempt limit.

Also, is it possible to monitor if someone tries to enter a lot of passwords really quickly?

Click to expand...

Only for admin accounts accessing admincp but it wouldn't have helped anyways when they weren't using the site to crack the passwords.

Good job to staff, my Thanks to you is posted in the TD.

@Squid Thanks, I wasn't sure of the way it worked.

Is there any indication of what the hacker was looking for or trying to achieve an why?
Also, what about an announcement suggesting users to change their password?

I changed all my passwords after the Sega Pass hacking. Now I've changed all my passwords on every site I use again with a crapload of different garbage nonsense passwords I've just written on a physical notebook. Annoying hacking is annoying.

Squid said:

At this point we highly recommend that everyone change their password as its likely that the hacker had access to all or at least part of the password hashes and could brute force your password if it remains unchanged.

Click to expand...

First of all thanks for your work and for the notification message
Have to admit that the message first read to me like the hacker had somehow accessed a cleartext password database ... As for the rest of it, sound advise as always.

Squid said:

Yes and no. The real problem is that no one would be able to login and everyone would need to reset their passwords. As GED said the database stores the hash of your password and not the actual password, and if we change the hash function the hash stored in the database is now invalid.

Example: Your password was password (don't actually use that as a password). The current hash function might hash it to 761f6da3c (in reality the hash is 128-bits or 16 hex digits not the 9 I'm using) and 761f6da3c is what would be stored in the database. If I changed the php to use another hash function then when you typed in password the new hash function might hash it to 907fbe8ac45d, which of course does not match what's in the database so you couldn't log in.

Click to expand...

GrnEyedDvl said:

We looked at it, its a pretty intrusive rewite to do it, there are calls for it all over the place. And it would have to be done all over again when we switch to 4.0.

Click to expand...

You don't have to replace the existing algorithm with a new one to attain better hash security. You could take the resulting password hash and salt used by the existing algorithm, feed it to a new algorithm and then store the new password hash. In this way, you can simply upgrade the password database without requiring anyone to reset their passwords. The use of md5 should eventually be obsoleted, but depending on the new algorithm, that is inserted between the old algorithm and the database, the rehashed password may practically withstand brute-force cracking; even if that new algorithm is published publicly.

Of course, if the stolen data was using simple md5(password) or md5(md5(password), salt) or any other weak variation, users should still be advised to change their passwords. Because even if we don't reuse the password elsewhere, there can still be a trust issue in this forum.

GrnEyedDvl said:

Also it should be explained what password hashes are. It is NOT your password. Passwords are not stored in clear text, even if I manually go into the database and look at your password, I do not know what it is. vBulletin runs passwords through an algorithm and combines that with a random number and generates a hexidecimal number.

Click to expand...

While password hashes are technically not your password in plain text, weakly stored password hashes are practically them.

If I may ask, I have two questions. First, are everyone affected or only those who have received the forum notice or is that unknown? Second, are any other data other than the password hashes stolen, like our e-mail addresses and user names?

And thank you all very much for your openness about this issue.

painter said:

You don't have to replace the existing algorithm with a new one to attain better hash security. You could take the resulting password hash and salt used by the existing algorithm, feed it to a new algorithm and then store the new password hash. In this way, you can simply upgrade the password database without requiring anyone to reset their passwords. The use of md5 should eventually be obsoleted, but depending on the new algorithm, that is inserted between the old algorithm and the database, the rehashed password may practically withstand brute-force cracking; even if that new algorithm is published publicly.

Click to expand...

It means a lot of extra work to change the password hashing algorithm. First we'd need to update all points in the code that are involved in the hashing and that alone is not trivial. Second we'd then need to modify every user record in the database by taking the existing hash value and hashing it some more. At the least this would cause significant downtime for members.

If I may ask, I have two questions. First, are everyone affected or only those who have received the forum notice or is that unknown? Second, are any other data other than the password hashes stolen, like our e-mail addresses and user names?

And thank you all very much for your openness about this issue.

Click to expand...

Every user on the site received the forum notice and potentially the entire database is in the hands of the hacker, this includes email addresses and user names.

Squid said:

Every user on the site received the forum notice and potentially the entire database is in the hands of the hacker, this includes email addresses and user names.

Click to expand...

Thanks for your answer.

Squid said:

Every user on the site received the forum notice and potentially the entire database is in the hands of the hacker, this includes email addresses and user names.

Click to expand...

They have my email now too? Need to update my porno subscriptions then I guess.

There is a very simple way to prevent brute forcing. Simply require 1 or 2 seconds between each login attempt and any brute-force attack to try and retrieve a password or maybe even use a rainbow table to find it will fail as the amount of options would drag these attack on for at least hours which would make it easy to detect.

Muffer Nl said:

There is a very simple way to prevent brute forcing. Simply require 1 or 2 seconds between each login attempt and any brute-force attack to try and retrieve a password or maybe even use a rainbow table to find it will fail as the amount of options would drag these attack on for at least hours which would make it easy to detect.

Click to expand...

Obviously you did not read this thread.

The attempt to crack the password is not made through the site. The hacker got a copy of logins, and has them on his local machine. He can then brute force the hash values until he generates a matching hash, and then use that value to login to the site.

The site already has a 15 minute lock if you fail to enter the correct password 5 times in a row. Thats a default vBulletin setting, and its always been enabled.

spent a good few hours changing every password to every account I've ever had. Also changed a few emails, and deactivated some accounts. Better safe than sorry.

Was this these lulzsec chaps? and will this happen again?