Was This the First Denial of Service Attack?
An anonymous reader writes "Way back in 1974, Dave Dennis, then aged 13, decided to try out the -ext- TUTOR command on the PLATO system at the University of Illinois, and see if he could cause all the terminals of other users to go offline. It worked. And he never got caught. Of course, the powers that be eventually caught on and fixed the -ext- command so terminals by default didn't automatically receive -ext-'s sent from other locations."
I'm not sure how this could be described as a "script kiddie" technique. The only pre-written software he used (exploited) was the 'ext' command itself. Unless you're expecting all 'real' crackers to only exploit programs and/or operating systems they've written themselves?
Yes, yes, I know, Rule of Funny and all that. As a card-carrying pedant, it's a contractual obligation to bitch about this sort of thing.
Sounds like the worst security system ever.
*cough* Diebold. *cough*
#fuckbeta #iamslashdot #dicemustdie
It used to be possible to crash early Sun servers (or at least the terminal server attached to the server by trying to copy data from a virtual terminal (cat /dev/ttyp0) or something similar.
One university department tried to get around the user quotas on commercial UNIX licenses by creating a single user account for an entire class. Hilarity ensued as students working on real-time projects would accidently kill each others processess.
Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
Back in the 19th Century (in the US anyway), mail *recipients* paid postage to get their mail from the local general store. Political figures and others who might have a negative following would receive scores of blank letters and have to pay for them. The objective was to either crowd out the legitimate communications or bankrupt the recipient. Traditionally, one could place an ad in the local paper explaining that he or she would no longer receive letters at the store, which would free them from their obligation.
I'd rather have someone respond than be modded up.
You know, this was all way before my time, but back then, security was not a common concern on university computers. People working in a lab trusted each other; thus, those who used Unix (or a similar system) would leave their home directories world readable, and as another example, ITS had the ability to observe another user's keystrokes. Things changed in the 1980s as more students got computer access and as proprietary software became the norm.
There are still echoes of the trust that existed back then. For example, where I am now, anyone in the CS department can remotely access any computer system located in the department, and the permissions on home directories are 755 by default. The only firewall is on the gateway between the department the general campus network, but port 22 is open for any system so you can always ssh through the firewall. We are given root upon request on our assigned desktops. There are plenty of ways that I could subvert others in the department, I could even bring the entire department to its knees by running a simple fork bomb on every system we have, but I do not do any of that because I am not here to attack people or make their lives difficult.
Palm trees and 8
First packets sent by Charley Kline at UCLA as he tried logging into SRI. The first attempt resulted in the system crashing as the letter G of LOGIN was entered.
I'd bet that part of the initial DARPA deployment testing involved deliberate attempts to jam the network
Just saying....
In high school in 1974 our district (8 schools) used an HP access timesharing system. It ran the BASIC language. I was able to write a very short program that would cause the system to crash. Having discovered this bug in the system, I was able to bring down the entire district's computers at will. I had discovered this capability while exploring a new feature of BASIC. Fortunately for them, I was ethical and informed my teacher who at first didn't believe the exploit until I demonstrated it in front of her. We then contacted HP, gave them the code, and they came up with a patch within a couple of months. I'm not sure if anyone at HP can confirm this at this point.
I am sure that there are probably earlier exploits as well.
And as a side note, I was also a PLATO author in 1975 and greatly enjoyed working on that system.
The earliest one I know of was by the smartest man I ever knew (and the strangest). He was my mentor. In the IBM 360 days this guy used to write code .. COMPLEX code in binary on the roller bars on the front of the console because he was too lazy to logon. He made IBM's code more efficient by eliminating all modularization. It was more efficient to just have one big super efficient kernel, so he redesigned their system, and got something like 140% efficiency out of the hardware (40% greater than theoretical possibility) by IBM's own benchmarks, and found a security hole in their code in the process .. as he put it "bit enough to drive an 18 wheeler through", which he reported to them. They told him it was his hacking, he broke something ... NOT OUR CODE!!! IBM CODE CAN'T BE BROKEN!!! So he went to their 'demo center' and fed in a deck of punch cards.
On the IBM Selectric console in the IBM demo center, it printed.
"May I please have a cookie?"
The operator ignored it.
8 hours later during shift turnover It printed
"I never got my cookie"
The two operators looked at it, shrugged, and ignored it. The dayshift operator went home.
4 hours later the console printed.
"You're not a very nice operator either, I never did get my cookie"
The operator thought the guys upstairs were fooling around and ignored it.
2 hours later.
"WHERE IS MY COOKIE!"
hummm...
1 hour later.
"Dammit give me a cookie!"
30 minutes.
"I WANT A COOKIE!"
15 minutes ... 7.5 minutes ... eventually we get to 32 cookies this second .. 64 cookies this second ... 128 cookies this second.
An IBM Selectric typewriter which is the main console for a 360/65 cannot print even the word cookie in a second, much less a whole sentence, and certainly not 128 of them! There was ONE way to crash a 360/65 .. Fill up the console buffer. The system considered console messages to be important, and if the system couldn't print all of them, it halted.
Reboot ... excuse me... Mainframe terminology here... "IPL" the system. First console message:
"You know, I never DIID get my cookie!" .. and the process starts over.
Finally IBM called my mentor...
um... did you submit a job to the demo center?
Yes, but don't worry, it was just a simple 'unprivileged' process, and as you said, your security is flawless, so I am sure there is no danger. :-)
Sir, I think we are prepared to acknowledge that there MAY BE a security hole in our system somewhere. It seems that your job never finished and yet it does not seem to exist in the system anywhere. Our experts tell us we have to re-install the operating system to fix it. Do you have any alternative suggestions?
Just one... Go get the best operator you have and put him on the console and call me back.
Yes sir... .. an hour later
Sir, this is king super operator, they just called me back in to work to assist you in solving our issue.
OK ... now listen carefully. I am only going to say this once. Type carefully, and don't screw this up .. are you ready?
Yes sir.
Good type this ... "c" "o" "o" "k" "i" "e" ... now press "Enter"
Console prints . "Thank you that was good", and the job ends.
After that IBM never ever questioned it if my mentor reported a problem with IBM software ever again.
See This journal entry I posted a while back... These days, at least in the US, I'd probably be up on federal wiretap charges or something. Back then, it was serious enough that they'd threaten to throw me out of college, but I never got any sense of there being jail-time involved...
Simon
Physicists get Hadrons!
I don't think it was quite as early as 1974, but somewhere right around there, I remember going to the "math room" in Jr High, and being able to access a terminal to get to "the main frame". It was something that used fan-fold paper (not a CRT). You could write BASIC programs on it, I think. I kind of remember writing stuff as complicated as 2D grid based Star-Trek type programs (one step up from Hunt the Wumpus).
Anyhow, we did have a command that we could type in that would crash the system, which we did once in a while, just to cause mischief. I really don't recall if we discovered it, or it was given to us (a la script kiddie), but it eventually ended up being a program called "runme" or some such...
Anyhow, letting random people on a "public" terminal to the mainframe of the San Diego unified school district is probably a thing of the past.
The best security breach, by far, however was an attempt to save money by re-using the fan-fold computer paper. Man, there was some juicy stuff on the flip-side of that stuff - names, addresses and IQ rating of all your class mates, payroll runs, all sorts of entertainment!
Simpler Times. Get off my lawn!
This issue is a bit more complicated than you think.
Taking out telegraph lines, signal towers, killing messengers. DoS attacks have existed as long as people have tried to communicate over distances. Even man in the middle attacks, intercepting and replacing semaphore messages etc.
"Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
No
I will back that up with my own story of a weaker DoS. The year was one of 1970-72, I do not know which. UC Berkeley had two CDC 6400s, A was normal, B was used for an experimental time sharing system and thus had an optional-at-extra-cost instruction, Exchange Jump, which swapped context. I had been toying with a Fortran program and gotten tired of it, so decided to finish it off in a burst of glory. It began execution in some obscure subroutine instead of MAIN, never called MAIN, and as it ground away at its nominal task, it gradually modified an innocent instruction into an Exchange Jump. But sadly, once it finally had modified it to the Exchange Jump opcode, there was no context, just a pointer to 0, and it farked the entire machine.
Now I wasn't truly anti-social. I had in fact written on the card deck that it was only to be run on machine A, not B. Unbeknownst to me, that Exchange Jump instruction was also used by diagnostic programs, and the tech was too lazy to disable it after each visit, just left it enabled at all times, so my Fortran program crashed the machine.
It wasn't much of a DoS, I will admit. The OS, CALIDOSCOPE (Cal Improved Design On SCOPE (Supervisory Control Of Program Execution)), could only handle 6 batch jobs at once at most, so that's the worst it could do. But I did get called in to the admin's office, who sighed and gave me that "What are we going to do with you?" look. He knew I wasn't malicious, but he had to warn me to not do it again.
Infuriate left and right
When i was in school (age 6), we had a single computer in the whole school which ran a selection of very simple programs, one of which simulated a snooker table and calculated how many times a ball would bounce before falling down a corner pocket. You had to enter the width/height of the table and guess how many bounces...
I entered a size of 0 for the table, and the program promptly crashed.. The teacher saw, called my actions stupid and sent me to the headmaster, who promptly banned me from ever touching a computer again so long as i was at that school.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
My own tale from 1974/5 was that my school had a time-sharing terminal and rented time from a local consulting company. Normally we used BASIC, but the maths teacher came back raving about the new language he had been taught at a weekend conference: APL. As one of the better pupils, I was given all the documentation, and went away to read up about it. A few weeks later, I had developed my symbolic differentiation program, and had carefully entered it in, and saved on paper tape. Unfortunately the program had a minor bug, so it used up *slightly* more CPU time than anyone might have expected. Apparently, the bill for the few seconds of run-time before I killed the program was over GPB 300 - a huge amount, and as it was pointed out to me, about the same as the computing budget for the entire year :( Fortunately the computer owners realised it was a mistake and didn't actually charge the school for the time - so I was off the hook, and took greater care to ensure that programs ran efficiently and bug free. A good lesson for a 13 year old.
Well, the -ext- command was used to send data to an arbitrary piece of "external" equipment attached to the terminal. A couple devices were a 4-voice music synthesizer, a Votrax voice synthesizer, and a random-access audio play-back device.
It was useful with some of the equipment for another user's program to be able to send such external data to your equipment and vice versa. Most people didn't have anything attached, but the system didn't know that. With nothing attached, all it did was make your terminal really really slow, as the other program queued up output for you that was basically thrown away, but had to be sent anyway (the external data took up about 3 character's worth in the data stream, with about 180 characters/second being output).
The system actually had pretty good security, and insulated each user from the other in terms of resource usage, and this wasn't strictly speaking a security breach, but this was a way to interfere with other users in an unintended way. It didn't take the entire system down, it only interfered with the terminals that were targeted.