My First Hack: The SPARCserver 600MP

By Michael Gebis, Thu 18 March 2021, in category Hacking

"Ladies and gentlemen: the story you are about to hear is true. Only the names have been changed to protect the innocent." And I really did change a few details, if for no other reason than this story is 25 years old and I have a faulty memory. For legal reasons this post is just a joke.

Welcome To The Internet

My first internet account was at University of Illinois in 1991. Back in those days, any student who filled out the right paperwork could get an account on a single giant Unix machine called "uxa.cso.uiuc.edu". It was my first email account--I was mjg51721@uxa.cso.uiuc.edu. Coming from MS-DOS, it BLEW MY MIND that not only could that computer run multiple programs at once, but that dozens or even hundreds of users could be running programs at once. Whoa.

A Sequent Symmetry

As powerful as uxa.cso.uiuc.edu was (it was a Sequent Symmetry with 13 386 CPUs!), every month more and more students signed up for accounts and the system bogged down. UIUC had a good relationship with Sun Workstations, and they bought one of the very first SPARCserver 600MP systems, which had four SuperSPARC I CPUs. This was ux4.cso.uiuc.edu.

A SPARCserver 600MP

This machine was hella fast. But it was Sun's first foray into multi-CPU systems, and the OS had a lot of bugs. It crashed a lot. Students with accounts on ux4 faced a lot of downtime as kernel panics caused the machine to reboot at least once a week.

Unix User Accounts, and /etc/passwd

Before I talk about the hack, I need to talk a little bit about how user passwords work on unix. There's a user database (called /etc/passwd) that has lines that look like this, one for each user:

mjg51721:u5WIUSg5fUuJM:1721:100:Michael Gebis:/home/mjg51721:/bin/csh

See that string, "u5WIUSg5fUuJM"? That's the password hash. In early versions of unix, this data was open to everyone, which seems very janky. But miraculously the system was still (kinda) secure.

How? Well, when a user logged in and typed the password "hunter2", the system would take it and compute a one-way function called crypt() that outputs a garbled string--in this case, "u5WIUSg5fUuJM". Despite thousands of very smart people trying, nobody has been able to compute the reverse of the crypt() function. In other words, it's easy to go from "hunter2" to "u5WIUSg5fUuJM", but there's no way to go from "u5WIUSg5fUuJM" to "hunter2".

But notice that the system can still log users in--as long the user typed the the correct password, it would always garble the same way, the system would see it matched the saved garbled password in /etc/passwd, and all is good.

Cracking Passwords

That is... until some other smart people realized that while they couldn't reverse crypt(), they could just run crypt() on billions of different guesses really fast. So they created a program called crack, and it would try to garble every word in the dictionary, every word + a number, the user's first name, etc. These simple strategies are able to correctly guess a lot of passwords.

Later versions of unix mitigated this attack by writing the actual passwords into a heavily protected file called /etc/shadow. The garbled password would be stored there, and the /etc/passwd user database would just have an "x" for the password. As long as only the system could open /etc/shadow, but normal users couldn't, nobody would know the garbled passwords, they could not run crack, and once again, all is good.

The Hack

SunOS did in fact use /etc/shadow, so cracking ux4's passwords should have been impossible.

But it turns out that when SunOS on ux4 crashed, it had a feature to assist the Sun engineers debugging the system. The OS wrote a crash dump file called kcore ("kernel core") to the root directory that could be used for post-mortem crash analysis.

And SunOS wrote the kcore file with world-readable permissions, meaning any user could open the file.

And the kcore file usually ended up having an in-memory copy of /etc/shadow in it.

You can probably see where this is going.

I was still on my uxa account and didn't have access to ux4, but a friend did. The next time ux4 crashed, as soon as it came back up we quickly copied the kcore file to a scratch location. Then we wrote a program (basically "strings kcore | grep") to extract the shadow password file out of the kcore file.

And then we moved that /etc/shadow file to another computer where we were able to run crack. It wasn't fast, but after about a week it had finished. And we had cracked something like 10% of the user passwords on ux4.

The Proof Is In The Pudding

As it turns out, we didn't really want to break into the system or anyone's account. Really, we were a couple of goodie two-shoes. We just wanted to see if we could. We should have been satisfied at this point. But all good engineers know--if you didn't test it, you can't say it worked. We didn't personally know any of the users with cracked passwords, but one of them was a frequent poster to the UIUC newsgroups. We talked ourselves into believing that he was the kind of guy who might find this funny and not get angry.

So one night, we went down to the lab and tried to log in as him. And it worked. We immediately logged out and ran out of the lab, probably looking guilty as all hell.

We never told anyone, including the target. I never used any of the other passwords, and as far as I know, neither did my friend.

But a hack's a hack, and that was my first.