Steve Riley on Security : false claims

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.

Myth vs. reality: Wireless SSIDs

Steve Riley — Tue, 16 Oct 2007 10:08:58 GMT

Do you ever wonder sometimes how it is that some ideas just won't die? Like the thought that not broadcasting your wireless network's SSID will somehow make you more secure? This is a myth that needs to be forcibly dragged out behind the woodshed, strangled until it wheezes its last labored breath, then shot several times for good measure.

Folks, there are fundamental differences between names, which are public claims of identities, and authenticators, which are secrets used to prove identities, and I've written extensively about this before. An SSID is a network name, not -- I repeat, not -- a password. A wireless network has an SSID to distinguish it from other wireless networks in the vicinity. The SSID was never designed to be hidden, and therefore won't provide your network with any kind of protection if you try to hide it. It's a violation of the 802.11 specification to keep your SSID hidden; the 802.11i specification amendment (which defines WPA2, discussed later) even states that a computer can refuse to communicate with an access point that doesn't broadcast its SSID. And, even if you think your SSID is hidden, it really isn't. Let me explain.

All 802.11 wireless networks, regardless of the kind of operating system or encryption you might use, also emit unencrypted frames at times. One kind of unencrypted frame is an association frame. This is what a client computer, or "supplicant" in the 802.11 protocol vernacular, emits when it wants to join a wireless network. Contained within the frame, in clear text of course (since the frame is unencrypted), is the SSID of the network the supplicant wants to join.

Both Windows XP and Vista work best when your access points broadcast their SSIDs. XP really doesn't behave well at all with nonbroadcasting SSIDs. Vista has some added smarts to improve this a bit. Normally, Vista continually sends probe requests for nonbroadcasting networks. These probes are similar to unencrypted 802.11 association frames, and will generate clear-text responses from the access points if a nonbroadcasting network is present. You can reduce, but not entirely eliminate, these probes by configuring the wireless client to probe only for automatically-connected nonbroadcasting networks.

Both these behaviors make it very easy for an attacker to discover your SSID. The bad guy, perhaps a contractor or a guest in your facility, could run one of many wireless sniffer programs and simply capture the hundreds of association frames or probes that litter your air. No amount of "hiding" configured in your access points can prevent this kind of traffic interception.

So there you have it, simple SSID discovery. The old axiom remains true: security by obscurity is no security at all. Hiding an SSID will not hide a wireless network, so ignore any such advice -- and it's amazing how often I continue to see this. By the way, also ignore any advice that says to use MAC address filtering. It's amazingly trivial to spoof the MAC address of an allowed supplicant -- simply sniff the traffic, look at the MAC addresses, and use the neat little SMAC utility to change your MAC to one that's permitted.

Nonbroadcasting networks are not secure networks. The right way to secure a wireless network is to use protocols that are designed specifically to address wireless network threats. If you're still using WEP, either static or dynamic, I encourage you to move to WPA2 as soon as possible. For those of you at home running XP and have kept it updated, or if you're running Vista, then, you simply need to enable WPA2. We've got some additional guidance for home/small offices and for enterprise networks with certificate services or without. If you have hardware that's more than two years old and you can't upgrade it, check to see whether it supports WPA (an interim specification released before WPA2 was ratified). Both WPA and WPA2 are built on sound cryptographic principles, they're proven in the field, and they'll keep the bad guys out -- even when you're broadcasting your SSID to the world.

Bogus Microsoft sweepstakes emails

Steve Riley — Mon, 20 Aug 2007 01:35:48 GMT

Over the past month I've received at least three enquiries from people asking about the legitimacy of emails claiming the recipients have won large amounts of money in a Microsoft sweepstakes or lottery -- often 500,000 British pounds. This is an easy question to answer: they're fake.

Recently, someone forwarded me the email. Let's examine some of its characteristics.

