Security Curve Weblog

Airplane Hijinx

So, worth reading for the humor is the AxisofLogic take on airport security. I'm glad I'm dieting, since according to them, the "stripper-o-matic" nudity cam could be coming to an airport nearby.

Smishing

Have you heard about Smishing? Apparently, that's what you call it when you get a phish SMS on your cell phone. The scenario is the following: you get a suspicious SMS with a link in it, you follow the link which downloads a file, you are asked if you want to install the file, you agree and install it, and finally you get some trojan that hoses you. Totally a raw deal for the phone user. Although sometimes you have to draw a line in the sand, and I'm *not* going to call it smishing. Really, it sounds too dumb. So I'm just not gonna do it.

Ancillary to that, I'm less concerned about the phone-phish (see, not calling it smishing) that installs a trojan and more concerned about the phishing that asks you for information like your profile password, PIN, or other information. A few weeks ago, I probably would have discounted this as something serious to worry about, but then I got signed up for DateSite and now I fully understand the power of the nagging, insistent, and unstoppable SMS. Seriously, if my phone lights into "This Corrosion" or whatever at 2AM, I think I'd be ready to give away just about any information they want if that'll get the texting to stop.

In other, totally unrelated, news - AT&T Loses all our data.

Cloud of Smug Centered over Apple HQ

Did you ever see that South Park episode where everyone was so self-satisfied from driving hybrid cars that a gigantic cloud of Smug formed over South Park and threatened to cause the end of the world? People were going around saying things like "I prefer to be part of the solution rather than part of the problem" and holding themselves up on a pedestal because they're so great. Something about that scenario reminds me of Apple's recent marketing. Here's what I mean.

Back in the day, when Apple went live with their new message about how they're better than everybody else because they don't have the same quantity of malware, I thought it was only a matter of time before they got slammed. However, they didn't get slammed. In fact, I don't know what the bad-guys are doing, but not only has this message not caused Apple any pain, but it has actually been so successful that they have expanded it to further emphasize their contention that there is no malware for the Mac. This time, the PC dude is wearing a trench coat and trying not to be recognized because of all the spyware while the Mac guy is just relaxed and at peace. Apparently, Mac's don't get malware, and they don't get spyware. Behold the power of marketing.

Not only do they not get malware now, but Infoworld has taken it a step further in their recent longwinded diatribe about why the Mac is has superior security and can't get spyware/worms (apparently, the architecture of the Mac is so superior that malware just "can't happen under OS X".) Not that these arguments have any technical merit: I won't go into all the reasons why this kind of thing is specious again, since I've done it so many times in the past... but, trust me, there is absolutely no technical reason why malware won't run on a Mac. It will, I guarantee it. No matter what the bloggers over at Infoworld tell you, all general purpose PC's can get malware. It's just plain logic.

Look, computing platforms are built to allow the user to manipulate the environment, right? And if a user can do it, a user's agent can do it. And since there is no way to know user intent programmatically, if a user's software agent can do it, malware can do it. For example, if a user can install software that gets launched at boot and uses system resources, then spyware can install software that gets launched at boot and uses system resources. If a user can reformat the disc, malware can reformat the disc. But buy in to Apple's message, and it seems like there's something magical about Mac that defies this - somehow once software is undesirable to the user, it can longer be installed on the system. Bull. Sooner or later, people buying Macs based on these flawed assumptions marketing by Apple will get a wake-up call, and I think it sucks that Apple's capitalizing on these false claims in the meantime.

Socialite Buzz

You saw that Paris Hilton was accused of hacking, right? How interesting is that? When I saw the link over on Pete Lindstrom's blog, I had to check it out. Which I did; I also did some digging on the service that made it all possible: SpoofCard. Now, here's what I don't get... How do they know it was Paris that was doing the hacking? It seems like they must have some serious faith in their authentication technology to make sure it really is Paris if they're going to put everything on the line (damages from potential libel claims are almost sure to impact their bottom line) to implicate Paris. This mystifies me, so I've been digging around the SpoofCard site - it looks to me like the only way that SpoofCard can tell who you actually are is from the credit card on file when you purchased the card. Is that what they're using to accuse Paris? I hope not, since tons of things can happen between when you buy a calling card and when you use it. Maybe somebody stole the PIN or maybe she bought the card as a gift for someone else.

