Simple Machines Community Forum

Hello SMF,

I just now learned about the thread IMPORTANT: Community security breach (http://www.simplemachines.org/community/index.php?topic=508232). I of course would simply reply there but the thread is locked. The thread has a lot of pages and while I spent some time searching I didn't find a specific answer to this so here goes:

I read the opening post and believe to understand what happened. Correct me if I am wrong, but I assume that once the 'hacker' logged into an admin account he pointed his browser to Admin Center > Server Settings > Database and Paths. From there one could find the database username, but the password is encrypted. There is discussion on how hackers can decrypt this, so I assume that is what was done and the password was somehow able to be viewed in plain text.

What I'm doing
In Admin.template.php, right at the beginning of the function template_show_settings(), I've added this:

  // If you are not really BigMike then GTFO
  $allowedip = array('##.###.###.###', '##.###.###.###', ...... );
  if (!in_array($_SERVER['REMOTE_ADDR'], $allowedip))
    return;

...where these are the IP numbers of my internet connection here at work and at my house.

Now the only way to view admin settings is to be physically connected to the network here or at my house.

My Question
Is this enough to prevent what happened? My goal is that if someday in the future someone logs in with some admin's account they won't see JACK, just blank admin settings pages with tabs at the top.

I'm assuming that without the encrypted "Database Password" field filled in, there would be nothing to decrypt .... correct?

Thanks!!
Mike

the issue that happened here had nothing to do with the username or password of the database being used from that page.

That's not what happened. It's a reasonable supposition but it's not what happened.

Incidentally, that part of the admin page is gone in 2.1 but for a different reason ;)

LainaaNow the only way to view admin settings is to be physically connected to the network here or at my house.

If template_show_settings were the only way to obtain such, I would agree with you, but it isn't - and would not even remotely have prevented the attack that actually happened here. You don't need direct access to the DB connection details to query the DB.


What I will tell you is that viewing the settings is not even remotely the most serious thing a hacker could do if they obtained your admin password. They can upload mods and themes - each of which contains raw PHP code - and can also edit your theme templates to access raw code. And none of this is prevented by your modification.

IP address binding is one method, but certainly not a foolproof one, of hardening your account against tampering. http://custom.simplemachines.org/mods/index.php?mod=2181 will handle that for you should you wish to do so, and do so across the entire form rather than just the settings page.

Ahh very interesting, thank you Gentlemen for the enlightenment. We have three total admin accounts including myself because sometimes I am away (I visit Japan often) and it's nice having someone around who can drop the admin-hammer if needed.

I don't know much about hacking (which is both good [at least not everyone is a hacker] and bad [I should know how to protect myself]). That thread really opened my eyes to a lot of stuff and I read a lot of great articles surrounding the hacking of passwords. I've learned a bit about sql injection and am now going to learn more on malicious code gaining access to my raw data.

Topic marked as solved! Thank you again!
Mike

Hey guys,

I'd like to follow-up on this. I have done a ton of reading and have learned a lot! Very, very interesting stuff.

Can someone please confirm if the following are correct:
1) When I enter my password and log into SMF, SMF hashes whatever I just entered and then compares that hash to the hash currently stored in my profile, correct?
2) SMF doesn't actually know what my actual password is, correct? It only knew it long enough to get it hashed, and then it dropped it, yes?
3) Currently, there are only two direct ways to crack hashes: No.1: by "discovering" and hashing the actual/correct string to yield a matching hash, or No.2: by the rare chance of collision. Is this correct?

