Xerox Alto zero-day: cracking disk password protection on a 45 year old system | Hacker News Reader

Xerox Alto zero-day: cracking disk password protection on a 45 year old system

righto.com

240 pointsjjwiseman64 comments

The comment from the owner of the disk he cracked is pretty great:

Doug Wyatt January 4, 2018 at 10:38 PM

I'm flabbergasted. That's my Alto disk you broke into!

The APL stuff is surely related to some work I did with Leo Guibas, showing why lazy evaluation would be a really good idea for implementing APL: see Compilation and delayed evaluation in APL, published January 1978. (That paper gives me an enviable Erdős number of 3, since Leo is a 2.) I'm sure it's not a complete APL implementation, just a proof of concept. It happens that my very first part-time job at PARC, in 1973, involved writing decision analysis software in APL -- on a timesharing system!

Given the AATFDAFD hint, I'd guess the real password is ADDATADFAD. This derives from a project I did with Jef Raskin at UCSD in 1974. (He mentioned it in this interview.) The Data General Nova we were working with produced some garbled message with ADDATADFAD where it should have said ADDITIONAL, and it was a running joke ever after. Strange, the things that occupy some brain cells for over 40 years.

Thanks for an amusing blast from the past.

-- Doug Wyatt (Xerox PARC 1973-1994)

My brain didn't parse the "Xerox PARC" bit at the bottom and I just assumed that birth/death years and I got really confused as to how he replied to something posted in 2018.

Reminds me of a year or two ago when I had to boot my old SGI. Forgot the user password on IRIX and thought that this is where I'll be clever (hacking terminals, matrix music in the background, etc.). Turns out, IRIX had 8 character limit for user passwords. Thanks to the modern GPUs and a passwd file restored from the system (on a recovery console), a few hours later I had the password brute-forced. I'll get to be clever hax0r next time, I guess.

I don't know. Cracking passwords using A SUPERCOMPUTER FROM THE FUTURE, seems plenty worthy of some decent theme music...

Fits right into Kung Fury [1] - a parody/homage of 80's movies that includes time travel and Hackerman... And a dinosaur, vikings and nazis and David Hasselhoff. It's as bad as it sounds, but in a good way. They fit an impressive amount of 80's movie tropes into 30 minutes.

https://www.youtube.com/watch?v=bS5P_LAqiVg&t=1306s

I hope he ran the Hollywood script while the password cracker ran modestly in the background

https://github.com/dustinkirkland/hollywood

Best one I've seen was a university library card catalog system from the 80s/90s that used unshadowed, 8-character salted passwords via the crypt() function on the Unix box it was on. Inexplicably, whoever wrote the application had limited it to require exactly five uppercase letters, crackable in a few seconds on my 33Mhz 386.

Maybe that was the reason? To provide a way for the developer to do customer support in these cases, that is.

The password being there, as the people in the bike store where I bought the lock told me, to keep the honest people honest.

Anyone with admin access on the Unix box could have just edited the password file and put in a hash for a password they knew.

My high school in the late 90's similarly handed out passwords all composed of 8 (or was it 6?) numbers. Combined with Windows 98's weak hashing (was it LanMan back then?), Cain & Abel on contemporary hardware could reveal them in seconds.

