You’ve probably already heard about the 'Chupa Cabra', literally a "goat sucker". It’s a mythical beast rumored to inhabit parts of the Americas. In recent times it has been allegedly spotted in Puerto Rico (where it was first reported), Mexico and the United States, especially in the latter’s Latin American communities. The name Chupa Cabra has also been adopted by Brazilian carders to name skimmer devices, installed on ATMs. They use this name because the Chupa Cabra will “suck” the information from the victim’s credit card.

The Brazilian media regularly shows videos of bad guys installing their Chupa Cabra onto an ATM. Some of them are unlucky, or incompetent, and get picked up on security cameras and caught by the cops.

That’s what makes installing an ATM skimmer a risky business – and that’s why Brazilian carders have joined forces with local coders to develop an easier, more secure way to steal and clone credit card information. From this unholy alliance, the ‘Chupa Cabra’ malware was born.

A very important “internet trust” discussion is underway that has been hidden behind closed doors for years and in part, still is. While the Comodo , Diginotar, and Verisign Certificate Authority breaches forced discussion and action into the open, this time, this “dissolution of trust” discussion trigger seems to have been volunteered by Trustwave's policy clarification, and followup discussions on Mozilla's bugzilla tracking and mozilla.dev.security.policy .

The issue at hand is the willful issuance of subordinate CAs from trusted roots for 'managing encrypted traffic', used for MitM eavesdropping, or wiretapping, of SSL/TLS encrypted communications. In other words, individuals attempting to communicate over twitter, gmail, facebook, their banking website, and other sensitive sites with their browser may have their secure communications unknowingly sniffed - even their browser or applications are fooled. An active marketplace of hardware devices has been developed and built up around tapping these communications. In certain lawful situations, this may be argued as legitimate, as with certain known DLP solutions within corporations. But even then, there are other ways for corporate organizations to implement DLP. Why even have CA's if their trust is so easily co-opted? And the arbitrary issuance of these certificates without proper oversight or auditing in light of browser (and other software implemented in many servers and on desktops, like NSS ) vendor policies is at the heart of the matter. Should browser, OS and server software vendors continue to extend trust to these Certificate Authorities when the CA’s activities conflict with the software vendors’ CA policies?

Many of the apps we enjoy are free. Well, to call them free is a bit misleading. You pay for the apps by looking at advertisements. This is a platform we should all recognize from the sidebar of Facebook, or Google, or almost any service that doesn’t charge a premium to use it. Advertising has paved the way for many services to gather a huge audience audience and still profit.

On Android and in many cases iOS, the advertisers have gotten very aggressive. They now collect all kinds of data through multiple forms of advertising. I’d like to take a look now at what you can expect.

The Adobe AIR and Adobe Flash Player Incubator program updated their Flash Platform runtime beta program to version 5, delivered as Flash Player version 11.2.300.130. It includes a "sandboxed" version of the 32-bit Flash Player they are calling "Protected Mode for Mozilla Firefox on Windows 7 and Windows Vista systems". It has been over a year since Adobe discussed the Internet Explorer ActiveX Protected Mode version release on their ASSET blog, and the version running on Google Chrome was sandboxed too.

Adobe is building on the successes that they have seen in their Adobe Reader X software. Its sandbox technology has substantially raised the bar for driving up the costs of "offensive research", resulting in a dearth of Itw exploits on Reader X. As in "none" in 2011. This trend reflects 2011 targeted attack activity that we’ve observed. 2011 APT related attacks nailed outdated versions of Adobe Flash software delivered as "authplay.dll" in Adobe Reader v8.x and v9.x and the general Flash component "NPSWF32.dll" used by older versions of Microsoft Office and other applications. Adobe X just wasn't hit. IE Protected Mode wasn't hit. Chrome sandboxed Flash wasn't hit. If there are incident handlers out there that saw a different story, please let me know.

    Perhaps the worst possible scenario is when a bank website is hosting malicious ads: you never know what can be installed and when on your computer if you click on the ad banners.
