Analysis Shows Traces of Wiper Malware, But No Links to Flame

One of the things about the investigation into the Flame malware that's remained unclear for several months now is what ever became of the so-called Wiper virus that had been seen erasing data on machines in Iran and that led researchers to eventually discover Flame. No actual samples of Wiper have been seen, just indirect evidence that the malware existed, but now researchers have analyzed some hard drive images of machines that were affected by Wiper and found that the malware has some links to Duqu and Stuxnet, but was in fact a separate attack and doesn't appear to have any ties to Flame.

The first indications of Wiper's emergence came in April when reports of attacks on businesses inside Iran that were destroying data on infected machines began to surface. The malware was wiping certain sections of the hard drive of infected machines, but no one was able to put a finger on exactly how the attacks were happening. 

"During the investigation of the mysterious malware attack in April, we were able to obtain and analyze several hard drive images that were attacked by Wiper. We can now say with certainty that the incidents took place and that the malware responsible for these attacks existed in April 2012. Also, we are aware of some very similar incidents that took place in December of 2011," researchers at Kaspersky Lab wrote in a new analysis of Wiper released Wednesday.

"The creators of Wiper were extremely careful to destroy absolutely every single piece of data which could be used to trace the incidents. So, in every single case we’ve analyzed, almost nothing was left after the activation of Wiper. It’s important to stress 'almost nothing' here because some traces did remain that allowed us to get a better understanding of the attacks. From some of the destroyed systems we were lucky enough to recover a copy of the registry hive. The registry hive did not contain any malicious drivers or startup entries. However, we came up with the idea to look into the hive slack space for deleted entries."

In the course of analyzing the hard drives, the researchers quickly identified a file that had a name similar to those used by Duqu. They tried to recover the file from the disk but found that it had been overwritten by garbage data.

"We found the same “wiping” pattern in several of the other systems we analyzed - a service named 'RAHDAUD64' which was deleted just before it is wiped - and its file filled with garbage data. In these other systems, the RAHDAUD64 service pointed to different filenames, such as '~DF11.tmp' and '~DF3C.tmp'. So it’s possible the names were random," the analysis says.

The algorithm used by the Wiper malware employed a specific pattern when erasing data, with the malware searching for and erasing dozens of file types, including Zip files, Word and Excel files, executables, PDFs and many others. It would then destroy files in some specific folders, including Documents and Settings and try to destroy files on any attached USB devices. Wiper would then erase certain sectors of the hard disk.

"Wiping a disk that is several hundred gigabytes in size might take hours. So the creators of the malware were careful to select wiping algorithms that could achieve maximum efficiency," the analysis says.

One of the other interesting things the researchers found was some similarities between the files that Wiper destroyed and some of the files used by Stuxnet and Duqu.

"Interesting enough, on some systems we noticed that all PNF files in the INF Windows folder were wiped with a higher priority than other files. Once again, this is a connection to Duqu and Stuxnet, which kept their main body in encrypted '.PNF' files," the researchers said.

After digging through the hard drives and analyzing the traces left by Wiper, the researchers came to the conclusion that the malware was highly effective in destroying not just the data on the machines, but most of the traces of the malware itself.

"There is no doubt that there was a piece of malware known as Wiper that attacked computer systems in Iran (and maybe in other parts of the world) until late April 2012. The malware was so well written that once it was activated, no data survived. So, although we’ve seen traces of the infection, the malware is still unknown because we have not seen any additional wiping incidents that followed the same pattern as Wiper," the analysis says.

Courtesy by Dennis Fisher

The Rise of Cross-Platform Malware

For most of the recorded history of malware, viruses, Trojans and other malicious software have been specialists. Each piece of malware typically targeted one platform, be it Windows, OS X or now, one of the mobile platforms. But the last few months have seen the rise of cross-platform malware that have the ability to infect several different kinds of machines with small variations to their code.

