Boards.ie Attack - What Happened? Please post all questions here.

Jonathan

DaPoolRulz wrote: »

Boarder Man, could you answer something for me. How can this be the first time you've heard about it if you had to reset your password when the site came back online to get access to your account back?

He possibly got the PM email notification and reset his password when he came to post?

Daemos

Ah well spotted, makes sense now, thanks

Conor

The Boarder Man wrote: »

Not likely. The email account I use for Boards goes to two different mail providers. One of them is over zealous so I check the Spam folder regularly, the other doesn't filter much at all and it's not there either. Possibly got caught in a server side filter???

It's quite possible that the initial mail was dropped outright.

When we were sending it, we were still at the point where our own machines were not available for use (myself and Ross were still in the process of restoring them from known-safe sources) so Daft spun up a bunch of Amazon EC2 instances for us and we used those to send them. Since the mail from those EC2 machines were not coming from the regular Boards.ie infrastructure, many e-mail providers would have either marked them as spam or dropped them outright. It was very much a "best effort" attempt at getting the mails through, which was why it was important for us to leave the same message on the site while it was down and for Darragh to contact as many media outlets as he could to get the word out.

The recent PM used our regular machines and the vBulletin PM system, but even then many notification e-mails were bounced and I suspect many more were silently dropped. Hotmail in particular has been dropping notification e-mails from us (on and off) for some time now.

The frustrating thing (for me, at least) is that I have no idea who did or didn't get the notification. Most mail considered spam is dropped, not bounced* so there's no way for me to tell the difference between a successfully delivered mail and a failure.

Could we have sent one or more e-mails/PMs between the end of January and now? Certainly. Would it have made an appreciable difference in the number of people who knew about the attack? I don't know, but I doubt it. Judging by the number of people resetting their password, posting here and using the contact form, most people either got the message (by e-mail, site announcement, mass media, whatever) in January or don't care either way. I'd love to figure out a way of efficiently contacting people who haven't found out, but I can't think of a way of doing that without unnecessarily contacting those who have.

I'm very sorry that some people didn't get the message the first time. I'm also very sorry for those people who still haven't got the message. If anyone knows how to contact those without spamming people who did get the message, I'm all ears.

* This is a very, very good thing BTW.

The Boarder Man

DaPoolRulz wrote: »

Boarder Man, could you answer something for me. How can this be the first time you've heard about it if you had to reset your password when the site came back online to get access to your account back?

Jonathan wrote: »

He possibly got the PM email notification and reset his password when he came to post?

Yep.

Conor wrote: »

It's quite possible that the initial mail was dropped outright.

When we were sending it, we were still at the point where our own machines were not available for use (myself and Ross were still in the process of restoring them from known-safe sources) so Daft spun up a bunch of Amazon EC2 instances for us and we used those to send them. Since the mail from those EC2 machines were not coming from the regular Boards.ie infrastructure, many e-mail providers would have either marked them as spam or dropped them outright. It was very much a "best effort" attempt at getting the mails through, which was why it was important for us to leave the same message on the site while it was down and for Darragh to contact as many media outlets as he could to get the word out.

The recent PM used our regular machines and the vBulletin PM system, but even then many notification e-mails were bounced and I suspect many more were silently dropped. Hotmail in particular has been dropping notification e-mails from us (on and off) for some time now.

The frustrating thing (for me, at least) is that I have no idea who did or didn't get the notification. Most mail considered spam is dropped, not bounced* so there's no way for me to tell the difference between a successfully delivered mail and a failure.

Could we have sent one or more e-mails/PMs between the end of January and now? Certainly. Would it have made an appreciable difference in the number of people who knew about the attack? I don't know, but I doubt it. Judging by the number of people resetting their password, posting here and using the contact form, most people either got the message (by e-mail, site announcement, mass media, whatever) in January or don't care either way. I'd love to figure out a way of efficiently contacting people who haven't found out, but I can't think of a way of doing that without unnecessarily contacting those who have.