I was in a similar situation. I bought a used SGI Octane, but didn't have the root password and I didn't want to reformat the machine (and didn't have OS discs). It ended up being pretty easy to crack the password, though I can't remember the exact process (this was years ago). Once you have physical access, pretty much any security implementation can be defeated.

Turns out I need to do that with my old SGI. Got any tips?

Multiple ways to do it. All lead to you getting to the /etc/passwd file and the hash inside for the root.

If you have IRIX installation CD then you can even set the new password, but you probably don't have it? You can also put the disk into another SGI, also not what everyone has. If guest account is enabled, login with guest (no password) and just cat the /etc/passwd. If guest account is not enabled, you can do the cat via sash, which is a bit more compicated, like this: https://web.archive.org/web/20151023042224/http://crackaddic...

Once you have your hash, do it with John the Ripper (GPU version). Store the password int a text file in format of root:hash and run john the ripper on it. Encryption is, AFAIK, DES so use john --format=des passwd.txt if john doesn't autodetect which encryption it is (I remember I had to set it manually). It can take awhile, depending on the GPU, but not that long.

If you run into trouble, I can have a look. I think I wrote down somewhere what to do, in case I need it again.

Thanks for this, looks to be not a problem at all! Well, now I've got one less reason to keep the SGI boxes wrapped up, thanks!

Boot from a CD, mount the drive, change the password or remove it - if it were linux I'd edit /etc/shadow - obviously easier with another IRIX machine to put the drive into.

When I was in similar situation (bought an old SGI O2 box and didn’t had any other SGI machines to plug HDD into to get /etc/passwd), I used telnet RCE/privilege escalation exploit: https://www.exploit-db.com/exploits/20149/, worked like a charm. These old systems have many vulnerable services running by default, including telnet.

Had some great suggestions, but this one wets my whistle the most, haha!

Probably what I'll do, though, is set up SCSI on a linux box somewhere and try to xxx the shadow, seems to be the smoothest route .. don't wanna mess too much, because after all, 20 years later .. I still wanna boot my old SGI like the good ol' days. :)

Not quite what you're asking, but if you just want to get a shell on the machine, IRIX often had a bunch of accounts with no password. Try lp, demo, games, and guest.

Would something like John the Ripper, first with wordlists and then with incremental mode, be acceptable? http://www.openwall.com/john/

http://www.openwall.com/john/doc/

You will need /etc/passwd file from SGI the disk. Either use irix installation CDs or boot the system over network [1]. You could also try booting openbsd [2] to get your hands to it.

Next you would use something like hashcat [3] to bruteforce the password.

1. http://software.majix.org/irix/install-network.shtml

2. https://ftp.openbsd.org/pub/OpenBSD/6.2/sgi/INSTALL.sgi

3. https://hashcat.net/hashcat/

Try logging in as lp. Often no password.

I think you don't need a GPU to crack an old password (with crypt?) limited to 8 chars.

Better than that only the Windows LM Hashes

Very cool that he found a flaw in the algorithm

But this is really the antithesis of what a zero-day originally was, which was a crack circulated on or even before the release day of software[0]. The Alto is 45 years old :)

Odd how words and phrases can change so much over a short period of time that they invert their meaning.

[0] that's what it meant in the early / mid 1990s when I was peripherally involved. Now it seems to mean 'zero days of notification to the vendor'.

Now it seems to mean 'zero days of notification to the vendor'.

I think 'zero days since a patch has been released' is probably more accurate.

And those old (~1995) WaReZ sites are the reason I distrusted javascript from the beginning

Just seeing the word WaReZ reminded me of the day I read about bit torrent. My first reaction was that the days of FXP for distributing scene releases were numbered.

That number never reached zero. Or do you think topsites went torrent?

If anything, they went further underground, with the masses preferring the ease and availability of torrents.

Personally, torrents fulfill my needs these days, I can't be bothered to Sneakernet, DDC or FXP anymore.

My general impression of “zero-day” was that it meant the vulnerability had been there (and still was present) since day zero. This fuzzy definition in my head doesn’t really make a great deal of sense in the presence of regressions, though: if the vulnerability was only introduced in version 1.2.3 which was released three years after the first release, calling it “day zero” seems decidedly odd.

Maybe it's a XeroDay?

Alright then, it's a 16,425-day vulnerability. That's an even more impressive thing, call up Guinness.

I perceive you are not a respecter of leap years.

Let’s just call it 2¹⁴ days and be done with it.

How did people get access to unreleased software?

Back then games had to be gold to be sent to the CD/Disk manufacturer, then you had to receive the copies and send them to be packed or directly to the distributors if they handled the finale packaging. This meant that a golden sample could circulate for as much as 6 months (and even longer) before the game would go on sale. Also as all support was pretty much phone support which also included some basic gameplay support you would have support staff often at 3rd party call centers who would require access to the game before it goes on sale (for large games at least, small companies tended to have support in house).

Today with digital distribution even if it's for patches only you don't care about the game going gold the DVD could contain a build that is utterly irrelevant pretty much every new install from disk requires a day 1 patch that can be often as large as downloading the whole from scratch (pretty much every console owner knows this, PC games also get a day one patch but digital distribution is a given for the PC market these days).

So zero-day for games at least isn't that important anymore, also DRM is harder to crack these games some games take months to crack, some don't get cracked at all, some rely on a weaken DRM version to be released (e.g. STEAM) down the line that can be cracked more easily.

For DVDs/BR today this also often happens you have full BR rips often weeks before the official release date, sometimes months just because they are already ready just waiting on the right time to go on sale or for some online distribution exclusivity deal to end.

I work for a large games publisher and we still do that in fact! I've recently been on a trip to our customer service centre, and the guys and girls there have access to early builds of nearly all of our games so that when the game comes out they can provide advice on day one. And yes, I too was surprised to find out that they do provide actual gameplay advice if someone calls with a question - every desk had several massive game guides for our games just in case.

It doesn't surprises me that they still do that but with how easy it is to track builds these days and the fact that games today are released broken with "we'll fix it after launch" mentality it's not really that much of a source anymore.

Early builds that might not function outside of the internal environment aren't much of a deal the last leak I remember that got a scene release was probably the Doom 3 Alpha.