Attackers, like people in other walks of life, tend to specialize. They find something that they're good at, say, writing Windows rootkits or creating OS X Trojans, and they often will stick with that. There's not much reason to branch out if they're having success with something already. For a long time, most malware was written for Windows, because that's where most of the users are. Going after OS X or Linux didn't make a lot of sense.

But that's begun to change lately. One recent example is the Crisis Trojan, which has the ability to infect both Windows and Mac OS X machines. The first version of Crisis that researchers discovered targeted various versions of OS X, and it was a typical data-stealing Trojan, listening in on email and instant messenger communications. The interesting thing about Crisis is not only that there are versions for multiple platforms, but also that the installer for the malware, which masquerades as an Adobe Flash installer, checks to see what operating system it's on and then installs the appropriate version.

The malware also has a function that looks for VMWare images stored on the infected machine, and if it finds one, it will mount the image and then copy itself to the virtual machine image.

 

Researchers found a similar piece of malware back in April. That one was disguised as a Java applet that would install different payloads depending upon what OS the target machine was running. So, attackers have decided that more is better when it comes to platforms. Why restrict your creation to just Windows or OS X when you can have both?

Microsoft researchers looked at a recent attack that involved a piece of malware using similar techniques and found that the attackers have been honing their skills.

"In the case of a cross-platform offering, the attacker utilizes a decision agent to recognize the appropriate package or software for its target. When the victim pulls pages or content from the attacker's distribution channel, an agent (often referred to as the browser's user-agent) provides information, and a decision is made on behalf of the victim – that is, it automatically identifies the appropriate package or software without asking the user," Methusela Cebrian Ferrer of Microsoft's malware Protection Center wrote in an analysis of the techniques used by cross-platform malware.

"However, in the recent event described, we observed that the delivery of malicious code through vulnerabilities in Java employs a decision agent as part of a cross-platform attack. As shown in the timeline below, we first noticed this feature used in a Java vulnerability referred to as CVE-2011-3544. It was followed last month by the use of a Java Signed Applet attack – a form of social engineering where the user is lured to accept a signed Java applet and thereafter allows the attacker to run any payload."

One thing that's helping drive this trend is the existence of vulnerabilities in apps such as Java that are installed on several platforms, giving attackers the ability to use one vulnerability to get their malware on more than one platform. That's a key advantage for the attackers, and highlights the importance of keeping third-party apps patched and up to date.

Courtesy By Dennis Fisher

Which Browser Offers the Most Secure Password Storage?

Considering the availability of browser-based password management and auto-fill systems and the intuition that you should never put all your eggs in one basket, do the three major browsers offer robust enough security features to justify trusting them with your passwords and, in some cases, credit card information? 

Both Google Chrome and Mozilla Firefox’s latest iterations store viewable lists of all stored passwords. By default, anyone signed into your Windows account will be able to view passwords or other auto-fill data stored on Firefox and Google’s operating systems, according to Eric Geier in PC World.  If you are going to use browser-based password storage, Firefox is the most secure option due in large part to a built in master password feature, Geier said. The feature is not enabled by default, but once it’s turned on, it encrypts any passwords stored on Firefox and makes it so those signed into your Windows account will need a password to view saved passwords in the Firefox settings.

Furthermore, and perhaps even more securely, if the master password setting is enabled, users will be required to provide that password the first time they use a saved password each browsing session.

Unlike Firefox, Chrome offers no master password protection. Passwords are obscured by asterisks in Chrome’s settings, if a user highlights any given password and clicks show, then they can view that password in plaintext. Unlike the other two browsers, users can change passwords from within the settings page, which is a neat feature, but doesn’t do much in the way of security. Chrome, Geier points out, will not sense password changes on its own, so if you do change a password, then you’ll have to change it in the settings. Also problematic for Chrome is that it, unlike Firefox, will store credit card details, including full card name, numbers, and expiration dates.

 

