Predictability Can Be Fatal

Share it on Twitter  
Share it on Facebook  
Share it on Linked in  
Hey, Baby, where'd you get such a great set of settings?

When I was still in my formative years, I (like most otherpost-pubescent males) was always hunting for the magical key toyouthful bliss. There just had to be a common vulnerability -- the rightline, the right look, the right attitude, whatever -- that the vastmajority of the opposite sex would instantly fall for.

Although some claim to have, I never found it.

For some reason, every young lady that I came across had somethingunique about her. Whatever ploy, tactic, or stroke of dumb luck I foundmomentary success with once, failed miserably on the next go around.Were they secretly plotting against my teenage happiness? Was there aconspiracy involving all young womanhood?

No, there was just one little thing that kept it challenging -- kept theplaying field pretty level for all of us mere mortal boys. Everyone istheir own individual person, with their own impressions, likes,dislikes, values, and moral structure.

To put it in geek terminology: There is no default configuration amongstwomen.

Monoculturalism revisited

When Dan Geer, Charles Pfleeger, et al. last fall released theincendiary report, ''Cyber Insecurity: The Cost of Monopoly'', quite afew folks perked up, including Dr. Geer's employer.

In the report, this team, which was made up of some of the world'sforemost authorities on security, present a powerful argument againstwhat has become the status quo in much of the corporate and governmentIT realm.

To make a long story short, the report claims that Microsoft's dominancehas created a global target environment that leaves little guesswork forthe bad guys (girls, things, dogs, whatever) while the good guys findthemselves in ever-shortening supply, trying to defend increasinglycomplex, yet predictable, systems.

That, predictability, can be fatal.

Referring to Nimda and Slammer, they wrote, ''These worms did not haveto guess much about the target computers because nearly all computershave the same vulnerabilities.''

Let me say that the problem that's going to have you pulling your hairout when the next virus/worm/rootkit hits the streets, ispredictability.

Defaults. That's the ticket in. That's what the worm authors are banking on. Nimda relied upon them, and so did Blaster, SQL-Snake,Code Red, and nearly every other self-propagating beastie since theMorris Worm hit the wild 16 years ago.

