It seems that development of the main module of SpyEye stopped with last autumn’s version 1.3.48 – and this is now the dominant strain of SpyEye malware.

SpyEye distribution by versions for the period since 1 January 2012*
* Others (7%) includes: 1.2.50, 1.2.58, 1.2.71, 1.2.80, 1.2.82, 1.2.93, 1.3.5, 1.3.9, 1.3.25, 1.3.26, 1.3.30, 1.3.32, 1.3.37, 1.3.41, 1.3.44.

But just because the authors are not developing this platform further, it doesn’t mean that SpyEye is no longer getting new functions. The core code allows anyone to create and attach their own plugins (DLL libraries). I’ve been analyzing SpyEye samples since the start of the year, and I’ve counted 35 different plugins. Below you can see a table with those plugins and the corresponding number of samples in which they were included:

I am now back from the Kaspersky conference: Security For The Next Generation, the International Cup 2012 which took place in the Netherlands, more specifically in Den Haag and Delft. All the guests stayed at an amazingly nice hotel named the Steigenberger Kurhaus Hotel. The hotel was located just by the beach at Scheveningen in The Hague.

Kaspersky had invited the winners from the local student conferences taking place all over the world and had them compete for the final title. Not only students attended the conferences, we also had professors from universities around the globe and also some of the experts from the Kaspersky Global Research and Analysis Team.

More information about the student conference can be found here: http://www.kaspersky.com/about/events/educational-events/it_security_conference_2012_international

DAY #1 - Arrival

This day was probably one of the weirdest days in my entire life. It started out amazingly with a nice breakfast, a sweet espresso and great music flowing out from my speakers. I checked that I had everything fixed: passport was there, all the clothes was there, flight and hotel bookings, everything was there.

Suddenly I heard the taxi coming, so I took my bags, my stuff and I locked the house. The taxi then took me to the train station, where I had to take a bus for half the journey due to some maintenance. I didn't really care about this because I had some bombastic dubstep with me, so I just jumped on the bus en enjoyed the ride.

After about an hour, we stopped at some deserted train station where we all got off, and then took the original train to the airport. Before jumping on the train I just wanted to double check that I had everything with me, but there was something missing... MY WALLET! DAAAANG!

It is quite rare to analyze a malicious file written in the form of a cross-platform browser plugin. It is, however, even rarer to come across plugins created using cross-browser engines. In this post, we will look into a Facebook worm that was written using the Crossrider system – a system still in beta testing.

Image source: http://crossrider.com

Google is set to launch Android 5.0, aka Jelly Bean, this fall. But do we even need it? While Google has made some steps in securing its Play branded marketplace, and offered a few security updates to the operating system, it is a fact that the most targeted Android platform is still 2.x. Why is that? There are several reasons, not the least of which is a lack of security patches provided to previously deployed operating system versions.

    Carolina Dieckmann, a famous Brazilian actress, recently became the victim of cyber attacks that allowed cybercriminals to steal personal property - nude pictures of her- from her computer. Many pictures or maybe all of them got leaked to the Internet. This incident has served as a good incentive for the Brazilian government to have new cybercrime laws in the country (the current law to fight cybercrime in Brazil was approved back in the 40’s of XX century). As a result of this incident, a new cybercrime law that carries a punishment of up to 2 years in prison for such crimes has finally been proposed for consideration. This is a good and right move! A press article in Portuguese can be

    “Forgetting” or “underestimating” are the main reasons for data loss around the world. In an airport lounge during my last trip I came across  some cool tab devices running on Android integrated with an external keyboard available for public use and connected to the Internet.

As in the past I performed a quick check of downloaded files, most visited sites and browser history and found a huge list of sensitive information. Here are some examples:

• Access via OWA to a corporate email of a Latin American bank.
• Medical files from Spanish hospitals.
• Commercial offers with personal banking information of a service provider.
• Personal traveller information with full names, IDs, frequent flyer number and the destination of the flight.
• Audit control released by a Latin American government to local companies.

I didn’t check if the browser function “save passwords” was enabled. Just imagine if it was! I also didn’t check the saved cookies. Anyway enough sensitive information was already exposed out there.

Lots of people are not very good at safeguarding their personal information on standard PCs; they are even worse when it comes to tab computers. More often than not, they just don’t know where a file was downloaded on a tab, and they have no idea how to delete it afterwards.

I wonder how much sensitive information is already exposed in this way at airports around the globe! Without any doubt it’s a huge advantage for cybercriminals who know how to use social engineering and a big pain for security officers of the companies who have to train employees. Another important point is when people fly on business – they are usually managers, so any leaked information can compromise not only their personal identity but also a company’s secrets.

At the recent SOURCE Boston conference, one presentation that caught my attention was called SexyDefense - Maximizing the home-field advantage.

This was quite a thought-provoking presentation that was based on the old concept that offense is always the best defense.

