Dumb and dumber – Legendary bloopers committed by IT admins

For those of us who make our living behind a keyboard in IT, it’s hard to imagine a more time-tested vulnerability than the end user. Armed with network access, these IT viruses wreak havoc nearly everywhere you look – havoc borne of tech idiocy.

Of course, not all computer users live to cause mayhem, sowing the seeds of destruction in our metaverse, merely by clicking every last Storm worm variant that appears in their in-boxes.

In fact, sometimes the worst offenses spring from our own ranks, hatched by individuals whose stated mission is to help technology work better: the IT admin.

For the most part, we IT folks toil away unsung in often miserable conditions just to make workplaces more efficient, secure and supportive of end-user needs. But then, a few of us – well, we can be caught doing some really dumb things.

It’s only fair that we turn the spotlight inward to expose a few legendary IT brain farts committed by those who are paid to know better.

“Preconfiguring PCs with Stone Age malware” Incident:

Toward the end of 2006, several high-profile consumer electronics companies — both makers and retailers — ended up with egg on their faces when reports surfaced that they were shipping to consumers devices infected with malware.

Apple’s Video iPod and several models of digital photo frames were found to be infecting the computers of unsuspecting users the first time they were plugged in. The risk associated with those infections was significant. In the end, however, the damage was limited.

A year later, though, that wasn’t the case. In September 2007, German computer maker Medion announced that as many as 100,000 laptop computers sold through Aldi superstores in Germany and Denmark came preinstalled with Windows Vista, the Bullguard antivirus program — and a virus.

The case could have been devastating for the privacy or information security of anyone who bought one of the laptops.

Modern malware, highly adept at stealing information such as bank account log-ins or credit card numbers, poses a real risk to consumers and companies alike.

Only it wasn’t, because the virus, Stoned.Angelina, dates back to 1994, a full year prior to the launch of Windows 95, let alone the advent of widespread Internet access or online commerce.

Thankfully, Stoned.Angelina isn’t a particularly dangerous virus, at least not to anything more recent than DOS.

It’s a boot-sector virus that replicates itself by copying itself to floppy disks. Remember those? The Medion laptops didn’t even have floppy drives.

Medion never said exactly how this historic malware relic ended up in the default image on so many laptops. In the case of the iPod and photo-frame infections, the malware came from an infected machine in the factory in China that assembled the final products and installed the software onto the devices’ internal storage.

When you consider just how difficult it must be to load Stoned.Angelina onto a modern computer, you get a sense at how boneheaded the IT guy would need to be in order to infect a drive image used in tens of thousands of hard drives.

Fallout: With no way to spread and no effect whatsoever on Windows Vista, Stoned.Angelina took its toll mainly on Medion, making the company a laughingstock. The punch line: Even though the machine came preloaded with an antivirus app, the antivirus engine couldn’t clean the system. Bullguard later released a repair program that cleaned out the boot sector, just in case you someday, somehow found a floppy drive that worked with the laptop and inserted a disk.

Moral: One, don’t let the guy running an old copy of DOS on his computer build your drive images. And two, if you’re going to deliberately infect thousands of computers, pick malware that’s actually going to do something.

“Oh, you wanted to recover those backups?” Incident:

Suppose your company’s mission was to inform others about the business of technology. Surely you’d want your own IT operations to be above the cut, if only to maintain a modicum of credibility with your readers.

In one of the more amazing not-practicing-what-you-preach stories of recent history, the editorial and design staff of tech-centric Business 2.0 somehow managed to lose its entire June 2007 issue to a hard-drive failure on its editorial server sometime during the night of April 23, 2007.

As wrenching as it must have felt for its editorial staff to realize that a month’s worth of work was gone, that sinking feeling in the pit of the stomach must have been compounded by its status as a standard-bearer for sound data-protection practices, including frequent and comprehensive backups.

Well, at least the Business 2.0 IT staff did the backup part. What they never seemed to do was the restore part, as a test to make sure the backups were readable and that they worked. And that’s exactly what failed when the admins tried to recover from the catastrophic crash.

Fallout: As for the editorial content of the issue, it turned out that the lawyers had copies of every article in a final, copyedited state. But the layout and design of the magazine had to be re-created from scratch. A heroic effort from Business 2.0’s art department saved the day and got the magazine produced (reproduced?) in record time, on deadline for press.

Moral: As any halfway sensible IT person will tell you, it’s not enough just to back up the data; you also have to test those backups periodically to make sure they actually work.

“Soup of the day: Social Security numbers” Incident:

Throw a bag of the finest steaks into a piranha-infested river, and you’ve got no right to complain when the fish make quick work of it.

In a sense, that’s what happened when a 15-year-old freshman at Downingtown West High School stumbled upon and then copied files containing highly sensitive personal information — including Social Security numbers — of roughly 41,000 current and former students, families and other town residents.

Similar because, as the district admits, the sensitive data was placed in a completely unprotected part of the school’s computer network by a member of the district’s IT staff. More than that, the admin had stored the files in a network segment to which students had access.

Whereas the student was charged with three felonies and one misdemeanor computer crime for copying information left nearly in plain view, the admin is considered guilty of nothing more than a brain-dead IT gaffe.

For what it’s worth, the town’s police determined that the student merely copied the data to a portable drive and gave only one copy to another student, who is cooperating with the police. That hasn’t dampened the witch hunt, however, as several parents and residents are calling for the student to serve jail time.

Why the district was collecting the Social Security numbers of residents for the purpose of sending them newsletters, however, has not come under scrutiny. Nor has the lack of safeguards IT placed on that information.

