Spire Security Viewpoint

One billion, on hundred eighty-eight million unaffected by Conficker

I would like to congratulate the 1.188 billion Internet users who have successfully kept themselves from being affected by the Conficker worm/botnet. A success rate of 99.9% is something to be proud of. With this level of protection, we can all be comforted that the Internet is a safe place to be as long as we are careful.

Congratulations!

February 16, 2009 in Threat Management | Permalink | Comments (0) | TrackBack (0)

Canary Accounts Warn of Hacks

Robert Graham of Errata Security makes a great recommendation in a recent post:

The first is to create "canary" accounts. Create accounts that have e-mail addresses, like "something-really-long-xyz-123@gmail.com". This account is not going to get any spam e-mail. When it does get its first spam, you'll know that it came from your database. When I create recommendations for clients, this is always one of the first things I suggest. (Likewise, if you are an e-commerce site, you should get dummy credit cards that only exist in your database). This won't stop you from getting hacked, but it will at least tell you when a hack has happened. (I suspect that this isn't the first time phpbb has been hacked - just the first time it's been made public).


Canary accounts are a great idea (and its a great name for the concept). I believe there was a company out there at one point that would do this for individuals and their email addresses, and I've talked to a few folks who have used the concept in databases. It requires good planning to ensure that all business processes are factored into managing the accounts.

February 07, 2009 in Threat Management | Permalink | Comments (1) | TrackBack (0)

Mechanical Turk: Reputation Manipulator?

Mechanical turk is really a fascinating service. I must admit, however, that I feel the same way I did years ago when I opened up the Washington Post Help Wanted section and saw "job openings" for protesters (yes, I actually believed protesters protested because of their beliefs, not to earn a pay check).

In this case, a quick scan of Amazon's Mechanical Turk reveals all sorts of "hit" opportunities to add comments, reviews, and other feedback for various entities - websites, photo sites, personal injury lawyers (yep, saw that one), etc...

Once again, it isn't like this stuff wasn't happening already, but online reputation in today's world is too flimsy to be useful. That is why adding "real name" tags like Amazon does is so meaningful.

January 21, 2009 in Threat Management | Permalink | Comments (1) | TrackBack (0)

Mechanical Turk: A Human Botnet?

Amazon's Mechanical Turk service: pay someone to perform a task that can be done with a browser/PC. Rote tasks with no questions asked. Of course, there are charges involved. It looks to me like an easy way to build online reputation (and from the likes of it, that is one of its uses). Who knows what you could do with enough money and an army of Turks at your disposal? Maybe a way to cover your tracks or build plausible deniability by hiring a bunch of online impersonators?

Doesn't scale as well as a real botnet, but there are some possibilities here...

January 18, 2009 in Threat Management | Permalink | Comments (0) | TrackBack (0)

More on Benevolent Botnets

Kurt Wismer at antivirus rants posts a thoughtful followup to my benevolent bots post. He probably does a better job than I did explaining the risk of this "benevolence." I agree entirely that as soon as you perform some operation with the bot, either taking advantage of its native capabilities or dropping a new executable on the compromised system, then you are no longer benevolent.

What is more interesting to me is how you might use the passive takeover of a control server (the way F-Secure and the German researchers did) to further security. So this is more like a detection mechanism that may then communicate with a responsder that is authorized on the same client.

