Conficker on the rise - again!

The infamous Conficker computer virus (also known as Downup, Downadup and Kido) appears to be making a comeback. In this past week we've seen two clients from different industries attacked by this worm. The worm uses a combination of advanced malware techniques, which has made it difficult to counter and has since spread rapidly into what is now believed to be the largest computer worm infection since the 2003 SQL Slammer.

At a minimum, all your computer systems should be updated with the latest virus definations and Microsoft has released a removal guide for the worm, and recommends using the current release of its Windows Malicious Software Removal Tool to remove the worm, then applying the patch to prevent re-infection.

Read more!

Launching Exploits with Browser Detection

I recently published the latest FireFox 3.5 Heap Spray exploit to the public. This vulnerability took advantage of a font tag overflow which ultimately allowed the attacker to perform a heap based spray and execute code on the remote system.

A little basic background on heap sprays, they are relatively simple to exploit. The attacker essentially fills the heap with tons of "nops" (no operation) (in this case 0c0c0c0c which ends up being our return address) and ultimately the shellcode. When the return address is overwritten, it will point to a place in the heap (0c0c0c0c) which is a pretty good shot will be somewhere in our nops and ultimately continue to process no operations until we hit our shellcode. The reason why these exploits are not 100 percent successful is while we have a good percentage (typically 90-95% clip sometimes smaller) to hit our nops and ultimately our shellcode, sometimes we can land in the heap where we haven't overwritten everything, or in the middle of our shellcode, which would produce a crash.

Take a peek at the exploit code here: http://www.milw0rm.com/exploits/9181

Basically, the exploit will setup a webserver on port 80, you then connect a FireFox 3.5 browser (already patched by the way) it will trigger the overflow, spray the heap, and ultimately execute a bind shell on port 5500. This exploit code is inefficient in major way because it will attempt this exploit on anyone connecting to it regardless of browser, OS, or whatnot. More importantly, this exploit is ONLY for Windows based systems. To have a little more fun with this one, I decided to craft it a little differently now that the patch is out. We can make this much more reliable and efficient but throwing in some simple browser javascript detection and make this more of a universal exploit for a variety of different operating systems. If you look at the latest Fast-Track commit:

http://svn.thepentest.com/fasttrack/bin/exploits/firefox35.py

I've taken a few steps to allow you to attack both OSX, Windows, and Linux systems.

First lets take a peek at the first line:

// Initial detection for Firefox.
if (navigator.userAgent.indexOf("Firefox") != -1)
{

This will detect if FireFox is present, if so, continue on:

// Detect Windows and Linux
if (navigator.appVersion.indexOf("Win") !=-1)

If the OS is Windows, then set the payload and nops/return address to Windows based systems.

// Detect OSX and Firefox
else if (navigator.appVersion.indexOf("Mac") !=-1)

If browser is "Mac" then load the payload and nops/return address to Mac based systems.

// Detect Linux and Firefox
else if (navigator.appVersion.indexOf("X11") !=-1)

If system is *NIX, then load the payload and nops/return address to *NIX based systems. In this instance, it will only cause a FireFox crash.

Next:

else
{
window.location="about:blank"
}

If none of the criteria are met, then just load a blank page. This is useful for us when we have something like Internet Explorer or Safari that we know is not vulnerable, no need to actually execute the exploit right?

Alternatively using python it is also just as easy. I'll blog later on the method about detecting user-agents within the HTTP server within Python and handling those requests to perform the same functionality.

Read more!

Blogger/BlogSpot Cross-Site Scripting

So the other day I posted a unique blog on here relating to Cross-Site Scripting(XSS), and our account got suspended. I simply posted an image with the "onmouseover" attribute in the image tag to do some simple JavaScript alerts, notifying you that it could have been an XSS stealing your username/password, redirecting the page, logging your keystrokes, or even launching a buffer overflow against your browser. This is definitely not new news at all [1], however they have appeared to try to fix it (very poorly may I add) sometime in the last year. They attempt to filter certain things is a decent start since I documented over a year ago (06-27-08) [2] where you could type in a simple <script>alert('xss')</script> and it would work. Either they have failed at fixing it, or just don't care. Whether or not some of you reading our blog reported it as spam or perhaps Blogger/BlogSpot noticed my proof of concept and didn't approve, let's just hope their approach to information security is not like that of the United Nations [3], who apparently get hacked in 2007 via SQL injection and publicly blogged about, and continue to be vulnerable as of 07-01-09 [4], as gathered from Google cache data. Either way, many people wonder why there are so many breaches, and penentration testers like myself know that the vast majority go unreported. With so many vulnerabilities indexed in Google, and a slow/poor response to fix them or having them attempted to be fixed and done so incorrectly, no doubt, it is a matter of WHEN, not IF your information gets compromised.

UPDATE: Apparently I was trying to hard with my XSS proof of concept the other day and I stand to be corrected: A plain vanilla open and close script tag with an alert in it still works. From what I can tell, the input for the "Compose" view is HTML Encoded when published and the "Edit Html" view is published raw. Maybe after a few years of knowing about the problem and not doing anything about it, they should be nominated for a pwnie award[5]?

Read more!

Verizon/Cybertrust QSA in Jepoardy

Looking at the latest QSA list from PCI (https://www.pcisecuritystandards.org/pdfs/pci_qsa_list.pdf) shows Verizon/Cybertrust to be in a number of possible QSA violations and failure to comply with a number of applicable QSA Validation Requirements. We've all known for sometime that the larger scale breaches (Hanniford, TJX, and others) have occurred under the watch of Verizon/Cybertrust. While I don't think the blame solely should be placed on them..They are still under an obvious review that should have been done a long long time ago from the PCI Counil. But in mentioning that, solely relying off of a compliance standard to secure you is about as effective as getting some magic snake oil. It's still a start, its the most technical compliance standard out there, but is still a compliance standard, not an information security program.

I do think this is a rude awakening for companies that are maintaining QSA's and don't perform quality work and perform the audits to the fullest extent of what the standard requires. I really do hope that companies will start working with their customers instead of rubber stamping because they send junior consultants or lack the expertise in order to complete the entire requirements list.

This should also keep several information security professionals up at night knowing that they might be as compliant as they originally had anticipated.

One thing that has totally upset me with the entire PCI process is once the breach occurs, guess who comes in to investigate? Oh would you be surprised if Verizon/Cybertrust comes back in to see how the breach happens? Does that seem completely crazy to anyone else but me?

Read more!

IPhone 3g S Enterprise Ready?

With the latest release of Apple's iPhone, the question arises to most IT savvy individuals: Is it ready for our enterprise?

There are a slew of enhancements that Apple has specifically focused on in order to attract the attention of the private sector. Most people don't know that the new iPhone Configuration Utility 2.0 allows a laundry list of configurations that enhances the overall security and control through policy. While these features are a great start, they still don't match up to Blackberry's configuration overall. Most specifically the BES Server policy management and configurable options.

Some of the features out there that iPhone does support is:

Password complexity
Remote Wipe
Hardware based encryption
VPN Access
Wireless Security Policies

and much more.

Overall, do I think the iPhone is enterprise ready yet? Most people say no. I would say why not. If you can enforce security policy on the device, ensure that the information is encrypted, and protect your mobile information in a centralized manner... Then whats the big quarrel? Is it as good as Blackberry? No. But it IS manageable if you decide to move forward with it.

Some links:
http://www.apple.com/support/iphone/enterprise/
http://manuals.info.apple.com/en_US/Enterprise_Deployment_Guide.pdf
http://support.apple.com/downloads/iPhone_Configuration_Utility_2_0_for_Mac_OS_X
http://support.apple.com/downloads/iPhone_Configuration_Utility_2_0_for_Windows

Read more!

Check, Please!

One of the most intriguing stories in the security world today is the lawsuit Merrick v. SAVVIS in which Merrick stipulates that SAVVIS is liable for lack of diligence on an audit of CardSystems, on which Merrick relied. This groundbreaking lawsuit could change the liability landscape, allowing assessors to be sued by indirect third parties. Prior to the more formal PCI DSS program, there were many suspicions of rubber stamp audits occurring. But even today, we see organizations pushing for the cheapest audit they can do and still get the passing “check” mark. It’s this minimum approach to security we’ve often called “malicious compliance” that leads to a lack of quality and a greater risk of breach.

Just for some more background, SAVVIS had certified CardSystems Solutions as compliant under the VISA CISP program (predecessor to PCI DSS). During a breach of CardSystems, approximately 40 million cardholder data records were compromised. At that time, this was one of the biggest breaches recorded. The forensics investigation concluded that the CardSystems firewall was not compliant and that records were not being encrypted as they should be. The big debate at this point will be to determine if SAVVIS did enough due diligence at the time or if CardSystems possibly withheld any information from the auditor.

I think that last sentence is really what irks me about the relationship between an auditor and an organization. I completely understand and agree for the need of ethical independence between both parties. But I am frustrated when it creates such a wall and lack of collaboration that the auditor just becomes someone to fill in check boxes. Then the organization takes an adversarial approach in which they ‘speak only when spoken to’ and hope the auditor doesn’t uncover the dirty little secrets of what isn’t working. It’s when something isn’t working right that a breach occurs.

So when looking for an auditor, I think it’s important that organizations make a conscious, formal decision on what they are looking for. It’s the old Chinese proverb, “Be careful what you wish for since you might just get it”. If it’s a check mark approach, then understand that may be all you are getting. You aren’t getting a consultant or an advisor. On the other hand, if you are looking for a auditor who isn’t just working off a checklist but is truly interested in your organization’s risk, then you can end up with a partner that can provide a whole lot of value, not just for compliance but also for security, since the two aren’t the same.

I guess the whole point of this exercise is to step back and take a look at your organization’s approach to the quality of the security program. The most common approach is following the “Plan, Do, Act, Check” lifecycle. As a pure security assessment firm, we feel very strongly that there needs to be a big emphasis on the “Check” step, so much that we put it first. No matter what step you are performing, you need to do it well if you want quality improvement. Security is not a very forgiving practice as a misstep in quality can quickly lead to incidents, then the blame game, then someone’s job. That’s not to say that quality is costly. But cheap certainly is. So the next time you place an ‘order’ for an auditor, think twice when you ask for the check.

Read more!

The Human Exploit

So you're sitting at your desk and the phone rings. "Hey this is Mark from information security. We are noticing that your computer is creating a lot of traffic out to the internet. Are you noticing that anything on your computer is out of the ordinary lately?"

What would you say? Well, in the average Social Engineering test we perform, the answer is quite honestly a, "yeah my computer is slow... can you guys finally come and fix it?"

That’s when we say, "Sure! We’d be glad to *cough* help! Go here, download this patch, and run it..." and a couple minutes later we have fully compromised a system sitting behind a firewall in a corporate environment and easily getting past the antivirus software as well.


On average, we are able to get over 70% of end users to comply with anything we want them to do in "fixing" their computer, by just dialing their number and talking to them. How would you feel knowing that your end users are freely giving their computers and data away to attackers over the phone?

So what can you do to stop it? Well, a lot actually. Depending on your budget (which these days is low for everyone) you have the option to proxy all of your outbound connections, close down your firewall, install HIPS/NIPS protection, and the list goes on.

Sure you can do a lot to MASK the problem, but when are you going to stop the problem at its source? No, I am not advocating firing everyone you work with, but I am saying that there should be policies, procedures and MOST of all, end user training to teach people about these attacks.

People are most always willing to help, lend a hand and be polite and courteous to others on the phone. In reality, this type of attack could happen to virtually any company. In fact, the larger the company is, the easier it is to exploit.

The moral of the story is that unless you have some type of training involved for employees, they are very susceptible to Social Engineering. Even these days. Next time, it just might not be SecureState on the other end of the phone, it could be someone with a malicious intent.

Read more!