Security researchers from North Carolina State University are warning that the majority of Android malware are repackaging other legitimate (popular) apps to get past the mobile platform's rudimentary security barriers.
After analyzing more than 1,200 Android malware families, the reserachers -- Yajin Zhou and Xuxian Jiang -- found that 86.0% repackaged legitimate apps to include malicious payloads and argued that the theats can be effectively mitigated by policing existing Android Markets for repackaging detection.
The pair, working within the Android Malware Genome Project, calleed for a a joint effort involving all parties in the Android ecosystem to spot and discourage repackaged apps. "The challenges lie in the large volume of new apps created on a daily basis as well as the accuracy needed for repackaging detection," the group said in a paper [PDF] to be delivered at the upcoming IEEE Privacy and Security Symposium,
The researchers also found that more than one-third (36.7%) of Android malware enclose platform-level exploits to escalate privileges. "Unfortunately, the open Android platform has the well-known “fragmentation” problem, which leads to a long vulnerable time window of current mobile devices before a patch can be actually deployed," according to the paper.
Worse, researchers bemoaned the fact that current Android platform still lacks many desirable security features. Anti-exploit mitigations like Address Space Layout Randomization (ASLR) was not added until very recently in Android 4.0 and other security features such as TrustZone and eXecute-Never need to be gradually rolled out to raise the bar for exploitation.
The analysis also revealed that the dynamic loading ability of both native code and Dalvik code are being "actively abused" by existing Android malware families. It also found that about 45% of existing malware subscribe to premium-rate services with background SMS messages to generate spoils for cyber-criminals.
The researches recommend that the coarse-grained Android permission model be expanded to include additional context information to better facilitate users to make sound and informed decisions.
The research project also pitted Android malware against four mobile security products and found the results to be poor.
After analyzing more than 1,200 Android malware families, the reserachers -- Yajin Zhou and Xuxian Jiang -- found that 86.0% repackaged legitimate apps to include malicious payloads and argued that the theats can be effectively mitigated by policing existing Android Markets for repackaging detection.
The pair, working within the Android Malware Genome Project, calleed for a a joint effort involving all parties in the Android ecosystem to spot and discourage repackaged apps. "The challenges lie in the large volume of new apps created on a daily basis as well as the accuracy needed for repackaging detection," the group said in a paper [PDF] to be delivered at the upcoming IEEE Privacy and Security Symposium,
"Our characterization of existing Android malware and an evolution-based study of representative ones clearly reveal a serious threat we are facing today. Unfortunately, existing popular mobile security software still lag behind and it becomes imperative to explore possible solutions to make a difference," Zhou and Jiang said.
The researchers also found that more than one-third (36.7%) of Android malware enclose platform-level exploits to escalate privileges. "Unfortunately, the open Android platform has the well-known “fragmentation” problem, which leads to a long vulnerable time window of current mobile devices before a patch can be actually deployed," according to the paper.
Worse, researchers bemoaned the fact that current Android platform still lacks many desirable security features. Anti-exploit mitigations like Address Space Layout Randomization (ASLR) was not added until very recently in Android 4.0 and other security features such as TrustZone and eXecute-Never need to be gradually rolled out to raise the bar for exploitation.
The analysis also revealed that the dynamic loading ability of both native code and Dalvik code are being "actively abused" by existing Android malware families. It also found that about 45% of existing malware subscribe to premium-rate services with background SMS messages to generate spoils for cyber-criminals.
The researches recommend that the coarse-grained Android permission model be expanded to include additional context information to better facilitate users to make sound and informed decisions.
The research project also pitted Android malware against four mobile security products and found the results to be poor.
"The detection results of existing mobile security software are rather disappointing, which does raise a challenging question on the best model for mobile malware detection. Specifically, the unique runtime environments with limited resources and battery could preclude the deployment of sophisticated detection techniques. Also, the traditional content-signature-based approaches have been demonstrated not promising at all," Zhou and Jiang added.
News broke today that Russian developer Alexey Borodin has hacked Apple's In-App Purchase program for iOS, allowing iPhone, iPad, and iPod touch users to circumvent the payment process and essentially steal in-app content. Apple has confirmed it is now investigating the issue.
"The security of the App Store is incredibly important to us and the developer community," an Apple spokesperson told The Loop. "We take reports of fraudulent activity very seriously and we are investigating."
Borodin told The Next Web that all his service needs is a single donated receipt, which it can then use to authenticate anyone's purchase requests. Borodin has spent several hundred dollars on in-app purchases testing and generating receipts.
His circumvention technique thus relies on more than just installing certificates (for a fake in-app purchase server and a custom DNS server) to allow "purchases" to go through. Since he is essentially emulating the receipt verification server on the Apple App Store, the app treats Borodin's server as an official communication.
The problem lies in how Apple authenticates a purchase. There is nothing that ties the purchase directly to a customer or device, meaning a single purchased receipt can be used again and again. In short, this hack means in-app purchase requests are being re-routed as well as approved.
Last but certainly not least, Borodin says Cupertino is transmitting its customers' Apple IDs and passwords in clear text, although he notes he can't see credit card information. The following information is transferred from your device to the Borodin's server: app restriction level, app id, version id, device guid, in-app purchase quantity, in-app purchase offer name, app identifier, app version, your language, and your locale.
Whoever operates in-appstore.com could easily be gathering everyone's iTunes login credentials (as well as unique device-identifying data) in a classic man-in-the-middle attack. The Terms of Service have this rather reassuring message (typos left intact):
We newer collect your password or any of your personal and accesible data, such as appleID, temporary auth key and other .
Borodin told Macworld he was "shocked" that passwords were passed in plain text and not encrypted. Apple of course presumed its iOS software would only be talking to the official in-app purchase server with a valid security certificate. That's a very poor assumption to make, as Borodin's hack has clearly shown.
"The security of the App Store is incredibly important to us and the developer community," an Apple spokesperson told The Loop. "We take reports of fraudulent activity very seriously and we are investigating."
Borodin told The Next Web that all his service needs is a single donated receipt, which it can then use to authenticate anyone's purchase requests. Borodin has spent several hundred dollars on in-app purchases testing and generating receipts.
His circumvention technique thus relies on more than just installing certificates (for a fake in-app purchase server and a custom DNS server) to allow "purchases" to go through. Since he is essentially emulating the receipt verification server on the Apple App Store, the app treats Borodin's server as an official communication.
The problem lies in how Apple authenticates a purchase. There is nothing that ties the purchase directly to a customer or device, meaning a single purchased receipt can be used again and again. In short, this hack means in-app purchase requests are being re-routed as well as approved.
Last but certainly not least, Borodin says Cupertino is transmitting its customers' Apple IDs and passwords in clear text, although he notes he can't see credit card information. The following information is transferred from your device to the Borodin's server: app restriction level, app id, version id, device guid, in-app purchase quantity, in-app purchase offer name, app identifier, app version, your language, and your locale.
Whoever operates in-appstore.com could easily be gathering everyone's iTunes login credentials (as well as unique device-identifying data) in a classic man-in-the-middle attack. The Terms of Service have this rather reassuring message (typos left intact):
We newer collect your password or any of your personal and accesible data, such as appleID, temporary auth key and other .
Borodin told Macworld he was "shocked" that passwords were passed in plain text and not encrypted. Apple of course presumed its iOS software would only be talking to the official in-app purchase server with a valid security certificate. That's a very poor assumption to make, as Borodin's hack has clearly shown.
An Illinois woman who claims LinkedIn violated its own user agreement and privacy policy is spearheading a class action lawsuit against the business-networking site in wake of the recent loss to hackers of private data.
Katie Szpyrka, a registered LinkedIn account holder since 2010, claims the company “failed to properly safeguard its users’ digitally stored personally identifiable information including email addresses, passwords, and login credentials.”
Szpyrka, who filed the suit in United State District Court in the Northern District of California, is demanding a jury trial on grounds including breach of contract and negligence.
She says the users in the class action group include individuals and entities in the United States who had a LinkedIn account on or before June 6, 2012, including those who paid for an upgraded account.
Two weeks ago, LinkedIn reported that Russian hackers had stolen nearly 6.5 million passwords. Users, who are prone to reuse passwords across different web sites, were urged to change their passwords. With more than 150 million users, the password theft involved less than 5% of LinkedIn’s user base.
In the suit, Szpyrka, who pays $26.95 per month for a premium LinkedIn account, says LinkedIn’s privacy policy promises users that all the information they provide will be protected with industry standards and technology.
She says LinkedIn failed to comply with basic industry standards by using a weak encryption format. The company had encrypted passwords with a SHA-1 algorithm, but according to experts the fact the company neglected to “salt” the hash weakened the security.
The suit specifically points out that LinkedIn failed to salt the passwords before storing them. The salt adds a dimension to the hash that makes it more difficult to uncover the protected data.
The suit also references preliminary reports that said hackers used an SQL injection attack, which lets hackers access databases via a Web site.
SQL injection attacks have been one of the most common forms of attack dating back to 2007. The first attacks date back to 2005. The suit sites National Institute of Standards and Technology checklists as common guidance for avoiding SQL injection attacks.
The suit also faults LinkedIn for not publicizing the attack and says it only came to light after it was announced by third-parties. The suit claims the company later admitted it “was not handling user data in accordance with best practices.”
The suit claims that damages are in excess of $5 million.
Katie Szpyrka, a registered LinkedIn account holder since 2010, claims the company “failed to properly safeguard its users’ digitally stored personally identifiable information including email addresses, passwords, and login credentials.”
Szpyrka, who filed the suit in United State District Court in the Northern District of California, is demanding a jury trial on grounds including breach of contract and negligence.
She says the users in the class action group include individuals and entities in the United States who had a LinkedIn account on or before June 6, 2012, including those who paid for an upgraded account.
Two weeks ago, LinkedIn reported that Russian hackers had stolen nearly 6.5 million passwords. Users, who are prone to reuse passwords across different web sites, were urged to change their passwords. With more than 150 million users, the password theft involved less than 5% of LinkedIn’s user base.
In the suit, Szpyrka, who pays $26.95 per month for a premium LinkedIn account, says LinkedIn’s privacy policy promises users that all the information they provide will be protected with industry standards and technology.
She says LinkedIn failed to comply with basic industry standards by using a weak encryption format. The company had encrypted passwords with a SHA-1 algorithm, but according to experts the fact the company neglected to “salt” the hash weakened the security.
The suit specifically points out that LinkedIn failed to salt the passwords before storing them. The salt adds a dimension to the hash that makes it more difficult to uncover the protected data.
The suit also references preliminary reports that said hackers used an SQL injection attack, which lets hackers access databases via a Web site.
SQL injection attacks have been one of the most common forms of attack dating back to 2007. The first attacks date back to 2005. The suit sites National Institute of Standards and Technology checklists as common guidance for avoiding SQL injection attacks.
The suit also faults LinkedIn for not publicizing the attack and says it only came to light after it was announced by third-parties. The suit claims the company later admitted it “was not handling user data in accordance with best practices.”
The suit claims that damages are in excess of $5 million.
Summary: Both Visa and MasterCard have confirmed they have warned U.S. banks that a credit card processor was reportedly breached. Both firms say their own security systems were not compromised.
News broke today that Visa and MasterCard have reportedly warned banks of a major potential breach at a U.S.-based credit card processor (see Visa, MasterCard warn of ‘massive’ security breach and Analysts on Visa, MasterCard credit card security breach). Both Visa and MasterCard have now confirmed the breach, although the two also emphasize their own security systems were not compromised.
First off, here’s Visa’s statement:
Here is MasterCard’s statement:
Alerts sent out to U.S. banks late last week advised them that certain cards may have been compromised, and that full Track 1 and Track 2 data was taken, which means perpetrators got enough to counterfeit new cards. The breach, which is believed to have occurred between January 21 and February 25, 2012, may involve more than 10 million compromised card numbers.
News broke today that Visa and MasterCard have reportedly warned banks of a major potential breach at a U.S.-based credit card processor (see Visa, MasterCard warn of ‘massive’ security breach and Analysts on Visa, MasterCard credit card security breach). Both Visa and MasterCard have now confirmed the breach, although the two also emphasize their own security systems were not compromised.
First off, here’s Visa’s statement:
Visa Inc. is aware of a potential data compromise incident at a third party entity affecting card account information from all major card brands. There has been no breach of Visa systems, including its core processing network VisaNet.
Visa has provided payment card issuers with the affected account numbers so they can take steps to protect consumers through independent fraud monitoring and, if needed, reissuing cards.
It’s important for U.S. Visa consumer cardholders to know they are protected against fraudulent purchases with Visa’s zero liability fraud protection policy, which exceeds federal safeguards. As always, Visa encourages cardholders to regularly monitor their accounts and to notify their issuing financial institution promptly of any unusual activity. Additional consumer security tips are available at www.VisaSecuritySense.com.
Every business that handles payment card information is expected to protect the security and privacy of their customers’ financial information by adhering to the highest data protection standards. Visa also supports advanced security layers such as encryption, tokenization and dynamic authentication through EMV chip technology to further protect sensitive account information and minimize the impact of data compromises.
Here is MasterCard’s statement:
MasterCard is currently investigating a potential account data compromise event of a U.S.-based entity and, as a result, we have alerted payment card issuers regarding certain MasterCard accounts that are potentially at risk. Law enforcement has been notified of this matter and the incident is currently the subject of an ongoing forensic review by an independent data security organization.
Alerts sent out to U.S. banks late last week advised them that certain cards may have been compromised, and that full Track 1 and Track 2 data was taken, which means perpetrators got enough to counterfeit new cards. The breach, which is believed to have occurred between January 21 and February 25, 2012, may involve more than 10 million compromised card numbers.