Here's a look at some of the default conditions that a few mass attackstook advantage of:

  • 1988: Morris Worm -- Sendmail DEBUG enabled, fingered running, C compiler present (Unix);
  • 1999: Melissa -- Outlook mail reader uses MS Word, macros enabledin Word;
  • 2000: I Love You -- Windows Scripting Host enabled, ActiveScripting enabled (Windows/IE);
  • 2001: Code Red -- .ide/.ida bindings in IIS;
  • 2001: Nimda -- Sharing enabled, scripts/vti_bin/msadc dirs allow execution:
  • 2003: Blaster -- RPC/DCOM interface enabled;
  • 2003: Slammer -- MSDE 2000 installed and network enabled by many products, and
  • 2004: W32/Bobax -- UPnP enabled (used for target identification).

    Across the board, no firewall was enabled... by default.

    Now, we're not going to delude ourselves into believing that automataare the only things that ail our information systems. There are plentyof other information warfare tactics that are equally, if not more,destructive and costly. But worms sure take a bite.

    Off the top of your head, how many hours have you or your staff spent oncleaning up the past year's worth of pseudo-randomly targeted attacks?

    Continue on to hear how being different, and even being obscure, can be your biggest weapon against attacks.

  • The value of obscurity

    A few years ago, I wanted to make some code available to others via aweb-server on my home DSL-connected network. The provider, however,being more security-minded than most, blocked incoming port 80 SYNpackets to residential net space. No problem. I merely configured myweb-server to listen on port 81, and I made sure that the URL I posted,and linked to, and emailed about, looked like:http://www.mydomain.dom:81/.

    Funny, I never saw a single web attack come my way. Security throughobscurity? Nope. Fewer annoyances through obscurity? Yup.

    Plenty of sites are doing it. Why not you? IMAP mail on port 10143,secure shell on port 2222, etc. Of course, you don't want to make a tonof extra work for yourself administering all this non-standardization.RFCs and the IANA exist specifically to promote standards ofinteroperability. Flying in the face of them is going to cost you if youcare to interoperate with users, and systems and processes that aren'tfamiliar to you.

    Every one of you is free to build your own net the way you see fit. Justdon't expect anyone else to have a clue about how to communicate withyou -- not even the bad guys.

    Back in the glory days of Novell IPX-based LANs, I was a big fan ofkeeping TCP/IP off of client systems and using IPX/IP gateways toconnect to the rest of the world. There wasn't a single IP-based wormthat would stand a chance of propagating inside the net. That came at acost, of course, of efficiency and convenience.

    Efficiency, convenience, interoperability... I sound like an ad-man fromRedmond! Truth be told, no one ever noticed any productivity increaseafter migrating to an all-IP network.

    Sound system and network administration often lends a measure ofobscurity by modifying, updating or removing conditions expected byattackers.

    Few worms are monolithic. Instead, they take advantage of the DLLs,commands, directories and other components that the author knows isgoing to be present on your box. Modern versions of MS Windows oftendon't allow you to remove ''critical system files", but you often canremove the filename extension mappings that load them.

    Bingo! We've just defeated Code Red without patching.

    Whenever the Morris Worm encountered a system that had its C compilerremoved, it couldn't build its tools, rendering it unable to propagate.Period.

    Recently, I was looking into why some User Mode Linux based honeypotsweren't vulnerable to most buffer overflow (BOF) attacks. Turns out thatthere were extra environment variables being passed along by the kernelto the running services. This made the execution stack addresses ofthose services different from those expected by the attack authors.

    As an experiment, I took a stock Redhat Linux 6.2 system, unpatched, andbooted it with an extra unnecessary parameter. This did what I expected.It offset the stack addresses a bit, and three out of four attacks Ithrew at it failed. Not bad, considering I didn't have to do anythingcomplicated.

    More elaborate stack randomization techniques are used by OpenBSD,grsecurity and others, all serving to obfuscate reality.

    Obfuscation techniques are only worthwhile as long as your adversary is unaware of them. Once a skilled, determined attacker gains knowledge ofyour ''customized'' environment, the benefit of it is mostly lost.However, by clouding the field, you are less likely to be dealing withthe latest worm-du-jour, and can dedicate resources to handling moreserious incidents.

    Know What You've Got

    Sure, there are quite a few operating systems and products that do itthe right way. OpenBSD, Novell Netware, GentooLinux -- they all share a common thread. They don't turn all kinds ofthings on by default. Even Windows Server 2003 installs with several of the old standards (like IIS) turned off. Heck, some of them even come with industrial-strength firewalls. Cool!

    Unfortunately, none of them are right for my mother. Even if I couldconvince Mom and Dad to drop a few gigabucks on a modern commercial OS,or to eat up the better part of their retirement years on asecure-out-of-the-box open source installation, they would screw it upby downloading the latest painting package, racing game, MP3 player orwhatever, that renders the box wide open.

    We've been demanding convenience for so long that software and OSvendors have geared up to provide it by the bucket-load. In time, homeusers will demand security and stability. Won't we?

    It is essential to know what is on ''by default''. Part of any sound configuration management scheme is baselining and validation. And thatshould include sandbox scanning and monitoring.

    Can you justify the expense of responding to a root compromise becauseyou trusted the vendor's defaults? Try taking them to court to recoupyour costs.

    There are plenty of tools to help you baseline your systems and remove unnecessary defaults. A great starting point is the Center forInternet Security's site: http://www.cisecurity.org. There are CISbenchmark tools available for most operating systems, including CiscoIOS.

    Linux, MAC OS-X and HP/UX users have Bastille hardening scriptsavailable at: http://www.bastille-linux.org, which walks you through theprocess of locating and remedying many default security pitfalls.Windows shops should already be using the Baseline Security Analyzer andthe MMC Security Configuration and Analysis snap-in.

    And just maybe someone will develop a tool to analyze the configs of thefairer gender by the time my son hits high school. Nahhh, let him sufferlike the rest of us.

    George Bakos is a Senior Security Expert with the Institute for SecurityTechnology Studies at Dartmouth College. His research includes wormdetection and intrusion analysis. Bakos formerly was a security engineerfor Electronic Warfare Associates.