Internet Explorer 9, Geier writes, offers the most basic password storage. Unlike the other two browsers, there is no way to view or edit passwords in the settings. In fact, all you can do in the settings is regulate which general information is being stored (usernames, passwords, forms, etc.) or delete all autocomplete history altogether. While its features pale in comparison to those of its primary competitors, the default autocomplete settings provide ample protection to the passwords themselves, although users on your Windows account will still be able to access any online accounts stored by autofill if they know where to look on the web.

Courtesy By Brain Donohue

Flaws in Shamoon Malware Reinforce Theory It's Not A Wiper Variant

Some clumsy coding discovered during an analysis of the Shamoon malware has led researchers to conclude that it is probably not related to the Wiper malware that hit some Iranian networks recently and likely isn't the work of serious programmers.

A prime error appears to come from the main executable -- the dropper -- which in some systems is launched as a service to create a scheduled task, only the programming works incorrectly due to the date August 15, 2012 being hard-coded into the malware. Thus, if the current year is 2013 or later but the month is earlier than August, the malware reads the date as arriving before the August 2012 checkpoint value.

"This error indirectly confirms our initial conclusion that the Shamoon malware is not the Wiper malware that attacked Iranian systems," wrote Kaspersky Lab researcher Dmitry Tarakanov in a Securelist post. "Wiper is presumed to be a cyber-weapon and, if so, it should have been developed by a team of professionals. But experienced programmers would hardly be expected to mess up a date comparison routine."

"Wiper" was the name researchers gave to malware that was discovered earlier this summer on some networks in Iran erasing data from infected machines. Like that malware, Shamoon steals data from infected computers before overwriting the master boot record, rendering compromised machines unbootable. But upon further analysis, researchers realized the two pieces of malware differed.

In an earlier post by another Kaspersky Lab expert, Shamoon was considered an imitation of the earlier malware tied to energy systems. "It is more likely that this is a copycat, the work of a script kiddies inspired by the story. Nowadays, destructive malware is rare; the main focus of cybercriminals is financial profit. Cases like the one here do not appear very often."

Tarakanov outlined evidence for such a conclusion by examining how the program runs in a typical 32-bit operating system. For instance, the program expects arguments that work like a list of IP addresses linked to computers targeted for infection. When the program runs without such arguments, it must rely on a service it installs locally, called a distributed link tracking server, to ensure the malware reboots and changes workstation configurations whenever the operating system loads.

"There is an easier way to force the OS to run a service at startup – just set up the appropriate option of a particular service," Tarakanov wrote. "Moreover, 'TrkSvr' gets created by malware with that option adjusted to start automatically. Why the author followed this method, with dependencies, is difficult to understand."

Courtesy by Annie Satia

Fake Flash Player, Laden with Malware, Making Rounds

Scammers have already begun to take advantage of Adobe’s recent decision to remove its Flash Player from Android’s Google Play marketplace. Last week's removal has prompted scammers to start promoting fake versions of the software to unsuspecting smartphone owners. While researching the scamware, security firm GFI Labs uncovered a separate fake version of the Flash Player that's not only bogus but an SMS Trojan that comes bundled with adware.

According to a post on the company’s blog, the app named 'adobeflashinstaller.apk' comes replete with adware from the mobile ad network AirPush. Once installed, the app tricks users into following a series of steps to root their phone before downloading another .APK file. This file, hosted on a XDA-Developers forum post, is a hacked version of Adobe’s Flash Player app. While the app isn’t necessarily malicious, it’s not authorized by the company, meaning it’s possible the app could grant or install permissions without the users’ knowledge further down the line.

Meanwhile, the app’s adware leads to the installation of advertisements on the phone. If the user tries to deletes them, the adware will simply add more of them. The adware also will change the users’ home page; send pop-up ads to the phone’s status bar every fifteen minutes and even read and send the users’ phonebook contacts to advertisers.