I'm very sorry that some people didn't get the message the first time. I'm also very sorry for those people who still haven't got the message. If anyone knows how to contact those without spamming people who did get the message, I'm all ears.

* This is a very, very good thing BTW.

Thanks for the reply. I appreciate that a lot of effort went into the response from the Boards team and that it was mostly complete and effective. However, since I was one of the "unlucky" ones I'm still of the opinion that a PM should have been sent out earlier even if it meant notifying a lot of people twice. But, I'm happy to move on now.

DeVore

Cool... lets do that and hopefully bring this unfortunate period to a close.

DeV.

TheyKnowMyIP

Any updates in relation to this attack? I am intrigued by Conor's post where he stated that only part of the user database was potentially downloaded. Could you please clarify this statement where possible? Have these sensitive user details been recovered, or is it safe to presume any user data is essentially public knowledge at this point?

Thanks

Dav

The case is at a stage where we can't talk about it as it may prejudice things or put us in contempt of court.

As a general guideline though, I would treat any data that's been compromised like this as "in the wild." In our case, repeating what's already been said, the User Table was taken which has your username, email address, any other information you'd chosen to give us and a hashed and salted copy of your password.

blatantrereg

Dav wrote: »

The case is at a stage where we can't talk about it as it may prejudice things or put us in contempt of court.

As a general guideline though, I would treat any data that's been compromised like this as "in the wild." In our case, repeating what's already been said, the User Table was taken which has your username, email address, any other information you'd chosen to give us and a hashed and salted copy of your password.

Is the court case finished? Can you talk about it?

In our case, repeating what's already been said, the User Table was taken which has your username, email address, any other information you'd chosen to give us and a hashed and salted copy of your password.

How does this work? You dont enforce https. The password is hashed using this clientside javascript -- http://b-static.net/vbulletin/clientscript/vbulletin_md5.js?v=387

Surely if someone can gain access to the server, then there is a signifcant possibility that they would also be able to reverse this? So saying they have a hashed and salted version of your password might be selective editing to suggest the compromise is less severe than it actually was?

Come to think of it, any time someone logs in over http on a shared network, someone could get their password in this form - as well as see the encoding script. That seems dreadfully insecure tbh.

Why not enforce https for logging in? Most major sites do that, and https works on this site already.

GlennaMaddy

blatantrereg wrote: »

Why not enforce https for logging in? Most major sites do that, and https works on this site already.

Why not get out of the password business altogether and allow us to use Facebook login, Google login etc.

Boards.ie: Danny

GlennaMaddy wrote: »

Why not get out of the password business altogether and allow us to use Facebook login, Google login etc.

Why not encourage more sites to use Boards login like Adverts?

seamus

blatantrereg wrote: »

Is the court case finished? Can you talk about it?

No. To the best of my knowledge anyway it's still ongoing. Probably actually be in the papers when it comes up.

Surely if someone can gain access to the server, then there is a signifcant possibility that they would also be able to reverse this? So saying they have a hashed and salted version of your password might be selective editing to suggest the compromise is less severe than it actually was?

No, it's factual. The attacker didn't actually get access to the server. They had access via a backdoor to be able to view and download tables from within the database.

It wasn't a sitting a terminal with root access to the underlying OS scenario like you see in the movies.

As best I understand it, the attacker managed to get the table containing the hashed and salted passwords, but didn't get the salts (which are stored in a separate table). I might be wrong on that. Without the salts, reverse-engineering is possible, but a lot more diffcult.

Come to think of it, any time someone logs in over http on a shared network, someone could get their password in this form - as well as see the encoding script. That seems dreadfully insecure tbh.

Why not enforce https for logging in? Most major sites do that, and https works on this site already.

"Dreadfully insecure" is probably putting it a bit strong IMO. Using HTTPS for logon has a larger overhead than standard HTTP, so it's not really a matter of flicking a switch. In a list of "important things that boards needs done", adding an additional layer of logon security would rank way down there.
At present boards does at least what any other forum does, and more than most. I still get emails the odd time from sites saying, "You haven't logged in, in a while. Here are you logon details in case you've forgotten", and an old password staring at me, in plaintext.

