IMPORTANT: Community security breach

[Peter_AUS]

As an owner/administrator of several sites I run, this really didn't bother me, as much as I have read, I use strong passwords and not the same one for any sites or places I am registered with.  Hacks happen, fact of life on the internet.  One of my sites, gets constantly bombarded with hackers and spammers, and spam registrations very rarely get through, due to how my software is set-up and also the way the server is set-up as well. Only reason that I can think of not being a victim to any Hacks (touch wood) is because a friend who is very savy in security has set up my system to be virtually impregnable, though as has been said, nothing is impregnable.  Even large Corporations, Banks, Governments etc. have been hacked and they spend zillions of $$$'s on security.  Basically Security is only as good as the person who sets it up is.

For heavens sake leave the Admins alone and get on with life, 10 pages of virtual complaining, over a site that is free and supplies the product free is just a lot of Bull S**t as far as I am concerned.  Leave them alone and let them get on with what they do.

To the Admin concerned, Lesson learnt and we all have and will make mistakes in life.  It is the fact we learn from these mistakes that make us better Admins.

And although it says I am a Newbie, I have in fact been a member since 2007, I just don't post here that often.

[Ranti84]

Haven't been here for a long time (since 2007 by look of my very short post history).  Frankly, I forgot what password this place used.  I'm sure I probably used it elsewhere at the time but I know my password scheme has changed since then. 

Regardless, I changed the password here to something that is completely different from other ones I use.  ...since I forgot about even HAVING this account I may end up forgetting again (or the password at the very least).

Just to emphasize, when I checked my profile after seeing the post about the secret question (mine was blank) I noticed my 'native language' was Albanian too.  Maybe it's just because I hadn't been here for so long and it was a feature added since 2007?

Also, I noticed the 'odd' email subject too (Simple Machines Community Forum: Onderwerp).  For what it's worth, I got my email yesterday at 12 PM CST.

Mistakes happen...even big mistakes like this...and it's known where the fault lies.  There's no use in crucifying whoever it happened to, I'm sure they feel horrible enough as it is.

[Leto Atreides II]

How to I delete my account.  I prefer that option over having this happen again which I find inexcusable. 

Wow. How many professions have a 100% success rate? Even dedicated surgeons can lose the life of a patient. Since no one is impervious to hacking, you may as well delete all your e-mail accounts, Facebook and any other social sites you may be on, sell your computer and stay safely far away from all the Internet.

[Leto Atreides II]

Name.com suffered a similar breach not too long ago:

Received May 8th:

We are writing to inform you of a security measure we have taken to protect the integrity of the domain names and information associated with your account.

Name.com recently discovered a security breach where customer account information including usernames, email addresses, and encrypted passwords and encrypted credit card account information may have been accessed by unauthorized individuals. It appears that the security breach was motivated by an attempt to gain information on a single, large commercial account at Name.com.

Name.com stores your credit card information using strong encryption and the private keys required to access that information are stored physically in a separate remote location that was not compromised. Therefore, we don't believe that your credit card information was accessed in a usable format. Additionally, your EPP codes (required for domain transfers) were unaffected as they are also stored separately. We have no evidence to suggest that your data has been used for fraudulent activities.

As a response to these developments, and as a precautionary measure, we are requiring that all customers reset their passwords before logging in. If you use your previous Name.com password in other online systems, we also strongly recommend that you change your password in each of those systems as well.

Please click the link below to reset your password:
[link redacted]

We take this matter very seriously. We've already implemented additional security measures and will continue to work diligently to protect the safety and security of your personal information.

We sincerely apologize for the inconvenience. If you need any additional assistance or have any questions please email [email protected]. We'll continue to be as open and honest with you as possible as additional important information becomes available, so keep your eye out for a blog post or additional emails.

Thanks,
The Name.com Team

[CountryLady]

In addition to identifying a few possible reasons that some did not get the email, (see below) I'd like to say... Many "Thanks!" to all who have been hard at work on this issue and those who manage to keep their cool when some members have tantrums. Eventually, they will learn it is much smarter to be part of the solution, rather than part of the problem.

I'm with Tony Reid...

A lot of good can come out of this. As a community we can do better.

