Monday, May 30, 2011

Lenny Zeltser on Information Security — Tracking Known Malicious Websites by ETag Identifiers

Tracking Known Malicious Websites by ETag Identifiers

Anti-malware companies as well as organizations that protect their own networks benefit from keeping track of known malicious systems on the Internet. The goal is often to block inbound access from known malicious hosts and also to restrict outbound connections to them. The undesirable systems are typically identified using IP address, domain names and URLs. Research by CompuCom’s Ramece Cave suggests adding ETags to the list of identifiers of malicious websites.

ETag is an optional HTTP header that was designed to make it easier for web browsers to cache website contents, thus improving the pages’ load time by avoiding downloading content that the user retrieved earlier. ETag acts as a fingerprint of the web server’s content; if the content changes, the server will generate a new ETag, indicating that the browser’s prior copy of the content should no longer be used.

Attackers sometimes use the same instance of the malicious page and web server, but expose it using different domain or server names. Ramece found it effective to use ETag as the unique identifier of a malicious page. This seems more efficient than keeping track of the numerous domain or server names the attacker might use. CompuCom’s research team:

“Identified a single ETag associated with malware which could be used to filter 12 domains as well as identify compromised hosts trying to reach command and control domains.”

Based on this information, the team created an IPS rule to flag web traffic that included the malicious ETag.

While there are several sources of known malicious IPs and domains, I haven’t seen the inforsec community discuss the use of ETags to track known malicious websites. Is this a promising approach or is does some limitation make it impractical? Perhaps time will tell.

If this interests you, check out the 2-day Combating Malware in the Enterprise class I’ll teach in DC in July; code COINS-LZ gets you a 10% discount. Also, I’ll teach a more in-depth Reverse-Engineering Malware class on-line this summer; get a free iPad 2 if you sign up by June 22.

Lenny Zeltser

This is really interesting and I'm surprised to not see it being discussed by the IPS, NGFW, Network Forensics and Threat feed vendors more extensively. Shouldn't we be putting up some sort of public database of malicious ETags to be used by those tools?

Friday, May 27, 2011

Vulnerability reporting in the age of social media - F-Secure Weblog : News from the Lab

Vulnerability reporting in the age of social mediaPosted by Mikko @ 13:28 GMT | Comments

Last night, I was searching for an old email when I spotted this funny header:

Tweetdeck XSS

Somebody had a sense of humour, inserting a XSS joke in email headers.

I thought it was funny, so I posted about it to Twitter:

Tweetdeck XSS

Few minutes later, I saw Robin Jackson reply with this:

Tweetdeck XSS

That can't be real. No Twitter client would execute Javascript just because a Tweet would contain a "script" tag.

Tweetdeck XSS

Tweetdeck XSS

To prove it's real, Robin posted a screenshot.

Tweetdeck XSS

The client he was using was Tweetdeck for Chrome. Time to inform the developers. And of course, they are on Twitter as well.

Tweetdeck XSS

Randy Janinda from Twitter's security team responded within minutes:

Tweetdeck XSS

Tweetdeck XSS

Tweetdeck XSS

And just two hours later I got the confirmation from Tom Woolway of the Twitter development team that the fix is out:

Tweetdeck XSS

Signing off,

The security community working as it should. Collaboration, speed, effectiveness, no fussing around, quick response. Good to see it. Congrats to Mikko, Robin Jackson and the Tweetdeck (Twitter) guys.

Tuesday, May 24, 2011

ShackF00 » Less Talk, More Action

Earlier this month in NYC, my friend Marcus Ranum and I were having dinner and drinks after a day at the IANS forum. Marcus, in a lighthearted mood, posed the following question to me:

A fight breaks out between giant robots, pirates, and ninjas. Who wins?

We had a fun and spirited debate about this, and laughed at the sheer ridiculousness of the question itself – a pointless conversation, but fun, to be sure. The problem is, we’re having a lot of the same kinds of conversations in infosec right now.

Recently, my friend Josh Corman posted an article on CSO Magazine’s site entitled “The rise of the chaotic actor: Understanding Anonymous and ourselves”. As I would expect (coming from Josh), it is interesting, well-written, and insightful. It’s also totally, completely unimportant. Let me say that another way: IT’S A WASTE OF %*&^$ TIME. Now, lest you get the impression that I am bashing Josh, please know that I am not. I count him as a friend, he’s incredibly smart and talented. In fact, his Rugged Software project is one of the best, and likely most important, efforts underway in the infosec industry right now, and needs all the support it can get. But this? Drivel. And no, it’s not the content that chaps me. Not at all. Although, I must say, the use of D&D references crosses even MY boundary of geekiness acceptance.

Nope, not the content. What, then? The thing that pisses me off about this, and lit a fire under my ass yesterday, is that Josh, and CSO Magazine, put this out there with the disclaimer that this was “important”. Folks, it is not. It’s not because this kind of input is the equivalent of my conversation with Marcus – a watercooler discussion point, an anecdote, a thing to have a short chat and discuss casually – NOT something that will really change the fact of what we are dealing with. And what we are dealing with is the same problem we’ve had for a while now, in my opinion – too much blah blah blah, not enough elbow grease security.