If you concerned about privacy on a shared network, then I would suggest that it's you who has more work to do on securing your info than boards tbh. If you don't control the network that you're using, then HTTPS is just as vulnerable as HTTP.

As for other logons, it's always a good idea, but probably way down there in terms of priority. Not everyone has a facebook or google account, and limiting the available logon options will turn away a lot of potential users, either because they don't have one of those accounts or because they don't want to allow boards to sign in via a Google or facebook account.

It would be nice, I agree, but not essential, and boards could never really get "out of the password business" without making a conscious decision to turn potential new users away.

GlennaMaddy

Boards.ie: Danny wrote: »

Why not encourage more sites to use Boards login like Adverts?

Because you were hacked once, and now I can't trust boards.ie with my preferred password.

Boards.ie: Danny

blatantrereg wrote: »

Is the court case finished? Can you talk about it?

How does this work? You dont enforce https. The password is hashed using this clientside javascript -- http://b-static.net/vbulletin/clientscript/vbulletin_md5.js?v=387

HTTPS is just encrypting communications between the user and the server. It is not server-side security. The password is hashed with md5 client-side to avoid sending plaintext passwords which can be sniffed. If a user has JS turned off then we'll take their plaintext password and md5 it server side before adding it to the salt and md5'ing the lot again to check against our records for the correct password.

Surely if someone can gain access to the server, then there is a signifcant possibility that they would also be able to reverse this? So saying they have a hashed and salted version of your password might be selective editing to suggest the compromise is less severe than it actually was?

There are 4 bits of information in the equation - plaintext password, md5 password, salt, stored password (the result of md5[md5 password + salt]). All they have is the stored password and the salt.

They need to produce a string that when md5'd and concatenated with the salt for the given user and md5'd again will match the stored password. The likelihood that this will occur is very very small. Unlike other systems that just store the md5 of your password which becomes vulnerable via a Rainbow Table lookup, using salts effectively kills this option and massively reduces the chance of a collision (and thus, a password crack).

Come to think of it, any time someone logs in over http on a shared network, someone could get their password in this form - as well as see the encoding script. That seems dreadfully insecure tbh.

Sniffing will either return the plaintext password if clientside JS is off, or will return the MD5 of the password if JS is on. This can be looked up via rainbow tables. If this is a concern you do have the option of using HTTPS

justsomebloke

Boards.ie: Danny wrote: »

Why not encourage more sites to use Boards login like Adverts?

Since my name change on boards around a month or so ago my usernames on boards and adverts are no longer the same

Boards.ie: Danny

justsomebloke wrote: »

Since my name change on boards around a month or so ago my usernames on boards and adverts are no longer the same

Offtopic ever so slightly...but it's not something most sites using external auths expect to happen. They expect that if they're presented with a new username it's a new user

blatantrereg

Boards.ie: Danny wrote: »

HTTPS is just encrypting communications between the user and the server. It is not server-side security. The password is hashed with md5 client-side to avoid sending plaintext passwords which can be sniffed. If a user has JS turned off then we'll take their plaintext password and md5 it server side before adding it to the salt and md5'ing the lot again to check against our records for the correct password.



There are 4 bits of information in the equation - plaintext password, md5 password, salt, stored password (the result of md5[md5 password + salt]). All they have is the stored password and the salt.

They need to produce a string that when md5'd and concatenated with the salt for the given user and md5'd again will match the stored password. The likelihood that this will occur is very very small. Unlike other systems that just store the md5 of your password which becomes vulnerable via a Rainbow Table lookup, using salts effectively kills this option and massively reduces the chance of a collision (and thus, a password crack).



Sniffing will either return the plaintext password if clientside JS is off, or will return the MD5 of the password if JS is on. This can be looked up via rainbow tables. If this is a concern you do have the option of using HTTPS

Thanks - there's a lot of information in that.

I knew what https was. However I had [apparently incorrectly] inferred from a post here that passswords could be determined from server access (if not stored in plain text) if they were sent in encrypted form from the client.

