Dan Guido, working with Mike Arpaia, brings his well received intelligence-driven security ideas from "The Exploit Intelligence Project" of 2011, into the mobile space.
http://www.trailofbits.com/research/
Showing posts with label Mobile. Show all posts
Showing posts with label Mobile. Show all posts
Tuesday, April 24, 2012
Sunday, February 26, 2012
ASLR in Android Ice Cream Sandwich 4.0
Via Duo Security Blog -
For the uninitiated, ASLR randomizes where various areas of memory (eg. stack, heap, libs, etc) are mapped in the address space of a process. Combined with complementary mitigation techniques such as non-executable memory protection (NX, XN, DEP, W^X, whatever you want to call it), ASLR makes the exploitation of traditional memory corruption vulnerabilities probabilistically difficult.
However, ASLR is commonly an all-or-nothing proposition. If ASLR is not applied to all areas of memory in a process, its effectiveness is often nullified. A single executable mapping that is mapped in a static location in the address space is often sufficient to construct a ROP payload. For example, this was the indeed case with the OS X prior to 10.7, where the dynamic linker was not randomized, providing a sufficient gadget source for a ROP payload.
So, let’s take a look at this new-fangled ICS 4.0 platform and see if ASLR was properly and fully implemented.
[...]
Unfortunately, the ASLR support in Android 4.0 did not live up to expectations and is largely ineffective for mitigating real-world attacks, due to the lack of randomization of the executable and linker memory regions. It also would be beneficial to randomize the heap/brk by setting kernel.randomize_va_space=2.
In addition to ASLR, Android could certainly stand to beef up some of it’s other exploit mitigation mechanisms. Non-executable memory support was recently added and GCC’s stack protector is now enabled in the default NDK CFLAGS, but other mitigations are still lacking. RELRO is missing allowing GOT overwrites as demonstrated in Stealth’s GingerBreak exploit.
I’d also love to see code signing support similar to iOS, which prevents the introduction of new executable code in an address space. In addition, code signing would hamper the ability to pull down additional malicious code at runtime, a technique I demonstrated two years ago at SummerCon that the RootSmart malware authors have recently adopted.
Let’s just hope that we don’t have to wait for another major version release of the Android platform to get the same exploit mitigations that have been available on desktop and server platforms for years.
As Dug eloquently summarizes below: “TL;DR: ICS ASLR = FUBAR”
UPDATE: Nick Kralevich from the Android Security Team provided the following updates in the comments below:
For the uninitiated, ASLR randomizes where various areas of memory (eg. stack, heap, libs, etc) are mapped in the address space of a process. Combined with complementary mitigation techniques such as non-executable memory protection (NX, XN, DEP, W^X, whatever you want to call it), ASLR makes the exploitation of traditional memory corruption vulnerabilities probabilistically difficult.
However, ASLR is commonly an all-or-nothing proposition. If ASLR is not applied to all areas of memory in a process, its effectiveness is often nullified. A single executable mapping that is mapped in a static location in the address space is often sufficient to construct a ROP payload. For example, this was the indeed case with the OS X prior to 10.7, where the dynamic linker was not randomized, providing a sufficient gadget source for a ROP payload.
So, let’s take a look at this new-fangled ICS 4.0 platform and see if ASLR was properly and fully implemented.
[...]
Unfortunately, the ASLR support in Android 4.0 did not live up to expectations and is largely ineffective for mitigating real-world attacks, due to the lack of randomization of the executable and linker memory regions. It also would be beneficial to randomize the heap/brk by setting kernel.randomize_va_space=2.
In addition to ASLR, Android could certainly stand to beef up some of it’s other exploit mitigation mechanisms. Non-executable memory support was recently added and GCC’s stack protector is now enabled in the default NDK CFLAGS, but other mitigations are still lacking. RELRO is missing allowing GOT overwrites as demonstrated in Stealth’s GingerBreak exploit.
I’d also love to see code signing support similar to iOS, which prevents the introduction of new executable code in an address space. In addition, code signing would hamper the ability to pull down additional malicious code at runtime, a technique I demonstrated two years ago at SummerCon that the RootSmart malware authors have recently adopted.
Let’s just hope that we don’t have to wait for another major version release of the Android platform to get the same exploit mitigations that have been available on desktop and server platforms for years.
As Dug eloquently summarizes below: “TL;DR: ICS ASLR = FUBAR”
UPDATE: Nick Kralevich from the Android Security Team provided the following updates in the comments below:
- kernel.randomize_va_space is set to 2 in ICS 4.0.3, randomizing the heap/brk mapping.
- Support for randomizing the linker mapping will be available in a future Android release.
- Support for randomizing executable mappings (PIE) will be available in a future Android release.
Saturday, January 28, 2012
Lookout: Our Take on the ‘Apperhand’ SDK (aka ‘Android.Counterclank’)
Via Lookout Mobile Security Blog -
Today, news came out that claimed a particular family of malware, termed ‘Android.Counterclank’, had infected 5 million users. We disagree with the assessment that this is malware, although we do believe that the Apperhand SDK is an aggressive form of ad network and should be taken seriously.
This isn’t malware.
The average Android user probably doesn’t want applications that contain Apperhand on his or her phone, but we see no evidence of outright malicious behavior. In fact, almost all of the capabilities attributed to these applications are also attributable to a class of more aggressive ad networks – this includes placing search icons onto the mobile desktop and pushing advertisements through the notifications bar.
Malware is defined as software that is designed to engage in malicious behavior on a device. Malware can also be used to steal personal information from a mobile device that could result in identity theft or financial fraud.
Apperhand doesn’t appear to be malicious, and at this point in our investigation, this is an aggressive form of an ad network – not malware.
We’re researching ad networks closely.
We spend a significant amount of time looking not just at mobile apps, but also at SDKs that are commonly integrated into apps. We’ve recently been focusing heavily on the capabilities of various mobile advertising SDKs. We believe that ad networks are important for the overall mobile ecosystem; however, some advertising networks go beyond the commonly accepted behavior of ad networks with more aggressive tactics.
This particular ad network SDK, com.apperhand, bears similarities to one previously distributed in a number of apps in June of 2011 as the “ChoopCheec platform” or “Plankton”.
[...]
We’re continuing our investigation.
At this point, it appears that what we’re seeing is an example of an ad network that pushes the lines of privacy. Over the past few months we have been closely tracking this, and we are seeing a trend of this type of behavior. While this is not malware, we do think that consumers should take it seriously, and we’re actively working on a solution to help users understand whether applications have potentially undesirable behavior such as this while not creating unnecessary worry.
Today, news came out that claimed a particular family of malware, termed ‘Android.Counterclank’, had infected 5 million users. We disagree with the assessment that this is malware, although we do believe that the Apperhand SDK is an aggressive form of ad network and should be taken seriously.
This isn’t malware.
The average Android user probably doesn’t want applications that contain Apperhand on his or her phone, but we see no evidence of outright malicious behavior. In fact, almost all of the capabilities attributed to these applications are also attributable to a class of more aggressive ad networks – this includes placing search icons onto the mobile desktop and pushing advertisements through the notifications bar.
Malware is defined as software that is designed to engage in malicious behavior on a device. Malware can also be used to steal personal information from a mobile device that could result in identity theft or financial fraud.
Apperhand doesn’t appear to be malicious, and at this point in our investigation, this is an aggressive form of an ad network – not malware.
We’re researching ad networks closely.
We spend a significant amount of time looking not just at mobile apps, but also at SDKs that are commonly integrated into apps. We’ve recently been focusing heavily on the capabilities of various mobile advertising SDKs. We believe that ad networks are important for the overall mobile ecosystem; however, some advertising networks go beyond the commonly accepted behavior of ad networks with more aggressive tactics.
This particular ad network SDK, com.apperhand, bears similarities to one previously distributed in a number of apps in June of 2011 as the “ChoopCheec platform” or “Plankton”.
[...]
We’re continuing our investigation.
At this point, it appears that what we’re seeing is an example of an ad network that pushes the lines of privacy. Over the past few months we have been closely tracking this, and we are seeing a trend of this type of behavior. While this is not malware, we do think that consumers should take it seriously, and we’re actively working on a solution to help users understand whether applications have potentially undesirable behavior such as this while not creating unnecessary worry.
Friday, October 28, 2011
Android Orphans: Visualizing a Sad History of Support
http://theunderstatement.com/post/11982112928/android-orphans-visualizing-a-sad-history-of-support
The announcement that Nexus One users won’t be getting upgraded to Android 4.0 Ice Cream Sandwich led some to justifiably question Google’s support of their devices. I look at it a little differently: Nexus One owners are lucky. I’ve been researching the history of OS updates on Android phones and Nexus One users have fared much, much better than most Android buyers.
I went back and found every Android phone shipped in the United States1 up through the middle of last year. I then tracked down every update that was released for each device - be it a major OS upgrade or a minor support patch - as well as prices and release & discontinuation dates. I compared these dates & versions to the currently shipping version of Android at the time. The resulting picture isn’t pretty - well, not for Android users....
-------------------------------------------------------------------------
This is one case where Apple's full vertical market control of their phone product is a positive.
Carriers have never been good about applying OS patches on mobile phones. It was less important when each carrier had a different OS, but as they increasingly converge toward Android...the bad guys are watching the number of mobile devices that can be exploited with one attack plan increasing in front of them very quickly - all thanks to the carriers themselves.
The announcement that Nexus One users won’t be getting upgraded to Android 4.0 Ice Cream Sandwich led some to justifiably question Google’s support of their devices. I look at it a little differently: Nexus One owners are lucky. I’ve been researching the history of OS updates on Android phones and Nexus One users have fared much, much better than most Android buyers.
I went back and found every Android phone shipped in the United States1 up through the middle of last year. I then tracked down every update that was released for each device - be it a major OS upgrade or a minor support patch - as well as prices and release & discontinuation dates. I compared these dates & versions to the currently shipping version of Android at the time. The resulting picture isn’t pretty - well, not for Android users....
-------------------------------------------------------------------------
This is one case where Apple's full vertical market control of their phone product is a positive.
Carriers have never been good about applying OS patches on mobile phones. It was less important when each carrier had a different OS, but as they increasingly converge toward Android...the bad guys are watching the number of mobile devices that can be exploited with one attack plan increasing in front of them very quickly - all thanks to the carriers themselves.
Sunday, October 16, 2011
Secure Android Kernel Could Make for 'Classified' Smart Phones
Via GCN -
A research team from Google, George Mason University and the National Security Agency have developed a hardened kernel for the Android 3.0 operating system that could solve the problem of using smart phones in military operations and emergency response.
The kernel, which is in the final stages of certification testing, opens the way for the Army to begin issuing smart phones or tablet-type wireless devices to troops in combat operations.
The White House also is interested because the hardened kernel could help fulfill a government plan to create a secure national wireless network for first responders, Michael McCarthy, operations director of the Army’s Brigade Modernization Command’s Mission Command Complex, said at the AUSA Annual Meeting and Exposition in Washington on Oct. 10. McCarthy also heads the service’s Connecting Soldiers to Digital Applications (CSDA) program, the lead organization involved in selecting handheld wireless technologies for military use.
[...]
There were delays in getting the operating system accredited until NSA came forward several months ago and offered to expedite the approval process, McCarthy said. The new effort kicked off with a series of meetings with CSDA program personnel and representatives from NSA and the National Institute of Standards and Technology.
The Android kernel is now being tested for a Federal Information Processing Standard 140-2 certification, which is expected by mid-October. “That’s the first level of security that we’ve got to get before we start moving onto being able to ultimately do secret [communications],” he said.
[...]
After the testing is complete, it is just a matter of filling out the certification paperwork, McCarthy said. “That is a game-changer for the security business because it then sets the conditions so that in the second quarter [late March 2012] they can do the certification of the Secure Sockets Layer, which then gives us the ability to operate at the classified levels,” he said.
In addition to the Army’s plans to provide troops with smart phones, the Obama administration was attracted to the technology to support two of its initiatives. One is an effort by the White House Communications Office to move the executive branch from BlackBerry devices to Android-based phones. The reason is because Android devices with the new kernel can be secured at a higher clearance level than BlackBerry devices, McCarthy said.
[...]
One of the concerns behind the government’s drive is that the radio communications networks used by federal, state and local response agencies are not very secure. This is a special concern for law enforcement and emergency response organizations’ operational channels, which could be subject to interception, spoofing and jamming. “They’re looking at replacing radio with a smart phone,” he said.
A research team from Google, George Mason University and the National Security Agency have developed a hardened kernel for the Android 3.0 operating system that could solve the problem of using smart phones in military operations and emergency response.
The kernel, which is in the final stages of certification testing, opens the way for the Army to begin issuing smart phones or tablet-type wireless devices to troops in combat operations.
The White House also is interested because the hardened kernel could help fulfill a government plan to create a secure national wireless network for first responders, Michael McCarthy, operations director of the Army’s Brigade Modernization Command’s Mission Command Complex, said at the AUSA Annual Meeting and Exposition in Washington on Oct. 10. McCarthy also heads the service’s Connecting Soldiers to Digital Applications (CSDA) program, the lead organization involved in selecting handheld wireless technologies for military use.
[...]
There were delays in getting the operating system accredited until NSA came forward several months ago and offered to expedite the approval process, McCarthy said. The new effort kicked off with a series of meetings with CSDA program personnel and representatives from NSA and the National Institute of Standards and Technology.
The Android kernel is now being tested for a Federal Information Processing Standard 140-2 certification, which is expected by mid-October. “That’s the first level of security that we’ve got to get before we start moving onto being able to ultimately do secret [communications],” he said.
[...]
After the testing is complete, it is just a matter of filling out the certification paperwork, McCarthy said. “That is a game-changer for the security business because it then sets the conditions so that in the second quarter [late March 2012] they can do the certification of the Secure Sockets Layer, which then gives us the ability to operate at the classified levels,” he said.
In addition to the Army’s plans to provide troops with smart phones, the Obama administration was attracted to the technology to support two of its initiatives. One is an effort by the White House Communications Office to move the executive branch from BlackBerry devices to Android-based phones. The reason is because Android devices with the new kernel can be secured at a higher clearance level than BlackBerry devices, McCarthy said.
[...]
One of the concerns behind the government’s drive is that the radio communications networks used by federal, state and local response agencies are not very secure. This is a special concern for law enforcement and emergency response organizations’ operational channels, which could be subject to interception, spoofing and jamming. “They’re looking at replacing radio with a smart phone,” he said.
Thursday, October 13, 2011
New Mac Trojan Variant is VMware-Aware
Via Virus Bulletin -
Researchers at F-Secure have found a variant of the 'Flashback' trojan for Mac (a fake Adobe Flash Player update) that is capable of detecting whether it is run in a virtual environment.
Virtualization is a technique commonly used by malware researchers as it allows them to run the malware in a safe environment. To frustrate researchers and to avoid detection, malware authors regularly build in anti-virtualization techniques: the malware tries to detect whether it is running in a virtual environment and does not run if this is the case, thus hiding its malicious activity.
While such techniques are commonly seen in Windows malware, Mac malware using anti-virtualization techniques had not hitherto been seen. This is yet another example that shows that Mac malware is not only becoming more prevalent but also more advanced.
More at F-Secure's blog here.
----------------------------------------------------------------------------
While anti-virutalization is nothing new for Windows malware, it is a new development for Mac malware....and thus resembles an evolution in the complexity and the feature set of Mac malware.
Similar to Android malware research recently conducted by Symantec, we should expect malware authors to continue to incorporate features from the Windows malware world into the Mac malware world. They will continue to explore the capabilities of this emerging malware ecosystem, especially if the revenue-per-infection ratio improves.
Researchers at F-Secure have found a variant of the 'Flashback' trojan for Mac (a fake Adobe Flash Player update) that is capable of detecting whether it is run in a virtual environment.
Virtualization is a technique commonly used by malware researchers as it allows them to run the malware in a safe environment. To frustrate researchers and to avoid detection, malware authors regularly build in anti-virtualization techniques: the malware tries to detect whether it is running in a virtual environment and does not run if this is the case, thus hiding its malicious activity.
While such techniques are commonly seen in Windows malware, Mac malware using anti-virtualization techniques had not hitherto been seen. This is yet another example that shows that Mac malware is not only becoming more prevalent but also more advanced.
More at F-Secure's blog here.
----------------------------------------------------------------------------
While anti-virutalization is nothing new for Windows malware, it is a new development for Mac malware....and thus resembles an evolution in the complexity and the feature set of Mac malware.
Similar to Android malware research recently conducted by Symantec, we should expect malware authors to continue to incorporate features from the Windows malware world into the Mac malware world. They will continue to explore the capabilities of this emerging malware ecosystem, especially if the revenue-per-infection ratio improves.
Tuesday, October 11, 2011
New Symantec Research: The Motivations of Recent Android Malware
Via Symantec Connect Blog -
For years now, we in the cyber security industry have been saying an explosion of mobile malware is just around the corner. Beginning in earnest this year, we have indeed observed a marked increase in threats targeting mobile devices – particularly the Android platform. However, it’s probably not accurate to say the expected explosion has in fact occurred. The reality is that cybercriminals are still very much in the exploratory phase of figuring out how to monetize the exploitation of mobile devices. This is the topic of Symantec’s latest research. You can read the whitepaper in its entirety here (PDF).
Above all else, our analysis highlights how most current efforts to monetize mobile malware have only a low revenue-per-infection ratio. This has severely limited the return on investment achievable by attackers. It also offers detailed insight into the top current mobile malware monetization schemes observed by Symantec, including how each works and examples of the malware presently being used to carry them out. These schemes are:
[...]
Additional potential revenue-generating schemes likely to be seen in the near future are discussed as well. These include:
For years now, we in the cyber security industry have been saying an explosion of mobile malware is just around the corner. Beginning in earnest this year, we have indeed observed a marked increase in threats targeting mobile devices – particularly the Android platform. However, it’s probably not accurate to say the expected explosion has in fact occurred. The reality is that cybercriminals are still very much in the exploratory phase of figuring out how to monetize the exploitation of mobile devices. This is the topic of Symantec’s latest research. You can read the whitepaper in its entirety here (PDF).
Above all else, our analysis highlights how most current efforts to monetize mobile malware have only a low revenue-per-infection ratio. This has severely limited the return on investment achievable by attackers. It also offers detailed insight into the top current mobile malware monetization schemes observed by Symantec, including how each works and examples of the malware presently being used to carry them out. These schemes are:
- Premium-rate number billing scams
- Spyware
- Search engine poisoning
- Pay-per-click scams
- Pay-per-install schemes
- Adware
- Stealing mobile transaction authentica¬tion numbers (mTAN)
[...]
Additional potential revenue-generating schemes likely to be seen in the near future are discussed as well. These include:
- Selling stolen International Mobile Equipment Identity (IMEI) numbers for use on previously blocked or counterfeit phones.
- Peddling fake mobile security products—another tactic that has been highly successful in the PC realm.
Monday, October 3, 2011
HTC Android Phones Leak Private User Data
Via Threatpost.com -
There is a serious security issue with a variety of HTC Android phones that enables any app with Internet permissions to access a huge amount of private data on the device, including call logs, email addresses, SMS messages, last known GPS location and more. The problem was introduced via an update to the HTC phones that installed a tool called HTCLogger that collects the data.
The issue was discovered late last week and researchers developed a proof-of-concept app that shows how much data any arbitrary app can access on the affected devices, which include the EVO 4G, EVO3D, Thunderbolt and others. The leak of what should be private data is enabled by the presence of the HTCLogger tool, according to a report on the Android Police site, and any app installed on an affected device that has Internet permissions can then access the data cache via a local port. Many Android apps have the android.permission.INTERNET permission by default.
[...]
HTC did not immediately respond to a request for comment on the issue.
The list of functions and information that the HTCLogger app can access is long, and includes both coarse and fine location data, network information, IP address, WiFi state, detailed data on the OS version and kernel, account information on the device, system logs and other data. The HTC tool was apparently meant as a way for developers to get detailed information about what is causing problems on a device. However, as the Android Police research shows, that data also can be accessed by a long list of other apps and used for other purposes.
The problem only affects HTC Android phones with the stock Sense firmware installed. Users who have rooted their phones may be able to delete the logging tool themselves. The file is located at /system/app/HtcLoggers.apk, according to the Android Police report.
-------------------------------------------------------------------
It would seem that HTC totally screwed up and didn't consider the security impact of their new application development helper tool.
There is a serious security issue with a variety of HTC Android phones that enables any app with Internet permissions to access a huge amount of private data on the device, including call logs, email addresses, SMS messages, last known GPS location and more. The problem was introduced via an update to the HTC phones that installed a tool called HTCLogger that collects the data.
The issue was discovered late last week and researchers developed a proof-of-concept app that shows how much data any arbitrary app can access on the affected devices, which include the EVO 4G, EVO3D, Thunderbolt and others. The leak of what should be private data is enabled by the presence of the HTCLogger tool, according to a report on the Android Police site, and any app installed on an affected device that has Internet permissions can then access the data cache via a local port. Many Android apps have the android.permission.INTERNET permission by default.
[...]
HTC did not immediately respond to a request for comment on the issue.
The list of functions and information that the HTCLogger app can access is long, and includes both coarse and fine location data, network information, IP address, WiFi state, detailed data on the OS version and kernel, account information on the device, system logs and other data. The HTC tool was apparently meant as a way for developers to get detailed information about what is causing problems on a device. However, as the Android Police research shows, that data also can be accessed by a long list of other apps and used for other purposes.
The problem only affects HTC Android phones with the stock Sense firmware installed. Users who have rooted their phones may be able to delete the logging tool themselves. The file is located at /system/app/HtcLoggers.apk, according to the Android Police report.
-------------------------------------------------------------------
It would seem that HTC totally screwed up and didn't consider the security impact of their new application development helper tool.
Tuesday, September 13, 2011
SPITMO: First SpyEye Attack on Android Mobile Platform Now in the Wild
Via Net-Security.org -
The first SpyEye variant, called SPITMO, has been spotted attacking Android devices in the wild. According to Amit Klein, Trusteer’s chief technology officer, the threat posed by DriodOS/Spitmo has escalated the danger of SpyEye now that this malicious software has been able to shift its delivery and infection methods.
“We always said it was just a matter of time before the true potential of Spitmo was realized," says Klein. "When it first emerged [for the Symbian OS] back in April, F-Secure reported in its blog that it was targeting European banks. The trojan injected fields into a bank's webpage asking the customer to input his mobile phone number and the IMEI of the phone. The fraudster then needed to follow a cumbersome three stage sequence - get the IMEI number; generate a certificate; then release an updated installer. This process could take up to three days."
“We couldn’t believe fraudsters would go to that much effort just to steal a couple of SMSs - and it appears we were right," he says. "Information gathered by Trusteer's Intelligence Centre has discovered a new far more intuitive, and modern, approach of SPITMO for Android now active in the wild.”
[...]
Once the Trojan has successfully installed [on the Android device], all incoming SMS messages are intercepted and transferred to the attacker’s Command and Control server. A code snippet is run when an SMS is received, creating a string, which will later be appended as a query string to a GET HTTP request, to be sent to the attacker's drop zone.
[...]
What makes all of this so scary is that the application is not visible on the device’s dashboard, making it virtually undetectable, so users are not aware of its presence and will struggle to get rid of it."
-----------------------------------------------------------------------------------------------
Readers should keep in mind these Spitmo (SpyEye in the Mobile) and Zitmo (ZeuS in the Mobile) attacks are not purely mobile OS level attacks, they are really blended malware attacks.
Spimto & Zitmo: Attack Begins on the Desktop, But Increasingly Has Mobile Components
In the Spitmo case outlined by Trusteer above, the attack begins when the victim's PC is infected with this new variant of SpyEye. Once the victim visit their online banking website (on their PC), the malware injects a "new" security measure message on the website - which advises the user to download a Android application which is "mandatory in order to use its online banking service." The new measure pretends to be an Android application that protects the phone’s SMS messages from being intercepted and will protect the user against fraud.
The Zitmo attack outlined by Fortinet in September 2010 follows a similar pattern. The attack begins when the victim's PC is infected with this variant of ZeuS. It injects a message into the user's browser upon visiting the online banking website, asking for the user's phone number and phone model. Based on that info, it sends an SMS with a link to the appropriate version of the malicious package (a Symbian package for Symbian phones, a BlackBerry Jar for BlackBerry phones, etc).
Threat Mitigation Recommendations
With this deeper understanding of the Spimto/Zistmo attacks, it is clear desktop based protection is still critically important to mitigate these of blended desktop/mobile malware attacks. As always, multi-layered security system on the desktop is recommended to ensure a high-level of protection. However, it is likely, the mobile components of these blended attacks will grow more advanced (and perhaps more independent) as the mobile devices themselves grow more powerful and mobile banking becomes more common.
The first SpyEye variant, called SPITMO, has been spotted attacking Android devices in the wild. According to Amit Klein, Trusteer’s chief technology officer, the threat posed by DriodOS/Spitmo has escalated the danger of SpyEye now that this malicious software has been able to shift its delivery and infection methods.
“We always said it was just a matter of time before the true potential of Spitmo was realized," says Klein. "When it first emerged [for the Symbian OS] back in April, F-Secure reported in its blog that it was targeting European banks. The trojan injected fields into a bank's webpage asking the customer to input his mobile phone number and the IMEI of the phone. The fraudster then needed to follow a cumbersome three stage sequence - get the IMEI number; generate a certificate; then release an updated installer. This process could take up to three days."
“We couldn’t believe fraudsters would go to that much effort just to steal a couple of SMSs - and it appears we were right," he says. "Information gathered by Trusteer's Intelligence Centre has discovered a new far more intuitive, and modern, approach of SPITMO for Android now active in the wild.”
[...]
Once the Trojan has successfully installed [on the Android device], all incoming SMS messages are intercepted and transferred to the attacker’s Command and Control server. A code snippet is run when an SMS is received, creating a string, which will later be appended as a query string to a GET HTTP request, to be sent to the attacker's drop zone.
[...]
What makes all of this so scary is that the application is not visible on the device’s dashboard, making it virtually undetectable, so users are not aware of its presence and will struggle to get rid of it."
-----------------------------------------------------------------------------------------------
Readers should keep in mind these Spitmo (SpyEye in the Mobile) and Zitmo (ZeuS in the Mobile) attacks are not purely mobile OS level attacks, they are really blended malware attacks.
Spimto & Zitmo: Attack Begins on the Desktop, But Increasingly Has Mobile Components
In the Spitmo case outlined by Trusteer above, the attack begins when the victim's PC is infected with this new variant of SpyEye. Once the victim visit their online banking website (on their PC), the malware injects a "new" security measure message on the website - which advises the user to download a Android application which is "mandatory in order to use its online banking service." The new measure pretends to be an Android application that protects the phone’s SMS messages from being intercepted and will protect the user against fraud.
The Zitmo attack outlined by Fortinet in September 2010 follows a similar pattern. The attack begins when the victim's PC is infected with this variant of ZeuS. It injects a message into the user's browser upon visiting the online banking website, asking for the user's phone number and phone model. Based on that info, it sends an SMS with a link to the appropriate version of the malicious package (a Symbian package for Symbian phones, a BlackBerry Jar for BlackBerry phones, etc).
Threat Mitigation Recommendations
With this deeper understanding of the Spimto/Zistmo attacks, it is clear desktop based protection is still critically important to mitigate these of blended desktop/mobile malware attacks. As always, multi-layered security system on the desktop is recommended to ensure a high-level of protection. However, it is likely, the mobile components of these blended attacks will grow more advanced (and perhaps more independent) as the mobile devices themselves grow more powerful and mobile banking becomes more common.
Thursday, July 7, 2011
Phishers’ World in Your Cell Phone
Via Symantec Uber Security Response Blog -
Technologies in cell phones are advancing day after day, and so phishers are also seeking various means to exploit vulnerable cell phone users. The two key areas in which we can see this trend are, firstly, the increase in phishing against wireless application protocol (WAP) pages, and secondly, the use of compromised domain names that have been registered for mobile devices.
Many legitimate brands have designed their websites for cell phones or WAP pages. The difference between a WAP page and a regular Web page is that the WAP page uses reduced file sizes and minimal graphics. This is done for cell phone compatibility and also to achieve higher browsing speeds while the user is on the move. Symantec has recorded phishing sites spoofing such Web pages and has monitored the trend. In June, social networking and information services brands were observed in these phishing sites. In the example shown below, the phishing page consists of nothing more than a form asking for users’ credentials. (This is a typical design created for cell phones.) When a victim enters the required information, the phishing page is redirected to the WAP page of the legitimate brand. The phishing site in this case was hosted on a free Web hosting site.
[...]
The domain names used for websites accessed by mobiles devices commonly have a “.mobi” top level domain (TLD). These domain names are compromised and utilized by phishers to host several phishing sites. Over the past six months, about 65 percent of these phishing sites spoofed brands from the banking sector, whereas 19 percent were from the e-commerce sector and the remaining were from the ISP, social networking, and information services sectors.
The primary motive of phishers in these attacks continues to be identity theft. Targeting cell phone users is just part of a new strategy for achieving the same result.
---------------------------------------------------------------------------
In January 2011, Trusteer, makers of the Rapport security software, gained access to the log files of several web servers that were hosting phishing websites. Analysis of these logs yields some interesting insight:
Compound that idea with the current lack of mobile phone security suites in general use (e.g. Anti-virus, Anti-phishing, etc) and you have a massive unprotected userbase which is more likely to act in a dangerous manner when mobile.
Technologies in cell phones are advancing day after day, and so phishers are also seeking various means to exploit vulnerable cell phone users. The two key areas in which we can see this trend are, firstly, the increase in phishing against wireless application protocol (WAP) pages, and secondly, the use of compromised domain names that have been registered for mobile devices.
Many legitimate brands have designed their websites for cell phones or WAP pages. The difference between a WAP page and a regular Web page is that the WAP page uses reduced file sizes and minimal graphics. This is done for cell phone compatibility and also to achieve higher browsing speeds while the user is on the move. Symantec has recorded phishing sites spoofing such Web pages and has monitored the trend. In June, social networking and information services brands were observed in these phishing sites. In the example shown below, the phishing page consists of nothing more than a form asking for users’ credentials. (This is a typical design created for cell phones.) When a victim enters the required information, the phishing page is redirected to the WAP page of the legitimate brand. The phishing site in this case was hosted on a free Web hosting site.
[...]
The domain names used for websites accessed by mobiles devices commonly have a “.mobi” top level domain (TLD). These domain names are compromised and utilized by phishers to host several phishing sites. Over the past six months, about 65 percent of these phishing sites spoofed brands from the banking sector, whereas 19 percent were from the e-commerce sector and the remaining were from the ISP, social networking, and information services sectors.
The primary motive of phishers in these attacks continues to be identity theft. Targeting cell phone users is just part of a new strategy for achieving the same result.
---------------------------------------------------------------------------
In January 2011, Trusteer, makers of the Rapport security software, gained access to the log files of several web servers that were hosting phishing websites. Analysis of these logs yields some interesting insight:
- Mobile users are the first to arrive at the phishing website
- Mobile users accessing phishing websites are three times more likely to submit their login info than desktop users
- Eight times more iPhone users accessed these phishing websites than Blackberry users
Compound that idea with the current lack of mobile phone security suites in general use (e.g. Anti-virus, Anti-phishing, etc) and you have a massive unprotected userbase which is more likely to act in a dangerous manner when mobile.
Tuesday, July 5, 2011
Australian Department of Defence - iOS Hardening Configuration Guide
http://www.dsd.gov.au/publications/iOS_Hardening_Guide.pdf
June 2011
Audience
This guide is for users and administrators of iOS 4.3.3 or later devices. These devices
include the iPod Touch, iPhone and iPad. To use this guide, you should be:
Parts of this guide refer to features that require the engagement of the technical resources of
your telephony carrier, firewall vendor, or Mobile Device Management vendor. While every
effort has been made to ensure content involving these third party products is correct at the
time of writing, you should always check with these vendors when planning an
implementation.
Additionally, mention of third party products is not a specific endorsement of that vendor over
another; they are mentioned as illustrative examples only.
Some instructions in this guide are complex, and could cause serious effects to the device,
your network and your agency’s security posture. These instructions should only be used by
experienced administrators, and should be used in conjunction with thorough testing.
Finally, for further clarification or assistance, IT Security Advisors of Australian government
agencies can consult the Defence Signals Directorate by contacting emailing
assist@dsd.gov.au or the DSD Cyber Hotline on 1300 CYBER1 (1300 292 371).
June 2011
Audience
This guide is for users and administrators of iOS 4.3.3 or later devices. These devices
include the iPod Touch, iPhone and iPad. To use this guide, you should be:
- familiar with basic networking concepts;
- an experienced Mac OS X or Windows administrator: and
- familiar with the Mac OS X or Windows interface.
Parts of this guide refer to features that require the engagement of the technical resources of
your telephony carrier, firewall vendor, or Mobile Device Management vendor. While every
effort has been made to ensure content involving these third party products is correct at the
time of writing, you should always check with these vendors when planning an
implementation.
Additionally, mention of third party products is not a specific endorsement of that vendor over
another; they are mentioned as illustrative examples only.
Some instructions in this guide are complex, and could cause serious effects to the device,
your network and your agency’s security posture. These instructions should only be used by
experienced administrators, and should be used in conjunction with thorough testing.
Finally, for further clarification or assistance, IT Security Advisors of Australian government
agencies can consult the Defence Signals Directorate by contacting emailing
assist@dsd.gov.au or the DSD Cyber Hotline on 1300 CYBER1 (1300 292 371).
Wednesday, June 29, 2011
Symantec: A Window Into Mobile Device Security
http://www.symantec.com/content/en/us/about/media/pdfs/symc_mobile_device_security_june2011.pdf
Executive Summary
The mass-adoption of both consumer and managed mobile devices in the enterprise has increased employee productivity but has also exposed the enterprise to new security risks. The latest mobile platforms were designed with security in mind—both teams of engineers attempted to build security features directly into the operating system to limit attacks from the outset. However, as the paper discusses, while these security provisions raise the bar, they may be insufficient to protect the enterprise assets that regularly find their way onto devices. Finally, complicating the security picture is the fact that virtually all of today’s mobile devices operate in an ecosystem, much of it not controlled by the enterprise—they connect and synchronize out-of-the-box with third-party cloud services and computers whose security posture is potentially unknown and outside of the enterprise’s control.
[...]
Summary of iOS Security
Overall, Symantec considers iOS’s security model to be well designed and thus far it has proven largely resistant to attack. To summarize:
Summary of Android’s Security
Overall, while we believe the Android security model is a major improvement over the models used by traditional desktop and server-based operating systems, it has two major drawbacks. First, its provenance system enables attackers to anonymously create and distribute malware. Second, its permission system, while extremely powerful, ultimately relies upon the user to make important security decisions. Unfortunately, most users are not technically capable of making such decisions and this has already led to social engineering attacks. To summarize:
Executive Summary
The mass-adoption of both consumer and managed mobile devices in the enterprise has increased employee productivity but has also exposed the enterprise to new security risks. The latest mobile platforms were designed with security in mind—both teams of engineers attempted to build security features directly into the operating system to limit attacks from the outset. However, as the paper discusses, while these security provisions raise the bar, they may be insufficient to protect the enterprise assets that regularly find their way onto devices. Finally, complicating the security picture is the fact that virtually all of today’s mobile devices operate in an ecosystem, much of it not controlled by the enterprise—they connect and synchronize out-of-the-box with third-party cloud services and computers whose security posture is potentially unknown and outside of the enterprise’s control.
[...]
Summary of iOS Security
Overall, Symantec considers iOS’s security model to be well designed and thus far it has proven largely resistant to attack. To summarize:
- iOS’s encryption system provides strong protection of emails and email attachments, and enables device wipe, but thus far has provided less protection against a physical device compromise by a determined attacker.
- iOS’s provenance approach ensures that Apple vets every single publicly available app. While this vetting approach is not foolproof, and almost certainly can be circumvented by a determined attacker, it has thus far proved a deterrent against malware attacks, data loss attacks, data integrity attacks, and denial of service attacks.
- iOS’s isolation model totally prevents traditional types of computer viruses and worms, and limits the data that spyware can access. It also limits most network-based attacks, such as buffer overflows, from taking control of the device. However, it does not necessarily prevent all classes of data loss attacks, resource abuse attacks, or data integrity attacks.
- iOS’s permission model ensures that apps can’t obtain the device’s location, send SMS messages, or initiate phone calls without the owner’s permission.
- None of iOS’s protection technologies address social engineering attacks such as phishing or spam.
Summary of Android’s Security
Overall, while we believe the Android security model is a major improvement over the models used by traditional desktop and server-based operating systems, it has two major drawbacks. First, its provenance system enables attackers to anonymously create and distribute malware. Second, its permission system, while extremely powerful, ultimately relies upon the user to make important security decisions. Unfortunately, most users are not technically capable of making such decisions and this has already led to social engineering attacks. To summarize:
- Android’s provenance approach ensures that only digitally signed applications may be installed on Android devices. However, attackers can use anonymous digital certificates to sign their threats and distribute them across the Internet without any certification by Google. Attackers can also easily “trojanize” or inject malicious code into legitimate applications and then easily redistribute them across the Internet, signing them with a new, anonymous certificate. On the plus side, Google does require application authors wishing to distribute their apps via the official Android App Marketplace to pay a fee and register with Google (sharing the developer’s digital signature with Google). As with Apple’s registration approach, this should act as a deterrent to less organized attackers.
- Android’s default isolation policy effectively isolates apps from each other and from most of the device’s systems including the Android operating system kernel, with several notable exceptions (apps can read all data on the SD card unfettered).
- Android’s permission model ensures that apps are isolated from virtually every major device system unless they explicitly request access to those systems. Unfortunately, Android ultimately relies upon the user to decide whether or not to grant permissions to an app, leaving Android open to social engineering attacks. Most users are unequipped to make such security decisions, leaving them open to malware and all of the secondary attacks (for example DDoS attacks, Data Loss attacks) that malware can launch.
- Android recently began offering built-in encryption in Android 3.0. However, earlier versions of Android (running on virtually all mobile phones in the field), contain no encryption capability, instead relying upon isolation and permissions to safeguard data. Thus, a simple jailbreak of an Android phone or theft of the device’s SD card can lead to a significant amount of data loss.
- As with iOS, Android has no mechanism to prevent social engineering attacks such as phishing attacks or other (off-device) Web-based trickery.
Thursday, June 9, 2011
Some Top Android Apps Put Data at Risk w/ Insecure Password Storage
via WSJ.com (Digits Blog) -
You’d think the spate of Internet security breaches this spring would have companies on their toes. But when it comes to wireless apps, some are still making rookie mistakes. Computer security firm viaForensics has found the applications for top Internet companies LinkedIn Corp., Netflix, Inc., Foursquare and Square, Inc. stored various forms of users’ personal data in plain text on a mobile device, putting sensitive information at risk to computer criminals.
The Android applications of LinkedIn, Netflix and Foursquare stored user names and passwords in unencrypted form on their Google-powered devices. Storing that data in plain text violates a commonly accepted best practice in computer security. Since many people tend to use the same usernames and passwords across any number of sites, the failing could help hackers penetrate other accounts.
ViaForensics also found the iPhone version of Square’s mobile payments app exposed a user’s transaction amount history and the most recent digital signature of a person who signed an electronic receipt on the app. A hacker would need skill and luck to exploit the vulnerabilities –- either via physical access to a person’s phone or through malicious software that is installed on the device — scenarios that could open bigger security risks than those created by the password problem alone.
Still, the opening is a concern. “Data should not be stored on a phone,” said Andrew Hoog, chief investigative officer of viaForensics, which is based in Chicago. If data is stored on a phone, he said, it should be encrypted.
----------------------------------------------------------------------
Earlier this year, OWASP announced a new "Mobile Security Project" with a new Mobile Top 10 Risks list (currently in draft). This “Top 10” initiative is intended to help organizations determine how to best apply development and security resources to better protect their mobile applications and data. This insecure storage of client-side data is the first risk in the list.
Mobile Code Security: Guide to Improving the Security of Your Mobile Application
http://www.veracode.com/security/mobile-code-security
You’d think the spate of Internet security breaches this spring would have companies on their toes. But when it comes to wireless apps, some are still making rookie mistakes. Computer security firm viaForensics has found the applications for top Internet companies LinkedIn Corp., Netflix, Inc., Foursquare and Square, Inc. stored various forms of users’ personal data in plain text on a mobile device, putting sensitive information at risk to computer criminals.
The Android applications of LinkedIn, Netflix and Foursquare stored user names and passwords in unencrypted form on their Google-powered devices. Storing that data in plain text violates a commonly accepted best practice in computer security. Since many people tend to use the same usernames and passwords across any number of sites, the failing could help hackers penetrate other accounts.
ViaForensics also found the iPhone version of Square’s mobile payments app exposed a user’s transaction amount history and the most recent digital signature of a person who signed an electronic receipt on the app. A hacker would need skill and luck to exploit the vulnerabilities –- either via physical access to a person’s phone or through malicious software that is installed on the device — scenarios that could open bigger security risks than those created by the password problem alone.
Still, the opening is a concern. “Data should not be stored on a phone,” said Andrew Hoog, chief investigative officer of viaForensics, which is based in Chicago. If data is stored on a phone, he said, it should be encrypted.
----------------------------------------------------------------------
Earlier this year, OWASP announced a new "Mobile Security Project" with a new Mobile Top 10 Risks list (currently in draft). This “Top 10” initiative is intended to help organizations determine how to best apply development and security resources to better protect their mobile applications and data. This insecure storage of client-side data is the first risk in the list.
Mobile Code Security: Guide to Improving the Security of Your Mobile Application
http://www.veracode.com/security/mobile-code-security
Wednesday, May 18, 2011
Beating Up on Android: Practical Android Attacks
http://www.immunityinc.com/infiltrate/presentations/Android_Attacks.odt.pdf
Abstract
In this talk Massimialiano Oldani and Bas Alberts exploit the Android Attack Surface. This talk will demonstrate the various ways Android devices may be compromised both remotely and locally. Furthermore, it will explore many of the interesting things a remote attacker can do once they have established access to your Android device.
------------------------------------------------------------
This presentation was presented @ Immunity Inc.'s Infilrate 2011 conference by two senior researchers for Immunity, Inc.
Abstract
In this talk Massimialiano Oldani and Bas Alberts exploit the Android Attack Surface. This talk will demonstrate the various ways Android devices may be compromised both remotely and locally. Furthermore, it will explore many of the interesting things a remote attacker can do once they have established access to your Android device.
------------------------------------------------------------
This presentation was presented @ Immunity Inc.'s Infilrate 2011 conference by two senior researchers for Immunity, Inc.
Wednesday, April 6, 2011
Mobile Apps Invading Your Privacy
Via Veracode ZeroDay Labs Blog -
An article in the Wall Street Journal, dated April 5, 2011, disclosed that Federal prosecutors in New Jersey are investigating numerous smart phone application manufacturers for allegedly, illegally obtaining and distributing personal private information to third party advertisement groups. The allegations state that mobile applications are gathering data such as GPS location, device identifiers, gender, and even user age without proper notice or authorization from the end user. The Journal tested 101 applications and found that 56 of them transmitted the device unique identifier off the device, while 47 transmitted the phone’s location. Five of the tested applications leaked personal information such as user gender and age.
Analysis
The folks at the Veracode research team decided to spend a bit of our time today breaking apart one of the accused applications to see what could be found within the code. Given what was written in the Journal article, we thought it would be most interesting to take an in-depth look through the Pandora application for the Android platform. A quote from the article states the following about the Pandora application:
Conclusion
So what does this mean to the end user? It means your personal information is being transmitted to advertising agencies in mass quantities. As more and more “free” applications attempt to monetize their offerings, we will likely see more of your personal information being shuttled out to marketing and advertising data aggregation firms. The application developers may not even be aware of the privacy violations they are introducing by using third party advertising libraries. They may merely think they are getting $x per ad impression, not that the ad library is leaking significant information about the user.
In isolation some of this data is uninteresting, but when compiled into a single unifying picture, it can provide significant insight into a persons life. Consider for a moment that your current location is being tracked while you are at your home, office, or significant other’s house. Couple that with your gender and age and then with your geolocated IP address. When all that is placed into a single basket, it’s pretty easy to determine who someone is, what they do for a living, who they associate with, and any number of other traits about them. I don’t know about you, but that feels a little Orwellian to me.
An article in the Wall Street Journal, dated April 5, 2011, disclosed that Federal prosecutors in New Jersey are investigating numerous smart phone application manufacturers for allegedly, illegally obtaining and distributing personal private information to third party advertisement groups. The allegations state that mobile applications are gathering data such as GPS location, device identifiers, gender, and even user age without proper notice or authorization from the end user. The Journal tested 101 applications and found that 56 of them transmitted the device unique identifier off the device, while 47 transmitted the phone’s location. Five of the tested applications leaked personal information such as user gender and age.
Analysis
The folks at the Veracode research team decided to spend a bit of our time today breaking apart one of the accused applications to see what could be found within the code. Given what was written in the Journal article, we thought it would be most interesting to take an in-depth look through the Pandora application for the Android platform. A quote from the article states the following about the Pandora application:
In Pandora’s case, both the Android and iPhone versions of its app transmitted information about a user’s age, gender, and location, as well as unique identifiers for the phone, to various advertising networks. Pandora gathers the age and gender information when a user registers for the service.[...]
Conclusion
So what does this mean to the end user? It means your personal information is being transmitted to advertising agencies in mass quantities. As more and more “free” applications attempt to monetize their offerings, we will likely see more of your personal information being shuttled out to marketing and advertising data aggregation firms. The application developers may not even be aware of the privacy violations they are introducing by using third party advertising libraries. They may merely think they are getting $x per ad impression, not that the ad library is leaking significant information about the user.
In isolation some of this data is uninteresting, but when compiled into a single unifying picture, it can provide significant insight into a persons life. Consider for a moment that your current location is being tracked while you are at your home, office, or significant other’s house. Couple that with your gender and age and then with your geolocated IP address. When all that is placed into a single basket, it’s pretty easy to determine who someone is, what they do for a living, who they associate with, and any number of other traits about them. I don’t know about you, but that feels a little Orwellian to me.
Thursday, March 17, 2011
WhisperCore Brings Device-level Encryption to Android
Via H-Online.com (Security) -
Whisper Systems, the developers of the RedPhone voice encryption and TextSecure SMS encryption systems for Android phones, has now released WhisperCore. The software is a device-level encryption system that is intended to protect all the data on a user's Android phone.
Whisper Systems CTO and co-founder, Moxie Marlinspike, told CNET that WhisperCore "uses AES with 256-bit keys in XTS mode, the same disk encryption protocol that's proven itself in the PC space with tools like TrueCrypt or LUKS (Linux Unified Key Setup)".
This first release is an early beta labelled version 0.1 and is described as a tech-demo. This release is only currently available for Nexus S phones but is expected to expand to other devices soon. WhisperCore will be available for free for individual use with pricing for commercial use dependent on deployment size.
The web site currently available states that the system integrates with the Android operating system and protects all the data and programs on the phone. It includes full-disk encryption and can be set so as to also protect data held on the phone's SD card.
The WhisperCore Beta is available to download on the Whisper Systems web site. Three installers are available, for 64-bit Linux, Mac OS X and 64-bit Windows. As a beta it should not be used where security or stability is important.
Whisper Systems, the developers of the RedPhone voice encryption and TextSecure SMS encryption systems for Android phones, has now released WhisperCore. The software is a device-level encryption system that is intended to protect all the data on a user's Android phone.
Whisper Systems CTO and co-founder, Moxie Marlinspike, told CNET that WhisperCore "uses AES with 256-bit keys in XTS mode, the same disk encryption protocol that's proven itself in the PC space with tools like TrueCrypt or LUKS (Linux Unified Key Setup)".
This first release is an early beta labelled version 0.1 and is described as a tech-demo. This release is only currently available for Nexus S phones but is expected to expand to other devices soon. WhisperCore will be available for free for individual use with pricing for commercial use dependent on deployment size.
The web site currently available states that the system integrates with the Android operating system and protects all the data and programs on the phone. It includes full-disk encryption and can be set so as to also protect data held on the phone's SD card.
The WhisperCore Beta is available to download on the Whisper Systems web site. Three installers are available, for 64-bit Linux, Mac OS X and 64-bit Windows. As a beta it should not be used where security or stability is important.
Friday, March 4, 2011
Analysis Shows DroidDream Trojan Designed for Future Monetization
Via Threatpost.com -
A detailed analysis of the DroidDream Trojan that was found in dozens of apps in the Android Market this week shows that the malware has a modular construction that likely was designed to give attackers the ability to monetize infected devices through installations of adware or spyware.
The Trojan itself is not especially clever or sophisticated and its communications with its command-and-control server on the back end are essentially by the book, as well. After infection, the DroidDream malware calls home to its C&C server to announce its presence and ask for further instructions. That's all rote, pro forma stuff.
What's most interesting in the DroidDream construction is that the Trojan is designed to act mainly as a downloader module, a shell to pull down other malicious modules in the future. This is the kind of malicious behavior that has been common in desktop and server malware for years now, but hasn't been seen widely on mobile devices as of yet. Most mobile malware up till now has been designed to carry out one or two specific tasks, say sending SMS messages to premium numbers or stealing online banking credentials.
"The highly modular architecture of the Trojan is interesting and points out of a few important conclusions. First of all, it has been designed to be easy to include in popular applications, to be uploaded on the Market with misleading names. Secondly, it has a classical command-and-control architecture – it sends an initial 'I’m here' query with basic info and then deploys a more complex downloader to infect the device further," Kaspersky Lab malware researcher Denis Maslennikov wrote in his analysis of the DroidDream Trojan. "This is pretty similar to many Windows Trojans. Finally, the ability to install other applications on the devices hints at the way through which the author was planning to monetize the infections – by deploying Adware or Advertising-supported apps on the device."
A detailed analysis of the DroidDream Trojan that was found in dozens of apps in the Android Market this week shows that the malware has a modular construction that likely was designed to give attackers the ability to monetize infected devices through installations of adware or spyware.
The Trojan itself is not especially clever or sophisticated and its communications with its command-and-control server on the back end are essentially by the book, as well. After infection, the DroidDream malware calls home to its C&C server to announce its presence and ask for further instructions. That's all rote, pro forma stuff.
What's most interesting in the DroidDream construction is that the Trojan is designed to act mainly as a downloader module, a shell to pull down other malicious modules in the future. This is the kind of malicious behavior that has been common in desktop and server malware for years now, but hasn't been seen widely on mobile devices as of yet. Most mobile malware up till now has been designed to carry out one or two specific tasks, say sending SMS messages to premium numbers or stealing online banking credentials.
"The highly modular architecture of the Trojan is interesting and points out of a few important conclusions. First of all, it has been designed to be easy to include in popular applications, to be uploaded on the Market with misleading names. Secondly, it has a classical command-and-control architecture – it sends an initial 'I’m here' query with basic info and then deploys a more complex downloader to infect the device further," Kaspersky Lab malware researcher Denis Maslennikov wrote in his analysis of the DroidDream Trojan. "This is pretty similar to many Windows Trojans. Finally, the ability to install other applications on the devices hints at the way through which the author was planning to monetize the infections – by deploying Adware or Advertising-supported apps on the device."
Thursday, March 3, 2011
2011 Becomes the Year of Mobile Malware
Via Veracode Blog (March 2, 2011) -
Google pulled over 20 malicious apps from the Android Marketplace today. The inevitable has happened. 2011 has become the year of mobile malware. All the pieces of the malware ecosystem puzzle that researchers have been warning about are falling into place..
[...]
The malicious apps that were pulled were legitimate apps that were pirated, modified by the attackers, and republished. To downloaders of these apps they behaved and looked like well-functioning apps. There was no reason for these users to rate these apps poorly in the Android Marketplace’s reputation system or to leave comments that the apps were suspicious. This shows that reputation systems are a poor method of ensuring an app store is free of malware.
To Google’s credit they did remove the apps and have, or will, wipe the apps from users’ devices but this is too little, too late. The mobile devices are already compromised as the malware took advantage of kernel vulnerabilities to root the devices and download more malware that didn’t come through the app store. Anyone who ran the malicious apps now has a compromised device running software with root permissions that Google cannot wipe.
The exact same thing could happen tomorrow even though we know what Android kernel exploit code was used and there are new versions of Android that fix these issues. This is because many Android phones cannot be updated to the new versions of Android, 2.2.2 and 2.3, that fix the root holes. Many Android phone providers have customized their versions of Android so up to half of Android phones running 2.0, 2.1, 2.2 are sitting ducks to the same problem tomorrow.
-------------------------------------------------------------------------------------------------
Android Malware DroidDream: How it Works
http://blog.mylookout.com/2011/03/android-malware-droiddream-how-it-works/
Google pulled over 20 malicious apps from the Android Marketplace today. The inevitable has happened. 2011 has become the year of mobile malware. All the pieces of the malware ecosystem puzzle that researchers have been warning about are falling into place..
[...]
The malicious apps that were pulled were legitimate apps that were pirated, modified by the attackers, and republished. To downloaders of these apps they behaved and looked like well-functioning apps. There was no reason for these users to rate these apps poorly in the Android Marketplace’s reputation system or to leave comments that the apps were suspicious. This shows that reputation systems are a poor method of ensuring an app store is free of malware.
To Google’s credit they did remove the apps and have, or will, wipe the apps from users’ devices but this is too little, too late. The mobile devices are already compromised as the malware took advantage of kernel vulnerabilities to root the devices and download more malware that didn’t come through the app store. Anyone who ran the malicious apps now has a compromised device running software with root permissions that Google cannot wipe.
The exact same thing could happen tomorrow even though we know what Android kernel exploit code was used and there are new versions of Android that fix these issues. This is because many Android phones cannot be updated to the new versions of Android, 2.2.2 and 2.3, that fix the root holes. Many Android phone providers have customized their versions of Android so up to half of Android phones running 2.0, 2.1, 2.2 are sitting ducks to the same problem tomorrow.
-------------------------------------------------------------------------------------------------
Android Malware DroidDream: How it Works
http://blog.mylookout.com/2011/03/android-malware-droiddream-how-it-works/
When the host application—Bowling Time, in this case—is launched by a user, DroidDream will start by sending sensitive data to a command and control server. The sensitive data includes: IMEI, IMSI, Device Model & SDK Version.
[...]
DroidDream is configured to perform at least one successful check-in with the command and control server, at which point the command and control server will respond and acknowledge the presence of malware on the infected device. We found that the DroidDream authors have configured the malware to make sure the device is not already infected with another variant of DroidDream. If the device is already infected, the malware will not re-infect it.
When DroidDream attempts to infect a device, it uses two known exploits, exploid and rageagainstthecage, to break out of the Android security container. Both of the vulnerabilities being exploited were patched by Android 2.3 (Gingerbread). If exploid fails to root the device, the malware will attempt to use rageagainstthecage. Once the phone is rooted, DroidDream is configured to searched for a specific package named com.android.providers.downloadsmanager. If the malware does not find this package on the device, it will silently install a second malicious application without the user’s knowledge. If DroidDream does find the downloadsmanager package, it will not continue infecting the device with the second malicious application.
At Lookout, we are currently in the process of confirming what this second application is capable of, but our initial analysis shows that it appears to be able to send additional sensitive information to a remote server. The second malicious application also appears that to have the capability to silently install other applications.
Wednesday, March 2, 2011
Data Visualization: Global Android Activations, Oct '08 - Jan '11
Data visualization of global Android device activations from October 2008 to January 2011.
Friday, January 21, 2011
The Sound of a Credit Card
Via ESET Threat Blog -
A recent article at Thinq.co.uk describes how an attack against Android based phones might be able to capture you credit card information even when you speak it into the phone. The interesting thing about this proof of concept is not that the application can capture voice details, but rather that it uses a second application to transmit the captured information.
Google designed Android so that certain communications were limited between applications, but the researchers found a way around that. Instead of directly sending the information from one program to another, they use a clever form of Morse code. Morse code was probably the first widely accepted binary form of communications. Dots and dashes are no different than ones and zeros. One application changes something like the screen brightness and another reads the screen brightness. Let’s say that full illumination is a dot, and anything less is a dash. By making minor modifications in how bright the screen is a lot of data can be transferred between programs without the user probably noticing it.
It will be interesting to see if this attack can be used against other smart phones as well.
A recent article at Thinq.co.uk describes how an attack against Android based phones might be able to capture you credit card information even when you speak it into the phone. The interesting thing about this proof of concept is not that the application can capture voice details, but rather that it uses a second application to transmit the captured information.
Google designed Android so that certain communications were limited between applications, but the researchers found a way around that. Instead of directly sending the information from one program to another, they use a clever form of Morse code. Morse code was probably the first widely accepted binary form of communications. Dots and dashes are no different than ones and zeros. One application changes something like the screen brightness and another reads the screen brightness. Let’s say that full illumination is a dot, and anything less is a dash. By making minor modifications in how bright the screen is a lot of data can be transferred between programs without the user probably noticing it.
It will be interesting to see if this attack can be used against other smart phones as well.
Subscribe to:
Posts (Atom)