In the 1980s when games were on cassette tape we used to go to either a recording studio or directly to the duplication plant. We'd take the computer with the mastering software and plug that into their reel to reel 'recorder'. I think it varied but was 1" or 2" tape usually.

We'd then run some cassettes off that master to validate they loaded, some of the copy protection was picky about the duplication quality and speed. They'd then start production and the finished product would be on the shelves in a week or two at most.

It was a fun and very interesting time visiting all those places. I went up to Telford once and was stuck there for a while as there was a mastering problem and we had to play with the copy protection. Most of the times it was a place by the A4 near Chiswick/Hammersmith.

The way it used to work in the old #warez days, was that people in the testing or supply chains (think cd packaging, for one) would leak things early. Groups like Razor1911 had suppliers, couriers, crackers, designers.. a wide network of people working on acquiring and spreading software.

An important thing you didn't mention is why these people participated in leaking software for no credit.

It is because they got something in return: access to the private FTP servers used by the group, which means they get to download their releases before they appear anywhere else.

This is especially attractive to people who manage DDL or streaming sites which earn a lot of $$$ from intrusive/malicious ads...

It is also a big deal for private torrent tracker operators and/or uploaders. If you get Razor1911 releases before any other tracker, people will want to get in ;)

Check out this article about music piracy -- I believe the process for game piracy was pretty much identical around that time: https://www.newyorker.com/magazine/2015/04/27/the-man-who-br...

I remember when the Commodore 64 scene got so serious that people started complaining if you didn't have -7 to -14 day releases... Some games were even released in "cracked" versions before all the levels were complete ("cracked" because I doubt they had to circumvent much copy protection when they clearly got their stuff from internal sources).

As someone who was a kid who actually cared about the games, it just seemed pointlessly tiresome to be worth it at that point.

I can just imagine some IRC battle on Dalnet channel #hackersunite where people are arguing about the appropriate use of zero-day, and then a netsplit occurs and half the arguers are lost in the abyss forever and this is how the word came to being what it is now

My own adventure disabling PowerBook Password Security on an old Mac:

https://bslabs.net/2016/01/30/disabling-powerbook-password-s...

Looks like a very similar form of protection and a similar way of defeating it.

Passwords like "HGFIHD" and "AAJMAKAY" look like initialisms. It might be fun to try to decode them. (xxxAKAY on a Xerox PARC disk from the 70s/80s... could it be?)

I should mention that I didn't want to leak someone's actual password (even if it's 40 years old), so I perturbed the passwords slightly. The real password doesn't exactly end in AKAY, so it's not Alan Kay. (Apologies for throwing cold water on your clever idea.)

There's a decent chance the passwords you found aren't the actual passwords either, considering how easy it is to generate collisions for the hash function.

Read a bit further on. The algorithm has a flaw where some of the first bits from the password are unused. "AAJMAKAY" was a working password that the author's brute force script found, but the "real" password probably had different characters at the beginning.

I always find security measures on old-school systems interesting. They always seem more geared towards keeping semi-honest mischief makers out than serious security. Which makes sense, based on the context of the time I guess.

IIRC, the Xerox Pilot OS was purely cooperative multitasking with a single shared address space.

They should totally file for a CVE for this.

Someone needs to come up with a catchy name and a logo for this exploit.

From the article:

> This attack is called XeroDay

Yes, I updated the article based on the discussion here. But I still need a logo :-)

Ha! Great day in the morning! Thank you!

I like msla's XeroDay

ReedCrack?

Silent Whimper?

Contralto?

ContrAlto won't work, since it's the name of the Alto simulator written by the Living Computers Museum. (It's a very good simulator, letting you see what happens right down to the microcode.) I'm going to use XeroDay for the attack name.

https://github.com/livingcomputermuseum/ContrAlto

When can we expect the security updates for the Alto?

German IT news site heise.de posted a nice tongue-in-cheek article about the vulnerability: https://www.heise.de/newsticker/meldung/XeroxDay-Zero-Day-Sc...

When programmers and mathematicians use the word "trivially" it really means "I'm smarter then you".

> Salting passwords also protects against password attacks using precomputed rainbow tables, but that wasn't a concern back then.

Hmm, if not to defend against rainbow tables... why were the passwords salted back then?

From the article:

One problem with hashed passwords is if two users have the same hash, then you know they have the same password. A solution (invented in Unix) is to hash some random bytes (called salt) along with the password to yield the stored hash. Since different users will have different salt, the hashes will be different even if the passwords are the same. (Of course you need to store the salt along with the hash in order to check passwords.) Like Unix, the Alto used salted and hashed passwords.

Without salts, you can tell if two or more people have the same password, and you can pre-compute a dictionary of common passwords.

Something nice to discuss at least.

Reply on news.ycombinator.com