Some Companies Don't Care about Web Defacement

An anonymous reader sent in an interesting link to a story that talks about companies that just Don't care about Defacement. The story is just a light think piece worth a glance. And hell, its the holidays so its not like anything else interesting is gonna turn up to read for a few days :)

Comments

Sounds familiar...

[Chuck Milam]

Gee, this sounds just like a certian company I work(ed) for. They were getting all proud when they bought a package that detected defacements and automatically copied a "known good" version of the web page back in place. Of course, I'm kind of a low man on the totem pole, so my idea of plugging the security holes, so there's no defacement in the first place has yet to make it past my next-level management.

Some take it too far though.

[rmadmin]

I knew a kid in high school that stumbled onto a permissions mistake or something along that lines, he backed up the html, threw up a defacement, and went 'Hahahaha'. A week later the FBI was trying to put the smackdown on him saying that 'By defacing the (Small, 200 customer) ISP's webpage he caused them $17,000 in business and damages'. So a small ISP like that loses $17,000 in business in 4 hours? Unlikely... So does that mean when someone DoS's my workstation and I can't access apache from home for more than 15 minutes I've lost $1062.50?

Re:Some take it too far though.

[dillon_rinker]

My ISP business website has been defaced.

(1) Obviously, there's a security breach. How widespread is it? We need to audit the network and see how severe the breach is and what hole was unpatched. I've got to put either employees or consultants onto it.

(2) We can't trust any code on our network, so the other copy of the web site on this other server may be bad, too. We'll have to check that against a known good copy, which means looking at our backups. Really, we need a known-good historical copy, too, just to be sure, so we've got to pull our off-site backups of the web site from records management vendor.

(3) One of our business clients saw the defaced web page and decided that they didn't trust us to protect their data. They will no longer do business with us. We have lost all of the income they would have provided forever.

(4) As part of our immediate security response, we had to shut down briefly. If someone had hacked our server, they might be trying to punch through to our client machines. Not a huge deal, but we had to issue a month's credit to everyone who complained about being unable to connect.

Add together 1-4, and I think you could easily come up with $17,000. Think about 2-3 net admins + 1 security consultant doing security cleanup for a week.

So does that mean when someone DoS's my workstation and I can't access apache from home for more than 15 minutes I've lost $1062.50?
No, because you are not a business concern. Note that the four hour downtime doesn't mean that all the costs were incurred in that four-hour timeframe. The ongoing security audit that becomes necessary in the event of a hacked server could have gone on for a week.

Are the figures inflated? Possibly. Did the idiot cost the business money? Certainly. Is the FBI playing hardball with the idiot who did it? Undoubtedly. You seem to be missing the point that your friend shouldn't have done it; instead, you are whining that the FBI talked mean to your friend.

Dead On...

[Bonker]

Sayeth the article:

What I am speaking of is investigating and prosecuting the criminal element involved in the act of defacement, root compromise or infection by "worms". In otherwords, companies tend to "fix & forget".

Actually, this is probably the stance that every serious IT department out to take. If your website was cracked, then it's almost certainly *your* fault your server was compromised. There just aren't any rootkits out there that don't exploit known buffer-overflows or other bugs. There are a few situations when this is not the case, but it's usually still someone sitting around testing a web application (like Slashcode) for buffer overflows or back doors.

Even if you do prosecute, it's like stomping cockroaches. There will just be more, and if you hadn't left the food out on the counter to rot, they wouldn't have come to your apartment in the first place.

Finally, there's the human element to contemplate. We all did stupid stuff when we were kids, which most website vandals are. I don't know any kid who didn't tresspass or vandalize property at least once during their youth. For many, it was the old junkyard or the cemetary. For these kids, its websites. Are you really going to put them in prison for decades because they're young and stupid? You might as well ruin their lives for experimenting with drugs or sex....

Oh wait. We do that too. Nevermind.

And this is surprising why?

[dirk]

This stuff doesn't surprise me at all. Companies are in the business of making money. If they report every intrusion that happens, that means other people find out about them (potentially). If people find out, they may be less likely to use that company (or their website or whatever) than if they believe there was never a compromise. I think companies should be forced to report it when there is a compromise that includes user information or something like that, but if it is just a web-site defacement (with no possibility of anything else) I would probably not let it get out either. Add onto that fact that some PHB automatically will assume it is the admins fault, even if they were told not to patch it/didn't have enough money to do it right/were ignored on their suggestions, that measn the less people who know about the exploit, the better off you are. I don't agree with the policy, but it is certainly understandable.

Yep, this isn't unusual at all.

[Anonymous Coward]

For professional reasons, I'm posting this anonymously.

I've worked at one or two places where boxes have been cracked and once the initial panic settled down the word that came down from On High(tm) was to quietly pull the system, disinfect it (but not reformat/reinstall), and return it to service. "This system needs to be available for the developers, we don't have time for you to find whomever did it."

Needless to say, I wasn't real happy at the prospect of putting a questionable system back into active duty. Just because you found the /usr/lib/.../31337^k17 directory and copied back the files replaced by the rootkit does not mean that you've found every last trojan horse or old config file. I'm surprised that the more intelligent kiddies havn't started doubling up their rootkits yet - one which acts as your basic rootkit, replacing system binaries et al, and a second in an entirely different location that they leave in place for situations just like this: If the primary rootkit is removed but the system isn't reinstalled, they've still got a way back into the system and a backup toybox to get revenge with. It wouldn't take much at all.

Not to rip on Redhat exclusively, but with all the RH servers popping up these days I'm surprised that the newer rootkits aren't being passed around as .rpm files. No muss, no fuss, but the sysadmin would still notice if (s)he did a verification from the install CD-ROM.

