Reply to post: This song could have been about me

Sysadmin cracked military PC’s security by reading the manual


This song could have been about me

Details differ, but this story is about 90% in sync with one of my own.

In the early 1980s, I was on a mainframe system that had a punchcard interface, and a terminal interface, which was actually just a terminal that simulated the punchcard system. This is important to the story.

The system used 8 different queues, and the terminal queue was only one of them. However, all terminal jobs, for all users, were using the same queue, queue #1. So if 200 users were using terminal jobs in queue #1, if you ran your job in queue #2, it would run much faster.

However, terminals could not use any queue other than queue #2. So, the secret (documented in the manual) was to use the SUBMIT command, to submit the job in another queue. Of course, you'd have to write all of the terminal inputs into the card deck ahead of time so your job didn't get stuck, but once you did, you'd find your job would run in 90 seconds rather than 90 minutes.

Now, at a terminal, you logged in with username/password. When you submitted a job to a queue, you needed to put /USER(username,password) card at the top so the job would log into the queue. A neat trick was that the card deck you submitted was the INPUT file, and you could play with it like a file pointer.

In other words, the following job:




When submitted would result in the output to your job appearing in your queue, and you would see USERNAME(MYUSERNAME,MYPASSWORD) in clear text. Amusing, but not very useful.

However, the mainframe was networked to another, and when you changed your password on one, it would change it on the other... eventually. So you could run this job to see what your current password was, ie. if the change had propagated over the network yet.

But how does it propagate over the network, I wondered. It turned out it was done as another job in the queue, but was done with the site admin's credentials. So, I wrote a batch job that changed my password, that looked like





And lo and behold, the following appeared in my batch queue:







And lo, I had the adminpassword, in clear text, in my input queue.

The admins denied I could do this. So, I logged in using their password. I was called into the head of network security's office who said no, this was not possible, and then I logged in at a terminal in front of him. He still didn't believe me, and he changed the admin password. I told him I could get it in 10 minutes, and I did.

The end result was "tell anyone about this and you will not only be fired, I will have you killed" or words to that effect.

I had been hoping/expecting that I'd uncovered an implementation issue that they hadn't properly configured, which could be fixed now that they knew of it. Instead, I'd found a design flaw in the network security layer than required an operating system patch. This was $BIGNAME$ corporation, which had mainframes around the world, in sensitive areas (far more sensitive than in the industry I was using it in), and the idea that a low-level user could crack the admin password in under 10 minutes stopped several hearts in the boardroom.

Eight months later, I was called back into the head of network security, and told to try it again. The bug had been addressed in a patch, but it was still being rolled out worldwide, and I was still not to speak of it "ever again". Which, technically, I guess I am, except (a) this story is 30+ years old, (b) the mainframe I refer to is almost entirely obsolete, as is the network it ran on, and (c) the issue would only affect said mainframe whose patch levels aren't at 1982 or so level yet.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon


Biting the hand that feeds IT © 1998–2020