The sending address is microsoft.co.uk-00@adelphia.net. The address was a hidden hyperlink. Legitimate emails you receive from us almost always come from @microsoft.com domain; occasionally a marketing partner will use their own domain -- this we're trying to eliminate. No legitimate mail from us would use an ISP's domain: Adelphia is a cable TV company that's been split up and sold to Time Warner and Comcast. Furthermore, the email has the appearance coming from Microosft UK, so using an American domain seems odd.
The subject line is "YOU WON (£500,000.00GBP)! Microsoft congratulates you!" Official communications from us typically DON'T SHOUT FROM THE ROOFTOPS. Also, it's incorrect to use both a currency symbol and the three-letter currency name. This like saying "$1,000USD." It's either "$1,000" or "1,000USD," but not both. And why is the amount in parentheses? Doesn't that indicate (on balance sheets, anyway) that the number is negative? One could interpret the subject line this way: "Congratulations! You've won the privilege of sending 500,000 pounds to Microsoft! Warm up your check book!"
The email insists that you contact Mr. Peter Garry, Microsoft's "fiduciary agent." There are some capitalization errors in this particular sentence.
There are several official-looking reference numbers, file numbers, and batch numbers in the email -- none of which would be useful information to the recipient.

Folks, were we to ever run a sweepstakes where we're giving away the equivalent of a million dollars, it's safe to say that we wouldn't use email to send winning notifications. Please tell your friends and neighbors that stuff like this is fake.

Oh, in case you're curious, do a search on the winning prize number: 14-21-25-40-40-47(21). Looks like hundreds, maybe thousands, of people have all coincidentally guessed the exact same number!

Bugged Canadian coin story is...wait for it...BOGUS!

Steve Riley — Wed, 17 Jan 2007 02:39:00 GMT

Surely you've heard, too many times by now, about the radio transmitters "discovered" in some Canadian coins. From the moment I first read about it, the steamy stench of pasture patties loomed large in the air. I watched in amazement as the story grew and the apparent credibility so many "journalists" ascribed to it! Well, the United States Defense Security Service now admits that the statement is "unsubstantiated following an investigation into the matter."

My variation on the rule is this: if something is too stupid to be true, it absolutely is. And, of course, there's a corollary: media attention to silliness is inversely proporational to factuality.

iPods spread disease?

Steve Riley — Wed, 18 Oct 2006 00:57:00 GMT

Well well. Looks like a few new iPod owners are getting infected when they attach their players to their computers. I'll quote the first paragraph from Apple's web site:

We recently discovered that a small number - less than 1% - of the Video iPods available for purchase after September 12, 2006, left our contract manufacturer carrying the Windows RavMonE.exe virus. This known virus affects only Windows computers, and up to date anti-virus software which is included with most Windows computers should detect and remove it. So far we have seen less than 25 reports concerning this problem. The iPod nano, iPod shuffle and Mac OS X are not affected, and all Video iPods now shipping are virus free. As you might imagine, we are upset at Windows for not being more hardy against such viruses, and even more upset with ourselves for not catching it.

So Apple has a quality-control problem, and they blame it on Windows? They mention that decent AV software would catch the virus, but then they become oblivious to the irony that they themselves apparently don't run any?

What's even more inaccurate in Apple's claim is that the malware isn't an actual virus. Rather than exploiting a code vulnerability to spread, it relies instead on a common configuration vulnerability -- the gullibility of humans. To encourage spreading, it creates an autorun.inf file, entices the user to execute the worm, and then looks for any mappped drives and drops itself on whatever it finds. I continue to maintain that autorun has no purpose on business computers and you should disable it at the domain level.

Apparently, someone at Apple fell for the dancing pigs and subsequently infected the equipment used in the manufacture of certain iPods. Ignoring their own problems, Apple finds it easier to blame Microsoft. That's right, blame is always preferable over responsibility.

Must be a slow news day: reporter writes 100% crap

Steve Riley — Tue, 03 Oct 2006 21:12:00 GMT

Imagine my surprise to read that Microsoft is removing NAP from Windows Vista! Does this guy actually get paid money to write this drivel? The particular folks quoted in the article all have their own agendas, of course.

News flash: we aren't dropping NAP. It's in the product now, we're actually running it on part of our own corporate network. And soon you'll get to enjoy the benefits of NAP in your own environments, too.

Security in Windows Vista 64-bit

Steve Riley — Sat, 12 Aug 2006 02:17:00 GMT

