browser extensions, a better attack vector than drive-by-downloads?

I came across this blog post (locally cached pdf) a couple of days ago of a developer of a Chrome extension who filled the gap after Google dropped support for the RSS reader. His Chrome extension was popular and gained more than 30,000 users.

To cut the long story short, he sold it for a 4 figure amount to someone who then turn his extension into a adware riddled version and updated all 30,000 users.

That seems to be an awful efficient way of infecting a lot of users for very little money. His chrome extension was “Add to Feedly”.

Unfortunately these things occur more and more often. Another example is “Tweet this Page” was taken down by Google due to it starting to hijack google searches. Apparently the developer sold it for $500! (from here)

In both cases, the bad guys talked the authors into selling by making nice claims such as “…they wanted the extension ‘for further development’”.

The funny thing is that Google (who is distributing Chrome) is making around 97% of its revenue from online ads, so it is not surprising that advertising within chrome extensions is neither prohibited nor discouraged.

“…Injected ads are allowed in Chrome extensions, but Google’s policy states that which app the ads are coming from must be clearly disclosed to the user, and they cannot interfere with any native ads or the functionality of the website.” (from here)

For malware authors, hijacking legitimate and good extensions is an outstanding business model. First of all, they know exactly how many potential victims they can buy. Secondly, due to auto-updates they can infect these people nicely and thirdly it takes quite a while for google to remove “non-behaving” extensions from the store.

What is the risk here? or What can a malicious chrome extension do?

Google has automated screening capabilities that will minimize the distribution of malware through chrome extensions. However we all know that malicious actors have tools available to make sure their software is never be found to be malicious. But then again, launching an executable (malicious or not) in a completely transparent way is not so easy.

The much bigger risk is that the chrome extension has full control of the website content, including all form fields. This could mean that a malicious chrome extension can

  • inject any kind of javascript into the website, effectively providing the same functionality as every sophisticated banking trojan out there. Should we call this Zeus-in-the-Extensions ;-)
  • sniff any provided input values into form fields. These could be usernames, password, one-time-password, tokens, email addresses, date of birth, SSN and much more.

Google has already announced that their extension policy is due to change in June 2014 and the new policy will require extensions to serve a single purpose. It would never cross my mind that they do this to vastly increase the number of chrome extensions, but surely only to provide a good service to us.

Oh, they also make it easier to use payment options to extensions. I can already see the topic for a future blog post.

Why metadata matters…

I know this is all over the web right now in the discussion about NSA and their natural hunger to collect whatever they can get their hands on. I don’t want to start a discussion on the legality or the ethnics of this, but the following slide from the EFF makes a very good point and to preserve it for my own good, here it is :)

metadata-1

see https://www.eff.org/deeplinks/2013/06/why-metadata-matters for more details…

Also very relevant is the post by Kieran Healy on “Using Metadata to find Paul Revere” here. A local copy is available here as pdf.

Example of a “well-done” phishing attack

So I got the following email this morning in my inbox which made it happily past our gateway based spam filter and my outlook spam filter.

1

