Google Search

Showing posts with label intrusion. Show all posts
Showing posts with label intrusion. Show all posts

Saturday, June 22, 2013

Scribd, "world's largest online library," admits to network intrusion, password breach

Over 170,000 people are part of the Sophos community on Facebook. Why not join us on Facebook to find out about the latest security threats.

Hi fellow Twitter user! Follow our team of security experts on Twitter for the latest news about internet security threats.

Already using Google+? Find us on Google+ for the latest security news.

San Francisco-based document sharing site Scribd has admitted to a network intrusion.

Scribd bills itself as The World's Largest Online Library, and with a suggested 50 million users or more, it's hardly surprising that the site has attracted the attention of cybercriminals.

Details are scant, but a notification published on the company's online Support Desk states:

Earlier this week, Scribd's Operations team discovered and blocked suspicious activity on Scribd's network that appears to have been a deliberate attempt to access the email addresses and passwords of registered Scribd users.

Because of the way Scribd securely stores passwords, we believe that the passwords of less than 1% of our users were potentially compromised by this attack.

We have now emailed every user whose password was potentially compromised with details of the situation and instructions for resetting their password.

Therefore, if you did not receive an email from us, you are most likely unaffected.

The comment that less than 1% of users were potentially compromised "because of the way Scribd stores passwords" could probably have been made more clearly.

At first blush, I was inclined to interpret this to mean that 99% of passwords were stored securely, presumably by salting and hashing, leaving only a small proportion open to the scrutiny of intruders.

? We've seen cases before where websites have upgraded their password handling systems to make them safer, but seem to have failed to migrate all users to the new system in a timely fashion, leaving some users in an insecure limbo.

The good news, if you read on, is that it looks as though none of Scribd's passwords are stored in cleartext, as the company goes on to say that:

Our investigation indicates that no content, payment and sales-related data, or other information were accessed or compromised. We believe the information accessed was limited to general user information, which includes usernames, emails, and encrypted passwords.

Scribd isn't claiming any certainty in what was taken (the verb believe implies acceptance without proof), but that's not unexpected.

Determining precisely what was stolen after an electronic break-in is tricky, and pedantic readers will be quick to point out that, technically, nothing was stolen because the original copies of the data remained behind.

Scribd also isn't clarifying how the passwords were encrypted, and the company probably doesn't actually mean encrypted, either.

Salting and hashing passwords is supposed to be a one-way process that allows the passwords to be verified, but not decrypted to reveal the original cleartext.

Assuming they were hashed and salted, then, stealing the password database doesn't directly reveal anyone's password.

But it does let the crooks mount an offline attack on the database, hashing a dictionary of passwords one-by-one and noticing when a guessed password is verified against the database of hashes.

And since Scribd isn't saying what password security algorithm it used, you have little choice but to assume it was a hashing process that doesn't slow down determined attackers much.

That's why the following behaviours are important:

When you choose a password, don't pick anything obvious. Attackers put the most likely passwords at the top of their dictionary lists, so the tougher your password, the later it will fall, if at all.Don't use the same password on multiple sites. Doing so means that your login details on the most important site are at risk from an attack on the least secure one.If you store password databases, use a strong salt-and-hash system (e.g. bcrypt, scrypt or PBKDF2) that makes it much harder and slower for attackers to go through their password dictionary, but not so slow that it's impracticable to verify individual passwords when your users login.

Scribd has put up an online "breach checker" which lets you check individual email addresses against the list of probably-pwned accounts:

It would have been a nice touch if the company had used HTTPS for this particular page, rather than sending your email address, and the notification of whether it was on the at-risk list, via unencrypted HTTP:

On the other hand, since anyone can check anyone's email address anyway, and since you probably received an email advising you to change your password already if your account was potentially pwned, it probably doesn't matter.

To learn more about managing, choosing and policing passwords in your organisation, why not listen to our popular Techknow podcast on this very topic?

(If you prefer to listen offline, you can download the podcast for later.)

