Yup, Somebody Cracked Slashdot
What a great way to wake up! I went to bed at about 10 last night, completely exhausted (stuff unrelated to Slashdot stressing me out). I guess the upside is that I had a good night's sleep: the downside is I still haven't had a morning cup of coffee ;)
Allright, so by using the 31337 haxx0r tool known as "Common Sense", {} and Nohican managed to get a Slashcode test site's administrative access (this isn't a root shell or anything: its only a series of Web forms used to post stories, and configure various parts of the site). This was our biggest mistake: the password (God/Pete) was never changed on the test site. From there, it was a cake walk.
By exploiting a known security hole in pre-2.0 versions of Slashcode, they executed some perl of their own devising through our template system, and managed to run netcat on the the box. The hole itself required "God" access on a Slashcode site, so it was never a problem before... but since the password was the Slashcode default of God/Pete, it wasn't hard. We knew about the potential problem but since nobody ever had God access besides me, it was never a problem!
From there they managed to get ahold of our backup database (updated nightly). And due to another hole (one that is also fixed in the upcoming 2.0 "Bender" source tree ;) they managed to pull my Slashdot administrative passwd from the dump, and login as me, to the real Slashdot. (our db stores passwords in plaintext. Yes it's stupid, but I wrote this code 3 years ago and had no clue).
Apparently that's where they stopped: all they wanted was to post a story claiming victory. Immediately after that, they e-mailed us and told us how they did it. Our crack team plugged things back up immediately. (and the guys were nice enough to chat a bit with them on IRC explaining a few things).
The moral? Our biggest mistake was not changing the default data on the test site, and I'm sure that we'll patch the next version of Slashcode to require new administrators to change their passwords during installation. The eval hole (we've been working on removing this problem for some time now and replacing it with a templating system that is secure, flexible, and easier than the really crappy one we're using now) and the password problem (also fixed in bender) won't be a factor in Slashcode 2.0.
It doesn't appear at this stage that they actually did anything beyond posting their story. (We're taking all the appropriate precautions to make sure. Hugs to Yaz, Liz and Pat who are gonna have it the worst). You should also change your Slashdot User Password right now just to be safe.
The whole Slashdot authentication is ridiculously insecure. I coded it years ago when I didn't really know anything about scalability or security. Since then various bugs in Web browsers have changed a lot of things, so we decided to fix the problems in Slashcode 2.0. Unfortunately it's not done yet, but it's getting there. Of course, anyone with functioning neurons knows that you use different passwords on each system (especially Web sites where you aren't using any encryption!)
Nobody ever would have got anywhere had we just changed the default password though.
The good news is that it looks like {} and Nohican were good guys: the did the deed, took the credit, and went no further. Then they told us exactly how they did it so we could make sure it wouldn't happen again. Honestly, that's the best kind of hack. Two years ago we had the bad kind of hacker: he rooted the whole damn system and never told us how they gained entry. That sucked more than I can describe.
The bad news is that we have to pretend that these guys totally took over, and rebuild everything anyway. It's gonna be a long couple of days.
You can direct inquiries to me, but understand that I'm just a little busy right now, so I might not be able to reply to everyone.
[Heh, I wrote the following text for some friends about a week ago. Fits perfectly here. :) ]
How many sites, servers or systems do you log into regularly? On how
many sites, servers or systems have you registered yourself with a
user name and password? Quite some number, or what? Now; how many
different passwords did you use? Of course you've been told many
times to use different passwords everywhere. I keep wondering what
idiot invented that impossible rule; it goes without saying that you
need to reuse your passwords, unless you have a computer in your
brain.
What's my point? Let's say one of the administrators of one of those
sites is not as honest as it first seemed, and takes a peek into the
password database. Or let's say that someone cracks into that
database and gets hold of all the passwords. What could that person,
given your often used password, do on all the other sites you visit?
Would you like someone else to speak for you? To buy for you? To
sell your stocks? To use the encyclopedia you pay for? To read your
mail? Probably not. And it doesn't have to be that way if all web
developers out there obey the following, simple rule:
Never store clear text passwords.
You do not need to keep a user's password to be able authenticate her.
To repeat: Neither you, nor your web server, need to store any user's
password. The technology is ages old: You pass the initial password
through a one way hash function, and store the garbled password in
your database. Whenever the user wants to log in, you take the user
provided password, pass it through the same hashing function, and
compare the result with whatever you have in your database.
I guess some of you don't know what hash functions are, so here's a
short intro: Hash functions, or message digests, are one way functions
that take a text as input, and produce a signature based on the text.
Calling the function "one way" means that, given a signature, it is
impossible to get back to the original text. A good hash function
also makes it extremely hard to come up with a different text that
yields the same signature.
Several hash functions exist. The password file on Unix traditionally
uses a DES based hash function, known as crypt, to hide passwords.
Windows NT uses MD4 for passwords. I would suggest you use a widely
available function known as MD5. It is considered more secure than
both crypt and MD4. PHP has the string function md5, Java has the
java.security.MessageDigest class which provides MD5, Perl has an MD5
module, and I guess you'll be able to find some component for
ASP/VBscript too.
If you've ever read about password hashing, you may have run into the
term "salting". We may use salting to make sure two hashed password
are different even if they come from the same password. If you choose
"beer" as your password, and have access to the hashed passwords, we
don't want you to recognize another "beer" drinker among the users.
You may think that requiring unique passwords is a solution, but it is
not: If you register somewhere, and learn that the password you chose
is already taken, you may run thru the users and test with the
occupied password until you reach the owner. We do _not_ want unique
passwords.
A common strategy for salting is to combine the user name and password
into a new string, eg. with a line break in between, and pass that
string through the hash function. Of course you will need to redo the
combination when you verify the password.
What follows is a simple example in PHP. We provide one function for
storing the hashed password, and one for authenticating a user. Of
course you will need to implement the database functions yourself.
# Given a user name and a clear text password, calculate the
# salted, hashed password.
function getHashedPassword($username, $password) {
return strtoupper(md5($username . "\n" . $password));
}
# Given a user name and a clear text password, calculate the
# salted, hashed password, and store it in a database.
function storeInitialPassword($username, $password) {
$hashedPassword = getHashedPassword($username, $password);
# Save the hashed password in the database.
setHashedPasswordForUser($username, $password);
}
# Given a user name and a clear text password, calculate the
# salted, hashed password, and compare it to the one in the
# database. Return 1 if the user is successfully verified,
# 0 if verification failed (bad password).
function verifyPassword($username, $password) {
# Fetch the hashed password from the database.
$hashedPassword = getHashedPasswordForUser($username);
# Salt and hash the provided password.
$hashedProvidedPassword = getHashedPassword($username, $password);
# If the two hashed passwords are equal, everything is fine.
if ($hashedProvidedPassword == $hashedPassword)
return 1;
# The hashed passwords didn't match. Invalid password.
return 0;
}
As the example shows, storing hashed passwords is almost as simple as
storing clear text password. And it is a whole lot more safe. If you
choose to hash the passwords on the site you develop, you should
consider mentioning it on a "privacy policy" page. Advanced users
will appreciate it, and understand that you take security seriously.
It was SGI's File System Navigator - a rather cool program for doing 3d visualizations of a file system. It's fun to play with, and actually suprisingly usable for normal work.
--
Instead, we have an open acknowledgment from the victims, a full story about what happened and what steps are being taken now, simple instructions for the users, and the proper amount of credit to the guys who cracked the site.
A little extra work for the /. crew, a good reminder for them to take security more seriously, but otherwise no big deal.
If only mainstream media could be this mature and accurate.
________________
________________
Private Essayist
I always thought my password was ***** anyways....
The anti-salmon
. . . become "FascDot Killed My Pr". They must have had a low bid on that eBay auction.
--
-- Geof F. Morris
This is nice to see. Big, front-page article saying they've been hacked, letting their users know. How many web sites do you think would do that for their users? Too few.
On the other hand, would we have been notified if the hackers hadn't put a big article on the front page? Food for though, but I'd like to think so.
Dave
'Round the firewall,
Out the modem,
Through the router,
Down the wire,
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
Ah, if only the trolls had known...
--
Change my password? Um.. why?
This is a message board site, not my bank account.
Not the administrative passwords on my Windows 2000/Linux box.
Not the passwords for my personal writing folders (which have a different password than the box).
Not the password I use for my internet account.
Basically, there is nothing worthwhile to steal here, and if someone posted something under my name so what? I would then change my password.
But I don't need to now.
- I don't care if they globalize against free speech. All my best free thoughts are done in my head.
It's not clear from the post, but it would appear that Slashdot simply stores the username / passwords in a table unmangled?
Damn...The minimum you should have done is hashed it (with either MD5 or SHA-1 - both of these are available for Perl). The next (recommended) step is to also salt the password prior to hashing to prevent dictionary and similar attacks.
Bruce Schneier is right in Secret and Lies: people just keep making the same security mistakes time and time again :((((
"Mary had a crypto key, she kept it in escrow, and everything that Mary said, the Feds were sure to know."
There's no difference between failing to keep the hackers out and leaving stuff where the hackers can get to it. But more, I totally disagree with your "theory" about passwords. Slash, please keep our passwords in plaintext, or keep it as an option for users who want it.
First, think of your bank account. It's real numbers stored in a computer, numbers that other people shouldn't be able to see or change. So, these numbers need to be protected. You can't effectively encrypt them (without leaving the keys sitting there: the computer needs to get to them) so the issue is purely one of protecting them. Give a computer scientist the task of protecting some vital data and she will set about designing a secure system. It's a fun problem to solve. Well, that's all passwords are: data that needs protecting.
Yes, there are scenarios where hashed passwords allow for a neat trick: knowing the hash lets you authenticate but does not grant you access. But that trick depends on certain elements that are not necessary to guard a website. Think of it this way: if someone gains root access to a website, they don't need an insignificant user's password.
The convenience of Slashdot being able to email a password if someone forgets it is a benefit that far outweighs the difficulty of the task of protecting them.
And to think, Andover paid you guys over $6 million each for this site. You'd think a company willing to part with such a huge chunk of change would at least EVALUATE the site. Most companies would be all up IN your koolaid before writing such a check and their audit would have shown that this site is held together by band-aids and paperclips that are 3 years old.
... just the eyeballs it would deliver to their advertising group.
It just goes to show that Andover had no interest in the *site* and it's validity or integrity
I can't say I'm surprised one bit.
Don't have to tell me that, after years of watching secretaries jot down passwords on 3x5 cards and post-it notes and tuck them into the pencil drawer of a desk.
Probably the best I ever witnessed was at some economy barn, like a Sam's club. They had the manager's password on a note taped to the front of the monitor, it had been there for some time.
Why don't I just give Anonymous Customer a refund of, oh, $500. Better make that $500.01 or the bean counter will get suspicious.
--
Chief Frog Inspector
A feeling of having made the same mistake before: Deja Foobar
As if I care about my password. What's someone going to do, log in and post as me?
--
Communication is only possible between equals
- Always change your default passwords (that is the easiest way to get hacked, as seen in The Cuckoo's Egg, a la Hagbard)
- Never store your passwords in plaintext. Preferably, just hash them.
- Never trust a good password to a website. I have a throw-away password I use for unencrypted web stuff; slashdot can have it, and I'm gonna keep it. If they hack my kuro5hin account, I'll survive.
- Hope for the best, expect the worst. If someone compromises your system, it doesn't matter how nice they are about it; make sure you check everything, regardless.
---
pb Reply or e-mail; don't vaguely moderate.
pb Reply or e-mail; don't vaguely moderate.
I'll admit, I'm fairly new to the writing of code for the web, but the first thing I did on taking over someone's site admin was change the passwords from plain text in the cookies and db to crypt() (didn't want to use md5 since a lot of different scripts and programs used the db - crypt is more common).
Even so, the way I have it currently set up is a problem. Someone could grab a copy of the local encrypted cookie, then use it to connect as the user from then on. The easiest way I can think of to solve this is to have the cookie be a combination of a timeout value and the encrypted pass, and store that value in the db as well ('till timeout) but even so, at least user passwords can't be read out of the database in my current setup.
Come on, this is just common sense. It wouldn't have taken 37737 knowledge of perl to have implemented that in the first version of Slashcode.
-- perl -e'print pack"H*","6e656d6f406d38792e6f7267"'
Now, the fact that the default password was used to get into the box is one issue.
Another issue is how the crackers managed to get root after the fact. They exploited known security holes.
Just something to reduce my karma, but since the code is open source, bugs are supposed to be found much more quickly and fixed within a few hours given the right channels. Yet, since the bugs are supposedly easier to find (looking through source code as opposed to trying various techniques to so what happens) than in closed binaries (that is one of the main arguments for open source), we have our lesson for today.
Which is:
If you use open source products, patch early and patch often. If you reinstall an old version, plan to spend a significant amount of time applying patches. Otherwise, those well known and easily-researchable bugs will come back to haunt you in sequential order.
Having been a computer instructor for a year and a half, I have found that there is good news when an authority screws up publicly. First, it shows than no one is an authority on everything. More importantly, when a mistake is made, sometimes students can learn more by finding out how to fix something than how to do it correctly in the first place. This event will have more admins thinking about security today than a dozen security articles would have.
All my programs have but one purpose. They take the contents of RAM and place those contents into a file called 'core'
Taco should not be so hard on himself over that particular flaw; the real shame should be felt by the million and one fuckheads who downloaded the code and didn't even look at it before installing.
'Course, this puts the whole "security through obscurity" thing in a slightly different light ...
-- the most controversial site on the Web
The last thing we need is for some troll to hack Slashdot and turn it into a goatse.cx mirror (a dream I'm sure has crossed the mind of many a middle-school, immature techno-jerk).
Honestly, though, what other features can we expect to see in Slashcode2? Story moderation (or changes to the overall mod structure)? Perhaps user-definable themes (OK, I know I'm going out on a limb there)? Removal of the suid requirement on the script? Just throwing out some honest questions...
----------
Signal 11's karma exceeded an unsigned BIGINT and triggered a buffer overflow leading to an exploit. Slash code operators are encouraged to kick Signal 11 in the nuts until the problem goes away.
I must agree. I've been running Crack for both Unix (Solaris and GNU/Linux) and Windows NT where I work, and it's amazing how many passwords were found just in a few minutes. Crack is an extremely cool program.
c 50-faq.html
http://www.users.dircon.co.uk/~crypto/download/
I don't remember where I found the NT port of Crack. Sorry.
Is there anyone else out there who hears warning bells when reading the words, "Change your password immediately here." with a link? Has nobody ever heard of social engineering? I know that I'm not the only person on Slashdot with a mild case of paranoia.
[dsplat ducks under his desk to avoid being spotted by the black helicopters]
The net will not be what we demand, but what we make it. Build it well.
Why bother changing your password? It just means that you'll have another unencrypted plain-text password laying around... Besides who really cares if your /. account gets hacked? What are they going to do? Kill your Karma?
Bah! Wait until they get the Slashcode 2.0 up and can affirm that encrypted passwords are being used.
dnnrly
dnnrly
Slashot had a story about 3 weeks ago stating that Western Union got cracked and recommended to their customers to changes passwords and even cancel their credit cards.
--weenie NT4 user: bite me!
--weenie NT4 user: bite me!
"Computers are nothing but a perfect illusion of order" -- Iggy Pop
http://dailynews.yahoo.com/h/zd/20000928/tc/mitnic k_to_it_managers_everybody_is_suspect__1 .html is a story about Kevin Mitnick's warning that people are always the weakest link in security. Here we have slashdot admins making a simple password mistake. Just imagine what the average user on a corporate network (with read access to the rest of that network) could do.
I would have made it a link, but either netscape or slashdot kept putting spaces in it because it was so long. Sorry.
WARNING: there is a trojan on your
For crying out loud, this got moderated *up*? The guy wrote the stuff 3 years ago, when Slashdot users could hardly have been referred to as customers. Heck, even now, I don't know that you can hold them to "Customer focus." Last I checked they weren't charging us anything to use slashdot, and weren't selling our data to anyone for profit. If you want to call loading a banner ad being a customer, then I guess...
But still, that's no reason for the demeaning tone of this post. I just love the way we geeks all tend to rip each other to shreds when we make stupid mistakes, and when we do so, the tone we take is almost always one of "I know everything -- I do no wrong." This should have been moderated as "Flamebait."
You had no moral obligation to inform the readers of anything. Slashdot folks are a pretty educated crew -- we're fully capable of drawing our own conclusions, thank you.
--
NeoMail - Webmail that doesn't suck... as much.
host -a -l slashdot.org (:
the database was hosted on just one box, never touched the webservers
True enough, but do remember that the weakest link defines how strong the chain is.
So what if you encrypt passwords on the server, passwords are stored in cookies on your home machine, as well as sent plaintext over miles upon miles of internet cabling before reaching slashdot.org.
If someone really wanted everyone's slashdot passwords, all they'd have to do is sniff some connection along the way.
Hackers will always hack in. There's no such thing as an invincible system. It's just a matter of time and determination (as we've seen time and time again).
"Darn, my winmodem won't work with Linux? I'll have to recompile it... with my blowtorch."
The person that left the default password on a publically accessible server should be canned.
At any job I've worked, something like this would get the preson responsible auto-canned for not making reasonable efforts to protect company data.
This is a special case, becasue the person who decided to implement a 'default password' in slashcode also works in the company where it is used. CmdrTaco also needs a good butt-kickin. Did feature lust could your judgement?
Also, the idea of storing the user database in clear text on a publically accessible server is also insane. Store nothing on publically accessible webservers.
I totally cringed when CmdrTaco decided to proclaim "No one would ever have gotten in if it wasn't for the default password".
OH MY GOD
I hope he takes a good look at his bliefs surrounding security. That's a very cocky and naive thing to say. I'd submit that someone who believes that enough to say that will most certainly get 'cracked' again. Have a nice day :)
Apologies to Sam Cooke (and Art Garfunkel)
// beldon@scamail.com
"Don't know much about TCP
Even less ICMP
Don't know how to make a subnet class
Even script kiddies would kick my ass
But if an OS that can be bought
Will install securely by default
What a wonderful thing that would be
Don't know much about LAND attack
Don't know how to spoof an IP stack
Don't know much about the port I'm on
Can't decide to leave a daemon on
If I install OpenBSD
And it does most of my work for me
What a wonderful thing that will be
Now I don't claim to be a sys admin
But now broadband's in my town
And I have to put something between me
And the people who know how to bring me down
Don't know much about DDoS
And my shell programming is a mess
Don't know how to build a firewall
Don't know much about nothin' at all
But if I can shield my root account
Without emptying my bank account
What a wonderful thing that would be."
-- Beldon
It's archived here.
---
Is this what happens when you put PERLs before Swine?