Steve Riley on Security : threats

Blamestorming

Steve Riley — Fri, 12 Sep 2008 09:03:42 GMT

So, let's recap the sequence of events:

The Sun-Sentinel newspaper in Fort Lauderdale accidentally republishes a six-year-old news story about the bankruptcy of UAL. It wasn't on the home page, but instead buried somewhere inside the web site.
Google's news crawler (an automated thing, remember) finds the story and incorporates it as part of its news feed.
Investors see the story, and immediately react. When UAL's stock plunged 76% to a low of $3, Nasdaq shut down trading. Eventually trading resumed, and the stock closed at just under $11, losing about 11%.
United blamed Tribune Company (the owner of the Sun-Sentinel) for "irresponsibly" changing the date on the story and demanded a retraction.
Tribune Company blamed Google, claiming they've had issues with Google's crawler "for months."

Who will blame be shifted to next?

Look -- if people haven't realized by now that the Internet pretty much lacks a delete function, then (IMNSHO) it becomes the requirement of each and every one of us to pay close attention to what we're reading, to use our own big brains and fine-tuned bullshit detectors to suss out whether something makes sense.

Since this is my blog, I'm going to parcel out blame the way I see it:

United: 0%. If the concept of "negative blame" made any sense, then I'd actually write −∞ (that's a negative infinity, in case your character set is different than mine).
Google: 5%. How can an automated crawler know that a newly-dated story isn't really new? Well, those folks over there at Google are smart. Certainly it shouldn't be that difficult to compare a "new" article against existing ones. Content hashes won't work as a comparison tool, because the date would be included in the hash computation, thus making the hashes different anyway. Full-text comparisons? Sure, it would take a lot of horsepower. Perhaps not every "new" story needs comparison, but at least the crawler could submit to the comparator any stories that ought to be verified (say those with the word "bankruptcy" in them).
Tribune Company: 30%. Hey guys, you changed the date on the article. Don't go blaming someone else for your screw-up.
Investors: 65%. If you're using an automated news aggregator (remember, an aggregator is not a source of news) to make major financial decisions -- decisions that affect the livelihoods of thousands (maybe millions) of people -- well, you're a moron. You should know that incorrect information can be just as instantly available as correct information. Verify potentially damaging claims before engaging in reckless behavior.

What's this got to do with security? I don't know, maybe nothing directly related. But it certainly raises the question -- what if someone intentionally wanted to cause nearly permanent damage to a person or a corporation? Malicious content, disguised as "news," certainly seems to have become a potentially successful attack vector this week.

Worried about a social engineering attack on a massive scale? I suspect that what happened Monday (8 September) was the largest social engineering attack in history -- although I wouldn't classify it as intentionally malicious. Just you wait until the idea spreads.

Throw away your digital picture frames

Steve Riley — Tue, 19 Feb 2008 06:36:00 GMT

Surely time itself has warped and it's suddenly April 1st. Come on, if you read the following, wouldn't you first think it was a hoax, as did I?

Virus from China, the gift that keeps on giving

An insidious computer virus recently discovered on digital photo frames has been identified as a powerful new Trojan Horse from China that collects passwords for online games -- and its designers might have larger targets in mind.
"It is a nasty worm that has a great deal of intelligence," said Brian Grayek, who heads product development at Computer Associates, a security vendor that analyzed the Trojan Horse... The authors of the new Trojan Horse are well-funded professionals whose malware has "specific designs to capture something and not leave traces," Grayek said. "This would be a nuclear bomb" of malware.

Mocmex is its name. Reportedly, it can evade hundreds of anti-malware and firewall products, including the Windows Firewall. I suspect that this succeeds only when users are logged in as administrators, so here's yet another reason to stop doing this altogether, as is the US Government with its new Federal Desktop Core Configuration for Windows XP and Windows Vista.