For example, Symantec could intercept communications at the botnet server level through passive takeover (I don't support actively hacking a botnet server unless given explicit authorization by some authority) and then either set up its own version of a "real-time blackhole list" for compromised clients and/or communicate with those clients it has an agent on to respond to the problem.

This still doesn't eliminate the problem of false accusation should someone replace a botnet server...

January 16, 2009 in Threat Management | Permalink | Comments (1) | TrackBack (0)

Benevolent Botnets

F-Secure has some very interesting data they compiled after infiltrating a Downadup botnet. At the same time, Chandler Howell at Not Bad for a Cubicle points to an article about a Storm worm/botnet infiltration. Both research groups toy with the idea of downloading their own 'cleaning' software but reject it due to ethical concerns.

If this sounds a lot like the Nematode and benevolent worm discussions of days gone by, you are right. But I think benevolent botnets are slightly different and worth evaluating on their own. They are kind of like an inverted honeypot.

The big difference is the architecture. Rather than a peer-to-peer type model where one client seeks out another, a benevolent botnet impersonates a command and control server and sits passively waiting for connections. Of course, the obvious thing to do for a connection (if you are benevolent) is to download a fix, which puts us right back to intrusive behavior and a definite problem.

But what else could you do if you were contacted by an infected client? The most obvious thing that comes to mind is to notify a different good guy of the infection and allow, say, an automatic update server (patch, av, whatever) to communicate with the infected client in an appropriate way.

It could be none of this matters, because the bigger risk is probably that the benevolent entity is falsely accused of having planted the bot to begin with...

January 13, 2009 in Threat Management | Permalink | Comments (0) | TrackBack (0)

WabiSabiLabi Update

This just in - WabiSabiLabi may close its doors. Here are some tidbits:

"...In the end, security researchers recognised the value of having an auction site like WabiSabiLabi, but very few buyers proved willing to use the site, said Roberto Preatoni, an Italian security consultant and WabiSabiLabi's director of strategy.

"It didn't work very well. The marketplace was too far ahead of its time," he said, adding that a final decision on the fate of the marketplace has yet to be reached."

A little over a year ago, as WabiSabiLabi was getting going, I made some predictions:

  1. No more than 100 vulnerabilities will have successfully been auctioned off at the website by the end of the year;
  2. Maybe 30-40 people will have participated in the auctions;
  3. The site will essentially go dormant or cease to exist by the end of 2008.
  4. If it doesn't go dormant, it will face at least one legal challenge by the end of 2009.

I just visited the site and the only thing I can see is 34 vulnerabilities in the "marketplace history" section (and nothing active). I can't really tell whether this is a complete set of all vulnerabilities offered, though my guess is that it isn't. Can anyone clarify?

Also, does anyone have an alternate explanation for WSL's pending demise other than it being "ahead of its time"?

November 04, 2008 in Threat Management | Permalink | Comments (0) | TrackBack (0)

Undercover Exploits and Vulnerabilities - 10-27-08

Looks like we have a confirmed addition to the undercover exploit list (old list). That makes 21 total since 1988.

  • 10/27/08 - MS08-067 RPC vulnerability (public info).
  • 11/23/07 - Xunlei Thunder PPlayer ActiveX control (credit: Symantec*)
  • 4/5/07 - DNS RPC Vuln (confirmed by Bill O'Malley who also discovered it)
  • 11/3/06 - XMLHTTP 4.0 ActiveX Control
  • 9/23/06 - cPanel (credit: Dave via Adam, Ilja)
  • 9/19/06 - Internet Explorer VML (public info)
  • 9/3/06 - MS Word 0Day (Symantec)
  • 8/16/06 - Ichitaro (Symantec)
  • 7/11/06 - Powerpoint 0day. (public information)
  • 12/29/05 - WMF. (public information)
  • 2/7/05 - Mailman directory traversal. (credit: ilja van Sprundel)
  • 2/4/05: Minix FTP Vulnerability (credit: Ilja van Sprundel, confirmed by Al Woodhull)
  • 11/16/04 - Twikis search.pm. (credit: ilja van Sprundel)
  • 12/04/03 - Rsync. (credit: David Goldsmith, Matasano)
  • 11/20/03 - do_brk() overflow. (credit: David Goldsmith, Matasano)
  • 3/18/03 - WebDAV. (publicly available information)
  • 12/9/99 - Solaris sadmind (credit: Steve Christey)
  • 9/3/98 - SunOS ToolTalk. (credit: TQBF, who never got the beer...)
  • 4/24/96 - rpc.statd. (double credit: TQBF - thanks again.)
  • 11/2/88 - Sendmail (credit: David Goldsmith, Matasano)
  • 11/2/88 - Fingerd (credit: David Goldsmith, Matasano)

Honorable Mention (which don't quite make the list because the vulnerability information was not discovered due to an active exploit):

  • RealServer ../../../ overflow
  • Any of the Immunity VSC releases (Mac OS X Kernel Local, anyone?)
  • Samba bug that HDM got hacked with... [this may get elevated, I am not sure]
  • [Credits: Dave Aitel and Anton Chuvakin for the information]

Definitions:

Undercover Vulnerability: A vulnerability that was generally unknown (e.g. not published on any lists, not discussed by "above ground" security folks) until it was actively exploited in the wild. The vulnerability was discovered through evidence of tampering or other means, not through the usual bugfinding ritual.

Undercover Exploit: The event and/or code used to compromise a resource running the vulnerable software in the wild.

*Note: the "credit" given is not to the person who discovered the exploit/vuln, but to the person who pointed me in the right direction. Thanks, all.

October 27, 2008 in Threat Management | Permalink | Comments (0) | TrackBack (1)

Is China a scapegoat for everything?

Answer: "China"

Question: [insert any question here that has negative connotations]

It seems like China gets blamed for every problem in information security these days.

It is well worth a quick pause to consider just how complex the "China issue" is from a risk/benefit perspective...

<pause>

...without necessarily blaming them for everything. (I saw the first traces of the recent Alicia Keys MySpace contamination, and I could have sworn those Chinese websites actually traced back to Russia at the next level).

This is truly an enormously complex issue; we'll have to keep our wits about us to treat it appropriately from a risk perspective, without giving in to the emotional part.

December 06, 2007 in Threat Management | Permalink | Comments (0) | TrackBack (0)

Should we fight...

Chris at Emergent Chaos illustrates his reason for "going to war" against corporations that are (presumably, but not really) complicit in allowing credit card numbers to be stolen - because it doesn't hit their bottom line hard enough. The real problem is that it doesn't hit our (individual) bottom line hard enough. To wit:

"...TJX executives said that store traffic through the end of January hasn't suffered since its Jan. 17 announcement of the security breach."

Chris' flawed assertion simply assumes that everyone cares as much as he does that some entity's credit instrument which was issued to him would be compromised. But the quote above is evidence that this isn't the case; people are willing to accept the risk, even in the face of multiple shopping and payment alternatives. (There is an entire body of literature around the notion of risk vs. reward that applies here. See, for example, Slovic, et. al. "How Safe is Safe Enough?").

Chris' fight is really against the establishment. For credit cards specifically and many debit cards generally, the burden of cost is the bank and/or card issuer. (It may be interesting to note that today there was a WSJ article talking about a bill in Massachusetts to assign the costs to the retailers that get hacked). Sure, we all pay a little, and those who get compromised pay even more (in the form of personal overhead), but it all appears to be reasonable for many (most?) folks.

To the extent that any of this information can be leveraged into more significant attacks against identities, again Chris' target is misplaced. In this case, the folks who accept this type of information for identity validation - information that is routinely shared to the tune of four billion transactions in a year - should be the real target.

I have great news, Chris - you don't have to fight. If the risk is too high from your perspective, you can simply opt out - credit cards are not a requirement in our society, they are a luxury.

February 22, 2007 in Identity Management, Threat Management | Permalink | Comments (1) | TrackBack (0)

»

About

Categories

  • Identity Management
  • Incidents
  • Metrics
  • Quotes
  • Threat Management
  • Trust Management
  • Vulnerability Management

Recent Posts

  • Best Practices for creating Best Practices
  • Should you swap out Windows for security?
  • Information Systems Security Association
  • The Question of Low Priced PCI Assessments
  • Whenever I read a post like this...
  • Implied Value of Life
  • Why won't anyone define what "failure" and "hopeless" mean?
  • The Scarecrow Knows Compliance... sort of
  • ROI, ROSI and Cost-Benefit of CCTV
  • Mr. Spock's approach to separation: Logical
Subscribe to this blog's feed

Archives

  • October 2009
  • September 2009
  • August 2009
  • July 2009
  • June 2009
  • May 2009
  • April 2009
  • March 2009
  • February 2009
  • January 2009

More...

Blog powered by TypePad