Of course, all this begs a few other questions too: like when SpoofCard realized that Paris and others were in violation of the law, why did they write a press release rather than going to the police?

Mastercard Certification

You may have noticed that there has been a slight dip in the frequency of blogging during the early part of this week.  As it happens, I've been participating in a MasterCard scanning recertification effort.  Since the topic was on the brain, I thought I'd discuss that as well as PCI in general in today's entry. 

So, as part of the gigantic machine that is PCI, Visa/MasterCard require that non-members (i.e. firms that aren't banks) undergo a quarterly external scan of their environment.  In order to be a firm in the business of providing that scan, you have to pass an annual certification test that proves that you have the chops in order to do the scanning at a certain level of expertise.  Basically, you're given a bogus environment and you have to go about performing scanning/investigatory activities on a mock-up environment in order to demonstrate your level of expertise.  And then, once you successfully complete the challenge, you are given a certificate that says you're "all good" from MasterCard's point of view.  That's basically the exercise in a nutshell. 

Basically, it's bull.  Why is it bull?  Here's the low-down: the economics of doing this type of scanning are not such that a firm can deliver anything close to the kind of testing that is done for the certification.  Some firms are offering the scanning "free" with other services (meaning that the costs are hidden in remediation or other projects), other firms are offering the service at "Crazy Eddie" discount rates and performing equally shoddy work.  A vendor might, for example, run nessus in its default configuration against a client environment, export the results as an HTML report, and "call it day" - grand total, 20 minutes of work.  What Visa/MasterCard really want is for vendors to take the time and energy to do it the right way, which of course is impossible when "discount" vendors are doing 1/20th the amount of work.  So it's unprofitable to actually do what Visa/MasterCard intended for quarterly scanning; ergo, nobody does.   

Of course, nobody over at Visa or MasterCard is complaining about it.  Which makes me wonder what their interest in the certification really is.  After all, since the certification activity is completely unrelated to what's actually being done in the field, I'm curious why they want vendors to get certified at all.  I'm wondering if the fact that they require this has to do with the fees required for certification, recertification, and fees to take the test.  100k per firm per year in recertification fees and testing fees seems like a good revenue stream to me - especially when the work involved is just setting up a few default installs of various operating systems for the test procedure. 

"Behavior Screeners". Sure.

Are you kidding me? In case you didn't see last week's NYTimes article, Faces, Too, Are Searched at U.S. Airports, I highly advise you to check it out. Now, normally I don't blog about the jackassery that goes on in airports - after all, most security experts that I talk to are all in agreement that the airline security measures are bogus, but this one is over the top! Here's the synopsis: when you're waiting in line to go through the insanely long security line, there are (apparently) individuals whose job it is to look for "agitated" or "nervous" individuals and give them the extra-close "latex glove" kind of scrutiny.

According to the manager of the teams, “It is like throwing a big fishing net over the side of the boat: You catch what you catch, but hopefully within that net is a terrorist.” A big net, indeed. And while we continue to fund them scouring for the four-leaf clover, nothing will continue to happen to improve security.

RSS 2.0, index facelift, and future content....

So, we here at the curve are looking to "embrace the future." Always a noble goal, right? More specifically, we're planning on offering some neato whiz-bang audio content - look for that in the coming weeks. Of course, in order to harness the full power of audio, we'll need to offer a syndication option that supports it. So the upshot of the deal is that now we're supporting RSS 2.0. Those of you using the RDF or RSS 1.0 feed probably won't notice the difference, although you can always get the new groovy extra features by subscribing to the new feed (I recommend doing it, since the new index contains all sorts of information the old one didn't.)

Why's Everybody Pissed at Consumer Reports?

Consumer Reports has apparently decided to test the capability of antivirus software to detect and respond to new and arising threats. In order to do this, they have contracted with an outside firm to create new malware which will then be scanned by the AV software. This sounded like a good idea to me, but then I read the reaction from the AV community:

[Sophos:] When I read about what ConsumerReports has done I want to bash my head against a brick wall. With over 185,000 viruses in existence was it really necessary for this magazine to create 5,000 more? It's a bit like Fire Monthly Magazine testing fire stations by lighting umpteen fires around the country and seeing who is the fastest at putting them out. It's irresponsible behaviour, and will be frowned upon by the anti-virus industry. Leave anti-virus testing to the independent testing bodies with expertise in the field. 

[Kaspersky:] After all there are many many thousands of viruses in existence already and we're adding around 200 new signatures to our database every day, why the need for someone to create new ones? 

And so on. Everybody's all in a tizzy about it. The AV folks claim that creating malware is wrong - no matter what the circumstances. The argument is that there is so much malware already that adding new malware to the list - no matter what the reason - is unethical. Now, maybe I'm an irresponsible lout, but I think that's USDA prime "bull".  Why?  Because #1 I don't accept that AV companies are the last stop when it comes to malware ethics and #2 I think Consumer Reports is performing a useful service to the community.  In other words, I think it's useful for customers to be able to quantify the efficacy of claims made by AV software vendors with respect to detection of new malware - and believe me the claims in this area are pretty big:

• Norton AntiVirus (NAV) has the ability to detect unknown viruses of various types using heuristic algorithms known as Bloodhound. [Symantec]
• With advanced heuristics and generic detection it finds even new, unknown viruses, even hidden in compressed files. [McAfee]
• Sophos AV does incorporate heuristic scanning for unknown viruses in the wild. [Sophos]

 And so on.  They all make the claim.  How can we know which work and which don't.  In order to test the reality of these claims, consumer reports decided to create some new malware for these products to find. Why is that so wrong? Let's break down the objections one by one:  

• Objection #1: It's wrong because the malware could get into the wrong hands and tear a swath of destruction across the land.  So, it seems to me like we don't know from what CR has said if the malware they created had functional propagation capability or payload; we also don't know if it was created inside a safe and controlled environment.  Is it OK if there is no destruction, or possibility of destruction?
• Objection #2: Because it means that AV companies need to write new signatures.  Um...  No offense, but "cry me a river".  Look, AV companies are not a public service.  As part of their risk/reward analysis, these companies have decided that it's more cost-effective at this time to write new signatures when new malware comes out vs. advancing the heuristic capability to the point where they don't have to.  They went into it with their eyes open, and I'm not about to agree that legitimate, useful research should stop because it hits Symantec's bottom line.  Not in this lifetime anyway.
• Objection #3: It's wrong "no matter what the circumstances" and "for any purpose".  This is what I call the "lalala" argument - remember when you were a kid and you'd put your hands over your ears and go "lalala"? Yeah, that's this.  Basically, in this view, it doesn't matter why you're writing it, what the payload/propagation is, or what the effect will be - it's just wrong.  Since this argument isn't predicated on anything concrete or specific (i.e. "it's wrong because I say it is"), it's somewhat hard to refute.  However, I think it's useful to point out that since in this scenario it's equally unethical no matter how inert the malware is, that this means the minute that you call something a virus it becomes problematic (for example if I started calling Microsoft Word "Win32.OfficeProductivity.A" it would then be unethical for me to have it.) 

Well, I guess I went on about this one...  It's just one of those things that gets me fired up.

Thoughts about OpenOffice

By now, you've probably seen the news coverage about the French Ministry of Defense and their analysis of OpenOffice. You may have even seen the OO.org rebuttal where they claim that it's "all good" over there and that anything to the contrary is bull. All in all, it's an interesting debate.

What's interesting to me is not whether or not OpenOffice is more secure - after all, I'm sure it has its security advantages (like the fact that researchers/haxors are targeting it less) and its security disadvantages (like leaving out anti-macro-virus countermeasures). However, what I find fascinating is the general unwillingness on the part of indviduals to accept that Microsof Office might have a lesser attack surface than OpenOffice. Maybe it does and maybe it doesn't, but why is the discussion so loaded?

Look, the word on the street is that OpenOffice is clearly more secure - that it's 100 times more secure in fact. But where is the evidence? Why are we so unwilling to accept that MSFT might have made some advances, and why are we so willing to accept that OpenOffice is superior just because it's an open-source project? Shouldn't we be objective?

Sometimes SharpReader says stuff dated last year is new...

...and then I blog about it, notice the date sometime in the middle of writing the entry, and ultimately delete the whole thing.

Gartner's Top Five Steps to Prevent Disclosures

Have you seen Gartner's top five steps to prevent information disclosure? In case you missed it, here they are:

- Deploy Content Monitoring and Filtering
- Encrypt Backup Tapes and Mass Storage
- Secure Workstations, Restrict Home Computers and Lock Portable Storage
- Encrypt Laptops
- Deploy Database Activity Monitoring

This kind of thing never fails to get my goat. Look, no matter how cool it would be, there are no "easy to follow steps" to preventing disclosures. Heaven knows I wish there were, but there aren't. Why not? Because businesses are different, risks vary according to industry, and deploying this stuff's not like flipping a light-switch.

Take number 2 for example - it's easy to say "Encrypt Backup Tapes and Mass Storage" and (if you're Gartner), you're likely to get press out of saying it. However, how realistic is it for firms to encrypt all their mass storage? Should they encrypt it all? What kind of encryption should they use? What happens to the keys? How do they store the keys? When do they change them? Is it "spare no expense", or can they compromise a bit in order to meet their budget? How about using some intelligence to gauge level of appropriateness for the business - for example, is it really worth it to spend millions encrypting ALL the backup tapes? Really? Even the ones that don't store sensitive data? Would it be worth it, for example, (if everyone in the firm has laptops) to bankrupt the firm in order to encrypt even those laptops without access to sensitive data? Maybe not.

Look, my point isn't that Gartner sux (because they don't) nor that they shouldn't write this stuff (because clearly somebody should) - my point instead is don't expect Garter to understand your business for you. Just because somebody comes around and says that "content filtering software" is the most important step you can take for security nowadays, don't just snap-to without thinking about it... Think about your business and what forwards your goals. After all, who knows if Gartner's even right? Trust me, they've been wrong before.