At the end of all of it, I did what they asked me to and put the box back into service. I'm reasonably sure that I swept the system clean but you can't prove a negative, you can only state a negative to within a certain tolerance. For all I know, the backed up system binaries I'd found and put back into place were trojans as well and the originals had long since been overwritten.

But that's in the past now.

And maybe not

[r_j_prahad]

I think a lot of companies would care if they could afford to, they've just made a business decision not to go after this sort of thing. Investigations can take months, and prosecution can take years. What responsible CEO would be willing to commit those resources to a process that won't yield a cash return? How much money do you think Intel got back from Randall Schwartz?

I, for one, cannot afford to have my servers collecting dust in an evidence locker while I rearrange my business schedule around interviews, depositions, and testimony. Sorry folks, but yes, I'd bury it and forget it.

Re:Simple solution

[Hiro Antagonist]

How about running web servers booted off cd-rom getting all of their content dynamically by calling java servlets against a remote machine using the secure xfer methods covered in yesterday's secure credit card transfer discussion?

There are a couple of good reasons why this unlikely to be a workable solution. First, this requires almost double the equipment (a two-tier minimum), and it requires the front-end servers to have some type of read-only storage, which most server appliances (like the Netra X1) don't have.

Second, keeping the systems patched and up-to-date (which will still be imporant) is even more of a chore, as you can't just install patch foo -- you need to install the patch on a clean system, make a bootable CD, and then go physically insert the CD and reboot the machine to install the patch. In terms of administrator time, this is completely unacceptable.

Third, it requires that you use JSP (and possibly EJB); things like PHP and Perl won't work with this kind of set-up. As nice as JSP+EJB can be for building complex and stateful web applications, it's really lousy for doing simple things like customer-feedback forms and the like.

Fourth, the applications on the second-tier server are still open to exploit, as is the OS on the external server -- it's possible to crack and root a machine even if it has a read-only root filesystem.

Fifth and finally, it completely violates the KISS principle (Keep It Simple, S*). More machines means more overhead for the admins, higher operating costs; and, most importantly, a more complex system. One of those little rules-of-thumb is that the more complex a system becomes, the more easily it will fail.

Something like a serial cable into the "servlet server" with a non-TCP/IP listener on the serial port. At max speed 115KB serial is like a 1Mbit connection. The web servers won't have IP access to the content server, and can't be defaced. Don't have to care about snort logs, tripwire -- all that happy hoo ha.
Want to run a bunch of web servers for load balancing? put an 8-port digiboard in the servlet server.


I fail to see where a 115Kb/s serial connection is equal to a 1Mb/s link; I would suggest checking the numbers again, as I'm pretty sure that the latter is about ten times as fast as the former, and requires less processor overhead -- serial connections consume much more CPU time than ethernet ones.

Snort and tripwire are very useful tools, and whether or not you have a "secure" setup, it's a good idea to run them. Snort is an extremely capable IDS (Intrusion Detection System), and if your uebersecure system is cracked, can provide valuable logs to find the attacker (and the original security hole). Furthermore, it's always a fun thing to watch the IIS exploit attacks pile up against your smug little Apache server...

HTH. HAND.

Management education of the legal consequences

[satch89450]

After reading the link for this story, I was amused to see that things really haven't changed in a number of places. Management doesn't worry about Web site security until it hits them where it hurts, their liability insurance premium, or when the executives spend some time in the cooler.

The majority of defacements I've seen described involve little more than vandelism, electronic tagging by lower lifeforms of script kiddies, that do very little harm to the company whose site is defaced. You "wash the walls" and go on. End of story.

Except that it isn't the end of the story.

What happens when the defacer decides to use your Web site to store a couple hundred cracked credit card numbers? How about the 600 MB of MP3s of copyrighted music material that appears in its own directory of your Web server? The kiddie porn? Can you imagine what would happen if a terrorist cookbook were to be uploaded to your site, given today's paranoia caused by the November 11 terrorist attack?

IANAL, but I recall the Mogur-BBS debacle when a BBS system was used to traffic in telephone calling card numbers. Some facts are missing from the account the link points to, but it's sufficiently accurate to be useful. Here is another account of the incident. Here is a more thoughtful retrospective and analysis.

Shall I bring up the episode of Steve Jackson Games as an indication of the kind of risk that operators of public computer systems face when security is not a primary concern? Steve Jackson Games is apparently alive and well (and probably mad as hell about being mentioned in a Slashdot article) so the news isn't all bad, but the six months they were effectively out of business -- the publishing business -- must have hurt and hurt badly. Granted, the Secret Service has learned much since that 1990 fiasco, but can you imagine the long arm, and the long flatbed truck, coming and taking your computer systems because of the acts of some malicious script kiddie who does more than tagging?

Can your company afford to have its Web servers siezed and perhaps damaged because of the illegal acts of non-employees?

What you can do: tell your manager to contact your company's general legal counsel and request they research the legal liability, and the practical effects of law enforcement action, resulting from illegal acts committeed on public servers that have inadequate security controls. Emphasize that the research include short-term effects such as equipment seizure and forceable removal, damage inflicted during such action, and the expense of obtaining the timely return of the equipment.

If you run an e-commerce site, also be sure to ask about legal exposure in the event any web server containing crdit card records, customer information records, order histories, or credit search information is compromised and the information released to unauthorized people.

Steve Jackson Games was almost put out of business based on a bogus rumor. How would your company survive the legal onslaught from a script kiddie interested in more than just defacement?