Talk

Flip

MNHQ have commented on this thread

1 2 ··· 5 6 7 ··· 28 29

MNHQ have commented on this thread

Site stuff

More about the Technical side of the attacks on Mumsnet

720 replies

JustineMumsnet · 19/08/2015 11:17

Hi all,
There are have been, understandably, a lot of questions about the tech side of the attack on Mumsnet, so here - courtesy of the tech team is some more detail. We obviously do have to be a bit careful with the details because we don't want to give away information that could help other hackers. Whilst it's true that "security through obscurity" isn't real security, we have no wish to make it easier for a future attacker.

We've spent a lot of time since the attacks began, proactively defending against them, minimising the impact of it and protecting against future attacks. With a busy site like Mumsnet there is a lot of information to go through. When we uncover a new snippet of information, perhaps a new suspicious user account, we have to go back to the start and reanalyze, so it can be slow going at times. We are working with our technology partners who have a lot of experience of these kind of attacks and we have used lots of resources available to us.

Some aspects of our technology stack have already been extensively tested by external specialists. Some of our software code is quite old - nearly as old as Mumsnet itself - and things have moved on a lot over that time. However, we have a program of code review whereby all new code is checked by someone other than the person who created it. It's not perfect and everyone makes mistakes, but we take the quality of our code very seriously.

The Denial Of Service (DOS) attack against Mumsnet was a heavy, sustained attack which initially overwhelmed our ability to respond to legitimate requests. Mumsnet might typically get something like 50-100 requests per second. During the attack we were getting around 17,000 requests per second. Each request carried more data than is normal as well.

The hacking attack on our website was separate from the DOS, though we believe perpetrated by the same person or people. We follow many of the industry's best practices, such as using HTTPS for our login pages, keeping our database separate from our cluster of web servers and not accessible from the internet, and so on. We don't necessarily use the same standards of security as say your online banking service might use, for example requiring multiple passwords or using two factor authentication. We try to balance security against usability and the sensitivity of the information we hold. After all, as pointed out by one of you in an earlier thread, the majority of information we have about a user is what that user publishes in Talk, which is there for all to see.

As has been mentioned several times, we keep our passwords encrypted and we use the recommended algorithms for this, with high "strength" settings. This means that if someone somehow obtained the password data from our database they wouldn't be able to make any use of them - they wouldn't work on our site or on any other site even if the user used the same password on that other site. This remains the case even for MNHQ staff; they cannot un-encrypt the passwords either.

We are now pretty confident it was a phishing attack. Phishing, where a hacker gets a user to enter their username and password into a form from which they can capture that information, fits all the data we have. The hacker doesn't need to decrypt anything, because they capture the password in the browser as it is entered (either by typing it, or if it was automatically remembered by the user's browser or password manager). The list of passwords that has been published includes some that users have identified as being ones that they've mistyped. Our database wouldn't have mistyped ones, only accurate ones, whereas those collected by recording what a user submits would and does contain errors.

It's not obvious how it has been conducted though. We have been able to create a proof of concept which shows that it could work, but that relies on some steps that would be difficult or virtually impossible for a hacker. Phishing attacks sometimes use social engineering to "trick" people into using the fake website rather than the real one, but again, for various reasons, we can rule some of these out. Other phishing attacks are more technical and use other means to get people to visit the fake page. One such example is Cross Site Scripting (XSS). XSS is ranked number three on Open Web Application Security Project top ten list of web site security problems. If the hacker can get the website to put his own code on pages which are to be viewed by other users, s/he can modify the page to either redirect the login process to their own site, to a page which looks just like our login page but is actually recording the details and sending them to the hacker. Also possible, but even less likely, is modifying our login page to submit the details to the hacker as well as to us. If the hacker had gained access to our Content Management System he could have done the former, though not the later. However, we record all changes that are made and there are no suspicious ones.

It's impossible for us to know how many users' passwords have been collected. It's a reasonable assumption, and our working one, that the passwords of everybody that has logged since 6th August 2015, and possibly some time before that, have been collected.

In light of the attacks, we've bolstered some aspects of our security, particularly around our administrative functions. We have further changes planned and will be working on these in the coming days.

Forcing everyone to reset their password, as we have done, would render the list useless provided that users don't choose the same new password and they've not used the same username and password elsewhere.

Some users have questioned why certain other changes aren't being made already, such as a move to enforcing stricter passwords, which makes sense. However, given how crucial the part of our system that deals with passwords is, we have to be really cautious when making changes to it so we don't want to rush and end up creating bigger holes but we will certainly take steps to encourage users to strengthen passwords as soon as practicable.

Any questions do post here - we'll answer as transparently as we can - bearing in mind the caveat about helping future hackers mentioned earlier.

OP posts:

Report

DavidTech · 19/08/2015 13:03

@Altinkum

*davidtech*

when posters are being forced to password change, can you put an alert message on stating it has to be a new password? not the old one!

many posters as have many said, still do not the the site is under attack.

Yes, we are doing that. It's not ready yet but it will be in our next update.

@UnbelievableBollocks

There has always been a requirement for at least 8 characters, which is actually the OWASP's recommendation.

They may have been recommendations, but it's established good practice that admin passwords should be more complex, regardless of whether you have enforced complexity rules. It's a bit like having the best safe money can buy, with a lock combo of 00000000 because the recommendation is a code of 8 numbers. It's valid, but bonkers.

Hey ho!

Absolutely. Some of those passwords were woefully inadequate. Again, without giving away too much, for what it's worth, MNHQ did recently do a whole-company session on data security.