More RSS Stuff (I'm still not convinced)

OK, so there was some fiery banter over the weekend (half of which got lost because of the server restore) about my picking on SPI - or more specifically my picking on Caleb's comments to the press - about the potential for significant malware that utilizes RSS (at least in the near-term).  Anyway, I thought I'd follow up on that and pass along a link that SPI sent around to a whitepaper that they've put together that further outlines their position on this.  The whitepaper, "Feed Injection in Web 2.0" makes for an interesting read, but I'm still not getting it entirely.  As far as I can tell, the point of the paper seems to be:

• You can download content that's created by a potentially dangerous person
• That content can get rendered by your reader and potentially execute scripts
• Sometimes readers don't implement security the right way

It seems to me like the first two bullets are sort of the point of syndication: somebody creates content for others to view - that content might include client-side functionality (scripts.)  The third bullet - while both true and interesting - is also equally true of web content, flash, email, and all sorts of other communication methods. So why is it unique to RSS?

Anyway, not to stir back up the bee's nest, but I'm still not convinced that there's anything unique to RSS that makes it more dangerous than other protocols/communication vectors; I don't think it's more likely to facilitate malware, I don't think it's more likely to engender end-user attacks, and I don't think it's likely that it'll be a common attack vector in general.  But that's just my two cents...

Administrative Bull

First of all, in case you haven't noticed, our site has been down the past few days...  The deal was, they needed to restore the server from backup tape (last Friday's apparently), so a few entries, comments, and so on got lost in the shuffle.  Sorry about that.  In any event, things should be in order now.  Sorry about the hassle.