The Fbi's "Operation Ghost Click" announcement in Nov 2011, involving the Rove Digital botnet delayed cleanup efforts that we previously discussed, continues to haunt both the internet networks and the mass media. A Forbes article and a Times article yesterday brought the apparition back to the front, with some claiming that the site offered by the DNSChanger Working Group is a new one, which it is not. The 2011 Operation being described, and the temporarily outsourced DNS server replacements and delayed cleanup, is the same. This phantom is nothing supernatural, so why all the discussion? The federal judge's extension allowing the Fbi to run these replacement DNS servers still cuts off access in early July. When those replacement servers are removed in early July, the infected systems resolving DNS queries at these previously-owned Rove Digital servers will simply not be able to resolve DNS requests. July 9th will arrive soon, and notifications continue to go out related to the hundreds of thousands of systems in the US alone that are still infected.

In the simplest terms, connectivity will not be severed for DNSChanger-infected systems, but internet communications will not function for infected systems that have not been cleaned up. In the US, government agencies, home users, and other organizations still infected with the malware will have systems that effectively can't get online, can't send email, etc. It will look like they are connected to their network, but they just won't communicate with anything.

At the same time, there seems to be issues with some existing identification efforts. Yesterday, I infected a system with DNSChanger and visited dns-ok.us. Results here:

Regarding the dns-ok site visit, my ISP's support team isn't aware of any "DNS redirections" that would cause the test to fail, and I will update this post with any update from our network admin that they are redirecting my system's dns queries. But that piece is highly doubtful. My point here is that infected system owners may be confused by this check. And the ip address was within the Fbi-provided ranges run by Rove Digital - perhaps a reader knows differently?
UPDATE (1:40 p.m. MST) - I received some details from my local ISP network admin. They are not redirecting any related DNS queries. However, one of their large upstream providers is redirecting DNS requests to another DNS server of their own. The other upstream link to the net does not seem to be re-routing DNS requests. So my infected client's traffic must be favoring routes through the larger upstream provider, and poof, the green/clean response banner appears. Any way you look at it, the response from the site can be inconsistent - sometimes red, sometimes green. Unfortunately, this sort of situation is going to confuse cleanup efforts. So, here we are again. To the potentially millions of folks running DNSChanger infected systems and are listening to the cacophony of incident responder consultants tossing out cheap cynicism that "AV is dead!", go ahead and download an "AV product" to scan your system. Of course, I like recommending our scanners (just visit http://www.kaspersky.com) because I have cleaned up DNSChanger infected systems with it (and the products have fully functional trial periods), along with our TDSSKiller rootkit removal tool to clean up especially complex DNSChanger infections.

Market share! It’s an easy answer, but not the only one.

In 2011, Apple was estimated to account for over 5% of worldwide desktop/laptop market share. This barrier was a significant one to break - Linux maintains under 2% market share and Google ChromeOS even less. This 15 year peak coincided with the first exploration by the aggressive FakeAv/Rogueware market targeting Apple computers, which we discovered and posted in April 2011 and later in May 2011, which no longer seem to be such an odd coincidence. Also, the delay in Apple malware until now most likely was not because Apple exploits were unavailable, or because the Mac OS X system is especially hardened. The 2007 "Month of Apple Bugs" demonstrated that the Mac OS X and supporting code is full of exploitable flaws. Safari, Quicktime, and other software on Apple devices is regularly exploited during pwnage contests, but widespread cybercrime attention hadn’t caught on until this past year.

At this point, we still don't know who is behind Flashfake, so we don’t know for sure that they were the same Mac OS X FakeAv/Rogueware group. Speculating that eastern euro-cybercrime is behind the botnet would be a pretty confident way to go right now. There are known groups from the region that have succeeded at wringing ad revenues from traffic hijacking. We don't believe that other sensitive data has been targeted. And the exploit distribution URLs that we are aware of have only targeted mac users. These factors limit the operational and technical needs of a financially motivated cybercrime gang.

In a sense, it would appear that their activity was somewhat similar to the Koobface or Tdss gangs. They haven't commited large unique financial crimes to attract the attention of law enforcement, and their malware contains hooks and other code to perform more sophisticated banking crime than search traffic hijacking, but they most likely were looking to make a multitude of small financial gains. On the other hand, thankfully, Apple hasn't given these guys ample notice to make their run. There can be plenty of money in that business - it is estimated that the Koobface guys ran off with millions after Facebook "outted" their operation under investigation. But based on the domain registrations we have examined, the individuals are not quite so public and they are hiding their identities while they hijack search engine traffic. The malware itself injects a number of hooks into running applications, much like the Zeus, SpyEye, and other spyware. If these were used for financial crimes, the group operating this botnet would need to organize money mules and accomplices to launder their stolen money, which would grow the group and attract the attention of other authorities.

On the technology side, Java is a big part of the puzzle. Although the Trojan is called Flashfake because users were being convinced to install the malware as an Adobe Flash update, more recent versions of the malware were being installed via client-side Java exploitation.

Three vulnerabilities were targeted with client-side exploits, none of them were 0day, which seem to have become much more difficult to come by. Besides, this set worked just as well for these operators. It is interesting to note the duration of time from the original Oracle Java security update to the Apple Java security update, and when in that timeframe the release offensive security research publicly appeared. And, when were Metasploit open source exploit modules were released targeting the related Java vulnerabilities? The windows of time may be alarming – these are not 0day exploits, but Apple simply hasn’t released patches, leaving their customers exposed to the equivalent of known 0day exploits.