What I've done with my personal passwords are the following:
1) I used this Strength Tester (http://rumkin.com/tools/password/passchk.php) and surprisingly found that my "most secure" password designs were only in the 40-45 bit range. In fact my more common password formats - which I thought were pretty decent - only scored in the 35-40 bit range (all the while I assumed my "most secure" passwords were over 9,000 times stronger).
2) I redesigned all of my password formats to now be almost 70 bits
3) I used time estimations from this Password Checker (http://password-checker.online-domain-tools.com) to make sure even medium sized botnets will take a very long time to crack em (currently over 200k years by that site's estimation which I think is probably overkill but I don't mind since you can't put a price on good security measures)

What I'm trying to get at is this: If we are going to update our passwords annually, then shouldn't we ensure that our passwords should take at least 10 times longer to crack, or some multiplier like that ... which in theory and also with luck will provide enough of a technology-advancement-buffer from password change to password change?

Thanks! All of this has TRULY opened my eyes about passwords and security. I've always known that its good to know what your enemy is doing (hackers), but I've never researched or genuinely cared to learn just what is going on until just one week ago.

Regards,
BigMike

1. Assuming you have JavaScript enabled, the password is normally hashed before it's even sent to the server (SHA1(SHA1(lowercase(username) + password) + session id). The server has the SHA1(lowercase(username) + password) stored and it rehashes with session id and compares that.

2. Correct. The only time in normal operation that SMF ever gets a password in plain text are the times you first register and if you change your password, and even then it never stores the plain version.

3. Correct.


Regarding your passwords:
1. Your tester is ... interesting. A phrase of mixed case, symbols and numbers is considered an order of magnitude weaker than a phrase of pure letters of similar length.

2. Good for you. Have fun remembering it.

3. Meaningless. All these precautions seem to assume the attacker already has your hash and is trying to brute force it. Improvements in CPU/GPU usage mean that it's possible to break SHA1 in a matter of minutes with the right commercially available hardware.

Of course, this assumes *the attacker already has your hash*. Which means your database has been already compromised, so you already lost the game.

If however you're trying to prepare against your account being bruteforced, you'd actually likely notice long before that happened anyway by way of all the errors in the admin error log of someone trying to force your account.

As always your replies are much appreciated Arantor.

Good to know on points 1-3. Thank you for explanation and confirmations.

Lainaus käyttäjältä: Arantor - marraskuu 13, 2013, 01:31:34 IP
Regarding your passwords:
1. Your tester is ... interesting. A phrase of mixed case, symbols and numbers is considered an order of magnitude weaker than a phrase of pure letters of similar length.

Hmmm that is no good. :o

Lainaus käyttäjältä: Arantor - marraskuu 13, 2013, 01:31:34 IP
2. Good for you. Have fun remembering it.

So what I'm doing is I have one kind of lengthy phrase that I remember, and then for every site I draw a few particular words to intermix with my phrase. Memorization is kept relatively in check and this ensures a big string length.

The only caveat would be if someone cracked 3 or 4 of my passwords then they would see a pattern form, but my intent is for them to be more difficult to crack and the base phrase I'm using is incoherent to the normal person, just looks like gibberish (but meaningful to me). So having one cracked password won't clue them into anything about my habits. Then after 1 year I switch up the base phrase and start over.

Lainaus käyttäjältä: Arantor - marraskuu 13, 2013, 01:31:34 IP
All these precautions seem to assume the attacker already has your hash and is trying to brute force it. Improvements in CPU/GPU usage mean that it's possible to break SHA1 in a matter of minutes with the right commercially available hardware.

Of course, this assumes *the attacker already has your hash*. Which means your database has been already compromised, so you already lost the game.

So this is where I am drawing my nervousness-slash-preparedness: For that dumb obscure site I created an account with 6 mos ago that took a small group of ten year olds five mins to hack. Now my hash is -- unbeknownst to me -- "out in the open". My goal is to have something difficult (certainly not impossible) to crack so that by the time I go around updating all my passwords the hash they have is rendered unusable.

BigMike

And if you have a password unique to your site, the hash is useless anyway.

Unless your server is compromised, which means the game is over anyway.

(And for sites I don't care about, I use 'password' as a password.)

That's a good idea to use some dumb, easy to use/remember phrase for sites one doesn't care about. I didn't think about that.