So negligent was the IT handiwork that, according to school district spokeswoman Pat McGlone, the student “did not need to crack any passwords, evade any firewalls or blow down any doors, so to speak. He just simply needed to be curious and bored,” as Will Hobson wrote in the Philadelphia Inquirer.

And if boredom is all it takes for a teenager to expose 41,000 Social Security numbers, you know your approach to IT isn’t smart.

Fallout: Fortunately for the student, cooler heads prevailed at the Chester County deputy district attorney’s office. The student won’t face prison time. The district, on the other hand, has had to scramble to send out 16,600 letters to residents warning them about the potential for identity theft and has rushed to better secure its network and this sensitive data.

Moral: Maintaining a highly sensitive database requires encryption — especially where bored teenagers are allowed to roam. In fact, keep your stored Social Security numbers off the cafeteria lunch menu portal altogether. Oh, and rather than just pillory a tech-savvy 15-year-old for taking advantage of an open door to sensitive personal data, lay equal blame on the IT worker, as well as the person in charge of collecting and protecting the database.

“The tool and the toolbar” Incident:

Being part of an online community can reap rich rewards. Allowing the tools that fuel those communities to wreak havoc on your company Web site — well, that’s probably not what you had in mind.

Of course, when it’s your boss who is insisting on tapping those tools, sometimes you have to buck hierarchy and sneak behind his back to help him toe the prudent IT line, as the administrator of a business-to-business Web site quickly found out.

The tool in question was a toolbar called Alexa, which tracks the surfing habits of its users and spiders Web sites to build a ranking system for comparing the popularity of Web sites. The admin debated the value of the toolbar with his boss often, though perhaps “debate” is too delicate a term.

“I told him time and again to uninstall it, and even did so myself a number of times, but he’d put it back every time,” the admin says.
“Then, one day, all dynamic content on the main page [of the B-to-B’s Web site] just vanished. I brought it back from backup and chalked it up to a bug. Then it happened again a little while later. I started snooping around our logs,” he says.

As it turns out, Alexa’s spiders had been ignoring the robots.txt file — and were instead capturing usernames and passwords.
“It logged into the administrative area and followed the ‘delete’ link for every entry,” the admin says. “My dumb-ass boss still didn’t want to uninstall Alexa — could have strangled the man.”

Fallout: The data was restored, with some difficulty, and Alexa’s spider was prevented, through other means, from accessing the administrative side of the Web site.

Moral: When confronted with the classic pointy-haired boss, Machiavellian subterfuge sometimes becomes necessary. Try using the Image File Execution Options registry key to prevent Alexa — or whatever undesirable, dangerous or obnoxious program he or she keeps using to make your life miserable — from running.

“Let’s just call it ‘boot.ini’ ” Incident:

Although not as wildly popular as World of Warcraft, the massively multiplayer game Eve Online has developed a dedicated global following in its first five years of existence. But even its most ardent supporters had to roll their eyes at the screw-up the game’s developers perpetrated on players this past December.

As part of a patch the company called “Trinity,” developers offered an optional graphics update. But instead of the promised dramatic improvement in the visual appearance of massive spaceborne warships and other in-game graphic elements, some players who installed the patch received an unpleasant surprise.

The developers used a file named “boot.ini” as the configuration file for the update — and an unfortunate extra backslash in the installer for the update. As a result, the installer overwrote the boot.ini file in the root of the C: drive that Windows uses to start up the computer, and then deleted itself after the patch was applied. When some players rebooted, Windows reported an error. A few PCs needed a Windows CD to affect repairs.

Fallout: In the end, the problem affected only a subset of players running certain versions of Windows. Moreover, it was easily reversible, though if you can’t boot up your computer to Google a fix, you’re kind of stuck there, chief.

Moral: The boot.ini botch is inexcusable. Having been located on the root of the C: directory since Windows 3.1, it’s not like it’s a little-known file. In other words, keep your platform knowledge within a decade of the latest developments, and never name your files after anything that appears by default on the root of the hard drive in Windows.

“Paging Dr. Data Breach, please come to the IT morgue” Incident:

Bringing down your fundamental means of protection simply to perform a data migration is one kind of stupid; forgetting to put it up again is monumental.

That’s what admins from an IT firm called Verus did. And by “called,” I mean “now out of business.”
To transfer data from one server to another, the admins disabled the firewall, then left it disabled, potentially exposing the personal financial details of more than 91,000 patients of at least five hospitals nationwide to anyone who happened by.

The five hospitals — three in the Pacific Northwest, one in Indiana and one in New Hampshire — reported that the problems originated from the Verus-operated bill-paying service each hospital used. The earliest breach was announced in late May 2007, the latest in late July.

The affected hospitals, which may have numbered as many as 60 in total, canceled their contracts with Verus as soon as the breaches were discovered. By August, Verus was out of business.
Initially, the incidents were each thought to have been isolated. The true scale of the goof was not known until Medseek took over the Verus contracts at many of the affected hospitals, a Medseek executive explained.

Fallout: According to published reports, there has been no criminal misuse of the data since the screw-up. Verus, of course, paid the price for its idiocy with its corporate life. The company was mothballed so fast, nobody knew what happened.

Moral: If you disable your network’s fundamental protection measures just to migrate data from one server to another, you’re doing it wrong. And for Pete’s sake, if you’re going to turn off the corporate firewall for any reason, be sure to turn it back on again.

Share on LinkedIn Share with Google+