Wednesday, February 28, 2007

I wanna be a Security Evangelist

A few months after mentioning on his podcast that he wanted to be a Security Evangelist, Martin McKeay was hired by StillSecure for this position. Hey security companies out there, this is my dream job too! :-)

An important thing to say, Martin made it by deserving it. Congratulations. I hope to achieve the same someday.

Monday, February 26, 2007

Features and the security point of view

The SANS ISC diary today is mentioning a javascript function present in today's browsers called onUnload(). What does it do?

The browser will execute it when the user is leaving that page. Very interesting feature, isn't it?

Well, not when you start looking with the eyes of security, as the post on the diary does. Those pop-up filled websites can prevent the user from leaving then just by executing a location=self.location when the onUnload is called. Incredibly simple and effective (at least for them). They can also pretend that the user is really leaving when it's actually not happening, giving room for a lot of phishing attacks.

This is a very good example of how a software feature can be seen when you put the Security Googles on. You need to do that every time when your developers are buiding new code. Do you have ayone thinking about the side effects of new features of your software?

A fnal remark about the onUnload() function is that it can, in fact, help on some security aspects. Just remember that almost no users leave a web application by clicking on the "Log Out" button/link. You can force the logout procedure by detecting the user leaving the website with the onUnload() function. At least a good thing for us.

Thoughts on MS Security Intelligence Report

It's old news, but just now I've found time to comment about the MS Security Intelligence Report.

Some things confirmed some of my opinions about the Brazilian security field.

First, banks here are quite more advanced on figthing phishing and malware against their clients than other contries. The report shows that password stealers and key loggers malware are a very common threat in Brazil. This is happening for years, what made our banks to migrate their online banking systems from simple password authentication to much more complex security systems. Today it will be very hard to find a bank here that is not using a different password for the debit card and for Internet services, on-screen keyboards, anti-malware plugins and OTP cards. We should really think about showing all those things on the regular security events around the world. It's funny to see that too fw people know about this.

There is information too about the use of Instant Messaging as a social engineering attack vector. Puting information leak and productivity issues aside, it shows that blocking IM seems to be not so necessary as it seemed before. If you consider that Microsoft Messenger updates can also be published by the regular patching systems (WSUS, Microsoft Update), it won't be something that really really must be forbidden. If your business like to use it, keep it working.

Another interesting data is the normalized view of Windows version with detected malware. Windows XP SP2 is responsible for only 3.7% of the cases. It clearly shows that even before Vista the last security improvements from Microsoft are having effect.

Log Injection

I've just read an interesting paper from SIFT about log injection. It just remebered something that I think it's very interesting, but not very new. I remember a very good presentation from the Sensepost guys in Blach Hat US 2004.

They showed a number of ways to fool people running attack tools against their network. Among those things they mentioned how was easy to exploit tools that generate HTML reports. I wonder how deeply it can go. There are lots of security tools that generate beautiful reports on HTML. Are they safe from this kind of attack? And what about current log analysis and SIM/SIEM systems, are they prepared to deal with log injection attacks? I wouldn't bet too much on it.

Fix Users

I've been away from the blog for a few days (lots of work to do before Black Hat), but I took note of this little article from Dark Reading.

This is a discussion about the value and results of training users. I have mixed feelings about it. I really believe that training users must be part of a security program. However, I must also admit that there are limits about the effectiveness of this measure. Afterall, they are humans. You can make 80% of your users avoid problems, but 20% will certainly look for them even after months of training.

On the DR discussion, RSNake mentions that you need to keep harmful things far from the users. I agree with him, specially about the local admin. A big problem is that on most of the organizations there are lots of people with special privileges on their workstations, mostly IT staff. These are the most dangerous, as they use to have dangerous tools installed and critical information access. They also think that they don't need security training, what is different from the regular business user, that knows that there is risk and that he/she doesn't know how to avoid it.

I think that problems from users actions is like a big hole being covered from two sides. One of them is the least privilege and default deny concepts. We need to take them seriously. The other is security awaress. Both sides are not enough to close the gap alone, but increasing both together will achieve the goal.

Friday, February 23, 2007

Black Hat Europe - Here we go!

Finally I've found time to write about my new challenge: to speak at the BH Europe!

I'm working on a botnet trends review with André Fucs and Victor Pereira, my old friends in security research. We already built some interesting things to show there, and I hope that some others will be ready for the presentation too. It's our first international presentation, so we are a bit anxious about it. There will be a presention from Jose Nazario on Black Hat DC next week, it seems that he'll show that some things that we will be indicating as trends are already being detected. Good to know that we are on the right track.

Monday, February 12, 2007

Modern malware

I've just read a very interesting analysis of a new malware on SANS ISC. They've found a malware that downloads a password protected zip file from a HTTP location. The contents of this package is encrypted. The malware also uses a certificate to establish SSL connections to the IRC control servers, avoiding detection by network IDSes. Very interesting.