The link is a phishing site (even though it is https:// ;-) – however no phishing filters have it in their list (e.g. google, firefox, microsoft, netcraft…) Clicking on it gets me here

2

Going through the process, they surely collect the hell of a lot of personal information. They also “check” each input values to be correct (e.g. you can’t continue by entering a non-valid credit card number). Looks really nice and clean.

3

4

5,jpg

And very nicely, they will try to log me into Amex straight away, so if I would have given them my “real” credentials, I would have been logged into my account…

7

Wow what a certificate (verified.cm) – CA’s completely broken

Looking at recent hacks, I had a quick look at the SSL certificate from verified.cm and who on earth is signing the certificate below? Oh yes… It is GlobalSign for sure… If we would need another argument why Certificate Authorities are broken, here it is… but then again we knew this for so long and they still exist…

So the SSL certificate for verified.cm has been issued to ssl2968.cloudflare.com. Cloudflare is of course a well-known cloud-based web firewall that is used by many good and shady sites.

This certificate has the following 40 (in words: FOURTY!) Alternative Names. Oh and don’t worry, it is also valid for 4 more years (until Jan 15, 2018). What could possible go wrong with this?

Did I mention that the domain that it was issued to doesn’t even resolve (ssl2968.cloudflare.com)?

Here are the fourty Alternative Names:

  • ssl2968.cloudflare.com
  • *.verified.cm
  • verified.cm
  • *.lynnfieldcommons.com
  • *.seehawaiilive.com
  • *.seaislandshops.com
  • bluesafesolutions.com.au
  • larende.com
  • *.youractivistportal.com
  • *.calligraphyofchina.com
  • seaislandshops.com
  • *.uvioo.com
  • snipjournal.com
  • escortgps.xxx
  • *.larende.com
  • seehawaiilive.com
  • *.snipjournal.com
  • *.prestomarket.com
  • *.themeat.dk
  • *.d2haa.org
  • cargames.org.uk
  • d2haa.org
  • *.templatation.com
  • *.descansogardens.org
  • youractivistportal.com
  • *.bluesafesolutions.com.au
  • tipple.me
  • calligraphyofchina.com
  • *.cargames.org.uk
  • *.tipple.me
  • landisgyr.com
  • prestomarket.org
  • *.prestomarket.org
  • uvioo.com
  • *.escortgps.xxx
  • templatation.com
  • prestomarket.com
  • *.landisgyr.com
  • lynnfieldcommons.com
  • descansogardens.org
  • themeat.dk

Protection vs Censorship

The title might sound a bit harsh, but with all these “good” people trying to protect you, where is the line between protection and censorship?

Byron Acohido (@byronacohido) just posted this tweet

tweetI personally hate these short URLs, but I thought this sounds interesting. The reason I hate these short URLs is that you don’t know where they take you (this one takes you from bit.ly/1eUu9e2 to t.co/yzm89jFvxS ;-) In this case it leads you to this:

pic1Wow… That’s what I preach almost daily… Watch out what you click on!!! And now I have to be saved by twitter??? Let’s have a look what this page really is all about:

pic2I can confirm that this is neither a “web forgery” or a “phishing site”. It’s also not a “site that downloads malicious software onto your computer”, nor is it a “spam site that requests personal information”. There is no iframe, not even javascript on this page. Only a couple of external references (e.g. youtube)..

Now I don’t care too much about whether TouchID has been hacked yet, but this almost crosses the line for me where twitter’s security team has been a bit too “motivated” to block content that is definitely not malicious.

What’s next? What other pages will be blocked in the name of security?

Search Engine Poisoning (malicious ad)

A very valid question that comes up all the time is “how do people get infected with malware” or “how do people lost personal information?” and there are so many ways that people are blown away by some of the examples I show them.

Today I came across one nice one again… Malicious Ad’s or Search Engine Poisoning… I used coinbase for some bitcoin activities and I wanted to transfer some bitcoins. So I typed in “bitcoin” into google and this is what came up coinbase1

So far so good and everything looks great. I now just click on the first link as this is an ad where someone pays Google money and Google not being evil, must mean that this is good, right? wrong.

All visual signs suggest that this is legitimate and the URL goes to google.com, but that should be ok as well, right? A look at the source reveals that this goes to google before it goes to one URL shortener to another URL shortener and then to the final destination!)

coinbase5

 

after the first URL shortener, we’ll see this!coinbase2

oops…

Luckily it was already known that this site is up to no good, as this server did hold a number of “nice” phishing pages designed to steal your bitcoin wallet information. With the current price of over 120 USD for one bit coin, that could be a very lucrative business

Some examples are:

coinbase3 coinbase4

 

Approximately 1h after notifying google, the malicious ad was gone, but please make sure you double-check where you click on.

 

how people get infected – or the perfect storm which luckily turned out to be harmless

One of the questions that always comes up at conferences and discussions is “how exactly get people infected with malware?”. The funny thing is that we malware researcher deal with this on a day-by-day basis, and the obvious reply ranges from malicious ad-banners to infected homepages/drive-by-downloads and phishing. All these techniques unfortunately work great.

One technique that is always a bit overlooked are malicious emails due to the “perception” that spam filters are effective. (whatever that means – especially in light of the RSA attack where the initial payload was an email which ended up in the spam folder and people moved it to the inbox to execute the attachment!!!). And my spam filter typically works really, really well…

Well, the other day I received an email from facebook that someone commented on a photo of myself

The interesting fact was that this email wasn’t in my spam folder, but rather in my inbox. Being one of the over 800 million facebook users, I thought: cool… let’s check it out and clicking on this link straight away downloaded a file called “FBviewer.exe”… Yeah, facebook viewer… makes sense.

Unsurprisingly this doesn’t smell right, so I asked virustotal what all the AV engines think of this file. As it turnes out, not much. 3 out of 43 AV engines detect something. Two with a heuristic (which may well be a false positive as well) and one AV detects something, but something completely wrong. The VT link is here: http://www.virustotal.com/file-scan/report.html?id=a34587d5bb473761ad9deb406dbc7515815325ca98d896238b696adf339b43cb-1320717477.

The disturbing fact is that none of the big AV engines detected this, so the “real” detection rate is close to zero.

I’ve no idea how Avast thinks this is Carberp, because this is a Spyeye trojan. When we analyzed the trojan, the C&C server was obviously still active, but luckily didn’t reply with a configuration files, so this instance of my Spyeye trojan was instructed to do nothing.