By now, many of you have heard us speak about or have read our writings on the improved security capabilities of Windows Vista. As I've said at a number of events now, the research I've done into these capabilities has convinced me that enterprises should seriously consider Vista upgrades. This OS is really gonna make the bad guys rethink their tactics.

My friend Jeff Jones has recently dug into the differences in 64-bit Windows Vista. In his first article he describes hardware no execute protection. His second article explores Patchguard, explains its value, and deflates some recent research into bypassing Patchguard.

If you haven't been reading Jeff's blog, I recommend adding it to your list of feeds.

File under: "You've got to be kidding!"

Steve Riley — Sun, 12 Mar 2006 04:15:00 GMT

Today I upgraded the brain on my i-mate K-JAM. Which, of course, requires a hard reset, meaning that I get to spend a relaxing day re-installing and configuring all my applications. Usually when I do this (too frequently, it seems) I browse around for new and improved software.

While perusing www.pocketgear.com for updated travel-related software, I stumbled across something that's incredibly funny and woefully tragic at the same time. You gotta check this out, if only for comic relief!

2004 Terrorism Survival Bundle 3.0
Don't be caught unprepared in the case of another terrorism attack. The 2004 Terrorism Survival Bundle includes:

Terrorism travel planner - international
Terrorism travel planner - USA
Terrorism survival plan database
Terrorism survival response database

I especially enjoyed the list of less common international threats: children, driving, food, kidnappings, landmines, missiles, piracy, soft targets, and vehicle explosions! How are children threatening?

What motivates a journalist?

Steve Riley — Thu, 19 Jan 2006 02:52:00 GMT

OK, I have to unload a burden here.

I often interact with the tech press in various places throughout the world. I've had wonderful, productive meetings with many fine journalists. New Zealand and Malaysia particularly stand out in my memory. However, a thing has happened today that, while not affecting my relationships with individual journalists, irritates me about tech reporting in general.

Take a look at this: "Windows Wi-Fi patch could be a long time in coming." It describes a "vulnerability" recently reported by a researcher at a security conference. c|net also wrote about this two days ago.

I'm disappointed at the seemingly superficial reporting here. Mark Loveless (the researcher) has discovered a way to confuse unsuspecting people simply by taking advantage of a feature in Windows. He has not discovered a vulnerability. There's no error in either code or the default configuration here.

Today's article implies that a bad guy can get access to any system he wants to. Thing is, the default configuration won't permit that. You have to run as local admin and deliberately misconfigure your wireless settings for a bad guy to connect to your computer -- and when you do this, Windows warns you multiple times about potential threats.

It saddens me that, rather than truly analyzing the researcher's report, the journalist simply chose to report "yet another vulnerability."

New site at the top of my favorites list

Steve Riley — Wed, 16 Nov 2005 12:46:00 GMT

You know, stupid security abounds. I just discovered this site today, and I plan to become a regular visitor -- and probably a contributor, too! I encourage you to explore it and enjoy. Oh, some advice: it probably would be unwise to read an offline archived version of this site on an airplane. :)

Stupid Security: Exposing fake security since 2003
http://www.stupidsecurity.com

The Internet routes around outages -- and censorship, too

Steve Riley — Tue, 27 Sep 2005 12:28:00 GMT

Have you seen this yet? "Grokster ruling begins the good fight" If you haven't, it's worth your time to read -- it's a terrible shibboleth for a U.S. "national firewall."

Coursey is promoting the idea that all U.S. Internet access should pass through a firewall that will block file-sharing and gambling sites. Since most of these sites have moved off-shore, Coursey claims that this isn't censorship, but it's the only way to ensure that "when the Internet is being used on American soil, it should comply with American law." Later in the article he chides the Chinese government "for filtering the Internet as delivered to residents of the communist dictatorship." He contrasts this with file-sharing and gambling and says that "since [these] are not accepted as universal human rights," it's OK to "stop illegal content from reaching American citizens."

Does Coursey lack a sense of irony? It seems so. In one swell foop he maintains that America should be allowed to filter what America has declared illegal -- file-sharing and gambling -- while denying that China should be allowed to filter what China has declared illegal -- political and religious content that's counter to and threatens the government.