However, this one still doesn't solve the major obstacles for malware spreading. It tries to use a simple TCP outbound connection to talk to the servers, what is usually blocked by well configured firewalls. It would be far more difficult to block it if it tries to use SSL HTTP connections through a common proxy setup. The malware could search google for an specific string (or a dynamic string generated by some sort of pseudo-random number generator), finding dynamically the URLs where it could download its commands.

Another thing that is interesting on that analysis is the note from the ISC handler saying that most antivirus are still not able to detect this malware. He mentions defense in depth strategy, what is absolutely right. The use of anomaly detection is also an important feature to fight these new malware threats. I'd like to see how the SONAR technology from Symantec would react against this particular case.

Tuesday, February 6, 2007

Other view about anomaly-based detection

I am a huge fan of anomany-based detection, instead of using the old and innefective signature-based. I'm always saying that about IDS and antivirus. However, it's always good to see different opinions and information. I've found this article very interesting, as it shows some problems related to anomaly-based detection. It's a very valuable reading.


I've heard last week, on a Executive Board meeting, a CEO complaining about IT budget requests that he was receiving trying to justify the expenses by showing a ROI. He mentioned that almost all were wrong, as they were based on cost avoidance and not cost reduction. Although none of them were related to security, I found his comments extremely pertinent to the famous ROSI discussion. I'm glad to see that my personal opinion about it is aligned with what the CEO of the company that I work for thinks.

Security monitoring - NSM and Logs

I really like to work with logs when the subject is security monitoring. In fact, all my Master Thesis is based on log analysis. However, Richard Bejtlich is right about some weaknesses on doing it only based on logs. He is quite right on saying that the absence of logs does not confirm integrity. He proposes the use of network sensors and other tools and procedures (in what he normally calls Network Security Monitoring, NSM) to complement the security monitoring process. It's a very good concept.

Silver Bullet Podcast

The "Silver Bullet" podcast, from Gary McGraw, is very good, and you probably already know about it. Imagine now an episode with:

  • Bill Pugh, Professor at University of Maryland, static analysis for finding bugs
  • Li Gong, GM at Microsoft, MSN in China
  • Marcus Ranum, CSO of Tenable Network Security, security products trainer
  • Avi Rubin, Professor at Johns Hopkins, electronic voting security
  • Fred Schneider, Professor at Cornell, trustworthy computing
  • Greg Morrisett, Professor at Harvard, dependant type theory
  • Matt Bishop, Professor at UC Davis, computer security
  • Dave Wagner, Professor at Berkeley, software security and electronic voting
This is very, very worth listening to!

Thursday, February 1, 2007

EV SSL - Was it really necessary?

There is a new security magic solution! It's called Extended Validation SSL certificates.

For me, this is extremely dumb. First, do you really know what kind of security a SSL certificate can provide?

SSL certificates can't provide security by themselves. The certificate role during a SSL session is to provide a way to ensure the identity of the peers, normally the server only. They are digitally signed by a company that is trusted by both parties in the communication.

What? Who is this 3rd party that I trust? I don't remember saying that I trust nobody to do that!

These companies pass through a process that allows them to be pre-installed on the most used browsers in the market. When you install IE or Firefox, for example, you are implicitly trusting on these companies to verify the identity of the web sites that you access through "https". This is that old "lock picture in the corner" thing, if it's there it means that the identity of site that you are accessing was verified by one of those companies (well, in fact it's not so simple, you have the choice to trust whoever you want, but let's keep it simple). If you click on that lock you will see the digital certificate that the site is presenting to you, with some information about the organization that acquired the certificate.

These companies that you trust are the Certificate Authorities. They need to check the identity of the organization that is requesting a certificate to put in its web site before issuing it. This verification process varies from each company to another.

That lock thing, however, was not being enough to avoid phishing sites. So some companies decided to create a "certificate on steroids", called EV-SSL. This new certificate could only be issued by CAs after a more thorough identity verification process, to avoid that company A will create a certificate for its site with the name of company B.

Besides that, new browsers would show more information about the web site being visited, as well as showing the address bar with a green color. That's nice. The company wanting to use it on its site just need to replace its current SSL certificate by an EV-SSL certificate paying an additional fee and passing through the verification process.

OK, so the EV-SSL brings more security by two ways:

- Better identity verification before the certificate issue
- More information about the site being visited presented by the browser

Hey, did somebody noticed that there wasn't a need to create (and to make companies pay more) a new kind of certificate to do that??? Why didn't the CAs just start following more strict verification processes for the regular SSL certificates? I bet that if Microsoft start threatening those CAs to remove their certificates from the Trusted Root CAs from IE if they don't improve their processes it would have the same effect. That green bar and more identity information presented could be done for any SSL certificate too.

But the CAs wouldn't be earning a few hundred bucks from every company with a SSL website with this approach...