Slashdot Mirror
Fired Techie Created Virtual Chaos At Pharma Co.
itwbennett writes "Using a secret vSphere console, Jason Cornish, formerly an IT staffer at the U.S. subsidiary of drug-maker Shionogi, wiped out most of the company's computer infrastructure earlier this year. Cornish, 37, pleaded guilty Tuesday to computer intrusion charges in connection with the attack."
For those wondering how he got caught, he accessed the servers from his home also for the McDonalds just before he accessed them he purchased some food using this credit card.
He could have potentially wiped out some on going expensive research while he was at it and potentially cost lives not to mention jobs at a company that obviously wasn't in the best financial health to start with. This selt centered little prick doesn't deserve any leniency.
I usually can only destroy 10 or so vm's before my vsphere client runs out of memory / handles or just segfaults for the fun of it. Needless to say, my displeasure with that vpshere client has caused me to become somewhat of a vsphere command line ninja.
Firstly, it appears this guy was treated poorly and not only is he a nitwit, it would appear that most of his coworkers/management were as well.
Secondly, it's acts of sabotage like this that make it hard for the rest of us to do our jobs.
Thirdly, on a not so serious note... wi-fi from McDonalds? vSphere console? How did he think he was NOT going to get caught? Did he even try to wipe the logs off the vsphere server? Had this guy two brain cells in his head, he could have obliterated their infrastructure and not left a trace of evidence.
Yes Francis, the world has gone crazy.
Shouldn't a "too long; didn't read" section be shorter than the rest of your comment? And it should provide a summary, rather than go off on some tangent.
which is totally what she said
What you really should care about when it comes to IT department is to keep them happy. The cost compared to what can happen when an employee is disgruntled is minor.
And even if you remove/change all passwords - are you sure that there isn't a backdoor somewhere? Especially in a system like Active Directory where login accounts can be "hidden" anywhere in the tree. Also - some accounts can't change password easily since there are services that may depend on them - or that the password also is the encryption key. It's just a ticking time bomb in some cases.
Some of you may claim "You are doing it wrong" when you depend on "unchangeable" passwords - but in some cases there are interdependencies that causes that kind of problem. And the problems can be all the way from a background task that locks the system account because it uses the old password to encryption key based on the password for the backup solution. In some cases it's caused by the third-party software that you use.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
And in case you didn't figure it out, "^" represents the CTRL key.
And oddly enough, it's not just VI - the windows command prompt works exactly the same way, open one now and hit CTRL+V (probably expecting to paste something) only to get ^V on your screen instead. But it's ok, hit CTRL+H and it'll backspace for you.
I believe its less to do with VI and it's CRAZINESS and more to do with the legacy of some keyboards not actually having a backspace key. Shock horror, I know.
(Cue the "...back in my day, we had to use TWO keys to backspace!" comments...).
+1 IDisagreeSoHeMustBeATrollOrAnAstroturferOrAShill
I know this might not be a popular opinion, but why should a business "really care" about keeping the IT department happy over any other department? Yes, they could do a lot of damage, but so could ANY disgruntled employee who walks in with a gun and starts shooting. Companies should treat ALL employees with respect, not grudgingly cozy up to IT because they feel like IT has them backed into a corner.
The other sense that I get from your statement was that it seemed like you were blaming management here. It feels a bit like, "Well, they didn't keep their IT staff happy, so they brought it upon themselves!" We don't know what the disagreement was, nor who was at fault for that disagreement. People get in disagreements all the time about relatively minor issues. Perhaps Shionogi wanted him to do something one way and he wanted to do it a different way. That's certainly not worthy of revenge. Right now, we just don't know. The simple fact remains that Mr. Cornish committed an act that was unethical and illegal and did substantial damage to the business. Yes, poor management controls and practices allowed this to take place, but they weren't the ones who committed the act.
I wouldn't blame management for the damage, but it certainly is foolish to not take proper precautions when firing IT staff with administrative access. The damage a disgruntled IT employee can cause these days is akin to burning a building down 20 years ago - you could lose everything.
Get a web developer
Yes... it's the "how can you get away with it?" question that boggles the mind. If you can't think at least that far ahead, then you should refrain from doing more than "wish damage." (You know, I wish something bad would happen to them because I hate them kinda thing?)
If it were me, I would do something more subtle... something based on a cron job perhaps ... something that runs, clears out logs and other things, mounts VMDKs, deletes random files, exchanges the file names of various random pairs of documents and things like that. It would be weirdness that people would dismiss at first as human error which give the trail time to grow colder and bad backup data to get worse and then at some point just go all-out, destroying itself and the systems -- preferably killing the hardware in some way. Even then the chances of getting caught are pretty good as it would be a careful balance of luck and planning to create this gradual corruption of data that wouldn't go noticed until it was too late... perhaps only corrupt files older than a certain date which are not as likely to be accessed for a long while.I suppose that would be enough to allow the corruption of backups and such along the way...
Anyway, the first thing should always be to plan not to get caught or even suspected.
...make it impossible for some elderly people (along with some kids with cancer, and perhaps a few diabetics) to get their meds.
Oh yeah, and incidentally, cost my employer money.
Douchebag of the Year Award candidate.
I am very small, utmostly microscopic.
Here is one small step that was taken by a high end hosting provider
All the systems had locked root passwords; nobody knew the actual root passwords; and they were different for each system.
All root is done via sudo except for the system console, which is in the locked server room
To gain sudo access, this is what happens
First you go onto a secure database that is tied in with the trouble ticket system. You log in using a token. You request root access to server x. The system checks to see that you are supposed to be able to have root for server x and it checks to see that you are working on a currently open trouble ticket for an application on server x.
If the secure database is happy, it sends a message to another secure server (in a different machine room). That system, which has yet another secure database, pulls an ssh private key from the database, installs it as a ssh private key in order to do an ssh shell session with the server you want to get on. That session runs a script that changes the /etc/sudoers to add your name. Along with that, it sets off a cron job that forces the /etc/sudoers fill back to its original configuration after a set ammount of time.
You log in, do sudo, and do your stuff. All logging is done to what I call a toilet paper machine (paper log) in yet another secure room. You are through and log off. You close the ticket. The entire process as described above is done but to restore the /etc/sudoers file back to the way it was. Even if you 'forget' to close the ticket, the timer cron noted above will still revoke your access to sudo and send an email to security.
The secure database servers noted above, each located in its own secure location, require two people authentication to access root. For those machines, the root password is split in half. One half is known by each of two key people. They both need to log in at the same time.
This is about the most paranoid root access that I am aware of.
Most Respectfully Yours Mark Allyn Bellingham, Washington