Follow @duckblog


View the original article here

Tuesday, February 12, 2013

DHS website falls victim to hacktivist intrusion

Over 170,000 people are part of the Sophos community on Facebook. Why not join us on Facebook to find out about the latest security threats.

Hi fellow Twitter user! Follow our team of security experts on Twitter for the latest news about internet security threats.

Already using Google+? Find us on Google+ for the latest security news.

Hacktivist group NullCrew recently announced a succesful intrusion (though intrusionette might be a better word) against a website in the DHS.GOV domain hierarchy.

DHS, of course, is the United States Department of Homeland Security.

The intrusionetted site was studyinthestates.dhs.gov, intended to help foreigners find out if and how they might be able to study at US schools, colleges and universities.

It looks as though the site was vulnerable to what's known as a directory traversal vulnerability.

That's where you construct a URL that persuades the server to navigate to a part of the web server you aren't supposed to be able to access, and to retrieve content from there.

Imagine, for example, that your webserver hosts a file that is available via the URL http://example.org/private.dat, but to logged-in users only.

If the server were to see an unauthorised GET request for /private.dat, you'd expect it to deny the request.

But your server needs to be careful that it doesn't let itself get tricked, for example by a request to retrieve a file such as /subdir/../private.dat instead.

If you start examining the filename from the left, it doesn't look like a file in the root directory, because there's a directory name (/subdir/) first. But the ensuing ../, which denotes "parent directory to the one I am in at the moment", leaps back up one level, thus cancelling out the initial step downwards into subdir.

Filenames with paths that lead upwards in your filing system are always a risk. By climbing upwards, an attacker may be able to wander "up-and-over-and-down" into otherwise-forbidden parts of your web server's directory tree.

In really bad cases, attackers might even be able to hoist themselves out of your web server's directory tree altogether, and into the rest of the filing system.

This might give them access to password and configuration files for the operating system itself, or for other software running on the same server.

Poor handling of upward-leading filenames seems to have been what was wrong on the Study in the States website.

It looks as though a PHP script responsible for a download repository was incautious in its argument handling. A URL of the sort:

http://example.org/known/dir/download.php?file=somename.dat

could be abused with a request like this:

http://example.org/known/dir/download.php?file=../../private.dat

This, it seems, caused the ill-configured download script to navigate upwards in the web server's directory tree, retrieving from the inside a file that would have been blocked if it had been downloaded directly from the outside.

The fault seems to have been patched now, but if NullCrew are to be believed (and let's assume they are), this hole was used to fetch the WordPress configuration file, apparently including the backend database location and password. This configuration file was then published on a publicly-available drop site.

Sadly, if the HTTP headers returned by the Study in the States website are telling the truth, there's still some more patching to be done.

Surely some mistake?

The site reports that it's running Apache 2.2.3 on Red Hat, and PHP 5.3.3. As I write this, those versions should really be PHP 5.3.20 and Apache web server 2.2.23.

Why not use this as a call to action for your own web servers in 2013?

Make sure you're updated with the latest security fixes for all back-end components you use. Attackers read the vulnerability mailing lists, so they already know how to break in to your unpatched servers.Consider running a Web Application Firewall (WAF) to scour inbound web traffic for bogus or risky-looking requests. This helps to shield your web servers from as-yet-unknown attacks.Perform regular penetration tests against your own web properties to make sure that tricks such as directory traversals are blocked and logged.

A quick look at your web server logs will almost certainly reveal a large number of (probably automated) attacks based on weird-looking URLs that the attacker hopes will sneak past your defences.

It's not a matter of if, or even of when, you might get attacked. If you're inviting inbound web requests, you're already under attack!

Follow @duckblog

Running a web server at home?

Why not try out the free Sophos UTM Home Edition?

You get web and email filtering, web application firewall, IPS, VPN and more for up to 50 IP addresses. You can also protect up to 12 Windows PCs on your network with Sophos Anti-Virus!

(Note: registration required.)


View the original article here