Vendor Hype 'du Jour': Blogs are Evil

Everybody's at BlackHat except me and apparently Michael Howard. I sort of figured that since BlackHat got bought out by the CSI people last year, that there'd be less people in attendance, but apparently that wasn't the case...  Anyway, as a consequence of that, chatter in the press is off the charts with respect to Infosec: press releases are way up, announcements are being issued like bullets from a tommy-gun, and everybody and their brother seems to be writing about what's going on in Las Vegas. Of course, vendor mouthpieces are saying those things that they say and using BlackHat as their pulpit to spread the message.  Yesterday, Caleb Sima (CTO of SPI Dynamics) took center stage to make the proclamation that blogs are evil:

Internet users who employ Web-based services such as Bloglines or Web browsers such as Firefox to read Web site feeds and blogs are vulnerable to embedded malicious code that can install spyware, log users' passwords, scan PCs and corporate networks for open ports and more, said Caleb Sima, chief technology officer at SPI Dynamics Inc., an Atlanta-based Web application security company.

Yes, apparently the blogosphere is like a gigantic petri dish newly filled with fresh auger; any day, colonies of bacteria could come and spread like wildfire throughout the tasty substrate.  And the reason nobody's doing it?  According to Caleb, because malware authors are dumb:

"The only reason we haven't had a lot of problems yet is because no one has really thought of it," he said... A Web feed could contain a link to another Web site or blog that's hosting malicious JavaScript. Or the Web feed's author could unknowingly paste that JavaScript into his own blog. Or a blog may have an area allowing readers to post public comments. Those can also store malicious bits of JavaScript...

