ESET ThreatBlog

AV Testing, AMTSO and EICAR

David Harley — Wed, 16 May 2012 07:48:42 +0000

Back in 2008, EICAR rejected a paper proposed by Andrew Lee and myself discussing the state of anti-malware testing and how it might be improved, on the grounds that it was “advertising” the fledgling AMTSO (Anti-Malware Testing Standards Organization) initiative. You can decide for yourselves whether that criticism was justified: the same paper was accepted later in the year by Virus Bulletin and is available as “Who will test the testers?” from the ESET conference papers resource page.

I mention that paper because it makes for an interesting contrast with the paper I presented last week at EICAR 2012. Since the new paper is very much focused on AMTSO, I guess EICAR has got over its sensitivity to 'advertising' the other non-profit organization. (And in fact, there has been a fair amount of subsequent and rational discussion between individuals involved with both organizations.) Though I have to admit that it lacks some of the optimism of the earlier paper – unsurprisingly, given that an awful lot has happened in and to AMTSO in the interim. But it feels like a good time to ask whether AMTSO still has enough credibility to achieve substantially more than it already has. Can the organization go beyond the substantial repository of resources it’s already compiled, to resume monitoring and commenting on tests and testers? (The short answer is probably, but not all by itself, and in any case we'll have more idea about future directions after the discussions at the workshop that begins today: watch this blog for more information.)

Here’s the abstract for the new paper:

After AMTSO: a funny thing happened on the way to the forum

Imagine a world where security product testing is really, really useful.

Testers have to prove that they know what they’re doing before anyone is allowed to draw conclusions on their results in a published review.
Vendors are not able to game the system by submitting samples that their competitors are unlikely to have seen, or to buy their way to the top of the rankings by heavy investment in advertising with the reviewing publication, or by engaging the testing organization for consultancy.
Publishers acknowledge that their responsibility to their readers means that the claims they make for tests they sponsor should be realistic, relative to the resources they are able to put into them.
Vendors don’t try to pressure testers into improving their results by threatening to report them to AMTSO.
Testers have found a balance between avoiding being unduly influenced by vendors on one hand and ignoring informed and informative input from vendors on the other.
Vendors don’t waste time they could be spending on enhancing their functionality, on tweaking their engines to perform optimally in unrealistic tests.
Reviewers don’t magnify insignificant differences in test performance between products by camouflaging a tiny sample set by using percentages, suggesting that a product that detects ten out of ten samples is 10% better than a product that only detects nine.
Vendors don’t use tests they know to be unsound to market their products because they happened to score highly.
Testers don’t encourage their audiences to think that they know more about validating and classifying malware than vendors.
Vendors and testers actually respect each others work.

When I snap your fingers, you will wake out of your trance, and we will consider how we could actually bring about this happy state of affairs. For a while, it looked as if AMTSO, the Anti-Malware Testing Standards Organization, might be the key (or at any rate one of the keys), and we will summarize the not inconsiderable difference that AMTSO has made to the testing landscape. However, it’s clear that the organization has no magic wand and a serious credibility problem, so it isn’t going to save the world (or the internet) all on its own. So where do we (the testing and anti-malware communities) go from here? Can we identify the other players in this arena and engage with them usefully and appropriately?

And here’s the abstract for the earlier paper.

Who Will Test The Testers? (2008 Abstract)

The anti-malware industry has been plagued since its earliest days by one poorly designed comparative test after another. In 2007, some of the best anti-malware researchers, comparative testers and product certification specialists took the first steps towards raising product testing standards with the formation of a group specifi cally focused on establishing standards and methodologies, educating both consumers and testers in discrimination between good and bad practice, and providing objective analyses of current testing practices. This paper summarizes current initiatives by the Anti-Malware Testing Standards Organization and other groups, but also considers next steps, going beyond objectifying methodology, educational issues and blowing away the fog of misinformation and fallacy, to the next level. Underlying these vital issues is a question: is it possible to make testers and certifying authorities more accountable for the quality of their testing methods and the accuracy of the conclusions they draw based on that testing?

David Harley CITP FBCS CISSP
ESET Senior Research Fellow

Millions have not reviewed Facebook privacy settings: Here’s how

Cameron Camp — Tue, 15 May 2012 17:35:52 +0000

Here are two staggering Facebook privacy statistics: Nearly 13 million US Facebook users have never set, or don’t know about, Facebook’s privacy tools, and only 37 percent have used Facebook's privacy tools to customize how much information is shared with third parties. That's according to a Consumer Reports survey released earlier this month. Given that there are now over 900 million Facebook users, more than the population of most countries, and given the broad sharing that is Facebook's default privacy setting, those stats strongly suggest a lot of people have some online privacy catching up to do.

A few months ago we highlighted Facebook security settings and how to enable various protections. In this post, we delve more into granular control of your data privacy. By ratcheting down your privacy settings, you can have more control over who can get to your data, helping to keep your social networking experience positive, and potentially preventing problems before they occur.

Protect Yourself

When you log into your account, you can view or modify your privacy settings on a pulldown menu under “Home” on the top right of the page. Here’s what mine looks like:

When you get to the Privacy landing page, you might notice your default settings are set to “Public”, here we update them.

Notice this is targeted at your default sharing options, you can also change them for specific items on the site by using the inline audience selector, but here it’s a good idea to select “Custom” and specify what fits your needs, here’s what’s shown by default:

That’s a little too public for many, so I make the default visibility to “Only Me”, keeping in mind that you can use the inline audience selector to widen the audience of particular data you want to share, but if you don’t, the default will be to keep it more private.

Notice you can also explicitly list people or lists you DON’T want to share things with, a sort of data sharing blacklist, which you may find useful if you opt to share with others but want to restrict certain aspects more granularly. If you select this option you are also presented with a note saying:

That means if you tag someone in a photo, for example, they will be able to view the photo, even though you don’t explicitly opt to share it.

Now let’s look at ways other people can access your profile information. We start by selecting the “Edit Settings” link back on the Privacy Settings page:

The default settings show “Everyone”, shown below:

These default settings are a little too permissive for my tastes, so I ratchet them down like this:

This setting keeps my profile a little more private. Back at the Privacy home page, let’s take a look at “Profile and Tagging” to control how information gets tagged and shared:

Here we can ratchet down who can post to your wall, who can see posts tagged in your profile, and so on. Below is the default:

I would prefer to restrict more content to friends only, so I change it to reflect that preference:

Also, you might want to control who can tag you in their content by enabling “Review posts friends tag you in before they appear on your profile” if you choose to restrict that.

Next we restrict past post visibility, which is a good idea if you’ve had a lot of posts in the past, and you’d prefer more granular control over how that information is shared:

When you edit this section, you are presented with a screen warning you about restricting past posts, warning that since it’s a global change, you may also choose to just restrict specific posts, rather than across your whole profile. Continue past this warning by selecting “Limit Old Posts.” You will be asked to confirm this choice, warning that this change may not be easy to undo.

Next we take a look at “Blocked People and Apps”, a sort of blacklist for specific functionality:

Click on “Manage Blocking” link, which opens the following dialog box:

This functionality can come in handy if you have been getting unwelcome interactions from someone on your friend list. Also, note that once you add a user to your Restricted List, they aren’t notified of the change, which is handy for dealing with potentially pestering friends wanting to know why you’ve changed your settings.

Summary

These are some of the basic protections that will help control the data sprawl of your private information. Of course, Facebook updates its security and privacy settings on fairly regular intervals, so we will provide updates from time-to-time. In combination with our earlier security post, this privacy primer should go a long way toward keeping your social networking safer and prevent problems with your personal data spreading further than you planned or expected. If you find this post helpful, or have any Facebook privacy tips you'd like to share, please let us know in the Comments below.

11 Tips for protecting your data when you travel

Stephen Cobb — Fri, 11 May 2012 22:41:33 +0000

When we relayed the FBI/IC3 warning to travelers about a threat involving hotel Internet service overseas last week it produced a lot of requests for advice on how to respond to the threat. So a few of us researchers at ESET came up with a list of data security tips for travelers. These tips will help you keep your data safe while traveling and should defeat this particular threat (IC3 says a pop-up appears as you are signing in to the hotel Internet and asks you to update perform a software which is actually a malware infection).

Below the list are some additional strategies and one example of what not to do with your laptop and your car, wherever you happen to be driving. If you have more suggestions we would love to hear them. Please use the Comment section below to share.

Make sure your operating system and antivirus software are updated before you go on the road.
Backup your data before you head out (and store the backup in a safe place).
Consider leaving some data behind or move sensitive data from your laptop hard drive to an encrypted USB stick.
Make sure you have password protection and inactivity timeout engaged on all devices including laptops, tablets, and smartphones.
If possible, only use reputable hotel Internet service providers (ask the hotel who their provider is before you book).
If the hotel Internet asks you to update software in order to connect, immediately disconnect and tell the front desk.
If you use hotel Internet to connect to your company network use a VPN.
Do not use WiFi connections that are not encrypted with WPA (avoid WEP encrypted connections which are easily hacked).*
Consider getting a 3G or 4G hotspot and using that instead of hotel Internet.
Avoid online banking and shopping while on any hotel or public Internet connection.
Disable pop-ups in your web browser.

Bonus tip #1: If you are on the road and suspect that your Windows laptop has become infected you can get a free online scan from ESET.

Bonus tip #2: Don't assume your laptop is safe from malware when traveling just because it is a Mac. Consider installing a reputable antivirus product, for example, you could install a free 30-day trial of ESET Cybersecurity for Mac OS X before you head out on your travels.

What not to do when on the road with your laptop

Do not park your car and then place your laptop in the trunk. Place your laptop in the trunk before you reach the place you are going be parking.

The reason? Someone who sees you place a computer in the trunk and then walk away from the vehicle knows the car is worth breaking into or stealing. A former colleague learned this the hard way in Venice Beach in 1996, back when a high-end laptop could cost over three grand.

WEP/WPA? How to know which encryption scheme an access point offers

If you are using a Windows 7 laptop you can see the encryption type for any available access point when you display the list of access points from the network icon in the Taskbar (typically lower right of the screen). You may have to hover over the point in the list to see the information.

If you are using a MacBook you can Option-Click the Airport icon for a list that will display the encryption type of your current connection and, on hover, other connections, as shown on the right.

(With many thanks to Aryeh Goretsky and Cameron Camp for their contributions to the tip list.)

King of Spam: Festi botnet analysis

Aleksandr Matrosov — Fri, 11 May 2012 07:32:36 +0000

We have just completed fresh analysis of the malicious software known as Win32/Festi. While the "Festi" botnet created with this malware has been in business since the autumn of 2009 we can see that the software is frequently updated, as described in our analysis, and these updates mean Festi continues to be a potent threat (Festi is detected by ESET as Win32/Rootki.Festi). You can download our whitepaper with the complete analysis here (.pdf). What follows are some of the highlights.

According to statistics from M86 Security Labs, Win32/Festi is one of the three most active spam botnets in the world. Thanks to plugin modules that we describe in our analysis Win32/Festi is also capable of being used for distributed denial of service (DDoS) attacks. The malware's kernel-mode driver implements backdoor functionality and is capable of:

Updating configuration data from the C&C (command and control server);
Downloading additional dedicated plugins.

As show in the diagram on the right, the Win32/Festi kernel-mode driver periodically contacts the C&C server and requests plugins and configuration information. The downloaded plugins perform the bot’s main tasks, such as sending spam.

In an interesting twist, these plugins are kernel-mode drivers which aren’t saved on any storage device in the system and are volatile in memory. Thus, when the infected computer is switched off or rebooted, which a victim might do if they sense something is wrong with their system, the plugins vanish from system memory. This makes forensic analysis of the malware significantly harder since the only file stored on the hard drive is the main kernel-mode driver, and this contains neither the payload nor information regarding which sites to attack or target with spam.

Each plugin is dedicated to performing certain kinds of work such as performing DDoS attacks against a specified network resource or sending spam. The plugins communicate with the main driver through a well-defined interface which we have documented in our white paper.

Another interesting aspect of Win32/Festi that we describe in our analysis is the malware's ability to bypass personal firewalls and HIPS systems that may be installed on the infected machine. To communicate with C&C servers and send spam and perform DDoS attacks, Win32/Festi relies on a TCP/IP stack implemented in Microsoft Windows OS in kernel-mode. However, the bot uses a custom implementation of the ZwCreateFile system service to send IRP requests directly to the transport driver.

Other evasive techniques that Win32/Festi employs include detecting whether it is running inside a VMware virtual machine and checking for the presence of a kernel debugger. We describe these in our detailed Win32/Festi analysis (.pdf).

Eugene Rodionov, Malware Researcher
Aleksandr Matrosov, Security Intelligence Team Lead

Foreign Travel Malware Threat Alert: Watch out for hotel Internet connections

Stephen Cobb — Wed, 09 May 2012 04:24:59 +0000

We received a worrying notice today from the Internet Crime Complaint Center (IC3) which is a partnership between the Federal Bureau of Investigation (FBI) and the National White Collar Crime Center (NW3C), The headline reads: "Malware Installed on Travelers' Laptops Through Software Updates on Hotel Internet Connections." We felt that the warning which followed the headline was serious enough to relay it promptly to our readers in its entirety:

Recent analysis from the FBI and other government agencies demonstrates that malicious actors are targeting travelers abroad through pop-up windows while establishing an Internet connection in their hotel rooms.

Recently, there have been instances of travelers' laptops being infected with malicious software while using hotel Internet connections. In these instances, the traveler was attempting to setup the hotel room Internet connection and was presented with a pop-up window notifying the user to update a widely-used software product. If the user clicked to accept and install the update, malicious software was installed on the laptop. The pop-up window appeared to be offering a routine update to a legitimate software product for which updates are frequently available.

The FBI recommends that all government, private industry, and academic personnel who travel abroad take extra caution before updating software products on their hotel Internet connection. Checking the author or digital certificate of any prompted update to see if it corresponds to the software vendor may reveal an attempted attack. The FBI also recommends that travelers perform software updates on laptops immediately before traveling, and that they download software updates directly from the software vendor’s Web site if updates are necessary while abroad.

Anyone who believes they have been a target of this type of attack should immediately contact their local FBI office, and promptly report it to the IC3's website at www.IC3.gov. The IC3's complaint database links complaints together to refer them to the appropriate law enforcement agency for case consideration. The complaint information is also used to identify emerging trends and patterns.

You can find a copy of the alert here and you might want to consider signing up for future alerts here. Additional defensive measures that you can take include doing the following three things before you leave home on your travels:

Perform a full backup of your laptop.
Make sure your antivirus software is up to date.
Install the latest operating system and application updates.

If we obtain any further details about this threat we will publish them here. If you are currently traveling and want to perform a virus scan of your Windows laptop, you can use the free ESET online scanner.

Facebook Memes: not always innocuous

David Harley — Tue, 01 May 2012 21:03:58 +0000

A few months ago I wrote a fairly short comment piece for Virus Bulletin on how some popular posts to Facebook that invite you to make use of your personal data might be useful to scammers and others as part of some sort of data aggregation attack. An example I included was a popular posting featuring a simple code whereby the poster, usually female, posts that ‘I’m [n] weeks in and craving [some kind of candy]’. where [n] represents the month as drawn from a list like this:

January - x weeks
February - y weeks
(and so on: the number isn't a simple n+1 increment, by the way)

There is another type of list on which different types of food, especially candy, represent different days of the month.

1 – Snickers
2 – Oreos
3 – M&Ms
(and so on up to 31)

(Note that these lists have been modified from lists that I've actually seen, not just copied.)

That article was published in the February 2012 issue of Virus Bulletin, as you may have noticed if you're a subscriber. If you're not, you can now read Living the Meme (by permission of VB, who hold the copyright), on the ESET resource page here,

You might want to note that the re-designed Resource page includes ESET white papers, ESET conference papers, articles by or featuring ESET researchers, and the monthly threat reports.

David Harley CITP FBCS CISSP
ESET Senior Research Fellow

Support Scam Poll

David Harley — Tue, 01 May 2012 19:49:32 +0000

Apologies if you're bored with my banging on about PC support scams, but it seems that there are plenty of people who aren't. At any rate, some of my previous blogs on the subject have attracted more comments than any of my blogs on other topics, and in fact, I've learned a great deal from some of those comments over the past two or three years.

And now I see that the Internet Storm Center is running a poll on Fake Tech Support Calls. The organization says:

We are trying to better understand how common "Fake Tech Support" calls are, and what they are trying to achieve. If you received a call that claims to provide tech support, or another service, only to extract information from you or to trick you into installing malware on your system, please use the form below to report any details.

None of the fields are mandatory, and you don't have to log in. The questions include the following:

Was the call automated or did a person call you? [In my experience, there's more often than not a pause when I pick up the phone, suggesting that dialling is automated and the scammer picks up when he sees there's a response. Of course it would be fairly difficult to automate the actual conversation...]
The gender of the caller, the language they used, and whether they had a strong accent.
Details of any URL they asked you to visit, and whether they asked for remote access.
Whether they identified the organization they were calling from,
Whether they asked for credit card data and/or other personal information.
The phone number of the caller

Actually, it was Martijn Grooten of Virus Bulletin who pointed this page out to me: he and I, along with Steve Burn and Craig Johnston, are working on a paper on the topic to be presented at Virus Bulletin in September. We're in the process of establishing contact with the researchers at ISC who are working on this in the hope of exchanging information, and would encourage you to fill in the questionnaire, if you have experience of the scam. But I'm still also extremely interested to hear of your experiences through the ThreatBlog, so keep the comments coming!

David Harley CITP FBCS CISSP
ESET Senior Research Fellow

Could your next new car be hacked (should you be scared)?

Cameron Camp — Mon, 30 Apr 2012 21:32:00 +0000

The wave of new data technology making its way into the next generation of cars – ranging from vehicles which semi-autonomously drive themselves, to realtime data streaming onto head's up displays – begs the question: will they be safe from cyber shenanigans, or will you have to deploy security software on your next (probably hybrid) car?

At Blackhat last year, I watched a demo of hacking a car using wireless, where they were able to unlock its doors and start it up. The team that did the demo disclosed the situation to the car manufacturer, with the hope they could put protections in place to stop those with less-than-noble intentions (and free time) to try the same. But what if the hacking team decided to go the “Dark Side” and started unlocking cars and driving them off to chop shops?

Traditionally, cars have had rudimentary computing systems, implemented to carry out fixed tasks like measuring fuel for injection, making your transmission shift more smoothly under gentle acceleration or to improve gas mileage – things like that.

But with some manufacturers hoping to roll out location-aware browser-based or embedded information systems, can scams be far behind? Browser-based exploits have a long and inglorious history on more traditional platforms. So with the computer power required to launch these new data-driven cars, ushering in a raft of accompanying full-featured embedded computers, can that be a more full-featured scam platform as well? As we've seen with recent Java-related exploits (with more independence from the underlying host OS), it's easy to imagine a Java app working its way into the car systems and doing things you wouldn't suspect in your car, like exfiltrate your data to some remote location (or far worse).

To be sure, manufacturers of cars tend to test their systems a little more fully than a hot Silicon Valley startup vying for VC capital, where the motto tends to be “launch fast, iterate fast.” But cars tend to stay around for 10 years or more, making a vulnerability in the software stack more tricky to manage, especially over time. Automotive recalls are famously expensive, and tend to have a cooling effect for the brand in general, but what happens when some corner-case (or mainstream) hack crops up on a several year old model, as in the case of the Blackhat demo? While there may be an update cycle that can be pushed over-the-air, updates and patch cycles gone awry could have much more scary side-effects than, say, your mousepad not scrolling like it used to.

Generally speaking, auto manufacturers seem to be planning more batches of read-only interfaces than read-write, where the car simply reports on systems and information, so there's less chance of systems introducing problems, say, from users grabbing a keyboard, logging in as Administrator, and then installing things. That's a good thing. But still there are myriad wireless technologies in the works to serve up information to occupants, and that tends to also have the ability to be susceptible to nefarious downloadable nastiness.

Will we see anti-malware software for your car? I think it's too soon to tell. Hopefully good design will blunt or remove the need. On the other hand, it certainly opens up new horizons for those seeking to socially engineer you based on information that may be gathered from your car's systems, obtained either ethically or otherwise, directly from the car, or down the line. If retail marketers knew you always drove past their store, they might target their messaging to be relevant to you, especially if they could data-mine from the streams reported by your car. And the thought of automotive-based ransomware is very scary indeed; whether or not it could disable your car or simply purport to, it's still unnerving.

Hopefully, manufacturers will engage the security community early and throughout the process to help with analysis, recommendation, and testing, which will hopefully keep us all safer from car-based hacks. If that fails, you may find even more motivation to dust off that Corvette restoration project sitting in the back of your shed and breath new life into it. It's old and boring technologically-speaking, but you know what you're getting, and not more.

For more reading on this topic, check out:

Article on vehicular vulnerabilities in Scientific American last year.
A 2010 article from "The Truth About Cars" describing core automotive computer technology like OBD-II and ECU, and CAN.
Interesting 2010 research paper referenced in the above article: Experimental Security Analysis of a Modern Automobile.
Need help finding the ODB-II port on your car? It is the same technology the Progressive insurance company uses for its "Snapshot" rate reduction device.

Privacy and Security in the Consumer Cloud: The not so fine print

Stephen Cobb — Sat, 28 Apr 2012 13:20:31 +0000

The consumer cloud expanded again this week with the addition of Google Drive to more familiar brands like Dropbox, Microsoft SkyDrive, Apple iCloud, and Amazon Cloud Drive. Unfortunately, most of these cloud-based file storage services come with privacy and security caveats, often involving language such as "You give us the right to access, retain, use and disclose your account information and Your Files…" and "We do not guarantee that Your Files will not be subject to misappropriation, loss or damage and we will not be liable if they are…"

Why cloud?

Before I explain why it is now more important than ever to read the "Terms of Service" and "Privacy Policy" that apply to any online services you may want to use, let me say a few words about what the consumer cloud means in practical terms. It means Internet access to gigabytes of online storage space–at low or no cost–from a wide range of devices, desktop to smartphone.

Full access is provided to the account holder and partial access may be made available to third parties designated by the account holder, like friends and family, on some consumer cloud services (we will deal with service operator access in a moment).

The way that people use and access consumer cloud services varies considerably but here's just one example: I have about 30 gigabytes of music on my Amazon Cloud Drive. This happened when I got a Kindle Fire for Christmas and, in my enthusiasm to explore it without first reading the manual, accidentally initiated a 5-day sync-a-thon between one of my home computers and the Amazon cloud.

I decided to let the massive file transfer run its course and as a result I am now enjoying almost instant access to a familiar collection of thousands of songs in my own cloud, from just about any Internet-enabled device. When I buy new songs from Amazon they auto-magically get added to my Cloud Drive which enables me to pull down a local copy to any device.

Are they private?

I am happy to tell people about my use of the cloud for music storage because all of my MP3s are legal copies, ripped from my own CDs or purchased from either iTunes or Amazon. But what if someone questions that assertion? Could Amazon or some other entity scan my cloud drive for illegal content? Yes. Consider this section of the Amazon Cloud Drive Terms of Use:

5.2 Our Right to Access Your Files. You give us the right to access, retain, use and disclose your account information and Your Files: to provide you with technical support and address technical issues; to investigate compliance with the terms of this Agreement, enforce the terms of this Agreement and protect the Service and its users from fraud or security threats; or as we determine is necessary to provide the Service or comply with applicable law.

In other words, there is a fairly broad range of circumstances under which Amazon might look at your stuff, whether it is MP3s, JPEGs, PDFs, spreadsheets, doc files, or anything else you might decide to put in your cloud (you will find roughly similar language in the terms of use for Google Drive, Dropbox, Microsoft SkyDrive, and Apple iCloud). How you feel about these terms may depend on what your files contain. For example, it would be convenient for me to store all of my digital photos in the cloud, but my feelings about that are quite different from my feelings about storing music files in the cloud.

I do not mean to single out Amazon. As Sean Ludwig at VentureBeat recently pointed out, there are many similar policies at Apple, Google, Dropbox, and Microsoft. He points to a longer article containing a useful comparison of the various consumer cloud providers–with the unexplained exception of Amazon–over at The Verge. As both articles point out, Google may have a bigger perception problem in the privacy arena than other consumer cloud providers because Google Drive is covered by the company's omnibus privacy policy that highlights just how many different pieces of information Google stores about the people who use its services.

Are they serious?

An area of added concern that extends to several of the companies mentioned is the reservation of rights to use your cloud content to advance the interests of the cloud service provider. Here is Google:

When you upload or otherwise submit content to our Services, you give Google (and those we work with) a worldwide license to use, host, store, reproduce, modify, create derivative works (such as those resulting from translations, adaptations or other changes we make so that your content works better with our Services), communicate, publish, publicly perform, publicly display and distribute such content. The rights you grant in this license are for the limited purpose of operating, promoting, and improving our Services, and to develop new ones.

Quite frankly, Google's lawyers could have made that whole paragraph a lot less scary if they had put the meat of the last sentence first, thereby making it clear that there are limited circumstances under which Google can use the very broad rights you are granting to them by uploading your stuff. Unfortunately, I'm pretty sure the words still mean the following scenario is entirely possible and legal: that special song you wrote and recorded and uploaded to Google Drive shows up on TV as part of a Google ad campaign, illustrated by those photos you took of your girlfriend (and this could happen without warning and without payment). Of course, you might be happy for the exposure, but that probably depends on the content of the song, the nature of photos, and even the current state of your relationships.

Are they secure?

Clearly, there are many good reasons to read the terms of use and privacy policies of any cloud service you are considering using before you start to upload files. If you need further persuasion, consider what one provider says about the security of your cloud data:

5.3 Security. We do not guarantee that Your Files will not be subject to misappropriation, loss or damage and we will not be liable if they are. You’re responsible for maintaining appropriate security, protection and backup of Your Files.

That's right, you are on your own when it comes to security. I do not get a warm and fuzzy feeling from this paragraph, which is part of the Amazon Cloud Drive terms of use. And I wonder how the Amazon Marketing department got away with this statement used to encourage people to pay for storage on Amazon Cloud Drive: Your files are securely stored online.

What they mean is that you have a backup of your local files in the cloud, not that there is anything inherently secure about their cloud. After all, as section 5.3 of the terms of use is going to tell you: When it comes to security, all bets are off.

All of which means I am not keen to put anything precious or hard to replace on that cloud drive unless I already have a strongly protected local backup. And bear in mind that the Amazon claim is arguably even more disingenuous if you buy files like books and music and video that are delivered to the cloud and never downloaded.

Indeed, cloud security disclaimers should give companies as well as consumers cause for concern. At an information security conference in San Diego last October the chief privacy counsel of a major insurance company made a strong case for saying that standard cloud services are not compatible with privacy regulations such as Gramm–Leach–Bliley. In other words, standard cloud contracts don't come with enough privacy and security assurances to permit their use for storing sensitive personal information that is subject to legal penalties for non-compliance.

Finally, even if compliance doesn't concern you, think about what stands between your data in the consumer cloud and anyone who might want to steal it, ransom it, or otherwise mess with it: a password. That's right, we are in the second decade of the twenty-first century and the security of your cloud data depends on nothing more than your ability to create and protect an unguessable password. Until that changes, the bottom line is sad but simple: When you drive into the cloud you do so at your own risk.

OS X Lamadai: Flashback isn’t the only Mac malware threat

Alexis Dorais-Joncas — Wed, 25 Apr 2012 13:27:35 +0000

The Flashback trojan has been all over the news lately, but it is not the only Mac malware threat out there at the moment. A few weeks ago, we published a technical analysis of OSX/Lamadai.A, the Mac OS X payload of a multi-platform attack exploiting the Java vulnerability CVE-2011-3544 to infect its victims. OSX/Lamadai.A has built-in features typical of a backdoor: namely download and execution of an arbitrary file, uploading of local files to the operator’s Command and Control (C&C) server, and spawning of a command-line shell.

After the technical analysis was done, we began the monitoring phase. This phase is very important because it allows for tracking of how the malware is used by its operator. We can catch new variants of the threat early on, or even a totally different malware family (as often seen in pay-per-install schemes), or see the operator launch Denial-of-Service attacks (or any other kind of malicious activity) from the infected systems.

The monitoring phase allowed us to witness a short, live dialog between our infected machine and the malware operator that we published this dialog in our initial analysis of OSX/Lamadai.A. This experience gave us some new ideas that we could put in place in order to gather more knowledge about this threat and the person or people behind it.

What we did is this: we planted some fake files in the home directory of our test “infected user” and waited for the operator to come back. About one week later, we got our first connection. Here are the highlights of the dialog that took place over a period of about 10 days. It started with a little reconnaissance in the ~/Documents directory. The Unix command ls is used to list directory content:

Then we see the theft of some Tibetan army status documents and a little porn for added value.

Now more reconnaissance and file theft, this time in the ~/Downloads directory.

It is quite interesting to see that the operator did not steal all the files we had put out for him. He left these three untouched:

2012_report.doc
application.zip
im5744.jpg

A few days went by during which the operator was only connecting to the system to issue some basic commands, most likely with a view to determining whether this was a newly infected system or not. The Unix command id returns the current user's identity and the sw_vers command prints the OS version information.

We decided it was time to refresh the environment to simulate infection of a new user and to install interesting new files to the user’s home directory.

Shortly after the new environment was up and running, we got an incoming connection. Almost instantly, the operator issued a command to download and execute a file (technical details of the new file below)!

Immediately after, the operator ran a few netstat commands, most probably looking to see if the new payload was listening on the network properly. The Unix command netstat displays the network status of the system, such as network connections and routing table.

Not seeing what he wanted to see, our operator tried to re-execute the dropped executable! Let’s see how that turned out:

Yes, you do have to specify the path to the executable when /tmp is not in $PATH. In despair, he attempted to take some screenshots of the entire desktop window, using the OS X ‘screencapture’ command. Oddly enough, the file was not saved in his current work directory as it should have. We can’t explain why that happened.

Then, a few connection attempts later, the operator logged back on and totally lost it. He issued two Unix ‘rm’ commands, used to remove directory entries: one to remove the user’s home directory and one to remove the system’s root directory.

That concludes this dramatic episode of Monsieur Frustrated Operator. Now to some technical stuff.

One of the first things we did was to recover and analyze the Mach-O executable dropped onto our test machine. We were curious to see what that was: a new variant of OSX/Lamadai, or even a specialized new piece of software? Instead, we found it was the same variant of OSX/Lamadai with a hardcoded C&C server set to 127.0.0.1. This explains why the operator grepped his netstat output for “127.0.0.1”. However, the rationale behind this action is up for debate inside ESET’s Security Intelligence Laboratory. Some argue that the operator realized he was connected to a monitoring system instead of a real, infected one and wanted to redirect the traffic away from the real C&C. Others contend that it would have been easier for him to simply deactivate or remove the malware from the system.

Also, when we first analyzed OSX/Lamadai.A, we said that the malware did not have persistence capabilities on an OS X 10.7.2 system, as the path /Library/Audio/Plug-Ins/AudioServer was not user-writable. We looked a little deeper into this, as other researchers reported that the threat was indeed persistent on their machines. We realized that this very same path is user-writable in previous OS X versions (10.5/Leopard and 10.6/Snow Leopard). This is the cause of some potential confusion and a timely reminder of the benefits of upgrading to the latest version of OS X.

Credits go to Marc-Étienne M. Léveillé for the technical analysis and test environment setup, thanks to the usual suspects for reviewing and commenting this article.

MD5 of the dropped executable: 46c8ca78af43012388936345336d203b

Alexis Dorais-Joncas

Security Intelligence Team Lead