In conclusion, this was almost a perfect storm. A fairly well written email that made it past the spam filter with a convincing topic that most people would fall for. The download of a trojan with virtually zero detection rate and probably a fairly high hit rate because people really want to find out what’s happening with this photo.

Luckily the trojan didn’t do anything on our system, but hey once you are owned, you are owned.

 

 

 

 

 

 

 

Man In The Browser: Mac OS X Edition: 1 of 3

1         Introduction

In one of the recent TrustDefender Labs reports (“Man-in-the-Browser 101 or it works as designed (Win & Apple Mac) – http://www.trustdefender.com/trustdefender-labs-blog-td-labs-blog-man-in-the-browser-101-or-it-works-as-designed-win-aamp-apple-mac.html) we gave a brief over-view of what a Man In The Browser attack was all about, and in that discussion we briefly touched on Man In The Browser (MITB) attacks on Mac OS X. But is this really plausible?

The reputation for Apple’s OS has been that its more secure and doesn’t suffer these problems. Well, we have touched on, and debunked this myth earlier, but the malware examples we have looked at have all been pretty unsophisticated. So maybe there is something in this idea of a more secure OS? Well, given the title of this article, you can guess that’s not true!

We will be looking at three different ways that MITB can be achieved on Mac OS X as well. The most interesting fact is that it is actually fairly easy to do and works exactly the same way as on Windows. Given the detailed knowledge of MITB from the fraudsters on Windows, one can only assume that they have the knowledge as well on Mac and it is only a matter of time before they maintain two complete different versions of their trojan, perhaps with a shared configuration.

2         Browser Hooking

In the previous article, we talked about function hooking, and, although that article was focused on Windows, the concept is exactly the same for Apple OS’es. The basic idea is simple. When the web browser calls a system function, we re-route the call to execute our code first.

We have identified three different methods for getting our code to be called before a system function is called. This list is not exhaustive by any means, and we will cover each in turn in a later in-depth report, but the point is there are multiple ways of achieving this goal.

Specifically,

  1. Library overloading using DYLD_LIBRARY_PATH
  2. Function overloading using DYLD_INSERT_LIBRARIES
  3. Code injection

The first two of these use features made available by the dynamic linker, and the last is a more complicated method where we inject some code directly into another processes memory.  However, regardless of which of method is used, they all rely on the same basic idea. Rather than directly calling a system function, we first call our function first. Like this:

We will cover lazy linking, and explore in more detail the details this image shows in a later article. For now, its enough to know that the system used to resolve symbols in shared libraries, can be perverted and used to call our code instead. All three of the mentioned methods exploit this mechanism, albeit in slightly different ways. Typically, in this situation, the injected code will do its thing, and then call the original system code, so the system call still does what it needs to for the process to run (at least apparently) correctly.

2.1       Results

So, now we get to the interesting part! We have the pieces in place, we just need to figure out the appropriate places to hook, and inject our code. The details of this aren’t really important here, but suffice to say its not a big issue to figure these things out. For MITB malware, we need to find a function that is called to retrieve network traffic, ie our HTML content, from the network. And, if we hook at the right place, we can get access to html content before its encrypted and sent, and also after its received and decrypted. This means that SSL doesn’t help protect the content. We can then add whatever content we like… and we can do all this with no special access rights!

This sounds very familiar from all the MITB trojans on windows such as Zeus, Spyeye, Carberp, Gozi, Mebroot,… And yes, exactly the same thing is easily doable on Apple Mac OSX as well.

So how does it look like?

Note the https url, the lock symbol indicating a secure session… and the extra form field in the sign on section. In case you aren’t familiar with citibank’s sign on page, the relevant section of the same site without our hook looks like this:

 

Note that we picked citibank for this exercise simply because they are a well known bank. There is no inherent flaw in their website (that we know of, anyway), its a fairly typical banking site, secured with SSL and a certificate from a trustworthy CA (whatever that means in these days!).

Its also worth noting that the code required to inject an extra form element into the page was of medium complexity and highly targeted to this particular website. This was mentioned in an earlier article that suggests the meaningful Intellectual Property is in the configuration file rather than the code injection method. All major MITB trojans share the same “Zeus style” web-inject configuration format to target many brands at the same time. This is where the real value of a MITB lies, and given its brand-specific, is no tied to the delivery platform at all.

All three methods outlined in this report will result in the same compromised page where 99% of the content comes from citibank, but some additional form fields or malicious JavaScript fragements are injected locally – even though EV-SSL is used and the padlock is visible.

The above results are possible using all three methods.

2.2       What next?

Over the next few articles we will look in greater detail at the 3 methods of hooking mentioned above. We will also touch on the security features available in Mac OS X (10.6 and 10.7) and how effective they are for this kind of attack.