Adobe ceased development on Flash Player for Android on August 15 after announcing it was shifting its focus to AIR, a runtime environment that allows apps that utilize Flash to run on devices natively. Adobe added that the current version of Flash Player as it stands may exhibit “unpredictable behavior” when the next version of Android, Jelly Bean, is further rolled out.

Courtesy by  Christopher Brook

SMSZombie Malware Infecting Android Devices, Stealing Money

A nasty new piece of malware that has the ability to steal money from users' via fraudulent SMS payments has shown up in a Chinese Android market and researchers say it's infected more than 500,000 victims. The SMSZombie malware is being hidden inside apps on the app market and once it's on a device it has the ability to prevent users from uninstalling it.

The SMSZombie malware targets Android devices and uses a flaw in the SMS payment system used by China Mobile to forward payments to the attacker without the user's knowledge. Researchers at TrustGo, a mobile security company, found that the malware is hiding inside of various apps on the GFan Android market in China and once users download an infected app, the SMSZombie malware attempts to gain administrator-level privileges on the device.

"The SMSZombie virus has been hidden in a variety of wallpaper apps and attracts users with provocative titles and pictures. When the user sets the app as the device’s wallpaper, the app will request the user to install additional files associated with the virus. If the user agrees, the virus payload is delivered within a file called 'Android System Service'," the researchers at TrustGo wrote in an analysis.

"Once installed, the virus then tries to obtain administrator privileges on the user’s device. This step cannot be canceled by the user, as the 'Cancel' button only reloads the dialog box until the user eventually is forced to select 'Activate' to stop the dialog box. These privileges disable users’ ability to delete the app, causing the device to return to the home screen even after choosing to uninstall the app."

 

Mobile malware of this kind is becoming increasingly more common as attackers focus on going after users on whatever device they use the most, and for many people these days, that means mobile phones. 

SMSZombie is designed to steal money from users by sending SMS payments to the attackers. The malware has the ability to send payments without the user's knowledge and can send them at random intervals and for whatever amount the attacker chooses. SMSZombie includes a configuration file that the attacker can update remotely, as well.

"Using a configuration file that can be updated by the malware maker at anytime, the malware can intercept and forward a variety of SMS messages. Because these messages often include banking and financial information, users accounts can easily be hacked further," TrustGo said.

"It has been confirmed that this virus has been used to recharge online gaming accounts via the China Mobile SMS Payment system. Commonly, the victim’s account is charged a relatively low amount to escape detection."

Courtesy by Dennis Fisher

Average Web App Attacked Every Three Days

Do not envy the life of a Web app. It's a brutal, public existence filled with attacks from all sides. In fact, a new report by Imperva sheds some light on this sad life, showing that a typical Web app is attacked once every three days and some are targeted as many as 2,700 times in a given year.

Web apps are lots of fun for attackers because they're publicly accessible and take all kinds of interesting inputs. Attackers can take their time, throwing whatever data they choose at a given app and then see what happens to break. To determine what this attack landscape looks like, Imperva monitored 50 Web applications for six months, looking at the kinds of attacks each one endured and pulling out trends. 

One of the more interesting findings was that the typical Web app can expect to be attacked every third day and that some of the applications are under attack as often as 292 days per year. There are likely to be multiple attack incidents on any given day, as well. The average attack that Imperva observed lasted a little less than eight minutes and the longest went on for about 80 minutes.

"However, regardless of attack frequency periods, compared to the peaceful periods, the success of the whole mission depends on the defense performance when under attack. Therefore, the defense solutions and procedures should be designed to accommodate attack bursts," the Imperva report says.

"While, typically, an application will see only some serious attack action on 59 days in 6 months (roughly on every third day on average), and the attack period may last only a few minutes. The intensity of the attack will be overwhelming if the defense side was prepared for the average case (27 or 18 attacks per hour as discovered on our previous reports) as the attack will consist of hundreds or even thousands of individual attack requests."