Am I the only one who sees a problem with this? Now of course China's actions completely violate all sense of human rights, but adopting their solution -- censorship -- will be no better in this country. If we establish a precedent of censoring illegal content, what's to stop various interest groups from galvanizing politicians to declare illegal anything that the groups don't like? Where will it end?

(Post script: I'm writing this from Taiwan! Also, last week in China, their "national firewall" was pretty useless...)

Lousy security

Steve Riley — Wed, 14 Sep 2005 01:33:00 GMT

Lousy security is all around us, and I'm not even thinking about airport security here (which, I admit, i love griping about). Here I have in mind lousy computer security. And lest you think I'm proceeding to engage in naval-gazing introspection, no -- I'm not going to write about our own products.

Jesper already wrote up his impressions of a popular wireless router. Now I'd like to tell you about some software I encountered recently.

Rights management systems (no, not evil DRM that stops you from using, on your own devices, music you've purchased) are becoming more critical in business information systems these days. It's becoming more and more difficult to use a network function -- in this case, file system ACLs -- to enforce access control to objects that can live in many places outside the network. This is the beauty of rights management systems: they offer you a way to enforce access control no matter where an object resides.

Sure, we have some pretty cool rights management stuff. But I'd like to tell you about another one. Recently at an event Jesper told me about a vendor who approached him. This itself isn't so unusual. But this gentleman was bubbling over with excitement about his new rights-management system that was entirely client based -- unlike Windows RMS, it required no server infrastructure. "Hm," thought I, and I agreed to let him show me the product.

Operationally, it was fairly straightforward -- while their software is running, any documents you create can be protected through the system. On the hard drive it's just an AES-encrypted blob. Good so far. I started chatting with him about how authorization is enforced, and while listening I tried an experiment. I had Jesper open a protected Word document inside Notepad -- always a good thing to do if you want to get an idea of how a file might be modified. At the top of the file was some XML, followed by random binary goop. Sure looked encrypted all right. Then I said, "Hey, save that thing right back to the hard drive and re-open it in Word," wondering whether a simple read-save in Notepad would do anything to his system.

We loaded Word, opened the document, and -- yes! -- a blue screen! Wham! Cue rapid expressions of surprise and fear across the sales robot's face.

What happened here? Originally the document was in Unicode. Notepad saved the file in ANSI. Obviously, then, their protection system is incapable of handling non-Unicode files, and the developers made the disastrous assumption that all input is valid. "Who would ever do that?" must have been their answer to the question "What if someone tries to open a non-Unicode file?" Probably, though, they never even thought to ask the question in the first place. The system should have checked the collating sequence and either rejectd non-Unicode files or adjusted for ANSI.

Now why do I relate this tale? It's simple -- software is difficult. Good software is more difficult. Good secure software is monumentally more difficult. Thinking about how a bad guy might abuse your application and developing reslient software that doesn't just blow up in the onslaught of attacks is something that the entire industry is only now beginning to figure out. Jesper's even talking about this now and demonstrating the good and bad in a new event session called "Is that app really safe?"

People bash Microsoft stuff for being insecure, but at least we have dedicated people whose job is to try to break our stuff. We've got the resources to do that. I'll tell ya, sometimes I'm not sure about some third parties, especially those selling "security software." Conduct your own dilligence, test the crap out of anything before you buy, and reward good vendors with your money.

New column - debunking security myths

Steve Riley — Tue, 12 Apr 2005 22:58:00 GMT

There is a lot at stake in security configuration guidance. First, it is easy to understand why people are clamoring for it. Everyone can see the benefit in turning on some setting and blocking an attack. In some environments, doing so is not even an option. A system must be configured in accordance with some security configuration or hardening guide to be compliant with security policy. In other environments security configuration guidance is strongly encouraged. Before you start making security tweaks, however, we feel that it is very important that you understand some of the fundamental problems with them. These are what we call the myths.

Part 1: http://www.microsoft.com/technet/community/columns/secmgmt/sm0305_2.mspx

Part 2: http://www.microsoft.com/technet/community/columns/secmgmt/sm0405.mspx