Something similar happens with security websites hosting malicious ads. They are supposed to be for security information. The people browsing such sites trust the content to be safe, but in actual fact because of the ad banners the resources may be anything but trustworthy.

Will the Bouncer be effective in addressing the malware problems with Android apps?

First of all, this is a good and really necessary move Google is taking, however the solution will be only partial. Based on the public information around this service, all apps will be scanned for known malware. Basically that means a multi-scanner or something similar will be used, so the quality of malware detection will depend greatly on what AV engines Google will use to analyze apps. Not all AV engines have the same quality, so there is a possibility some malicious apps won't be detected as malicious. The second step offered by Google is emulation. It's a good approach, however it can also be cheated by anti-emulation tricks or a malicious app can be programmed to behave differently once an emulation is detected, making the app appear to be non-threatening.  So, basically the same malware tricks used to bypass Windows security can be implemented now on Android.

Is it still a good idea to use a mobile security program for protection even with Bouncer in place?

Yes, for sure it's a good idea. The situation is many people download apps not only from the official Android Market, but also from third-party sources.  Nobody knows for certain what kind of apps are out there on private market stores, run by people not affiliated with Google. Additionally as we mentioned if Google's multi-scanner won't count on all AV engines but only some of them, it's certainly good to use AV detection on your phone as a second opinion for anything that might have slipped past Google’s scanner.

Are there ways for hackers to sneak infected apps into the store despite Bouncer?

Yes and one of them is by hacking well known and trustful developers accounts. In fact I believe that will happen in the near feature. I say this because of Google says it will check all new developers account. If a developer is already known and trusted by Google, that developer account will be a prime target for cybercriminals. Also, even though we haven’t seen it happen yet, we know cybercriminals can start developing apps that work differently in specific geographic zones. For example, an app could be designed to only behave maliciously if it detects a Latin American carrier…if the same app is used by a US carrier, no malicious behavior will be detected. That's also an anti-emulation trick which can be exploited by cybercriminals in order to avoid Bouncer detection.

In this webcast, Kaspersky Lab senior security researcher Roel Schouwenberg talks about the Diginotar certificate authority breach and the implications for trust on the Internet. Schouwenberg also provides a key suggestion for all major Web browser vendors.

It has been four months since Microsoft and Kaspersky Lab announced the disruption of Kelihos/Hlux botnet. The sinkholing method that was used has its advantages — it is possible to disable a botnet rather quickly without taking control over the infrastructure.However,as this particular case showed, it is not very effective if the botnet’s masters are still at large.

Not long after we disrupted Kehilos/Hlux, we came across new samples that seemed to be very similar to the initial version. After some investigation, we gathered all the differences between the two versions. This is a summary of our findings:

Let’s start with the lowest layer, the encryption and packing of Kelihos/Hlux messages in the communication protocol. For some reason, in the new version, the order of operations was changed. Here are the steps of processing an encrypted data for retrieving a job message which is organized as a tree structure:

№	Old Hlux	New Hlux
1	Blowfish with key1	Blowfish with new key1
2	3DES with key2	Decompression with Zlib
3	Blowfish with key3	3DES with new key2
4	Decompression with Zlib	Blowfish with new key3

S. Korean handlers are slow to take down the publicly distributed malicious code exploiting CVE-2012-0003, a vulnerability patched in Microsoft's January 2012 patch release MS12-004. We have discussed with reporters that the code has been available since the 21st, and a site appears to have been publicly attacking very low numbers of Korean users over the past day or so. The site remains up at this time.

    How much do you earn per day? If we look at how much a cybercriminal from Brazil earns every day, we’ll understand why Brazil is one of the main sources of malware in the world.

Brazilian cybercriminals really like to use short URLs to track infections and have their own stats. Here is the profile of one criminal using Bitly as a URL shortening service.