7 ms·

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

240 points by jjwiseman 9y ago

dogma1138 9y ago
They should totally file for a CVE for this.
- kens 9y ago
  Someone needs to come up with a catchy name and a logo for this exploit.
  - fenwick67 9y ago
    ReedCrack? Silent Whimper?
  - 33W 9y ago
    I like msla's XeroDay
  - kps 9y ago
    Contralto?
    - kens 9y ago
      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 https://github.com/livingcomputermuseum/ContrAlto
  - tda 9y ago
    From the article: > This attack is called XeroDay
    - kens 9y ago
      Yes, I updated the article based on the discussion here. But I still need a logo :-)
      - msla 9y ago
        Ha! Great day in the morning! Thank you!
dingaling 9y ago
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'.
- tqkxzugoaupvwqr 9y ago
  How did people get access to unreleased software?
  - gfosco 9y ago
    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.
    - Cyph0n 9y ago
      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 ;)
  - deleted 9y ago
    [deleted]
  - dogma1138 9y ago
    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.
Keyframe 9y ago
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.
- mmjaa 9y ago
  Turns out I need to do that with my old SGI. Got any tips?
  - jjwiseman 9y ago
    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.
  - DanBC 9y ago
    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/ http://www.openwall.com/john/doc/ http://www.openwall.com/john/doc/
  - Aloha 9y ago
    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.
  - Keyframe 9y ago
    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://crackaddict.com/~nate/hackirix.html 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.
jjwiseman 9y ago
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?)
- deleted 9y ago
  [deleted]
- kens 9y ago
  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.)
  - pieguy 9y ago
    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.
- Cyberdog 9y ago
  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.
izacus 9y ago
> 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?
- function_seven 9y ago
  Without salts, you can tell if two or more people have the same password, and you can pre-compute a dictionary of common passwords.
- deleted 9y ago
  [deleted]
- teh_klev 9y ago
  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.
KindOne 9y ago
When can we expect the security updates for the Alto?
mrpippy 9y ago
My own adventure disabling PowerBook Password Security on an old Mac: https://bslabs.net/2016/01/30/disabling-powerbook-password-security/ https://bslabs.net/2016/01/30/disabling-powerbook-password-s...
- kens 9y ago
  Looks like a very similar form of protection and a similar way of defeating it.
MikeBVaughn 9y ago
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.
z3t4 9y ago
When programmers and mathematicians use the word "trivially" it really means "I'm smarter then you".
colehasson 9y ago
Something nice to discuss at least.
raphman 9y ago
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-Schwachstelle-bei-Xerox-Alto-gefunden-1elf-3934443.html https://www.heise.de/newsticker/meldung/XeroxDay-Zero-Day-Sc...
mattnewport 9y ago
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)
- joshstrange 9y ago
  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.

240 points by jjwiseman 9y ago

dogma1138 9y ago

They should totally file for a CVE for this.

kens 9y ago
Someone needs to come up with a catchy name and a logo for this exploit.
- fenwick67 9y ago
  ReedCrack? Silent Whimper?
- 33W 9y ago
  I like msla's XeroDay
- kps 9y ago
  Contralto?
  - kens 9y ago
    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 https://github.com/livingcomputermuseum/ContrAlto
- tda 9y ago
  From the article: > This attack is called XeroDay
  - kens 9y ago
    Yes, I updated the article based on the discussion here. But I still need a logo :-)
    - msla 9y ago
      Ha! Great day in the morning! Thank you!

dingaling 9y ago

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'.

tqkxzugoaupvwqr 9y ago
How did people get access to unreleased software?
- gfosco 9y ago
  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.
  - Cyph0n 9y ago
    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 ;)
- deleted 9y ago
  [deleted]
- dogma1138 9y ago
  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.

Keyframe 9y ago

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.

mmjaa 9y ago
Turns out I need to do that with my old SGI. Got any tips?
- jjwiseman 9y ago
  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.
- DanBC 9y ago
  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/ http://www.openwall.com/john/doc/ http://www.openwall.com/john/doc/
- Aloha 9y ago
  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.
- Keyframe 9y ago
  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://crackaddict.com/~nate/hackirix.html 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.

jjwiseman 9y ago

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?)

deleted 9y ago
[deleted]
kens 9y ago
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.)
- pieguy 9y ago
  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.
Cyberdog 9y ago
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.

izacus 9y ago

> 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?

function_seven 9y ago
Without salts, you can tell if two or more people have the same password, and you can pre-compute a dictionary of common passwords.
deleted 9y ago
[deleted]
teh_klev 9y ago
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.

KindOne 9y ago

When can we expect the security updates for the Alto?

mrpippy 9y ago

My own adventure disabling PowerBook Password Security on an old Mac: https://bslabs.net/2016/01/30/disabling-powerbook-password-security/ https://bslabs.net/2016/01/30/disabling-powerbook-password-s...

kens 9y ago
Looks like a very similar form of protection and a similar way of defeating it.

MikeBVaughn 9y ago

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.

z3t4 9y ago

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

colehasson 9y ago

Something nice to discuss at least.

raphman 9y ago

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-Schwachstelle-bei-Xerox-Alto-gefunden-1elf-3934443.html https://www.heise.de/newsticker/meldung/XeroxDay-Zero-Day-Sc...

mattnewport 9y ago

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)

joshstrange 9y ago
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.