The virus actually propagates to just about any kind of removable USB storage device, jumping from various well-concealed hiding places on your PC whenever such a device is inserted. Picture frames are implicated because the virus apparently originated in the factory where the frames were built (in turn sold by Best Buy, Sam's Club, Target, and Costco, but now discontinued). Amazingly, according to the UK security firm Prevx, over 67,500 variants of this thing exist!

Even more amazing:

[Mocmex] isn't the only piece of malware involved. Deborah Hale of Sans said the researchers also found four other, older Trojans on each frame, which may serve as markers for botnets -- networks of infected PCs that are remotely controlled by hackers.
There is W32.Rajump, which deposits the same piece of malware that infected some of Apple's video iPods during manufacturing in October 2006. It gathers IP addresses and port numbers from infected PCs and ships them out, according to Symantec. One destination is registered to a service in China that allows people to conceal their own IP addresses.
Then there is a generic Trojan; a Trojan that opens a back door on PCs and displays pop-up ads; and a Trojan that spreads itself through portable devices like Mocmex does.

More reasons to disable Autorun, I suppose. Yet this isn't a cure-all: if you're logged in as administrator, the virus helpfully re-enables Autorun. Sheesh! If you own one of these frames, SANS suggests that you take it to a friend who has a Mac or Linux box and plug it in there. Yeah, that's good advice; there exist no viruses for these operating systems, correct? It's irrelevant which operating system you're using -- if you run with full privileges, you'll get 0wn3d soon enough.

It's fascinating that the thing targets online games, although it could certainly harvest just about any private information stored on your PC. Mining online game accounts might be pretty profitable, you know. Consider the number of people who pay real money for virtual (=fake) stuff in World of Warcraft, Runescape, and whatever else. I suppose losing their passwords to picture frames might help such people regain a tenuous foothold on reality.

More on Autorun

Steve Riley — Wed, 31 Oct 2007 01:12:27 GMT

Last month, in my post "Autorun: good for you?" I described why I believe you should disable Autorun on all computers in your organization. I also explained how you can do this for XP and Vista computers.

Well, it turns out that Windows will override this setting if you insert a USB drive that your computer has already seen. I received an email from Susan Bradley that links to an article on Nick Brown's blog, "Memory sitck worms." Nick mentions the MountPoints2 registry key, which keeps track of all USB drives your computer has ever seen. I'll admit, I didn't know this existed! I'm glad Nick wrote about it, though.

Nick also includes a little hack that effectively disables all files named "autorun.inf." Interesting, but something in me prefers to make Windows just plain forget about all the drives it's seen. So now I will amend my instructions. In addition to what I wrote earlier, you should also write a small script, and execute it through group policy, that deletes the following key:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2

When I searched for it in my registry, I also found a few others, so maybe you'd want something that would search through the registry and delete them all, although I don't know if such a tool exists -- I've never had a need to look for something like that.

Autorun: good for you?

Steve Riley — Sun, 23 Sep 2007 08:29:48 GMT

Yes, if you're a five-year-old and you're tired of always asking mom or dad how to start the game on the CD. No need to know how! Just pick up the disc (a little peanut butter on your fingers helps with the grip), slide it in the drive, and wait for the game to start. Groovy!

No, if you're a security administrator. Many people still aren't aware of the security risk that autorun raises. It isn't new anymore, but DarkReading's Social engineering, the USB way is still the best story the make the point. Check it out.

I really can't think of any business reason for keeping this feature enabled. Please shut if off, domainwide, as soon as you can.

In Windows Vista/Server 2008, go here:

Computer Configuration | Administrative Templates | Windows Components | AutoPlay Policies

Enable the "Default behavior for AutoRun" policy and set the default to "Do not execute any autorun commands."

Enable the "Turn off Autoplay" policy and set it to "All drives."

In Windows XP/Server 2003, go here:

Computer Configuration | Administrative Templates | System

Enable the "Turn off Autoplay" policy and set it to "All drives."

While this might be old news for many of my readers, disabling autorun still doesn't seem to be a common security mitigation. At a recent conference I was surprised at the number of folks who haven't considered the risks of leaving it enabled. Surely by now most of you have heard about how certain music CDs can spread rootkits in your network. Yeah, holding down the [Shift] key when inserting a CD-ROM or USB drive will bypass the autorun.inf file -- but do you really want to rely on individual users remembering this? Nope. Group policy is your security friend: put it to good use here and disable autorun right now.

(BTW, Sony is up to their dirty old tricks again.)

Updated, 22 September 2007. Turns out there's a registry key that keeps track of all USB drives your computer has ever seen, and this key will override the Autorun settings if you insert a drive that your computer has seen before. So in addition to changing Autorun, you'll also need to delete this other key. Write a little script and call it from group policy. Here's the key to delete:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2

More details here.

When you say goodbye to an employee

Steve Riley — Thu, 31 May 2007 21:29:45 GMT

...what do you do with his or her account? Recently this question came up -- someone was asking for guidance on how to handle this very situation. And, as often happens, the question was more about process and policy than anything to do with the technical issues of account management.

Those of you who've followed my writing and speaking will agree when I admit that I've become somewhat of a policy wonk over the past few years. Awhile back I spoke at an executive event in Taipei. I asked this question: "Who here can claim that their network is completely secure?"

Much to my surprise, a gentleman in the front row said "I can."

I honestly wasn't expecting that answer, so I decided to probe a bit. "Really? Wow. That's cool. How can you know that?" I asked.

His response: "Because I've installed every security product I can find."

...uh...hmm...it's unusual for me to be at a loss for words! But sensing a teaching moment, I talked for a while with the audience about risk assessment, about business drivers as the source of policy and process, and about technology as the implementation of some (but not all) process. It was a good conversation, one I've had many times since then.

You can twiddle all you want with various pieces of technology, but unless you have well-tuned processes that derive from policies reflecting the needs of the business, then your technological efforts are wasted. Very likely you'll end up focusing on threats that don't exist while ignoring those that can seriously bite you.

There are some elements, though, where you really don't need to worry so much about extensive process or looking to map from business drivers to policy to process. One of these is what to do with the accounts of ex-employees. While people become ex-employees for a variety of reasons, there's really only one threat that exists: all access by ex-employees is by definition unauthorized access. So as I see it, there's actually a very simple process for handling their accounts, and here it is:

Immediately disable accounts when users quit, get put on probation, or are fired
Delete these accounts when you no longer need them for recovering data

There's certainly no business requirement for keeping an ex-employee's account active. That's why you should disable it right away. If you instead immediately delete an account, you've made it nearly impossible to retrieve information that the employee has encrypted. The default recovery agent is a backup for EFS, but you need to have configured it correctly when you implemented EFS. However, for S/MIME there is no backup. Plus, in case you need to conduct any kind of investigation, you might need to log in to an ex-employee's account. So to be safe, disable it -- but keep it for a while.

Only after you're certain that you won't need it anymore can you then delete it. You don't want it to hang around forever, because for so long as it exists, it's something you have to manage. So when you're finished with it, after you've completed any investigations and have recovered whatever data you need, get rid of the thing. Now you can forget about it.

I see two remaining considerations. The first: it's up to you to determine the time interval between disabling and deleting. Here's probably the only point worth some thought in this process, and it's mostly about responsiveness. How much time can IT give the business units for completing an investigation and recovering data? Perhaps you'll have two time limits:

one for when no investigation is required (say 30 days for general collection and clean-up)
one for when there is an investigation (it's out of IT's hands, let the legal department decide -- but the duration should never be infinite!)

The other policy/process consideration is determining what data of the ex-employee to keep. I suppose "keep it all" would be one choice...but do you really need all the MP3s and porn that guy has collected? Unless you're investigating resource abuse, probably not! Here's an opportunity for you to work with the business units to decide -- most likely on a case-by-base basis -- which data to keep and which to discard.

Handling the accounts of ex-employees is pretty simple, really. So don't get too mired in arcane process work here. There's far more important work you need to be doing.

Yes, everyone knows you're a dog

Steve Riley — Thu, 07 Sep 2006 18:17:00 GMT

Amazing how long the legs are on the AOL search debacle. Of course, we in the online community often beat such storeis to death, if only because they deserve it!

Recently Kim Cameron posted the search history of user 16006693, which flits "from politics, to retirement, to politics, to religion, to sex, quickly back to religion (repent!), to food, and finally to heartburn." Why is it interesting? Probably because each and every one of us can find a bit of ourselves in user 16006693 (well, OK, not all of us; I know I'm not anywhere close!).

Check it out; don't hurt yourself too much from laughing:

16006693 nak
16006693 nack
16006693 sharona
16006693 knack
16006693 knack downloads
16006693 oakrige boys
16006693 oakridge boys
16006693 oakridge boys downloads free
16006693 jokes about dick cheney
16006693 jokes about dick cheney but not george bush
16006693 dick cheney creep
16006693 dick cheney dickhead
16006693 rummy dickhead
16006693 where is iraq
16006693 where is lebenon
16006693 his bullets
16006693 his bullies
16006693 shiits
16006693 shee-ites
16006693 bush appruval
16006693 bush approvel
16006693 bush drops below
16006693 dead reporters
16006693 dead reporters fotos
16006693 dead reporters pix
16006693 disembowled reporters pix
16006693 disembowled new york times
16006693 love thine enemas
16006693 love thine enemies
16006693 bible quote of the day
16006693 insperation from bible
16006693 george bush great president
16006693 george w bush great president
16006693 dream on
16006693 oakridge boys lyrics dream on
16006693 how to run country
16006693 how to run country when not really inerested
16006693 people to run country for you
16006693 over work
16006693 overwork
16006693 stress
16006693 best place to retire
16006693 places like crawford but without cindy sheehan
16006693 crawford the town not cindy crawford
16006693 crawford tx
16006693 like crawford tx but not so hot
16006693 best places to retire not hot
16006693 best places to retire global warming
16006693 global warming mith
16006693 global warming myth
16006693 crawford hot
16006693 cindy crawford hot
16006693 rice hot
16006693 rice hot not recipes
16006693 rice naked
16006693 rice nude
16006693 bible quotes resisting temptation
16006693 oakridge boys i’ll be true to you
16006693 oakridge boys trying to love two women
16006693 rice and beans
16006693 tex mex
16006693 tex mex not music
16006693 tex mex takeout
16006693 tex mex takeout dc
16006693 heart burn
16006693 heartburn

Configure your router to block DOS attempts

Steve Riley — Mon, 10 Jul 2006 23:27:00 GMT

Some time ago I had a discussion with a friend. He disagreed with my recommendations on how to configure a border router and the firewall behind it. I claimed that in the border router between you and your ISP, configure the six rules to block most denial of service traffic; in the firewall, configure additional packet filtering and content inspection. He claimed that it's better to repeat the router rules in the firewall, and if possible repeat the firewall rules in the router.

This struck me as disingenuous: "Why do the same work twice?" I asked. "It's defense in depth," came the expected reply. "If a bad guy gets through the router, maybe the firewall will stop him."

No, it isn't defense in depth. Defense in depth is about doing the correct things at all layers, and only things that are appropriate for each layer. When defense in depth degenerates into duplication of effort, the resulting security posture becomes more brittle and, arguably, less secure.

There are three kinds of vulnerabilities:

Code: an error in the software that you fix with a patch
Configuration: an error a human made while setting something up
Circumvention: an error in a security policy that encourages people to look for ways to get around the policy

By far, the most commonly occuring type (according to some research from CERT) is the second: configuration vulnerabilities. Given that it's far more likely for me to make a mistake in my rules than for the code in the router or firewall to be buggy, it's far more likely for a bad guy to break in through my error-ridden rules than for him to break in through a code vulnerability in either device.

Complexity is the enemy of security. Simplicity always wins. Therefore, to keep a network simple (and more secure), ensure that your defense in depth measures are tuned and specific for each layer, not merely duplicates of something you've taken care of at another layer.

Blocking DOS attacks

Now, back to the title of this post. In a border router, you should have six rules that will block almost all denial of service attacks. Remember the attack against the Internet in February 2000? Mafiaboy, the 17-year-old Canadian script kiddie, brought down 11 sites using 75 computers in 52 countries to send 10,700 messages in 10 seconds, causing an estimated $1.7 billion in damages. (Canadian police discovered him from his boasting in chat rooms. In 2001 he pled guilty to 56 charges and was sentenced to two years in a juvenile detention center).

Why did Yahoo, Buy.com, eBay, CNN, Amazon.com, ZDNet, ETrade, Dell, and Excite all succumb to the attack? Because they lacked one or more of these six important rules. MSN and Microsoft were targeted, but because our routers have these rules, we escaped the attack. The rules:

Block all inbound traffic where the source address is from your internal networks. Why in the world would there be traffic on the outside that originates from the inside? This is a sign that someone is spoofing you.
Block all outbound traffic where the source address isn't from your internal networks. This is the inverse of #1: there's never any reason for your network to emit traffic that's sourced from some other network. Somone on the inside is spoofing someone else (we have a term for such people: employee).
Block all inbound and outbound traffic where the source or destination addresses are from the private address ranges. Defined in RFC1918, these addresses are for use in internal networks; ISPs agree not to route such traffic. Of course, ISPs make configuration mistakes, too; I've seen traffic with these addresses on the Internet. So don't trust that your ISP is perfect, block the stuff yourself. And remember to include the Windows automatic private IP addressing block. The ranges, then, are: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, and 169.254.0.0/16.
Block all source-routed packets. Way back in 1970, when "routers" were Unix computers running a routing deamon, they weren't all that reliable. So IP includes a provision for the headers of a packet to indicate the route the packet should take from its source to its destination. Source-routing was necessary then, but it's completely unnecessary today: routers are some of the most reliable gear around. Source-routed traffic is the sign of an attack: drop it all.
Block all broadcast packets, including directed broadcasts. Broadcasts are useful inside a network, but have pretty much zero utility between networks, so don't let the stuff in (or out). And good old smurf attacks, still seen as a form of revenge in IRC, rely on directed broadcasts. [Thanks to Michael Dragone for suggesting this additional rule.]
Block all packet fragments. Fragrouter is an old but wonderful tool, imminently useful for evading network intrusion detection. With it, an attacker can create packet fragments -- TCP or UDP packets missing the TCP or UDP header -- and, for example, map out your firewall policy and prod for holes and mistakes in your configuration. With one notable exception, fragments are generally not created, so there's no reason to permit them into your network. What's the exception? IPsec -- or, more precisely, IKE authentication in IPsec. During the authentication sequence, IKE performs six round trips between the peers. As the peers negotiate a protection suite and exchange keys, IKE generates fragments: very rarely will the key fit in a single packet. So if you're allowing IPsec between the Internet and something behind your border router, you'll need to skip this final rule.

There you go. Program these six rules in your border router (and consider dropping whatever else you've got there now) and you, too, can tell the likes of Mafiaboy to go pound sand. Oh, and guess what? By being more secure yourself, you directly affect -- negatively -- the security posture of your neighbors and competitors! Did you ever think that a router configuration could become strategic competitive advantage? :)

How to secure your wireless network

Steve Riley — Sat, 12 Nov 2005 10:43:00 GMT

I'm now a contributing editor for TechNet Magazine. Everyone with a TechNet subscription automatically receives it; if you don't have one, you can still get the magazine free. The magazine's published three issues so far: Winter 2005, Spring 2005, and November-December 2005. You'll especially enjoy the "Hacking" series in the first issue, where Jesper writes up his "Anatomy of a hack" conference session that always seems to score a hundredth of a point or so higher than me! (LOL) Good news: the magazine is increasing its frequency; it'll be bimonthly through June 2006, then monthly after that.

Anyway, in the November-December 2005 issue, I've co-written (note I don't say "co-authored"; "author" is not a verb!) with Kathryn Tewson an article on wireless security for the Security Watch column. We describe the threat, some wireless security basics, how not to secure a wireless network (hint: bogus advice regarding SSIDs and MAC addresses figures prominently here), and details on access control and encryption. We also describe three common scenarios.

Read through the article for information on the various technologies and our recommendations -- which is pretty simple these days: WPA or WPA2 are really the only logical choices. While you're at it, subscribe to the magazine, too. I think you'll enjoy it. Look for more articles of mine in the magazine over time; for the January-February 2006 issue, I'll have an article describing VPN quarantine (just sent it to the editors today, actually).

August article: 802.1X on wired networks considered harmful

Steve Riley — Thu, 11 Aug 2005 20:55:00 GMT

Several months ago I learned from Svyatoslav Pidgorny, Microsoft MVP for security, about a problem in 802.1X that makes it essentially useless for protecting wired networks from rogue machines. Initially I was a bit skeptical, but the attack he described is in fact true -- I've seen it myself now. So I've been explaining the attack at conferences lately and have also included information about it in the book. However, I don't believe the danger presented by wired 802.1X is getting enough reach, so I've written about it in the August security management column.

As you read the article, remember that the vulnerability enabling the attack is a fundamental weakness in the protocol -- it authenticates only upon connection establishment and assumes all traffic after authentication is legitimate. The vulnerabiliy exists in wired networks because there's no follow-on packet authentication. You really should be using domain isloation with IPsec to thwart rogue machines, and at the article's end are links to information about that. Also, understand this particular vulnerability isn't present in 802.1X-protected wireless networks, because the authenticators and supplicants have established authentication and encryption keys that protect individual 802.11 frames.

New column -- The case of the stolen laptop

Steve Riley — Thu, 10 Feb 2005 21:12:00 GMT

Seems like once a week I hear from someone worried about stolen laptops -- or, worse, just joined the ranks of laptop theft victimhood. The best way to stay out of that club is to keep the thing with you at all times, or leave it in your hotel room when you don’t want to carry it around. Yes, everyone has heard the warnings about hotel room theft, but I’ve never had something stolen from a hotel room and I spend well over 200 nights a year in hotels. You’re far more likely to leave your laptop or PDA or smart phone or USB drive lying on the seat in the taxi or on the counter at the bar as you and your new friend depart for the evening.

So how do you protect your data if the unfortunate should ever befall you? Three features of Windows 2000 and Windows XP can help you keep your information out of the hands of a thief who somehow manages to get hold of your laptop: passwords, encrypting file system, and SysKey. Do realize that if you use these features, you will most likely frustrate the thief so much that he or she will destroy your laptop in anger and disgust, but this is far preferable to seeing the development plans and source code of your next killer product posted on Slashdot.

http://www.microsoft.com/technet/community/columns/secmgmt/sm0205.mspx