CVE-2012-0507

2012-02-15 Oracle patches Atomic Reference Array vulnerability

2012-03-10 First Itw exploits targeting the vuln

2012-03-30 Metasploit developers add Java atomicreferencearray exploit module

2012-04-03 Apple patches their code

CVE-2011-3544

2011-05-12 Reported to vendor

2011-11-18 Oracle patched their Java SE

2011-11-30 Metasploit developers add "Rhino exploit" module

2011-11-30 Krebs reports operational Blackhole site with the new Java exploit

2012-3-29 Patched by Apple

CVE-2008-5353

"Deserializing Calendar objects"

2008-08-01 Reported to Sun with first instance of the vulnerability

2008-12-03 Sun patches their code (Sun link down)

2009-05-15 Apple patches MacOSX code

2009-06-16 Metasploit developers add Java deserialization exploit

Also on this list is a lame exploit described as a signed applet social engineering trick.

I'd prefer to call it the "the terribly confused user presented with the Java 'do you want to trust this applet?' dialog and will run anything you present them" gamble. It first became a part of the Metasploit exploit module list on 2010-01-27. Basically, these guys present the user with a file that the user thinks is a JavaUpdate provided by Apple Inc themselves, which they grant trust to perform any action on their machine. The downloader will then communicate with a couple of sites to register and download new Flashfake components. These components in turn, collect the system UUID and timestamp, then auto-generate with a crypto algorithm a set of C2 domains, along with maintaining a list of hard coded domains. A couple of the newer components inject into running processes on the system hooking software functionality and hijacking traffic, much like past TDS malware.

Dan Geer's fantastic Keynote Speech kicked off Day 2 of SOURCE Conference Boston this morning. The talk itself was heady and complex, something to keep up with. Notable talks also were Jeremey Westerman's "Covering *aaS - Cloud Security Case Studies for SaaS, PaaS and IaaS", and Dan Rosenberg's "Android Modding for the Security Practitioner".

"The internet will never be as free as it is this morning." Dan Geer is one of the best, sharpest computing/network security speakers around. His talk descended from a high-level, lengthy, example-laden description of most every developed nation's dependency on the internet: "Dependence with respect to the internet is transitive, dependence on television is not...We are at the point where it may no longer be possible to live your life without having a critical dependence on the Internet, even if you live at the end of a dirt road but still occasionally buy nails or gasoline." And, he wound through multiple examples of failures in US systems to provide fallback options. He talked about his little local bank, whom he wrote a letter to close down the auto-created online account he wouldn't use. They, as an exception, closed it down immediately. His 401k account administrator Fidelity Investments, on the other hand, would not accept customer instructions from him in writing. The company continues to send him mailed marketing content of all kinds in writing at the address from which he sends his letters. Their auditors apparently approve of Fidelity's rejection of customer-initiated hand-written delivered communications, instead, accepting email/online chat messaging or instructions over the phone. This discussion made its way through systems design, unified field theory, and fault tolerance, eventually landing on key points that intrusion prevention is agreed not to be a workable model, instead, the elegance of "intrusion tolerance" must be built into systems, and countries and organizations that cannot build tolerance into their systems are not sustainable. Favorite quotes: "forget the banks, it is the internet that is too big to fail", "Is there room for those who choose simply to not participate in the internet?", "HTML5 is Turing complete. HTML4 is not", and "Should we preserve a manual means? Preserving fallback is prudent if not essential."

Jeremy Westerman's "Covering *aaS - Cloud Security Case Studies..." presented several design cases for Universities and other organizations. The single most important point to learn from this talk is that API key management is unfortunately not handled with as much urgency and awareness as private SSL keys for large organizations. This API key, in the context of multiple, popular single sign-on (SSO) solutions in use at large universities, is the key to tens of thousands, if not hundreds of thousands, of email accounts. Similar API key schemes are implemented on IaaS solutions like the Xen supported Amazon EC2 environment and VMWare vCloud Teramark environments. Without appropriate awareness, developers are storing that key in improper locations like the hard drive of the sign-on machine, or the developers themselves are storing keys on their development system hard drives in non-obvious places, emailing/"dropboxing" them around to each other and then simply transferring the API keys to the production environment, instead of re-issuing production API keys. It is practically imperative that these keys are taken out of the hands of developers. These loose handling practices are bad news - viral code like Sality and other viral code and worms previously high in our prevention stats have maintained functionality to steal FTP and web admin account passwords in order to silently host malicious code, encrypted or otherwise, on legitimate web sites without the owner's knowledge. In other words, developers have been effective and weak targets in the past for credential theft, enabling silent site compromise and malicious use. Most schools don't want that - I remember one unfortunate notification at a small Arts college, where the web admin really didn't want to believe that the encrypted blob of data hosted on his school's web server was a viral payload updating other students' infected systems, located there because his credentials were Sality-stolen after trying to run cracked software distributed over a P2P network. Anyway, it happens and it can be planned for and prevented.