Well that's certainly one possibility - but I doubt it.  I think there are other things going on too.  For example, maybe it's not as practicable as one might think; for example, I can tell you that I think it'd be a cold day in hell before I "unknowingly paste" malware code into my blog entries.  But maybe that's just me.  Maybe some other bloggers might be tempted to paste 40-50 lines of dense javascript code into their entries from an untrusted source without understanding what it does, stranger things have certainly happened. But are bloggers more likely to paste in this nefarious code than folks users on bulletin boards, users of services like MySpace, or other authors?  If so, why?  Of course, it could also have something to do with the (on by default) HTML-filtering capability in MT 3.2 comments.  Could it be that the fact that you can't put scripts into comments on most blogs helps to keep down the number of people doing that?  I would argue that it does - after all, the impossibility of doing something usually tends to keep it from happening...

So thanks to SPI Dynamics for pointing out this danger and putting blog readers on their guard.  After all, who needs blogs anyway?  Better we stick to traditional media where content is more strictly controlled and this kind of hacker activity can't happen.

OK. So maybe I was wrong...

I really don't like admitting when I'm wrong.  I really, really don't.  But looking down the road and imagining what the world would be like based on some of the recent developments in the application security space gives me pause.  I think it's time that I stop and rethink some of the premises that I've held to be true and reexamine the traditional thinking that is  widely held in the security community.  Let's play a few "thought exercises" based on recent events and I think you'll see what I mean...  

Scenario 1: Imagine you're a maintenance programmer working at a typical development shop.  Maybe you're working at a large software shop or maybe you're at a smaller vendor; either way it doesn't really matter - the key fact is that your job is to fix bugs.   When a security-related bug comes down the pipeline, your job is to find the source of the bug and fix it as fast as possible - you know that your customers, your boss, marketing, your shareholders, and maybe even the press are all waiting for you to get that patch out as soon as possible.  Maybe you need to work through the night tracing down some difficult problem in order to debug and publish the fix.  What happens if while you're working on one bug, another shows up in your queue.  You sigh, put it on the "back burner" and continue with what you were doing.  Then another comes in.  Then another.  And another.  And another.  Your queue starts filling up.  Your time-to-complete goes from days to weeks to months in minutes.  No time to stop and plan, no time to hire help, no time to share the load.  You've lost... Game over.  