Out of curiosity I sent a couple of cloned requests of my logins to see if they logged me in. They didn't.

I might sound daft, but without having a great knowledge of the subject I am surprised at how bad security is in a lot of places. A popular takeaway site is an example. It sends passwords in plain text, seems to store them in plain text (the password reminder email contains your actual password), and doesnt support https. They send you to a separate secure server to handle credit card info, but they do store your name, address, phone number - and password reuse is likely to be an issue too.

Morag

GlennaMaddy wrote: »

Because you were hacked once, and now I can't trust boards.ie with my preferred password.

preferred password?

Honestly what sort of idiot uses the same password on different sites?

GlennaMaddy

Sharrow wrote: »

preferred password?

Honestly what sort of idiot uses the same password on different sites?

I've about 6 different passwords that I use frequently, and I use Google, Facebook and Twitter logins where they are accepted. I've a special password just for boards.ie since the hack event, and that's a nuisance I could do without

Do you have individual passwords for every site you use?

TouchingVirus

GlennaMaddy wrote: »

Do you have individual passwords for every site you use?

I do, 143 and counting. How do I remember them? Using a password safe

All your eggs in one basket, even the Google/Twitter/Facebook basket is a bad idea IMO.

who the fug

TouchingVirus wrote: »

I do, 143 and counting. How do I remember them? Using a password safe

And you password for the safe is

TouchingVirus

who the fug wrote: »

And you password for the safe is

I'll save you the trouble, my credit card details are:

Paul Long
4921 0943 2122 3412
Exp 08/12
CVV2: 816

GlennaMaddy

TouchingVirus wrote: »

I do, 143 and counting. How do I remember them? Using a password safe

All your eggs in one basket, even the Google/Twitter/Facebook basket is a bad idea IMO.

And you have this password safe thing on all the laptops, pc's, phones etc?

blatantrereg

Most people reuse passwords because they have too many to remember otherwise.

This is a good policy: Limit the number of places you put anything confidential. Use strong individual passwords where you do. Use junk passwords and junk email accounts for everything else.

GlennaMaddy

blatantrereg wrote: »

Most people reuse passwords because they have too many to remember otherwise.

This is a good policy: Limit the number of places you put anything confidential. Use strong individual passwords where you do. Use junk passwords and junk email accounts for everything else.

This is exactly what I do, and I suspect others do too. I used to use a junk password on boards but now I've a unique junk password -as a password change was recommended by boards.

Last time I considered a password safe I wasn't convinced this was going to be any more secure as the safe's I looked at didn't have brute force protection and weren't available for the three devices I used regularly.

pickarooney

Sharrow wrote: »

preferred password?

Honestly what sort of idiot uses the same password on different sites?

About 93% of people.

who the fug

TouchingVirus wrote: »

I'll save you the trouble, my credit card details are:

Paul Long
4921 0943 2122 3412
Exp 08/12
CVV2: 816

Is there any credit on that one, also you share the same card number as Mr. P M Y Leg

blatantrereg

seamus wrote: »

No. To the best of my knowledge anyway it's still ongoing. Probably actually be in the papers when it comes up.
No, it's factual. The attacker didn't actually get access to the server. They had access via a backdoor to be able to view and download tables from within the database.

It wasn't a sitting a terminal with root access to the underlying OS scenario like you see in the movies.

As best I understand it, the attacker managed to get the table containing the hashed and salted passwords, but didn't get the salts (which are stored in a separate table). I might be wrong on that. Without the salts, reverse-engineering is possible, but a lot more diffcult.
"Dreadfully insecure" is probably putting it a bit strong IMO. Using HTTPS for logon has a larger overhead than standard HTTP, so it's not really a matter of flicking a switch. In a list of "important things that boards needs done", adding an additional layer of logon security would rank way down there.
At present boards does at least what any other forum does, and more than most. I still get emails the odd time from sites saying, "You haven't logged in, in a while. Here are you logon details in case you've forgotten", and an old password staring at me, in plaintext.