I don’t blog a whole lot. I spend my time in a breakdown that consists of about 30% teaching people to fix shit (sometimes by breaking it first), 60% actually fixing shit (or breaking it first), and 10% speaking about these things. That is 10% of my time spent proselytizing or (hopefully) educating in some way, usually on a technical subject. What I see a lot of out there is people wasting their cycles debating shit that DOES NOT HELP ACTUALLY SECURE ANYTHING. This is not a good trend, folks. We need more do-ers, people who can put hands to keyboard and actually get some security done.

Josh and I had a spirited debate about this on Twitter. He reminded me of the Plan-Do-Check-Act cycle, and said we need to Plan before we Do. He’s right, of course. I’m not insinuating that. But this is not planning. This is mental masturbation. And too much planning, with too little doing, leads to “analysis paralysis” and that is a death-knell for your security program. I’d rather see a CISO who’s a former drill sergeant than one who is an endless pontificator of “what could be”. My friends Alex Hutton and Mike Dahn made small points that are valid – Alex reminded me that not all work is purely hands-on technically, as he and his team at Verizon compile metrics and risk data that all of us rely on. Totally valid, and that IS important. Mike nudged me and said that theory and practice must go together like PB and J (great analogy), and certainly there’s some truth to that as well. But if you are ALL theory, or spend too much time there, you don’t get around to the doing. And there’s a lot that needs doing. Check this stat from Alex and team’s latest Verizon Data Breach report:

Wow. If we spent just 10% of the time we waste on mental masturbation like “what do they want? who are they? are they nice people” kinds of crap on ACTUALLY hardening boxes, screening and pruning ACLs and FW rules, tuning IDS, performing sound vulnerability management practices, and actually fixing our code, we’d be in hella better shape. Are these conversations fun? Sure. Do we need to really rethink our focus? Maybe. I personally do not care if Anonymous is a secret league of 1337 grandmothers from Poland, or whether they want to hack me for vengeance, political motivation, or just plain old theft. Nope. Don’t care. I just know I have adversaries, and I need to protect my sensitive data. That’s what I care about, and that’s what you should care about too.

A few months ago I posted a post-RSA note on “Change we can Believe in”. I had grown tired of all the whining in this industry about how we “need change”. Well, here’s a change for ya: Stop wasting your time on crap like this that is not impactful unless you are a state agency. Most of us just need to hunker down and fix some things.


Thas was simply perfect. I completely agree with Dave, not only with his main point but also on the high quality of Corman's article. I wasn't actively following my Twitter feed when they discussed all this, but after I read the comment from Mike Rothman I decided to read both sides. I confess that Corman's piece was so ethereal I only scanned through parts of it.

It's interesting and important to debate over the adversary motives, means and opportunities. That's a crucial part (but not the whole) of the intellectual work to identify priorities. But as Dave was quite clever to point out using the 96% number from this year's DBIR, we might end up being breached through obvious stuff while discussing the colour and the "chaos level" of the adversary. Again, using my blog's motto, balance is the key.

In terms of practical advice, if your organization is big enough to justify it, having different teams to work on different work streams like Threat Intelligence and Vulnerability/Exposure Management is probably the best way to deal with it, both bringing their results to a prepared executive who can check if those two different activities are complementing each other.

Friday, May 13, 2011

Reporting breaches to SEC

Just saw this in Yahoo! Finance:

, On Thursday May 12, 2011, 8:00 am EDT


By Victoria McGrane and Siobhan Gorman, Reporters, The Wall Street Journal


A group of U.S. lawmakers wants the Securities and Exchange Commission to push companies to disclose when they have fallen victim to cyberattacks.


Three weeks after Sony Corp. was forced to shut down its PlayStation network by hackers who stole users’ information, the group, which includes Senate Commerce Committee Chairman Jay Rockefeller of West Virginia, on Wednesday sent a letter to the SEC asking it to issue guidance stating that companies must report when they have suffered a major network attack and disclose details on intellectual property or trade secrets that hackers may have stolen.


The SEC guidance should also clarify that existing corporate-risk disclosure requirements compel companies to disclose if they are vulnerable to cyberattacks, the five lawmakers, all Senate Democrats, said.


Read the rest of this post on the original site

This is really interesting and can change the way companies deal with breaches. I can see C-level executives asking the CSO about what's being done to ensure they won't have to report anything to SEC :-)

Wednesday, May 11, 2011

Web applications security - one size does not fit all

I was reading a very good post about a Application Security Program implementation from George Hulme and saw something that is mentioned quite frequently in this field: don't try to boil the ocean when pushing security to your developers. It's kind of obvious when you read it, but there is an important question to ask when you assume that you'll prioritize on the most important apps and more critical vulnerabilities; what about the rest?
It's an extremely valid question, specially when you take a look at some recent breach stories. Take as example HBGary, who was breached through an SQL Injection in an app that wasn't considered "critical". I've seen dozens of similar cases, so we can certainly say that it's not that easy to dismiss non critical apps or vulnerabilities. So, if we can't leave them behind, does that mean we have to go with the "boil the ocean" approach?
Not necessarily. There are multiple options to tackle application security issues. Building a robust SDLC and having developers who understand security is certainly "the best" way to avoid vulnerable applications, but we cannot forget those other "reactive" alternatives, such as IPS, WAF (Web Application Firewalls) and other "silver bullet" boxes. So, if you want to prioritize your critical applications and  the most critical vulnerabilities in your SDLC, be sure to add some other control to deal with "the rest". That's all about protecting everything that can be exploited, but with different assurance/quality levels according to the importance of the assets and cost of controls.