Scenario 2:  This time, you're a sys-admin.  Your job is to keep the desktops and servers in your environment patched and to make sure that you implement workarounds for new security bugs as they're found.  One day, you walk into the office and find that you have a hundred advisories with instructions about tasks that you have to perform to keep your machines in safe working order.  What do you do?  A conservative estimate would be that it'll take you 2 months to install all the patches and various workarounds.  Where do you start?  Do you just "start at the beginning" and work through?  Do you prioritize the machines based on criticality (maybe you've already done that), spend a month or so regression-testing your apps, and then apply the patches?  How can you possibly keep up?  Answer: you can't.

Some of you are thinking that these scenarios are pretty far-fetched, am I right?  After all, it'd have to be a pretty fantastical situation to arise for a veritable "wall of bugs" to overload the traditional "find and fix" model, right?  After all, we've had the traditional "find and fix" model for years now, and everything's been fairly copasetic up until now.  Vulnerability researchers find a few bugs a month, vendors fix them without taxing development resources and system administrators deploy them without impacting their workflow over-much.  So why worry?  Well, guess what: the fantastical is here.  

Now, let me start my critique of the current situation by saying that I love the Metasploit Project; I use their framework professionally and I think what they're doing for the security community is top-flight.  I'm behind them all the way.  However, recently, to raise awareness about a vulnerability research technique called "fuzzing", HD Moore published a "bug a day" throughout July; as a result, his purpose was served - I (and I'm sure I'm not alone) am now fully aware of the power of fuzzing as a vulnerability testing technique.  Today, we find out that fuzzing has led to the discovery of more than 100 flaws in various ActiveX controls installed by default on Windows XP.  Sure is quite a few.  So, under the current "find and fix, full disclosure" model, maintenance programmers over at Microsoft are experiencing our "hypothetical" scenario #1; these guys are already working on the multiple browser bugs from last month and now they have 100 more on their plate.  When the patches are ultimately released for this, sys-admins in MSFT shops will be experiencing nightmare scenario #2.  Get ready, 'cause here it comes...

Now none of this is HD's fault.  He's a reputable guy and one of the shining stars in infosec.  His tool does what it does - and it does it really damn well.  However, I'm concerned about what the broader effect of the new technique might be on our current "bug-fixing infrastructure."  Am I alone in thinking that bad-guys are looking at his tool and drooling over the possibilities of what can be done with it?  Something tells me they're drooling for it like Pavlov's dogs.  How about researchers who care more about getting attention than they do about enhancing security?  If they found 100 bugs, might they be tempted to disclose them all en masse and get a good story in the press out of it?  Seems like they might.  

So, clearly there's a problem.  The infrastructure that we have in place for fixing bugs is not sufficient to handle this kind of bug-discovery pace and I have yet to come across a company that has the kind of administrative infrastructure to handle this kind of pace for patch release.  So what's the answer?  HD Moore proposes (rightly) that it behooves vendors to learn about fuzzing and use it themselves.  Maybe they will.  But what about in the meantime?  What about legacy software (there's a ton of it out there.)  What do we do?  Staff up? If you're used to fixing 5-10 bugs a month, how many maintenance programmers would you need to fix 100 bugs, or 1000 - how about 100000?  So just going by the ratio and ignoring economy of scale - if you have 25 programmers fixing 10 bugs/month, wouldn't you need 2500 to fix 1000/month?  That's if just 10 researchers used the same (freely available) fuzzer tool.  In salaries that'd be an increase in overhead of $250 million dollars; to put that in perspective, that's half of Netflix's projected revenue for 2005.  Is it worth it for software companies to stay open in that world?  Something tells me that cost would have a negative effect on the bottom line (understatement.)

So what's the answer?  I'm not entirely sure.  However, I can tell you that I'm thinking full-disclosure in a "fuzzed" environment isn't the same kind of tool that it was before it.  I'm a fan of full-disclosure, but if we (as Pete Lindstrom once jokingly recommended,) made bug-finding illegal, some of the symptoms would go away.  I'm not sure that's the right approach and I'm not advocating it, but maybe it's not so far off the mark as I once thought.