Even though the breach was due to a dumb password error by an admin, and it wasn't an exploit of the SMF software we could look at enhancing SMF in many other ways.

2FA perhaps, HTTPS at logon, separate fields in helpdesk for username/password - which get truncated every 24 hours. Segregation of admin and installer rights on the forum. Automatic password renewal every 90 days.

Automatic detection of password sharing in the forum(including PM's). I am sure there are many other ideas we could list.

The only thing is that as a community we need to pull together and get security enhancements like this done. It cannot be left just to the developers - they already have too much else on.

We need to pull together and make it happen.

"Stuff Happens" -- always has and always will. Our challenge is to do all that we can to protect ourselves if we've been lax in our password habits, recognize that we can all contribute to making SMF, our own forums and everything else more secure.

Those who have not received the email announcement might want to consider the following:
Check your email address in your SMF profile to see if it is still valid.
Check your email client's SPAM filter.
Check to make sure there IS a checkmark in the box to receive Important Announcements from SMF. This is available via your Profile > Notifications

Simple Machines Community Forum » Profile of CountryLady » Notifications *
Profile Info > Modify Profile (Caution: there are several pages to this... 1-2-3, etc.)

Profile
SMF allows you to be notified of replies to posts, newly posted topics, and forum announcements. You can change those settings here, or oversee the topics and boards you are currently receiving notifications for.

[  ] Receive forum newsletters, announcements and important notifications by email.

  ALSO... Check to make sure you have clicked "Notify" at the top of the "News and Updates"  Board. This is DIFFERENT from checking the "Receive Announcements from Forum Administrators" box in your profile > Modify Profile...!
This leads to an email to your address on record that says...
A new topic, 'IMPORTANT: Community security breach', has been made on a board you are watching.

You can see it at
http://www.simplemachines.org/community/index.php?topic=508232.new#new

(LOOK AT THIS NEXT LINE...)
More topics may be posted, but you won't receive more email notifications until you return to the board and read some of them.
(I've been guilty of forgetting this a few times myself.)

To the Admin who used a duplicate password elsewhere...
After learning the lesson involved, don't fret over this. Its not like you did this on purpose. Hacking is happening all over the world to every type and level of organization. We need constant reminders to be alert, both on-line AND in Real Life. We can mitigate, but not eliminate, danger, damage & loss. So, appreciate the support you've been given by the SMF Team and help write up the remedies so it doesn't happen to someone else.
PS- You should always be on the Team that handles problems of this sort. You now have experience in this kind of thing from several perspectives. Besides, it helps us heal when we can do something about a problem we caused.

SMF will be better and stronger as a team, as a software, as support team and just regular members for how we handle this, and I think it is being handled in an outstanding manner all the way around.
                                     WAY TO GO TEAM~!

[LiroyvH]

Thanks for your feedback all, it's really appreciated
Also thanks for the kind words of understanding that this can, unfortunately, happen. People make mistakes, so be it.

It's also nice to see that people are trying to inform each others of even more tips and tricks to protect themselves.
I guess that, in someway, we should be happy this served as a wake-up call to many people. When it happens "close to home", people tend to take it much more serious. And for that part, I'm grateful that something good comes out of something bad.

Just had to put that out there.
Thanks guys n girls for the feedback and helping each other!

[ARG01]

My site is down again. Again, out of nowhere. Since this whole hacking, nothing's been right, and we are drowning in this. It is literally killing us.

If it's the site in your signature, it seems fine to me. 

[johncall]

No harm, no foul so far.  I changed all the important passwords.  Stuff happens.

[Kindred]

Groovy....   I said this yesterday as well.... 

unless you used the same username and password on your site that you use here, there is unlikely to be anything related.

if you did use the same information on both sites *shakes finger while tsking*

However, the incident is unlikely to be related.
After all, his goal here (and on other other site like ubuntu) was not to take the sites down - it was to gather the user information without anyone knowing that he did it

[Madeyoulook]

I received a email notification from Simple Machines Community Forum yesterday. Thanks to the SMF admins for passing on the information.

My client uses the SMF forum on two of their sites. Is it just the administrators of these SMF forums who need to reset their passwords, or do all members on their forums need to reset their individual passwords, too?

[Deaks]

Really just admins and yourself, but will never go wrong to remind the members to use strong passwords etc

[[yub] Lazo]

I agree, I don't have the same password here and elsewhere but I reminded my Community members to use stronger password pointing on this case.

[GerryD]

If the passwords are MD5 encrypted, you cannot decrypt. 
But you CAN create a password, encrypt it, and see if it matches anything in the database.
So easy passwords can be discovered, not decrypted...

[Deaks]

GerryD

Yes, they are encrypted. Unfortunately it's possible to brute force with about 6.7 million 3 billion, or more, attempts *per second*.
A very interesting article about that, if you care, is located here:
http://www.zdnet.com/blog/hardware/cheap-gpus-are-rendering-strong-passwords-useless/13125

[Kindred]

also, we haven't used MD5 in years - SMF 2.x uses SHA1 salted and hashed - but the data is still "recoverable" if you have the time and the processing power.

[chivitli]

SMF2 uses salt, but since it's being upgraded from previous version, only members who have logged in since have salted passwords. And even with it, it won't slow attacker much

Considering year in which we are, using SHA1, MD5 and in general using your own password hashing methods - is wrong. I'd suggest to consider PHP requirements for 2.1 version and bump PHP to 5.3.7, as many projects already require PHP 5.3+. Then, use hxxp:github.com/ircmaxell/password_compat [nonactive] library to have hashing method compatible with PHP 5.5 native methods, which is such that even if security breach of this scale happens, attacker would find hashes useless, as in reality there'd be no way to decrypt them, considering the alghorytm (which is very slow, unlike sha1, md5 etc which are very fast). It takes some work, but this breach proves that all softwares should do the hashing right (and stop inventing their own methods, cryptography is hard to get right)

[chivitli]

Actually, smf salt is useless. You're using 4 hexadecimal characters, so there are 65 536 possible salt combinations. It's easy to build lookup table for all of those combinations. Thus my point about inventing your own alghorytms... Some useful reading can be found at hxxp:crackstation.net/hashing-security.htm [nonactive]

[Trekkie101]

We didn't invent it, salting is used to stop rainbow tables so that each forum will present it's own challenge to decryption. SHA-1 has obviously degraded over the years and every now and then we improve the method we use to stay up to date.

[Arantor]

Much as I hate to get involved, someone who I owed a favour to asked me to comment.

Firstly, you're incorrect about some of your assertions. The salt you're referring to is not used to compute the password hash. The password in the database is stored as SHA1(strtolower(username) . password) and has been for a very long time in SMF. No extra table is required for this. Oh, and if you notice, it's not actually 'rolling their own'. It's following standard practice (take the password, add something that's account specific and hash that)... and in ANY case the salt would be useless if it were used because it's RIGHT THERE IN THE TABLE. It's only any use if it's otherwise an unknown, but since it's not an unknown element, because it's right there in the table, it doesn't really help any since you already have to construct a rainbow table for every account in the first place.

Secondly, not all hosts are currently using 5.3.7 and up. There are still some very major hosts running 5.2 and in fact some hosts still offering 4.4 hosting for the time being, even though 5.3 itself is officially maintenance only now, and most of SMF's typical demographic applies to those because they're the budget end of the market. So that's not really something SMF can implement in a realistic fashion, but I guess reality of lots of support requests (and there are already multiple requests per day related to one really poor free host and their limitations, but hey, let's add a crap ton more!) is irrelevant.

Thirdly, I don't believe you understand what it means by 'decrypting the password'. It is mathematically impossible to actually decrypt the password hashed by a digest hash like SHA1. What you do is find something that when combined with the username and then hashed will give you the same hash as what you're looking for... that means potentially multiple passwords will actually work because you're not looking to find the original, you're merely looking for a collision. You may want to search for multiple collisions for this very reason.

Fourthly, it is well researched and documented that most people suck at choosing passwords. A 2011 study (whose link I can't immediately find) found that 'password' was still by far the most common password, followed by '123456' and direct variations of that. Breaking into systems can be done with that fairly easily.

Incidentally, pushing everything to bcrypt may not be the smartest idea in the world. If everything is pushed to bcrypt and a *single* vulnerability is found, suddenly a lot more targets are actually located. Having everything in a slightly different form does at least have some benefits with respect to lowering the immediate attack vector options. There is a little comfort - but very certainly not a lot - from security through obscurity, but it is no substitute by any means for real security.

Thing to note: the system is only ever as strong as the people who hold the keys to it. It is often significantly easier to leverage a weakness in a person rather than in the technology under them, as was done here, to leverage the access to perform queries on the database. Once the database is compromised, best security practice is to assume it is *always completely compromised* even if the data is encrypted with the strongest possible methods, because you never know what resources the intruder has to break that.

Consider: this attack was to force an admin's account. If there was no way to run arbitrary code through some fashion with an admin's account or to pull a database backup of some kind, there would be less risk. In fact, if there is no method by which to run arbitrary code or pull a database backup without server access directly, you need to do more than brute force that account, and proceed to brute force a server account. If someone's already gotten into the server itself, assume everything is compromised anyway because by definition it is.

The whole thing about hashes is only an issue if someone gets into the server or otherwise can obtain raw access to the tables and right now there are ways by which an admin can do just that, either by splicing code into template files, or by uploading a package. Stronger controls need to be added to these to prevent arbitrary code being able to be run with just an admin's account, for example enforcing upload via FTP of plugins (as other software does), as well as limiting the ability to run arbitrary code from the admin panel by removing the ability to edit files from said admin panel and enforcing use of either hosting control panel or FTP download/local editing.

I see where you're going but honestly you're picking on one of the stronger links in the chain. There are far, far many more issues to consider... like how on a number of shared hosting setups it is actually possible for your setup to be hijacked as soon as you install a mod. Or how in a number of shared hosting setups it's possible for your entire database to be compromised and with you not being able to do *anything* about it whatsoever. But of course these are minor considerations when compared to worrying about what will happen when a hacker gets in... I'd personally prefer to keep them out in the first place where possible, rather than tightening up what happens when they already have. (Not that you shouldn't ALSO do that, but in terms of priority, it's really a secondary consideration. Don't worry about locking up the family silver if the front door is already unlocked.)

[chivitli]

Thanks for the reply Arantor, my apologies if my tone sounded too harsh, it was not the intent.

My first assumption was incorrect indeed, as I read in Kindred's statement about the use of salt. So having seen salt column in db, I connected the pieces without looking into the code. In your case then username plays the role of the salt. Use of salt is not useless, because it prevents using a single lookup table.

I know that not all hosts are completely updated. By the time smf 2.1 comes out, situation will definitely be better. Latest Joomla, Vbulletin, Drupal, IPB 4, phpBB 3.1 (once they come out) etc require 5.3+, and on many budget hosts it's possible to choose php version. In any case, I'd expect situation to improve in the future. But I agreee that not all may have 5.3.7 as the minimum.

Thirdly, that's an unfair asumption, and yes I understand it very well, I guess anyone who ever bothered understanding anything about this topic got it. Though collision for sha1 is unlikely, attacker would usually use precomputed hashes from dictionary passwords, thus be after the original one. You cannot "decrypt" anything which is hashed, since hashing != encryption. But you can try to guess the original password, or depending on the algorhytm find the one with same hash.

Fourth - that's true, but I don't see how it relates to choosing hashing alghorytm. You can't protect irresponsible users, but you can do something for those who don't use "123456" passwords.

I am not a fan of security through obscurity, but in any case I don't see it as an option in open source software. Pushing everything to bcrypt with unknown weakness seems better than using alghorytm with known weaknesses, though I do get your point. If a weakness is discovered, well, you're in the same basket as everyone else, I doubt it's something which won't taken care of fast. But considering how long it's been tested, it seems fairly strong.

And I completely agree that there are many weaknesses out there, where people using/configuring the system are by far the biggest. I focused on this just because there have be so many hashed passwords stolen on various websites, that it's maybe time that everyone updates. At least if someone breached in the DB (and there are so many roads), *most likely* attacker won't be able to do anything with hashes. Even though the notice about the need to update the password would still be due.