If you concerned about privacy on a shared network, then I would suggest that it's you who has more work to do on securing your info than boards tbh. If you don't control the network that you're using, then HTTPS is just as vulnerable as HTTP.

As for other logons, it's always a good idea, but probably way down there in terms of priority. Not everyone has a facebook or google account, and limiting the available logon options will turn away a lot of potential users, either because they don't have one of those accounts or because they don't want to allow boards to sign in via a Google or facebook account.

It would be nice, I agree, but not essential, and boards could never really get "out of the password business" without making a conscious decision to turn potential new users away.

Oddly this post didnt seem to show up until after ones below it - or I guess it is more likely I just didnt see it...

You already can log on via https on boards so there wouldnt be any need to add additional layer. The only difference between what I suggested and the current situation is to make it the default or mandatory. I doubt the overhead would be that big to enforce https on logins only.

If you don't control the network that you're using, then HTTPS is just as vulnerable as HTTP.

That's simply incorrect. To get readable information transmitted over http all you need is a packet sniffer. I dont know how to get information transmitted over https. My understanding is that https is specifically intended for transmitting information over untrusted networks. You're basically rubbishing https entirely with this statement.

It's considered good practice to use https where confidential information might be involved on an untrusted network. Boards does offer this option so it leaves the user to decide if they are on an untrusted network or not. However most people using free wireless etc dont think "oh I'll switch to https because this connection mightn't be secure." That's why there's a movement that wants https to be everywhere - or at least for people to be made aware of what risks they might be exposed to. That said, the only time plain text unencrypted passwords are sent on boards are when javascript is turned off and http is used.

Incidentally, I'm saying this to clarify information, not because I am still pushing my original argument.

TouchingVirus

GlennaMaddy wrote: »

And you have this password safe thing on all the laptops, pc's, phones etc?

Yes

seamus

blatantrereg wrote: »

You already can log on via https on boards so there wouldnt be any need to add additional layer. The only difference between what I suggested and the current situation is to make it the default or mandatory. I doubt the overhead would be that big to enforce https on logins only.

The overhead may not be much on a small scale, but it depends on how many logins are processed by boards. I actually did know that it was possible to use HTTPS, but I forgot.

That's simply incorrect. To get readable information transmitted over http all you need is a packet sniffer. I dont know how to get information transmitted over https. My understanding is that https is specifically intended for transmitting information over untrusted networks. You're basically rubbishing https entirely with this statement.

Google "man in the middle" attacks. I'm not rubbishing HTTPS, but it was designed to provide point-to-point security. You lose that security when you insert another point (like a transparent proxy) between you and the web server.

If you are on a network that you do not control, then you can't even trust HTTPS to keep you free from packet sniffing.

Obviously the exposure is greater using HTTP and you're at risk from dodgy users as well as dodgy admins, but it's still the case that HTTPS isn't the be-all of web surfing security.

blatantrereg

seamus wrote: »

The overhead may not be much on a small scale, but it depends on how many logins are processed by boards. I actually did know that it was possible to use HTTPS, but I forgot.

Google "man in the middle" attacks. I'm not rubbishing HTTPS, but it was designed to provide point-to-point security. You lose that security when you insert another point (like a transparent proxy) between you and the web server.

If you are on a network that you do not control, then you can't even trust HTTPS to keep you free from packet sniffing.

Obviously the exposure is greater using HTTP and you're at risk from dodgy users as well as dodgy admins, but it's still the case that HTTPS isn't the be-all of web surfing security.

I never said it was. You said that "HTTPS is just as vulnerable as HTTP". It isn't.

Https doesnt make eavesdropping impossible. Obfuscation doesn't make reverse engineering of code impossible. Locking your door doesn't make burgulary impossible. However these things are all good ideas because they increase the effort required and decrease the convenience. Once you are out of the "risk/effort < reward" bracket for crackers - or at least have that ratio less enticing than most - you are probably ok.

I was reading about man in the middle attacks earlier today. They are one thing that https is specifically used to combat . I think your point is just that https isnt a silver bullet and that you are overstating that.