Unsurprisingly, the report found that SQL injection was the most common attack type. As simple as it is and as old as it is, SQL injection still works nicely, thanks to the widespread nature of the vulnerabilities the attack exploits. Oddly, however, Imperva found that while the vast majority of the IP addresses involved in attacks against the monitored Web apps were in the United States, most of the SQL injection attack traffic actually came from France.

Looking at historical attack data to try and predict when attacks may come in the future can be difficult, the report found. Much of the attack traffic the company observed flowing into the 50 Web apps it was monitoring came in unpredictable bursts. One of the apps, which Imperva monitored for a full year rather than six months, experienced short spikes in attack traffic every few weeks until a major burst in January 2012, which was seven or eight times the normal volume. The number of attacks then subsided and went back to its normal pattern of occasional spikes.

"Don’t be fooled by relative average calm of the battlefield. As you typically would witness a 'battle day' only on one day out of three, and it typically would last just a few minutes. However the way your security solution and process would perform on these minutes really determines your overall security performance. So, base your estimations for the security measures you need on the worst-case scenario and not on the average case," Imperva said in the report.

Courtesy by Dennis Fisher

In First Black Hat Talk, Apple Reveals Little New About iOS Security

An odd thing happened at Black Hat on Thursday: an Apple security official gave a talk. Seats began filling early, 20 minutes before the talk began, and expectations were high, with many people wondering how much the speaker would reveal about the inner workings of iOS security. And then the talk began and it was fairly clear that the answer to that question was, not much.

The talk by Dallas De Atley of Apple's platform security team was full of technical details on the myriad security features and defensive technologies in iOS, but most of it was review of the content that was in the white paper on iOS security that the company released earlier this year. Speaking to a packed ballroom, De Atley walked through the security capabilities of iOS, from the lowest level functions of the boot loader and kernel all the way up through the code signing requirements and app permissions. 

Apple's security philosophy, he said, is that security needs to be an integral part of a device or software design from the earliest stages of development.

"Our attitude is that security is architecture. You have to build it in from the very beginning. It's not something you can sprinkle over the code at the end," De Atley said. 

 

If that sounds a lot like some of the statements you've heard from Microsoft security officials in the last few years, that's not a coincidence. The philosophy is the same, as is the goal: make life for attackers as difficult as possible. For Apple, this means not only protecting the iOS operating system itself, but also ensuring that all of the apps on the phone behave correctly and that users data is safeguarded as well. 

"The phone has all of your personal data and these devices know an awful lot about how we live our lives and become a critical part of how we interact with other people," he said. 

That fact drove a lot of the security features that Apple built into iOS. The iPhone has a secure boot process that handles the way that all of the components are loaded before the kernel starts. It also has a firmware personalization feature that customies the low-level software to each specific device, which enables Apple to selectively disable newly discovered flaws in the kernel for portions of the user population without affecting everyone.

Apple updates iOS on a regular basis, pushing out new versions to users several times a year. But users have to install the updates manually, which can lead to some users running older, vulnerable versions of the software for some time. However, De Atley said that right now, 80 percent of the iPhone user base is running the most recent version of iOS. That means most iPhone users have all of the exploit mitigations, security patches and other updates Apple has released, a nice situation for any vendor.

In addition to the hardware and low-level software protections, De Atley said that a major part of the iOS security model is the way that the devices handle apps. All apps must be signed by the developer, each of whom is issued a code-signing certificate. And third-party apps--those not developed by Apple itself--are given a special set of restrictions.

"All third-party apps live in a container, and it's randomly assigned at installtion time, so apps aren't hard-coding where they live on the device," he said. "The container is sandboxed and that's enforced by the kernel."

Before the release of the iOS white paper, Apple officials had not spoken much publicly about the security of the system. Most of what was known about it was discovered through research by outsiders. De Atley's talk, while not groundbreaking, could be a positive sign of what's to come in future security communications from the company.

Courtesy by Dennis Fisher