All posts by abaumhof

in-depth report, Malware

Man-In-The-Browser 101 or “it works as designed” (Win & Apple Mac)

Leave a comment

1 Executive Summary

Everybody is talking about Man-In-The-Browser (MITB), so I thought we’d do a little 101 session on how these Man-In-The-Browser Trojans work. As there is way too much focus on the big guns such as Zeus/SpyEye out there, I thought we’d use one of the less known Trojans as an example and even discuss the implications on Mac OS X as well.

While the exact details are different, Man-In-The-Browser threats are also valid on Apple’s OSes (on iOS, sand-boxing and signing makes things pretty difficult, theoretically not impossible, and a lot easier if the device is jail-broken).

2 Introduction

For this paper, we’ll use a sample with MD5 of 3618ff28e3c0d48a09dbae5b5b42585a which seems like a new variant of BankPath/Multibanker trojan. It has a Virustotal detection of 9/43 (20.9%) – http://www.virustotal.com/file-scan/report.html?id=5fc899cbaa6e22aa8bbffb43bee778c7e6d4ad07597a14d5e280719941e33270-1306853690

While we looked at a Bankpatch Trojan in very much detail in an earlier post (http://www.trustdefender.com/trustdefender-labs-blog-banking-malware-bankpatchc-shows-that-the-bad-guys-are-extremely-innovative.html), this one seems to be different and we only want to focus on the MITB features as a part of the broader MITB discussion.

Man-In-The-Browser threats are malware that operate within your browser and have full access to the current Internet session and can change the web-page, add content, remove content, steal information and much more. Please note that it doesn’t matter whether the site is using SSL (or even EV-SSL) as the malware gets access to the content before its encrypted.

3 How does MITB work?

3.1 Windows

Now let’s have a look how all major Trojans do this at the example of Bankpatch and Internet Explorer. When the Internet Explorer opens a connection to the Internet, it will call a function named “InternetConnect” which resides within the wininet.dll module that every Windows installation has.

This is illustrated below:

MITB Trojans will now just “hook” into this first call between the Internet Explorer Application and the Windows System, so that the Trojan get full control over everything that is transmitted in this “call”.

3.2 Mac OS/X

But what about Mac OS X? As mentioned earlier the details are a little different, but the result is same. If a web browser is using the system API to manage its Internet connections, then malware simply needs to hook CFReadStreamOpen(), CFReadStreamRead() or CFReadStreamWrite()  in a similar way to the one described above.

3.3 Hooking

On a high level, it looks now as follows

 

On Windows, we will be able to accomplish this with just a change of 5 bytes in the Internet Explorer process! wow.

On Mac OS X we could take advantage of the lazy linking system used for resolving external symbols, and simple overwrite the resolved address with one of our own. So it would only take 4 bytes on Mac OS X (simply the address we want to call inserted into the appropriate location). This could be done either before or after the symbol resolution has occurred.

The interesting thing is that this is very easy to accomplish, so let’s have a look what Bankpatch is doing:

On a good system, a call to “InternetConnect” will go to the following location

 

Don’t be scared at the technical details, most of the info is not relevant, but what’s relevant is that the first three lines are always the same for every single function and is called “prologue”. An obvious question is why do we need this prologue?

3.3.1 Works as designed

And you can believe this or not, but this prologue was designed to enable “hot-patching” (see Microsoft http://blogs.msdn.com/b/ishai/archive/2004/06/24/165143.aspx). Wait a sec… hot patching??? You heard right… The first two bytes are not needed at all, but it is designed to allow a redirection of this function.

Can someone repeat this for me??? Man-In-The-Browser by design from Microsoft??? wow.

That’s pretty much what it is.

In order to “hook” into this call, the malware needs to do two things.

  • Firstly it needs to jump to its own codebase so that the malicious code is executed.
  • Secondly it needs to make sure that the original code is called (otherwise no internet connection would be established) as well.

 

The first part can be accomplished with 5 bytes (a JUMP instruction + 4 bytes address). As the prologue (that is not really needed) is exactly 5 bytes long, the malware can just overwrite the prolog and everything is fine… That’s convenient and easy.  The picture isn’t much different on Mac OS X. We just need to overwrite the address of the destination function (say CFReadStreamOpen) in the target executable look up table.

3.4 Let’s put this all together

Let’s see how Bankpatch uses these first 5 bytes to get access to the full internet traffic

 

So instead of the normal prologue, there is an unconditional jump (jmp 009b841f) basically telling the CPU to execute the Bankpatch code whenever InternetConnect is called. After Bankpatch does its work, it will then obviously call the original function so that the internet connection is established.

That wasn’t too hard, was it?

3.5 Mitigation approaches

If we replace the original prologue, then Bankpatch will not do any harm anymore. On Mac OS X, we can simply force the dynamic linker to look up the correct symbol again. Problem solved… without knowing any details, … Without any blacklist, heuristics, … Straight and simple…

Well, in reality its not so simple as the Trojan can just change those few bytes again and restore the hook, but we hoped to shed some light on how MITB Trojans do their dirty work, regardless of platform.

To make matters worse, signed binaries don’t help here either. On Windows, only the disk image is signed and once the file is loaded into memory, anyone can make any changes to it as there is no signature to the memory image.

On Mac OS X, lazy symbol resolution is part of the OS design and unavoidable.

4 Conclusion

As you can see the actual hooking of the browser isn’t a major hurdle and can be done easily. What is obviously more interesting is what Trojans do once the hooking has been done. This is where the MITB malware configuration comes into play with its bank-specific definitions and different behaviours depending on a particular situation. We have covered real-world examples in a number of other post re Zeus, Carberp, Gozi, etc.

The thing that is more amazing is actually that every single MITB Trojan uses these kind of hooking techniques, but hardly any Antivirus Engines or Security Suites look at these things.

Of course the TrustDefender Forensics Engine does.

Malware

Is Twitter the next big malware distribution mechanism?

Leave a comment

There is no question about the success of twitter, but the real-time nature of twitter brings some interesting security challenges to the surface.

First of all, many tweets contain shortened links where it is unclear what the “real” destination address is. You have no idea where you end up. There are countless examples where just the mere visit of a page leads to infection. In fact all exploit kits are designed to do so. One example is here: http://isc.sans.org/diary/Hit+by+MacDefender+Apple+Web+Security+name+your+Mac+FakeAV+here+/11053

The other problem is obviously the social problem. You follow someone on twitter because you are interested what they have to say (well that’s not really true, but anyway). So if they share a link, the click-through rate is pretty high. This in addition with the inability to determine where a link ends up with is a recipe  for disaster.

Which brings me to the main point: The main security mechanism employed here is trust. I know the person I’m following and therefore I trust him/her and therefore any links are trusted as well. Seriously, what can go wrong?

The problem is that this opens up a whole new dimension of malware distribution. Typical ways are email (spam), drive-by-downloads, providing infected serial key generators to software that people are desperate not to buy a software they use, search-engine-poisoning, just to name a few. But all these are insignificant if I could manage to provide a malicious link (that nobody would detect as such) to millions of followers on twitter.

What would be the options?

  • The hard way would be to start tweeting up until you have enough followers.
  • It’s much easier to just compromize someone’s account and send a link to a malware (in shortened version obviously)
  • You don’t even need to compromise an account at all!.
    • Just start a fake story about someone and let him retweet (happened to Rafinha Bastos who send a link to a fake story about his death to his 2.4 million followers) – using a short URL service. The redirected site was down as it showed obvious signed of fraudulent behaviour.
  • And of course LulzSec has apparently distributed a malicious program in their farewall message to its over 200,000 followers.

Additionally Twitter is the new way of distributing things in an insanely fast way that shouldn’t be accessible at all. For example, the source code for the notorious Zeus trojan was made public through Twitter.

So coming back to the main point of this blog. Twitter has to battle with 200 million tweets a day and can obviously not check every single link to see whether it is genuine. I trust they tell us that security is important, but every tweet is important to them in terms of growth. The short URL link providers obviously do what they can do (I tweeted about a recent phishing page they detected nicely here: http://twitpic.com/5i52g9). But they can obviously only block something they know is bad.

Trust is not and doesn’t work as a security measure.

Twitter uses a simple username/password authentication method that is convenient but broken. With the upcoming integration of twitter into iPhones and iPads, is this still enough? How many valid twitter logins were in the millions of username/passwords that were exposed in the last couple of weeks?

So be careful what links you click (always – not just in twitter).

in-depth report, Malware

Torpig – back to the future or how the most sophisticated trojan in 2008 reinvents itself

Leave a comment

1         Executive Summary

We have seen many different examples how improvements in the security landscape have forced the bad guys to change tactics and achieve their results via different, potentially less useful, methods.

A prime example is the introduction of UAC in Windows 7 together with the default user not running as administrator. This poses a tricky question for malware developers: Do I ask for elevation (UAC) and risk that users get suspicious, or do I do whatever I can without administration privileges?

Well the answer has been given. We’ve analysed Zeus before and Zeus will not bring up the UAC and will only infect the currently logged in user.

In this TrustDefender Labs report we look at a new strain of the notorious Torpig Trojan that gained massive publicity in 2008 when it was distributed together with the Mebroot / MBR virus. In this report we look at a new variant that will do an impressive amount of things completely without administrator privileges.

On a positive note, the lack of privileges restricts the trojan’s ability to hide itself deep in the system and is much easier to detect and remove.

2         Introduction

Torpig was basically the Zeus Trojan of 2008, as it was deployed as part of the Mebroot deployment vector. Its impressive feature list made it the Trojan of choice at that time.

We’ve covered Mebroot/Torpig back in 2008/2009; more details are on the TrustDefender blog here and here.

In the last few months, more and more Torpig Trojans appeared without the Mebroot component.  It was pretty obvious that this was done to make Torpig work on newer operating systems such as Windows Vista and Windows 7 where the introduction of UAC and the removal of the admin-rights for the default user forced the Trojan writers to adapt.

Unfortunately these security improvements didn’t make the problem disappear; it only made their job harder.

So in essence, Torpig is still very impressive with the following features:

  • Works perfectly fine in Windows 7
  • No UAC
  • Everything runs from usermode
  • Browser hooking works nicely
  • HTML web injection works like a treat
  • Completely silent

 

However:

  • It doesn’t feature any self-defences at all
  • Torpig is visible as a process in task manager
    • E.g. rundll32.exe C:\DOCUME~1\support\LOCALS~1\Temp\1.tmp,_IWMPEvents
    • Only current user is infected, not the whole machine
    • If you kill that process, Torpig is disabled
    • If you remove that file, Torpig is gone
    • Other side effects:  If IE runs as a separate user, Torpig will not be able to inject its HTML code anymore!

Other Trojans went down the same path. For Zeus 2+, the situation for example is as follows:

  • No UAC appears
  • Zeus runs as current logged in user
  • Browser hooking still possible

BUT Zeus is also easily detectable, easily removable, and has almost no self-defences.

From Zeus 2.0.9.8 manual:

So let’s look at Torpig a bit more in detail as it employs a number of interesting techniques that are very similar, but also different to the Zeus/Spyeye/Gozi/Carberp’s of the world.

One of the main differentiating factors is how the HTML injection mechanism works, and obviously HTML injection is used quite heavily to attack bank websites.

Another interesting observation is that Torpig will hijack search results (e.g. Google) and most likely perform Clickjacking. This is something we noticed with Carberp as well and we believe that there is so much money to be made with this, it too important not to do it.

3         Installation

We looked mainly at the Torpig sample with MD5 of 70675a7053ae38adb77d70a056956684.

It was first seen on April 10, 2011.

3.1       C&C DNS generation algorithm

One interesting fact is that while we installed the Trojan on April 10, even 2 months later it still successfully finds responding C&C servers that are up-and-running!

It achieves this by using an algorithm where Torpig will generate new domains daily to connect to on its quest to get access to a C&C server.

The fact that after 2 months our Torpig Trojan still finds responsive C&C servers says a lot about our current efforts in disrupting this infrastructure!

3.2       System modifications

As mentioned in the introduction, the main purpose of the Torpig Trojan is to also infect Windows Vista/7 machines, so even though we installed the Trojan on a Windows XP SP3 machine with full admin rights, the payload does exactly the same thing as if it was running as non-administrator. With one exception as it will add itself to the global Autostart registry to infect all users and not just the current one.

After the initial binary is executed, it will drop a DLL into the user’s temp directory and add the following command to the Autorun registry (only to HKCU – Current User):

rundll32.exe C:\DOCUME~1\support\LOCALS~1\Temp\1.tmp,_IWMPEvents

The interesting part is that they could have developed this as an executable, but then the Zeus executable would show up in the task manager. Using rundll32.exe (which is a legitimate Microsoft component) it can “hide” behind it.

The command above means that the system will load the 1.tmp DLL file and invokes a function call to the function _IWMPEvents.

3.2.1       It tries to infect the whole system, if possible

Even though the payload only affects the current user, Torpig will actually drop another DLL and tries to load this into the process with admin rights, if possible.

That means that if your user has administrator rights, all (!) users will be infected. If the user doesn’t have admin rights, only the current user is infected.

This is the Autorun in HKLM (Local Machine):

3.3       Code injection into other processes

As part of the installation, Torpig will inject executable code into other (system) components. Most notably into “explorer.exe”, which is a process that runs in the user’s context (no admin rights needed). Torpig did the same thing quite heavily before as well (back in 2008).

3.3.1       Basic user-mode rootkit techniques

Torpig will employ some very basic usermode rootkit techniques, such as very limited file hiding techniques. For example, the Torpig code within the explorer.exe process will create a temporary file:

The file is hidden in the file system with a hooking of FindFirstFile/FindNextFile and won’t be visible in the Windows explorer. However the “old” tab-completion trick still works (just open a command prompt and let the tab auto-complete the filename).

3.3.2       Named pipe !mscom$

In the “old” days back in 2008, Mebroot and Torpig used named pipes quite extensively to enable the various components to communicate.

It almost surprised us to see that one of the named pipes is exactly the same (\\\\.\\pipe\\!mscom$). Also the protocol used for the communication is still the same with some extensions. Chapter 8 (Appendix A) is dedicated to the named pipe communication.

3.3.3       32 bit vs 64 bit

Torpig successfully installed and operated on 32 bit systems.  It successfully installed on 64 bit systems as well, but it didn’t initialize properly (e.g., the named pipe !mscom$ wasn’t created).

However the DLL’s were dropped and loaded with rundll32.exe in almost exactly the same way.

3.4       Operating System / Brower compatibility

We tested various browsers and according to its technical capabilities, Torpig will work with Internet Explorer and Firefox. We see here the same improvements that we have seen with almost all other Trojans – that Torpig enhanced itself to work on Firefox due to its increased popularity.

However not all browser / OS seem to work.  Here is the matrix:

  • Windows XP, Vista, 32 bit
    • Worked fine with IE 7,8
    • Worked fine with Firefox 3.5 and 3.6. Didn’t work with Firefox 4 (!)
    • Windows 7, 32 bit
      • Didn’t work with IE 8 (!)
      • Worked fine with Firefox 3.5 and 3.6. Didn’t work with Firefox 4 (!)
      • Windows 7, 64 bit
        • Didn’t work at all. Not even the named pipe was created

3.5       Logical components

Torpig is made up of two main logical components.

The web browser code communicates with the explorer.exe code via the named pipe. The internet request then (e.g. to the C&C server) will be done from the explorer.exe process.

Note: It is pretty obvious that the fact that the internet requests are done by the explorer.exe process has numerous advantages. First of all, no browser plugins can see the traffic (as the traffic doesn’t occur in the browser), but also local firewalls and security solutions will not see anything.

3.6       C&C server communication

The C&C server communication is encrypted with a custom encryption mechanism and it looks pretty much unchanged from the one used before (described here: http://www.f-secure.com/weblog/archives/vb2008_kasslin_florio.pdf).

3.6.1       HTTPS Certificate

The requests to the C&C server are encrypted with SSL and a self-signed HTTPS certificate is used. This is possible due to the fact that the explorer.exe does the communication and “only” the content is then injected directly into the web browser’s process. So the web browser itself doesn’t even see any reference to the C&C server!

The following HTTPS certificate was used for the communication.

The “Valid from” date of 13 September 2010 surprised us a little bit as it is quite “old”…

3.6.2       The use of Geographic IP lookup

It seems that the C&C server quite heavily uses geo IP lookups to determine what should happen and whether a system should be infected or not. We successfully infected a machine in Australia, while we haven’t had such “luck” in the UK or Germany.

4         HTML content injection (MITB)

4.1       Browser hooking

Torpig uses the same mechanism as everybody else to hook the web browser process.

By hooking these functions, Torpig can get full control of the web browser traffic and can change whatever it wants. Please note that this also applies to HTTPS (EV-SSL) traffic.

4.2       Approach

Before we go into too much detail of how it works, let’s have a look at how Torpig uses the HTML content injection (Man-In-The-Browser).

First let’s be clear what we’re talking about. These instances below are examples of one particular configuration file of Torpig. All the examples we saw used a different approach for the HTML content injection than what we have seen in most Zeus/Spyeye configuration files.

This particular sample will not show anything suspicious before the user actually provides his authentication credentials (including 2-Factor-Authentication code). Before this information is sent to the “real” banking server, Torpig will inject additional form fields to steal more data complementary to the stolen login credentials.

So in this sense, Torpig doesn’t even attack the authentication system as such, but rides at the back of the existing session.

After all the provided information is collected and sent to the C&C server, Torpig “simulates” a correct login by using JavaScript to POST the login information to the login server

4.2.1       Identity theft (MITB) examples

In this section we provide screenshots to various banking sites. The target list for the Torpig trojan can be found in the Appendix and in no way is this list exhaustive

After logging in (with a fake account), the following screen appears:

Torpig’s configuration file checked every single entry to make sure it is correct. For example, it will check with Luhn’s algorithm whether the credit card number is actually a valid number!

While in most cases, we have seen “just” one additional page injected; we also came across an example where multiple pages will be injected.

First, they ask for Card related info:

Then query identity related info:

Ok, so how does this work in detail?

4.3       HTML injection details

This 10 page section is only available in the full indepth report. Please request one from labs@trustdefender.com

4.3.1       Curiosities

This section is only available in the full indepth report. Please request one from labs@trustdefender.com

4.3.2       Flaws in the system

This section is only available in the full indepth report. Please request one from labs@trustdefender.com

4.4       Conclusion

This section is only available in the full indepth report. Please request one from labs@trustdefender.com

5         Hijacks search results (Clickjacking)

A more and more popular feature even for transactional banking Trojans are the hijacking of search results.

Let’s assume you search for “Porsche 911” in Google.

Clicking on the first link (which should get us to Wikipedia) will send us to the following page:

Oops??

Another example: Searching for “Get Firefox 3.6” leads us to the following page…

Doesn’t look too good, that result page.

Another example:  (check out the link in the status bar that will be invoked when clicking on the first hit)

6         Removal

Torpig can be fully removed by deleting the two files from the Autorun registry that are referenced from the following two locations:

  • HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run, and
  • HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

Be sure to delete the right entry; in our case it was the entry with the rundll32.exe that references a .tmp file in a temp directory (Caution: be sure to know what you do in the registry editor as mis-usage could result.)

rundll32.exe C:\DOCUME~1\support\LOCALS~1\Temp\1.tmp,_IWMPEvents

Simply remove the two entries and delete the files from the hard drive.

Reboot the computer and you are clean.

7         TrustDefender

7.1       TDpro

Torpig uses the “usual” techniques to hook into the browser process. In addition to the code injection (executable and HTML) to the various components, one unique feature of Torpig is that the communication to the C&C server is done from the explorer.exe process. So even if there is a browser plugin or firewall checking all internet requests from the web browser, there is nothing to look at.

TrustDefender fully detects and protects users and enterprises from this threat, both on a process level (code injection), but also from the TCP/IP level (Secure Lockdown).

Below are a couple of screenshots from a walkthrough with TrustDefender with a demo site.

First it detects the malware.

And then the “Safe & Secure” mode will fully protect against it.

7.2       TDzero

As TrustDefender Zero utilizes our patent-pending page fingerprinting approach, it will detect the modifications to the page and therefore provide the financial institutions an early-detection system that doesn’t rely on blacklists, heuristics, updates or any downloads… It is completely transparent and an effective tool to protect against Man-In-The-Browser attacks of all sorts.

8         Appendix A: named pipe communication

This section is only available in the full indepth report. Please request one from labs@trustdefender.com

8.1       Static target list output (same tool we used back in 2008)

This section is only available in the full indepth report. Please request one from labs@trustdefender.com

8.2       Dynamic communication

This section is only available in the full indepth report. Please request one from labs@trustdefender.com

9         Appendix B: attached information to download

This section is only available in the full indepth report. Please request one from labs@trustdefender.com

 

 

Uncategorized

Quality Assurance in Trojans (Spyeye)

Leave a comment

In my day-to-day work, I focus quite heavily on the configuration files and the way trojans work in a particular circumstance.

Spyeye is obviously one of the trojans that is high on the radar as it is believed that the authors behind Zeus and Spyeye have “merged”. This has been supported by findings that Zeus and Spyeye trojans can now talk to the same backend system. (All trojans need a C&C server where they report their stolen data to. In this case, the C&C backend can handle data from Zeus and Spyeye).

The Spyeye trojan has a plugin structure that is extensible and makes sure that the trojan can adapt to new situations.

Well known Plugins are:

  • webfakes (alter web content in HTTP and HTTPS requests… this is to compromise any website)
  • ddos (denial of service)
  • ccgrabber (credit card grabber… scans POST request for credit card numbers (using Luhns algorithm) and steals the info)
  • backconnect (either via RDP or SOCKS5. provides a means for the fraudster to connect to your computer)

But one plugin was new to me

  • bugreport

This plugin takes care of any crashes of the Spyeye trojan and more details to the problem will be sent to the fraudster. The fraudster can also define what should happen in this case.

WOW… A built-in mechanism that allows the perpetrators to collect critical QA information from client systems to help them to make the trojan better? How many commercial software applications do have a similar system?

Curiosities

mobile browsers user interface vs. security

1 Comment

I came across a curiosity the other day that I’m still not able to solve, but here you go…

Recently, when logging in to facebook, the following message appeared on my iPhone:

I thought… Ok, in light of all the recent hacks, maybe someone miraculously hacked my iPhone and is trying to steal my facebook details (not that they are worth anything, but anyway).

So I took an almost maiden iPad here in the office and tried the same thing again and came across this picture

WTH???

I could not reproduce the same thing with any other device or browser. I tried IE, Firefox, Chrome on a PC, Android phone, … I could not reproduce this… On an iOS device, it doesn’t happen all the time, but I can fairly reliably reproduce…

With all the information I have, I am absolutely sure that this is the right certificate… I double checked all the details, including the serial number and the SHA-1 hash. This is definitely the correct certificate.

User Interface

But the real issue that I have is that there is no way in the world anyone can actually make sense of any of the presented information…

The world is abuzz at the moment with cloud offerings… more and more people will transact online… the traditional computer won’t exist anymore and we will only store things online if things go the way google pushes them.. But we can’t really solve the most basic security  issues?

The right action to do is to block this as its impossible to ascertain whether this is the right site… (leaving aside the fact for the moment that it is the right site!!!)

For completeness, here are the screens that are visible when you click on “Details”.

And one iPad picture with the serial number and the signature

And lastly the confirmed correct certificate. (actually raises a good question: how do you undeniably confirm this?)

Does anyone know what’s happening here? Is this a bug in iOS? session-renegotiation?

Strategy

Hope is not a Strategy (or why attacks such as RSA, Lockheed Martin, … had to happen)

Leave a comment

It seems that things have changed in recent times and suddenly everybody is under attack. First Sony with its reported 70 million compromised accounts, Epsilon, RSA – one of the most trusted brands online, now the worlds largest defence contractor Lockheed Martin, even PBS got targeted simply because they screened a critical documentary about Wikileaks. It doesn’t need much to get the attention of the wrong people. (we noticed that too!)

The resonating message from the media and people on the street is that if they can penetrate these companies, they can penetrate everybody, right?

Is the world turning upside down?

Well, for us security researchers this kind of news is not really new as it is well known that with the right tools, the right knowledge and some clever social engineering, the sky is the limit. A very nice example of how a security company penetrated a bank is here (very good reading) http://bit.ly/c4DhaZ. From the blog post: “We were recently hired to perform an interesting Advanced Stealth Penetration test for a mid-sized bank. The goal of the penetration test was to penetrate into the bank’s IT Infrastructure and see how far we could get without detection”.I specifically used an example that is more than one year old.

I think we are in the situation at the moment not because the lack of solutions out there, but because we tried to solve the problem with the wrong approach and with the wrong tools.

  • Example: Wrong Tool: Two Factor Authentication (e.g. RSA) is great for authentication (well not so great anymore, but that’s a different story), but shouldn’t we start authorizing as well? How can it be that a user can do everything once (s)he got authenticated? Shouldn’t we ask whether a particular user is authorized to do something? And naturally we should only give the user an authorization code for that particular action. Not one to do anything and everything.
  • Example: Wrong approach: As more and more companies and services are moved to the “cloud” we operate in a different risk exposure and we can’t simply apply the same security controls as if this is an internal application. Take email for example. Typically only accessible from the internal network (with all the security advantages), needs a much different protection from the outside. All these OWA’s (Outlook Web Access), employee remote access tools need additional security. But why only apply a higher authentication and hope that it will solve the security problem as well? We know that Man-In-The-Browser (MITB) trojans can circumvent most authentication solutions deployed today. Hope is not a strategy.

What we really need to do here is to do a threat based approach and use the right tools for the threats. Example: If the threat is a man-in-the-browser (MITB) trojans that alters a banking transaction, it doesn’t make sense to increase authentication. What we need here is a fraud detection solution together with authorization.

And what’s missing in all discussions is real-time detection and prevention capabilities based on suspicious behaviour. We need a much more intelligence based approach where suspicious activity can be detected very early on, preferably before any authentication process is completed. This suspicious activity can be as easy as the time needed to login to an account or time needed to complete the various steps of a wire transfer page.
In most cases we look at from a forensics point of view, we can detect suspicious activity based on the information that is present… But the trouble is that we can only forensically disseminate this information AFTER it has occurred. Let’s put in some systems that will proactively detect these things in real-time.

More on these topics in some upcoming posts…

Lessons learned here:

  • just one incident can have disastrous consequences.
  • authentication is something different from authorization.
  • don’t try to solve a security problem with an authentication solution.
  • if you know that your system can be circumvented, the bad guys either already know this as well or they’ll figure it out very quickly.
  • implement proactive, real-time solution, rather than reactive, blacklist,heuristic based solutions
  • deploy an intelligence based approach. Take advantage of the information you have and make sure you know all the things you need to know.

 

UPDATE: it seems that the concept of authentication and authorization is not made clear enough, so below is my attempt to clear this up.

  • Authentication: Proof that someone or something is who he, she, or it claims to be. (who you are)
  • Authorization: Once the system knows who the user is through authentication, authorization is how the system decides what the user can do. (what am I allowed to do)
Uncategorized

AusCERT 2011 presentation “Transactional Banking Malware” covering Gozi/Carberp…

Leave a comment

I finally found the time to upload my presentation at AusCERT 2011 with the topic “Transactional Banking Malware – Don’t fear the trojans; fear how they are configured to attack a banking website. A practical session with surprising outcomes” (http://conference.auscert.org.au/conf2011/speaker_Andreas_Baumhoff.html)

It is attached to this post (AusCERT_2011_Andreas_Baumhof_V2)… What do you think? Would love to hear some feedback.

Malware

Apple Mac OSX and Malware – Myth vs Reality

Leave a comment

1 EXECUTIVE SUMMARY

There has been much debate on whether Apple’s Mac OS X operating system is more secure by design or have taken advantage of security through obscurity, as Macs have traditionally had much lower penetration into the market than Windows based systems.
However, as Apple has enjoyed rapidly growing success over the past few years, not only with its iPhones and iPads but with also the growing popularity of Macs and Mac OS X, it comes as no surprise to see security companies predict that attacks on Apple’s systems and its users will also start increasing dramatically.
While ‘Security’ seems to be a competitive advantage, Apple has realised that some dedicated malware defences are needed via cloud web security, so it shipped an ‘Anti-Malware’ component with its Mac OS X updates. In June 2010, 3 (three) malware programs were on the list (link). When we checked in March 2011, there were still three!
Recently, Sophos made waves announcing a new “backdoor Trojan” for the Mac OS X platform, (http://nakedsecurity.sophos.com/2011/02/26/mac-os-x-backdoor-trojan-now-in-beta/). Although this Trojan (called Black Hole) is very new, it is not in a state that poses any threat, and doesn’t provide much for us to look at yet in an in-depth report.
Given that, we thought this a perfect opportunity to look at an existing piece of Mac malware known as HellRaiser 4.2, chosen because it is detected by Apple’s anti-malware defences, unlike ”Black Hole”. Using HellRaiser 4.2 lets us see how Apple’s defences work, so we can test their effectiveness and discover their limitations.
There is very little public information on the technical details of Mac OS X’s anti-malware feature, even in their animation tutorial videos, however, we will provide some technical details here. Furthermore after testing Apple’s anti-malware defences, you might have guessed that we found several ways around the built-in protection within just a few hours.
At ‘TrustDefender Labs’, we typically look at the most sophisticated Trojans available. While ongoing research on the latest malware Trojans has led us to have very high expectations on the levels of sophistication now seen in advanced malware, the Mac OS X HellRaiser 4.2 Trojan left us quite disappointed by being a relatively simple Trojan that, despite some “clever” features, doesn’t look like it was written by professionals.
Even though the Mac OS X malware industry is still in its infancy, the whole situation provides cause for concern going forward, especially as many of Apple’s end-users aren’t accustomed to treating malware as a serious security risk given Apple’s legacy as safe technology that’s easy to use and master, with historically miniscule and harmless malware threats compared with the barrage of malware, viruses and Trojans that Windows users have been subjected to for years. Introduction – Mac OS X and Malware
Apple and malware are two words that aren’t commonly spoken together. However, this is set to change in a big way in the near future. While Mac OS X only holds a relatively small percentage of the desktop market, its close smartphone and tablet cousin iOS is in the hands (literally!) of millions of people. This is a tempting target that  will see increasingly sophisticated and successful attempts at exploitation.
For all doubters, Apple has just released iOS 4.3, a massive update to iOS where Apple patched a stunning 49 (!) security vulnerabilities. Apple notes that these vulnerabilities “may lead to an unexpected application termination or arbitrary code execution”, which in plain English means having your device owned. The full list is available at Apple’s support site http://support.apple.com/kb/HT4564. It’s important to note that these vulnerabilities left iOS users unprotected until a new version of iOS was released, as opposed to having updates released on a much more timely cycle.
To give you an idea of the seriousness of unpatched vulnerabilities, we only need to look at one of the most targeted attacks on Windows operating systems and applications – Stuxnet.
The perpetrators behind Stuxnet exploited seven different zero-day attacks, developing highly successful and highly targeted malicious software to break into what would otherwise be highly secure installations. They went to incredible lengths to accomplish what they wanted. Do you think Stuxnet would have been less successful if the Siemens SCADA machines were controlled by Apple Macs?
This is the reality that we have to face in the future: there are inherent risks with what we do, regardless of the operating systems we use.
The trick is how you deal with the risk and whether you can manage the risks. This is the purpose of this TrustDefender Labs report, which looks at Apple’s built-in malware defences.

1.1 HELLRAISER

One of the existing pieces of malware on Mac OS X is HellRaiser 4.2. As we wanted to test Apple’s built-in protection, we needed to look at a Trojan that Apple already provides protection against, with HellRaiser 4.2 fitting the bill. We’ll look at it in this section a bit in more detail and will then look at Mac OS X’s defences.
Hellraiser is actually about 12 months old, with Virus Total reporting just over a 50% hit rate, so this Mac OS X Trojan isn’t new or unknown by any stretch of the imagination. However, we figured it’s still interesting to investigate, both in terms of what is capable of, and, more interestingly, what Apple is doing to protect against these kinds of things.
First up, let’s just see what happens if we run it:
Well, that’s a good start. It looks like Apple’s built in protection detects it!
However, let’s put that aside for a moment, and have a quick look at this malware. It’s not new, and seems pretty rudimentary, but offers a few clever features. HellRaiser is a Remote Administration Tool (RAT). The goal is to get the server running on a target system by whatever means necessary (i.e. social engineering), and then be able to connect to it from the RAT client.
Configuration is straightforward:
Once configured, installed and running on the target system, the server will email or FTP its local IP address and port to the specified host. From here, the cyber criminal can connect using the client software:

1.2 HELLRAISER PROTOCOL

As you can see from the last image in the previous section, the HellRaiser client exposes quite a bit of functionality. The server and client communicate via a protocol that appears to be roughly plain text, albeit turned into hex and base64 encoded. For example, if we use the “tell” function to create a message on the target system, Wireshark reports the following message on the main control port:
5655784a56446f7848314e46546b51634d446b784d5455324e69353661584146486a4d344e6830354e7a6b3044516f3d
We can convert this into something a little more useful:
The information circled in red above shows that, over a data port, a zipped file is sent that contains a file named 0911566 which contains our message.

1.3 HELLRAISER LIMITATIONS

For the most part, HellRaiser works but has some quite serious limitations. Firstly, the software is somewhat buggy:
Secondly, given it waits for a client to attach to the server, any form of NAT or firewall will stop it.  Apple’s built in firewall stops the connection, as will most routers that perform some kind of Network Address Translation (NAT).

2 APPLE’S ANSWER: FILE QUARANTINE

So, that’s what the cybercriminal is attempting. Now let’s look at what Apple’s OS X security experts are doing to protect us.  When a file is downloaded via Safari (or, indeed, any application that has “LSFileQuarantineEnabled” set to true), it is flagged with an extended attribute “com.apple.quaratine”. This contains some information about how the file was acquired, specifically the timestamp, application name, and the bundle identifier.
For example:
com.apple.quarantine: 0000;4d7468de;Googlex20Chrome;66B1A56C-4296-420D-A895-48DEA91D76F4|com.google.Chrome
When a file that has been downloaded is executed, “LaunchServices” will see this flag and prompt the user the first time the application is launched.

3 XPROTECT

Only once a file is marked quarantined does Mac OS X’s built-in malware protection kick in. There is no official statement as to what this is called, so we and others in the security industry are calling it XProtect, after the name of the definition file. XProtect is configured and updated by a standard plist file, which is a human-readable XML file format, containing a blacklist signature database that all users of Internet security and anti-virus software on Windows systems are well aware of.
Looking in the malware definition list (XProtect.plist), we can see a few entries for HellRaiser:
This is a really useful protective feature out of the box, and as long as the OS is kept up-to- date, Mac OS X users get some level of protection. On the downside, this list is updated relatively infrequently, at least when compared to anti-virus engines. Some anti-virus vendors claim hourly or even more frequent updates, while Apple’s anti-malware definitions are fairly static. Currently only three malware types are part of the list.
Once the amount of malware targeting Mac OS X increases, Apple’s infrequent updating may prove to be insufficient, and it’s obviously no help against zero-day, click-jacking or session based trojans.

3.1 XPROTECT IN DETAIL

Please refer to the indepth report

4 THE GOOD

Please refer to the indepth report

5 THE BAD

Please refer to the indepth report

5.1 WHAT PROGRAMS HAVE LSFILEQUARANTINEENABLED SET?

Based on average systems, it appears all common web browsers and email clients do have this set, either in the applications plist or in the system-wide “Exception.plist”, however, IM and, worryingly, P2P programs tend not to. Apple’s own programs are usually well behaved. Both Mail and iChat will create quarantined files.
The trouble though is that Instant Messanger and especially P2P programs are designed to exchange files. That is actually their whole purpose!
You can have Mac OS X up to date, but if you download a Mac OS X targeting Trojan with your torrent network, XProtect will not protect you! And downloading files is the only reason why people use torrent clients obviously.
If some malware does manage to run on a system, it can freely download and execute whatever it likes with no interruption from the OS.

5.2 SOME ATTACK VECTORS

Please refer to the indepth report

5.3 PERFORMANCE CONSIDERATIONS

The question of performance is also interesting.
“The number of new malicious programs detected during the year was approximately 13 million” – Kapersky, 2010
While the model of only running a scan on files flagged for quarantine means the performance impact should only hit on the first run of a downloaded application, the question of performance and scalability has to be asked. If the situation on Windows is anything to go by, Apple may have to deal with very large numbers.
Currently, “XProtect.plist” only has three different groups of malware. If we include variants we might be generous and say it detects 50 different strains. What happens if this number is increased?
I added 10,000 entries, each with a pattern match field to “XProtect.plist”, and it added about 7 seconds (!) to the time it took to launch a file flagged for quarantine that didn’t match any rule. This last clause is important, because “CoreServices” is smart enough to stop searching as soon as it finds a match. So the extra size didn’t make finding malware early in the list any slower.
This, in effect, means that non-malware faces an aggravating time penalty if the “XProtect.plist” gets too large.

6 CONCLUSION

It will be of no surprise to anyone reading this document that the idea of Mac OS X having perfect security is a complete myth. There is, however, a grain of truth in the idea that there is no malware on Mac OS X, albeit a small grain that is shrinking rapidly! As it stands today, there isn’t much malware that we can find.
That RATs (Remote Administration Tools) such as Sophos’s recently discovered Black Hole and HellRaiser get publicity says something about the current quantity and state of malware on Mac OS X. However, this shouldn’t be an excuse for Mac users to be lulled into a false sense of security. The malware is out there, and it’s growing both in terms of numbers and sophistication.
Apple is being proactive and introducing OS level security. It’s flawed security that is currently pretty flimsy, but nonetheless, it’s a (small) step in the right direction. It’s going to be interesting to see the direction Apple chooses from here.
iOS will only run signed binaries, so this type of protection is less important for that OS. Will XProtect get improved? Or will Mac OS X get locked down and only run signed binaries? And, how long will it be until there is a serious outbreak of malware on Apple’s platforms?

 

Malware

Gozi is back

Leave a comment

Gozi is back… sophisticated Man-In-The-Browser Trojan with extensive HTML injection configuration file

After some silence, Gozi is back virtually unchanged to the last outbreak in November last year. The target list is almost identical to the variant we analyzed then.

For more information about Gozi, please refer to our in-depth report from November 2010 as all technical details are still valid.

Also the injected HTML (Man-In-The-Browser) is very similar to the one we analyzed before, however there are obviously new C&C servers and as the injected JAVASCRIPT Code runs within the banking website, all C&C servers need to have a valid SSL certificate as well.

The one we looked at was issued on February 10, 2011 (!)

Technically there is nothing new to report, which is good and bad at the same time. The good news is that our report from November 2010 is still fully accurate, the bad news is that this most probably means that the bad guys don’t need to innovate as they are successful enough with the current status-quo.

If you need more information, the decrypted configuration file, samples, … drop us an email here: labs@trustdefender.com.