When forgetting to set a password for root is the least of your woes Take a trip back to when mainframes and terminals were all the rage and The Cloud was the smoke produced by the mainframe when a washing-machine-sized disk was about to let go. Welcome to another Who, Me? confession. Today's plea for forgiveness comes from a reader Regomised as "Doug" and is a warning to careless …
While not a defence in law, this is precisely the approach that is often needed in IT.
The best tester I ever worked would come up to us and say, "When I do [THIS], then [THIS], then [THIS], it goes kaboom". We would ask, "Why would you even try to do that combination", to which he would reasonably answer, "Because it allowed me to". We would then either make it impossible to so do, unless it was a safe combination and should have worked in which case we would fix it.
Thank you Gordon, you truly were Entropy's Little Buddy.
An unguarded prompt is the same opportunity (or temptation). What can I do with this? What could possibly go wrong?
My father in law had a similar guy in his team. He would carefully read the design documents and then break things very quickly. Best thing was that he actually figured out the password checking program would allow him to enter eight blank spaces as a password, because apparently the " " was counted in more than one list of acceptable characters, and thus fulfilled the "get one character at least from each of these lists"-criterium. Which was a bloody stupid mistake, but every programmer has made one mistake of this kind (at least). If we are lucky it gets caught in testing...
Ours was called Malcolm. He could break anything without trying. Eventually I had to add a series of traps in the code looking for unexpected input and branching to a subroutine with a label called [OhGodItsMalcolm] where the input was discarded before carrying on. This was our first real programming experience on a CCPM-based data processing system using Dataflex 3GL back in the mid 80's. It had 1MB of memory shared between the OS and the three user terminals.
My father used to use me in that role. Set my ~7 year old self down in front of the computer, let me bang the keys seemingly at random, & try to figure out how I managed to make the magic smoke escape.
"He never left the keyboard! I made sure! How the unholy HELL did he manage to cause the CPU to trigger a thermal run away situation???"
I didn't know then, I don't know now, I just know that my "I void warranties" t-shirt seems to fit in more ways than one. =-D
This post has been deleted by its author
Yeeeeeees... This is what QA is *meant* to do. Try anything, everything, see what happens. Even if that doesn't make sense to a developer and they rant on about how QA are trying all sorts of crap instead of testing the software.
No love, that *is* testing the software. If you do not sanitise your inputs, and you don't make sure your software doesn't let silly things like that happen, then yes, love, your software is going to do stupid things.
QA were, as much as they were the bane of the developers, my best friends because they highlighted pathways in the software that hadn't been thought of during the design/development process that needed to be... fixed/accomodated.
And yes. Unguarded prompts? Oh boy!
80%+ of development is handling things going wrong, that not only includes uncontrollable things like network disconnections, running out of memory, etc. as well as sanitising any and all user input. Sanitising user input does, of course, include the fundamental precept that no user input is trusted.
In my experience, far too many developers only think about the "golden path" through the software, where everything goes exactly as expected.
"80%+ of development is handling things going wrong"
It should be. It seems to be less and less the case. Sometimes just working out that things have gone wrong would be a start. Simple things like run a report at 5 mins past the hour to list everything that should have been in that hour's shipment but is still unshipped. It's just easier to let the customer complain.
Thinking only in terms of happy paths is the sort of thing that you expect from new grad devs maaaaaybe, anyone with a year of experience in industry still doing it is probably unemployed if I'm honest. Or at least unemployable at anywhere I've worked.
I recall an interesting stat, I don't remember the exact number but there was a fat metastudy a while back that showed a solid majority (well over 50%) of all outages that cost companies money could be attributed directly to missed error handling conditions. Even pretty bad engineers should be acutely aware of this.
EDIT: Thinking about it, most places I've worked if you didn't include automated tests for the error conditions or explanation of how they were tested in the pull it would be shut down without further consideration immediately.
"The problem isn't the bad engineers. It's the MBAs and accountants with NO engineering or QA training at all"
That is indeed the bane of each and every company. I cannot count the times our manglement tried to "optimise" (AKA: prohibit) any kind of real testing as long as the documentations were according to ISO 9000++ (AKA: falsified). This might come out a tad unhealthy, considering that our machines handle up to 30 tons/30000 kilograms with interesting speed.
I also cannot count the times that manglement allowed only time for a perfect path and timeframe for an also perfectly new prototype. This realitiy incompatible over optimistic approach failed each and every time, as predicted. Those predictions were naturally brushed aside in sheer arrogance, no matter how often (every time) the writing on the wall was glowing so hard that it could be seen galaxies away.
Bonus points if this nonsense timeframe was already contractually agreed to (of course without checking on the nominal delivery time for special components, which often exceeded the agreed on delivery date of the finished product) and suddenly bears the danger of not only an angered customer but also hefty penalty fees.
But as always.... it does not hurt where the decisions are made and the decisions leading to the issue cannot be influenced where it hurts most.
In such occasions, i really wish for Marx... Not Harpo, Groucho or Karl but the nice little high voltage generator, contacted at the correct place where the issue of the false decision constantly happens.
Quite some time ago (around the turn of the century) I was doing test and diagnostics for a new product.
Said product was in a 3U compact PCI rack with a couple of boards we had designed. My code ran on a host and connected via sockets (the joys of ioctl).
I was just getting the new tests running prior to these boxes going to production and I was getting weird errors.
Turns out that during the hardware initialisation (hand crafted PCI enumeration included) none of the initialisation code checked for errors. Therefore a failed init was a totally silent failure until I tried connecting to it.
I added a status word to the init code and successively cleared bits during the init sequence; in good 'C' fashion, zero in that word post init meant everything had worked but also had the added functionality that a non zero result identified just where in the init sequence things had gone wrong, saving significant troubleshooting time at production.
I just wish they had followed the 10 commandments for C programmers (see item 6) in the first place.
Device errors might not happen, but ensuring they are handled is better than some code I've seen (opened a file, spewed out information, closed file) and without one single check. Ironically what brought that down was the file handle being null due to unable to create the file, and then trying to write to a null handle. Oddly enough the system didn't appreciate that.
But still...
"In my experience, far too many developers only think about the "golden path" through the software, where everything goes exactly as expected."
Case in point in the old days: giving "restricted accounts" which only let people do email.
Do you know how many ways there were to break out of Pine (or most other "email programs") into a shell?
I set up a reward system. Any user who could send me a message after breaking out of the mail system got $10. I thought I'd nailed it down before letting people loose on it but ended up shelling out a few hundred dollars anyway (some didn't bother with the message, but enough did that the holes were picked up quickly)
"Yeeeeeees... This is what QA is *meant* to do."
Well, not necessarily. There is a line of reasoning that boils down to "you can't test-in quality" (or more fundamentally you can't bolt it on. Testing can detect and remove flaws - but at best a low test failure rate might indicate good quality. Quality is a result of sound planning, development and implementation using processes that aim to prevent or quickly eliminate defects and errors.
In this line of thinking Testers test - ideally they should be good engineers familiar with the system and be well read on testing methodologies. Quality Assurance is concerned with making sure things are done in accordance with the appropriate standards and procedures, by suitably skilled people - they might even run key reviews (though not be the subject matter experts). They [should] report independently from project management and [theoretically] are free from the project delivery pressures of the project team.
In reality quality is everybody's responsibility if you want to build a high quality product.
"ideally they should be good engineers familiar with the system" NOOOOOO!
The are restricted in their thinking! He will only test what he knows.
You need someone who is NOT an Engineer familiar with the system. Those who are UNfamiliar test it the real way, since they don't know what is expected.
Randomized (or even methodical) input testing based on zero knowledge can be automated using fuzzing techniques.
Deeper testing of a system requires an understanding of what it is meant to be doing and an knowledge of the ways in which things can go wron. It is this element of engineering that is often overlooked by implementors and is a skill that those who excel at testing have an affinity for. Good testers should always have this different viewpoint of the system. Some of their task can be completed without an understanding of the system - but system knowledge can also be used to inform testing.
However, all this does not build in quality, but should be _part_ of a process that assures quality (and QA should be checking that that process is being properly applied). If testing is finding more than infrequent design and implementation errors that is an indication that the execution of the design/implementation is flawed. Simply patching up those errors is unlikely to result in a good quality system.
This is a very dev-minded approach to the concept. The good testers I've met in my time understood black box and white box testing, understood the tradeoffs and came to the eng team with what they wanted to know about the system and what they didn't want to know about the system and in what order/when before a single workpiece came their way.
You mean Testers don't do this type of thing as standard? I've beta tested several products in my time. Knowing the product inside out meant that I could think up many a devious way to try and break it by doing something "unusual".
The mantra goes thus: "If a thing is possible, a user will do it. If a thing is impossible, a user will find a way do it anyway".
In my most recent incarnation, developing software for an automated cat feeder, I spent a long long time thinking up ways things might confuse the feeder. And yet, every now and then, something surprised us, like a cat simply beating up the feeder, or hiding toys in it, or in one case, an owner who rather than pushing the 'open' button simply picked up his kitten and let the feeder detect it to open the lid...
This reminds me of the episode of Cabin Pressure (can't remember which one) where Douglas challenges Martin to find out how many of the safety features they can disable and still fly.
"Hey, chief, I might be wrong, but I think we're flying into a mountain. This makes me feel... scared of the mountain. One thing we could do is pull up and fly over the mountain. How does that sound to..." </icon>
Conflation indeed. The other one is “Timbuktu”
(For non-listeners, in “Cabin Pressure”, the pilots often play games to pass the time)
DOUGLAS (protesting): No! No, I’m sorry, I’m done.
MARTIN: No-no, fair’s fair, Douglas. You promised if I joined in with Flight Deck Buckaroo, I could pick the next game.
DOUGLAS: But I hate this game!
MARTIN: Yes, and I hate Flight Deck Buckaroo.
DOUGLAS: How can you hate Flight Deck Buckaroo? It’s a terrific game! And it’s educational.
MARTIN: There is nothing educational about seeing who can disable the most instruments without setting off the recorded warning.
DOUGLAS: Yes there is! You find out all the things you don’t really need! Like altimeters.
MARTIN: No, this is educational. So, welcome to round two of Beat the Manuals!
I tried that with the NHS doctors app "Calculate the % chance of death when the patient has major heart surgery"
Put in normal inputs..... mine came back at about 0.75-1.25%
Next try how far up I can get the % to go ( 94.5%) as I remember.
Now lets try putting in some really silly values eg blood pressure 250/10 with a BPM of 0.05
Yupp crashed.(the bpm did it..... did'nt like values lower than 1)
But then how many hacks are done with the root account being "admin" and the passy "1234".....
I was supposed to "test" the new program. Unfortunately they did tell me not to do much of anything. So I just looked at what was on the screens and the help text.
But in fairness it was the new version of the program to create users IDs, accounts and set all the permissions. And they didn't have a test system.
Apparently there had been a few previous fun cases were the developers doing testing had deleted a few or all the user ids. So the new kid just starting, yeah, don't change anything seems like a good idea.
As a member of a student informal group that was interested in computers (mainframes at the time), during an ad hoc discussion by this group of testing I stated that terrible inputs should always be filtered. As an example of something that should never be allowed and would be filtered, I entered "remove =/=" on a teletype connected Burroughs 5500 (MCP OS which had a common one-level file system). When the teletype did not respond instantly with a message indicating prohibited input, everyone in the group looked at each other with an immediate packing up, quiet disappearance, and subsequent absence from the university computing center for several days.
A major historical and continuing design flaw has been the development of ad hoc input parser's by software developers (for parsers or any parameter passing mechanism) which assume an OS, character set (especially escape sequences and display rendering), user cultural behaviors, and downstream/upstream validation filtering. A technique that has proven very effective is to create a LALR(1) grammar exclusively for parsing all input with the grammar establishing which character sets, characters, and character set tuples are allowed for further parsing and analysis by a language or context-specific LALR(1) grammar.
Is exactly why Boots and the Co-Op Dept store in my home town were often filled with white noise of a saturday:
10 Goto 10 :Goto 10 :Goto 10 :Goto 10 :Goto 10 :Goto 10 :Goto 10 :Goto 10 :Goto 10 :Goto 10 :Goto 10 :Goto 10 :Goto 10 :Goto 10 :Goto 10 :Goto 10 :Goto 10 :Goto 10 :Goto 10 :Goto 10
was left on the BBC Micro, waiting for so less bright kid to hit enter :-)
Well, on ZX81s, I had a 6 character program encoded in the graphics character set that loaded a number into the "I" register of the Z80, which was used to store the base address of the character table.
Typed it into a REM in the first line of the program, with a call to the address of the first byte of the REM (which was one of the few fixed addresses in a program on a ZX81), and the display became a scrambled mess with no way to fix it. The only way was to power-cycle the system.
I used this method on my own ZX81, which had an extra 1K of static memory added under the keyboard, to provide programmable character sets. It puzzled a lot of people who saw my ZX81 displaying everything in lower-case, and I had some interesting times drawing music on the screen, and playing it at the same time on a Quiksilver sound board.
I remember "a friend" "accidentally" plugging a PC keyboard back into a Dixons demo machine, and "accidentally" deleting autoexec.bat so that the machine would not start the demo next time it was powered on.
Back in the early 1980s when "Dixons Reject!" was a powerful term of abuse for someone who was completely stupid. Sorry Dixons, RIP.
Reminds me of when I was working for a well-known (but now sadly defunct) software tools developer's tech support team decades ago and took a call from a pompous tw*t working for PC World, who was trying to blag free support for an issue that required a support contract. When I pointed out that he'd need to pay a small sum of money for me to open a support case, his response was "... but I'm from PC World, do you seriously not know who we are?!" to which I replied "Yes, you're part of Dixons". His response was a "WTF are you talking about!?", I suggested he read that day's newspapers where the headline was PC World bought out by Dixons Retail Group.
Many years ago, but many years after lessons should have been learned, I remember playing with a PC that was running GORILLA.BAS under QBASIC as a floor demonstration, and it was fun making inputs that blew the map up in unexpected ways, but it was even more fun dropping to the editor and changing random things. Like showing my name at the top instead.
Shouldn't that be fill the keyboard buffer G.10G.10:G.10... ?
Hitting Enter would expand it to GOTO 10:GOTO 10 .. overwriting the sound buffer causing the chaos.
Similar fun was to be had on the Beeb with VDU CTRL codes to change graphics modes and the like on demo programs that should have less accepting of their input.
Amateurs!
I used to tap in a little program that disabled both the escape and the break keys, waited 60 seconds, then used the BBC Micro's ENVELOPE command to make the same trim-phone ringing sound as Boot's own phones. I would withdraw to a safe distance to watch the staff running around first trying to find out which phone was ringing, then trying to stop the computer but failing as none of the buttons on their cheat sheet worked. Eventually they would set off the theft alarms when they had to move the computer to find the power button.
Very childish I know, so sorry if any former Boots staff are reading.
A guy that joined us from Boots (Our local stores computer sales guy), liked a drink (Possibly because of you lot).
One of his wizard wheezes was on Christmas Eve to sit in the bar of the closest purveyor of falling down liquid (Icon) & ingratiate himself into the rounds of each departments Christmas lunchtime drinks rounds, as they came in on staggered lunchtime breaks, he was finally rumbled when the last departing group asked if he was going back to work "Nope I took today off!" & he then partied (If he was still capable of movement) into the night.
He slept throughout Christmas Day apart from a valiant & brief effort to attend dinner (Looked at food, felt ill & went back to bed).
I remember at school discovering that holding down R whilst powering on did something hideous to the machine. No warning, countdown or on screen confirmation, just immediate Bork. Obviously we did on a few more machines before we convinced ourselves that it wasn't just chance that that particular machine had chosen that particular moment to destroy itself.
It was near permanent. It took our teacher about a week to find out how to fix it, then about an hour with each machine to actually fix it. As I recall he got it down to a few minutes before finally coming down hard on us for doing it again and again and again.
I once visited my local Fry's Electronics, browsed their demo machines, & discovered one had been left unlocked.
I changed the DOS prompt to read "C:\> Press any key to initiate the self destruct sequence..."
It was fun to watch customers approach, lift their hands in preparation to type something, then their eyes go wide & they backpeddled as if confronted with a ravenous Bugbladder beast of Traal.
Even funnier were the *employees* whom theoreticly should have known better.
Anyway, one clerk comes over, notices the prompt, & calmly rips the power cord out of the power strip along the back. He unlocks the security cable, removes that computer, puts a fresh one in it's place, locks down the new one, & turns it on.
No funky prompt, he locks the keyboard, picks up the suspect one, & wanders off.
Too bad I'd watched him typing in the password of "Frys". Walk up, hit the shift key to get the screen saver lock screen, enter the password, & go back to futzing with their shiny clean demo machine.
I'd probably go to hell for all the stupid shit I've pulled, but Satan's got a Permanent Restraining Order out on me & I'm not even allowed in the lobby. =-)p
Worked in an organisation that used smartcard and pins for authentication. I was in the office where the system admins worked. This was not a secure office. The admins regularly left their cards in the reader and buggered off. They usually had a loooong timeout set too. (saves having to put that long and complex four digit pin in.)
Procedures dictated that unattended smartcards be removed and reported. The System Mangler wasn't happy, the paperwork was a pain, and said to stop it.
So we (I) did stop. Didn't stop us (me) adding clear sticky tape to the chip or trimming the edges of the card so it was to small for the ID card holder. Or adding facial hair in indelible ink to the picture on the card.
Turns out this was more effective than them getting bollockings!
Anonymous for obvious reasons!
That was a great feature, until you kept forgetting to grab your card when you left the office (which I did all the time). The office manager got irate with me since she had to keep giving me a new card. Also, I'd forget about it, then I would have 3 session going on the server for weeks at a time. I finally remembered and had to go through and kill all of my old sessions off.
The SunRays were fantastic for that. I was working for Sun at the time, and they were everywhere in the vast Sun facility I was working at. Getting from one side of the facility to the other was about a 15 minute walk. As part of the job I often had to go all over the facility, and being able to just walk around with my ID card and slot it into whichever SunRay was closest meant no dragging a laptop about, and laptops weren't common at the time, most organisations used desktops. Meetings were great too, the team just slotted their ID into the SunRay in the meeting room and there were the materials they wanted to demo.
The downside was when you forgot to pull your ID card out of the SunRay and walked away, most typically happened when you left your ID card as far away as possible from where you next needed it, usually back at my desk at one far side of the facility. Bonus points if the SunRay in question was behind an ID card secured door (we had them in the comms and server rooms), so in addition to the long walk you needed to beg a colleagues ID card (who then couldn't work on a SunRay until you got back)
The ops caught me once. I'd gone to the loo and forgotten to lock my terminal. When I got back, the terminal was locked, with a note from the op, saying I had to repeat 1,000 times, "I will lock my terminal, when I leave my desk."
I took him at his word, I wrote the sentence in EDT, copied it 1,000 times.
I then used the VAX phone command to call him (ICQ, WhatsApp or iMessage for the 1970s user), when he answered, I piped the file with the 1,000 lines to his terminal.
We had a good laugh and I bought him a beer, when we met up for our AD&D evening.
While at university in the mid 90s, my mate and I were doing some work and needed to FTP a file to/from one of the servers, so we opened up the supplied FTP client (stored on a Novell fileshare IIRC), typed in the server name and found an auto-completed config set for that server. With the root account. And a password saved in the config. We looked at each other and hit "connect"... and promptly had an FTP session on the server as root.
After confirming we were definitely in as root (by downloading, deleting and re-uploading /etc/passwd - yes, a bad choice in retrospect, we could have FUBAR'd the machine), we decided we'd better tell the lecturer who looked after that box about the issue. The config in the FTP client was removed that day.
For some reason, probably to provide a maintenance window, the Unix box we were using for an assignment had user logins disabled for an hour at lunchtimes, just when we wanted to use it.
Fortunately a friendly sysadmin (yes, they do exist) had let slip the password for su so we could use that, then connect to our own accounts.
There were too many fellow students using the same box for anybody to do anything silly with the access, tempting though rm * (no need for the -r back then) may have been.
We used to send data to a third party marketing company for them to prepare mailshots for us. This was done via FTP. One day after uploading our file, I decided to cd ../ and much to my surprise, it allowed me to. Being the curious sort, I then typed ls -la and saw a list of recognisable company names. Picking one at random, I was able to access not only their directory but also their data.
This was in the mid-90s when "hacking" was Very Naughty. I spoke to my boss who was in the same quandary as me - report it as a security risk or potentially get arrested? His decision was to keep quiet about it.
Possibly the best approach might have been to have your boss go apeshit at the third party marketing* company for their lack of security as your own data was as much at risk from anyone else with FTP access as theirs was from you!
* Ah, a marketing company - well, that probably explains their lack of security. Their server was probably set up by the marketing boss's teenage son whose knowledge was based on his experience with AmigaDOS.
At the end of the nineties I had a similar issue with an FTP server managed by one of our suppliers. In that case I knew the guy who managed IT there, gave him a quick call and he sorted it out. Had I not known that guy I would have also mentioned it to my boss, with the remark that “if we can see their data, they can probably see ours”…
I worked for a while providing ad-hoc IT support for a small building company that provided specialised refurbishment and installation services in a rather cut-throat market. When I was first employed by them to sort out their computers I found their network of desktops and Internet connectivity, such as it was, to be rather lacking in any kind of security. I demonstrated this to the company's boss.
"Look, XXXX (their main rival for Government contracts and blood enemies) could do THIS and THIS and there's no password set and..." as I brought up the company's current contract list on the screen, followed by the unencrypted tender document he was writing for a future project in the six-digit price region.
"Oh." he said. "Uh, could you do that to THEIR system, you know, speaking hypothetically..."
"This was in the mid-90s when "hacking" was Very Naughty."
People used to complain that "hacking" had been distorted from its original 60s and 70s "hacker culture" definition to instead mean someone doing illegal/dubious security-related things (a la your 90s definition).
It's ironic that even *that* meaning has been degraded and redefined in an undignified way, a la "life hacks" or (e.g.) "menu hack", the latter being where you use various techniques (e.g. asking the staff for unlisted items or combining existing ones) to create something not on the regular menu.
I saw a billboard literally this morning where McDonald's informed us that we no longer need a "hack" to get a Chicken Big Mac.
FFS.
"And it's also in /etc so it's specifically not in $PATH$"
That's "supposed to not be in your $PATH" ... I strongly suggest double checking this, do not assume, I got bit once at a place where you'd think they'd know better.
::grumble:: ::bitch:: ::gripe:: ::moan:: ; Hey you kids, ger orf me lawn!
In the 90's I was working on a system fro a Police research department based in a Home Office building in London - we were based at the IT centre in Liverpool. At a meeting with the moron of a Chief Inspector in charge of the department (obviously deployed there to get him out of the way) he basically accused us all of being IRA sympathisers - "You've even got an Irish name!" I was told. After biting my tongue and assuring him that we were all sevcurity cleared, he went on about how sensitive the info was, and how access to it must be strictly controlled!
A week or two later I visited the office to see how the bobbies using the system were getting along and noticed a sticky label on a function key that said "Login". Using my supreme detective skills I asked the bobby what that was for - he said "we can't be arsed typing in user names and passwords, so we found out how to program it into the function key. One press and we're in!". Oh how I laughed!
Or to get around catastrophically stupid and/or ignorant "design" by the IT provider/dept.
My favourite: ~1998 reporting a stolen credit card (mail intercepted) at the Chelsea police station. The lone PC there was sitting there typing (hunt&pecking) the report into their expensive custom-built police system, and the phone rings. He picks up a tightly-folded battered-looking little square wodge of paper from beside the keyboard, wedges it into the gap between the spacebar and the surrounds, and goes and picks up what turned out to be a lengthy phonecall.
As he went back to his desk I asked him what on earth the paper + spacebar thing was all about.
Turns out the IT architects/developers never bothered talking to actual policemen, let alone watching them as they did their jobs. And "for security" they put a short timeout on every data entry screen : stop typing for a minute and you'd lose the lot.
Well, their job is filled with unschedulable interruptions. And they'd worked out that if you jammed the spacebar it'd keep firing in keystrokes and keep the screen alive. When they could come back to it, they'd just hit Tab (and trailing whitespace was trimmed), then Shift-Tab, and go back to typing where they left off.
A colleague of mine once told some bobbies that they couldn't get upgraded replacement kit unless the old kit stopped working. Funnily enough, the stuff they wanted replaced managed to 'fall down the stairs' at the station. From a ground floor office.
Reminded me of that chap who was so desperate to escape that he not only jumped out of a top floor window, but also pulled all his fingernails out on the way down...
Around 1986 I put together a "screensaver" for Sun gear that made the screen look like it had a couple of bullet holes in it. I occasionally deployed it on workstations where the user (engineer) had walked away, leaving himself logged in. Quite realistic on the colo(u)r Trinitrons of the day ... realistic enough to draw many a scream of "What the FUCK‽‽‽‽" from people who should know better.
We used to type up an email to the CTO or similar (replacing one character in the email address to make sure that it wasn't actually delivered if accidentally sent). The message body varied but usually contained enough profanity and lewdness to get SOMEONE in trouble. Hover the mouse over the send button and walk away.
In my experience it's usually p***ing about with the mouse settings to make things awkward (or changing things like the keyboard language settings where inappropriate) - There's a whole raft of things you can do if you have enough time, one favourite is taking a screenshot of the desktop and setting it as the wallpaper after hiding all the icons.
It has been known for people to deliberately shut a machine down to prove a point...
Best working example...Infra guy claims in a meeting that the company has implemented failover/redundancy.
Techies at the coal face know it isn't....
Random techie shuts down database server.
All hell breaks loose.....
Infra experiences a type of redundancy they didn't expect.
"Oh, and secure your root access – and never, ever, leave superuser accounts logged in."
Or as it had happened: a trader called it a day while, apparently, a trade was already filled in. And later on when cleaning staff came in, dusting everything and the keyboard, an accidental trade in the order of € billions was executed.
That, at least, was the official explanation. I wasn't involved in its investigation at all but believe it was neither accidental nor cleaning staff...
Back in the days when I was a "student assistant" at Uni, one of the other SAs set up batch files for "dir", "syscon", and other common Novell commands in his home directory that would log someone out. His reasoning being that was the quickest way to get logged out if you left yourself logged in and someone else discovered it.
So a high-level sysadmin found his account logged in, did a dir and got logged out. For some reason, she was furious... mainly because she wasn't too bright and didn't understand what just happened.
He got a huge bollocking from the head of sysadmins for his "shenanigans", but when it escalated to the department director, he was cleared and congratulated as a clever chap.
This didn't endear him to the sysadmins for a while, until they finally actually understood what he was doing, and grudgingly admitted it was a good idea after all.
The terminals were probably connected to a terminal server like an Annex, which acted as a serial "switch" to allow direct serial connections where you could tell it what server you wanted to be connected to, but also supported telnet to wherever was accessible via its network connection (the entire internet, in some cases)
10 years after leaving a sysadmin job at a UK university I decided, on a whim, to try telnetting in to their main admin server. Imagine my surprise when I found my account was still active, the password unchanged and still with sudo access? I did the decent thing and left a message in the operators terminal window…..
They obviously knew what root was, and were quite familiar with Unix commands since they were able to put together a shutdown command. They either didn't bother to check what server it was or did but lied about not knowing. I'm guessing they were planning to "teach a lesson" to whoever left it logged in as root, but teaching a lesson would be leaving 'echo "you shouldn't leave a root shell logged in"' not leaving a shutdown trap that they know would impact their client's business.
I usually have sympathy for the "Who Me" subject, but not this week. That's a high school level prank, not something a professional should be doing. If they had worked for me, they would be removed from that client site instantly. If they were REALLY good at their jobs I'd consider keeping them around after making it very clear to them that they will be left without a job and without references should anything remotely like that ever happen again. If they were just average I'd figure they were easily replaceable and would do just that.
"never, ever, leave superuser accounts logged in."
Many times. I walk up to use a terminal and it's logged on as root.
Look around. "Hello. Is anyone using this? Anyone? Hello?"
I just type in 'exit' and 'whoami' one more time to find the actual user name of the moron who left the system vulnerable. Log them off and go about my business.
Reminds me of a time way back when a colleague was trying to kill a rogue process, traced it back to its root and cheerfully did "kill -9 1".
Almost immediately the penny dropped, and was rapidly followed by a facepalm heard all the way across the office.
Fortunately the system was back up five minutes later and as it was already running slowly we just told everyone it was overloaded and had crashed and nobody seemed to think that was out of the question.
If you had root password on Unix ..
You could mount anyone's NFS home directory on a test lab machine and read their ~/mail that was in text
disclaimer
--
So I was told
Many people have told me that
I never said this
No .. I don't recall .
Yes . Donna and Steve were banging during lunch at her apartment across the street.
When you have root access, it means you have ... root access. And you can do all the things that root can do, including reading users' files. If you are supposed to have access to run some commands as root but not to read others' files, then the admins should not give you full root access.
we had big filers running solaris and samba
grab a windows 95 computer , hit escape to bypass login screen. make new user on the windows box named 'root' with blank password
Connect to filer by mapping network drive.
Drag and drop folders around. copy a bunch of pictures from windows to the filer.
all that stuff was done by 'root'.
The cause was a bug in solaris whereby it did not re authenticate. it said you are root over there, so you are root over here...
One of our testers said there are two extremes in testing
1) No matter what we did - we could not break it
2) If we were careful, and the wind was behind us, and we didnt push it - we could get all of our tests to run.
His favourite scenario was to limit the virtual storage allocated to each components and then hammer it. Including doing things in "the wrong order" and restarting it half way through. All that was "easy". The hard part was making it repeatable so that the same scenario could be retested with any fixes.
To this day there are so many apps in that limbo -- heavily multithreaded to take advantage of all the horsepower in modern CPUs, but one out of every 40 CI runs inexplicably fails, and if you want to paper over the race condition you can just run another and it'll work again.
Until the bug reports roll in.
At a previous job, I built some SMTP relays. They were highly tuned Linux servers with lots of disk space for mail spools. I published benchmarks, something like 1 million messages per day per server.
Years later, another team took over responsibility for email. Their tech lead made a Great Project to replace this old low-budget infrastructure with world-class appliances. He got test gear and quotes from 3 vendors, any of which utterly eclipsed the performance (and cost) of the Linux relays. Someone got me invited to help test.
My first suggestion was to list all the failure modes that each device was protected against: failed drives (RAID), redundant power supplies, battery-backed write cache, etc. Then induce every failure mode in rapid sequence. Yank a drive, wait a few minutes, re-insert it, wait until it started to rebuild the array. Then pull power from one supply, reconnect, yank the other power cord, reconnect, then pull both. Power it back on then start the performance test.
One appliance failed immediately. The others were badly impaired. Vendors got upset, and the tech lead was livid because he didn't look good either.
At a Meeting with managers and vendors, Tech Lead called me out on this BS. I was only sabotaging the project out of jealousy. He observed that the old relays had never been through that.
I showed them my original test results, where I had done exactly the same tests, but had first queued up 7 days of email on the Linux relays "because it could happen."
One appliance really shone. We bought that one. He never invited me to another project.
Working for a national company in headquarters, with around 20 IT staff in an open plan office, the rule was if you walked away from your computer without locking it, then it was fair game. One of our staff made a point of setting the desktop to be pictures of kittens and leaving an email to management telling them that you quit.
I never needed to hack our shiny new £50,000 UNIX Server, it was left completely open.
Full rwx permissions and privileges. Just change directory to another user
I was angry at our 3rd party supplier's incompetence but never said anything
It was too useful knowing the salary of everyone in the company
And the secret plans to geographically relocate to a cheaper part of the country, 150 miles away
Four of us, in the know, went to the Managing Director and complained and the plan was kiboshed.
(most of our customers were in the South East)
We set up a meeting at his house one evening
"How do you know all this?"
"Can't say, sorry"
The loophole was never closed
Left alone in the testing and development lab of our parent company in Germany we had access to terminals.
Played with commands to no real effect, luckily, I guess.
We found a command/script "crumple" which had the pleasing effect of, well, crumpeling the screen.
Nothing bad.
Next day we mentioned it, we were interrogated and finally called into the big bosses office
It started with "wtf were you thinking of" you could have caused untold damage and cost time and money and so on. (They were all valid points, we had no Unix knowledge and...)
We left feeling totally told off as if we were still at school.
Mind you, Munich and a few beers later, wft, Prost!
A student who was a Student's Union officer left herself logged in.
Another student decided to post under her login "I'm a stupid expletive expletive. I've let myself logged in" and an invite to tell her that via her email.
This was posted to alt.test, misc.politics, alt.flame, alt.tasteless and a few other delectable groups.
The sysadmins had a hell of a time with her account mailbox being over quota within minutes of this happening.
I am routinely put on beta teams at my employer with the instructions "Hey, Curtis. See if you can break this". And I do. Because the guys doing the programming don't actually use the software daily.
To this day, there's one dev who has stated that under no circumstances am I allowed to "test" his software. Interestingly, whenever he says that, upper management then pulls him off whatever project he's working on.
Whoever woke it up with enter got to see the command before the machine shut off...
A really devious person would do something more like:
echo "alias vi='grep -v bOzO .bashrc > brc ; mv brc .bashrc ; shutdown -h -Q 30' " >> .bashrc
That way they don't get to see the shutdown command when they wake it up with the enter key. Could lurk for days...
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
