Showing posts with label app store. Show all posts
Showing posts with label app store. Show all posts

Saturday, February 15, 2014

MAC TROJAN STEALS BITCOIN WALLET CREDENTIALS

from threatpost.com
A small number of Bitcoin wallets have been raided by a newly discovered Trojan that gobbles up credentials used to guard the digital currency.

OSX/CoinThief.A was found in the wild by a security consultancy specializing in Apple security called SecureMac; the malware was spreading on GitHub via a malicious app, which has since been removed from the code repository.

“At this time we’ve seen multiple reports on Reddit and other Bitcoin forums with users indicating that they’ve fallen victim to the malware, but we do not yet know the full scope of the malware distribution,” SecureMac lead developer Nicholas Ptacek said. “As news of this malware spreads, more victims will probably come forward.”

A Reddit discussion about the incident seems to link the author of the app called Stealthbit used to spread CoinThief to a previous attack targeting Bitcoin credentials carried out through an app called Bitvanity. The author of CoinThief went by the handle trevorscool or Thomas Revor, while the Bitvanity GitHub account was registered to a Trevory. The person posting said the Bitvanity app lifted more than 20 Bitcoins—an approximate value of $14,000 USD.

“The malware author tried to take down the malicious binary from Github yesterday, and possibly didn’t realize that it would still be available from the commit history,” Ptacek said. “At some point in the afternoon, the entire Github page for StealthBit was 404′ing, but we are not sure if the malware author deleted his account, or if the page was taken down by Github.”

StealthBit pretends to be an app used to send and receive payments on Bitcoin Stealth Addresses. Instead, when victims install it, their web browsing traffic is monitored by the Trojan, which sniffs out login credentials for Bitcoin wallets.

“At this time there does not appear to be any vulnerability that the malware is exploiting, but rather it is a classic case of social engineering,” Ptacek said. “The infected users thought they were installing an app to send and receive payments on Bitcoin Stealth Addresses, but the app did more than was advertised when it installed the malware. Since the user was intending to install the app, Gatekeeper warnings wouldn’t have been effective at stopping those users from running the app.”

The consultancy said the CoinThief Trojan is a dropper that installs browser extensions on Safari and Chrome running on OS X. The extensions keep tabs on Web traffic from the browsers and watches for log-in attempts on pre-loaded Bitcoin exchanges such as Mt. Gox and BTC-e and wallet sites such as blockchain.info. The extensions, meanwhile, are generically named “Pop-up Blocker,” and arrive with an equally generic description that wouldn’t raise suspicions with the user or security researchers.

“Additionally, the malware appears to monitor specific file locations on disk, checking to see when they are modified. Analysis of this malware is still in the early stages, so more information is likely to come to light moving forward,” Ptacek said.

The attackers hosted the source code and a precompiled version of the app on GitHub, SecureMac said. The source code and app, however, were not a match. The pre-compiled app contained malware not present in the source code and infected OS X users with CoinThief. Not only does the malware watch Web traffic, but it connects to a remote command and control server where it sends the stolen credentials and also receives updates from the attackers.

“Information sent back to the server isn’t limited to Bitcoin login credentials, but also includes the username and UUID (unique identifier) for the infected Mac, as well as the presence of a variety of Bitcoin-related apps on the system,”  SecureMac said on its site.

Ptacek said the remote server was registered in Australia via bitcoinwebhosting[.]net, but appeared to be hosted elsewhere. The remote server was located at www[.]media02-cloudfront[.]com, with a current IP address of 217[.]78[.]5[.]17, but it appears to be down at this time, Ptacek said.

Apple’s security restrictions make it highly unlikely the malware would have made its way onto the Apple App Store. Also, there is no indication of a mobile component of this Trojan for iOS devices.

“The Trojan only works on OS X, and we haven’t seen any indication of the presence of an iOS version,” Ptacek said. “Furthermore, due to the security restrictions Apple has built into iOS, this malware would not be able to function on iOS.”

Tuesday, December 17, 2013

Bah! Humbug! Apple Bans Christmas Tree

from cultofmac.com
#boycottapple
Why do you confuse us like this, Apple?


Renaming the 12 Days of Christmas app “12 Days of Gifts” one moment (just to underline that this is, after all, the holiday of shopping), and then producing what is genuinely one of this winter’s most heartfelt and touching Christmas ads the next — Apple has now further befuddled (and angered) a large group of people by banishing the giant Christmas tree in shopping area De Passage of Netherlands city The Hague.

The reason? It obscured the front entrance of Apple’s new store. The company apparently negotiated for the Christmas tree’s removal as part of its rental agreement to open the property.


Where previously shoppers had a tree like the one pictured above, here is what they now have instead:
Granted, a new Apple Store for a public Christmas tree isn’t the worst tradeoff in the world, but it also wasn't enough to stop local resident Phyllis White taking to her blog to complain — noting that:
“Certainly the local people will go to the [Apple] Store and spend their money and buy Apple products, so Apple, do the decent thing: give something back to our community, give us back our Christmas tree, our Christmas tradition, it is CHRISTMAS after all, a time for giving not taking!!”
Rumors that Tim Cook would be visited by three iOS-optimized ghosts teaching him the true spirit of Christmas were unsubstantiated at time of writing.

Monday, July 16, 2012

Apple In-App Store Hacked

from informationweek.com
Hacker finds way to loot in-app store items and posts a how-to on YouTube.

A Russian hacker has managed to find a way around the security checks in Apple's in-app purchasing system to make content sold in iOS apps available for free.
The hacker, identifying himself as ZonD80, has posted a YouTube video demonstrating how he was able to create an in-app proxy that authorizes in-app purchases at no cost.


"To buy in-app content," he says in the video,"you must install two certificates and set the IP address of the DNS to a specific IP."
On a Blogger hosted site, he has asked for donations to support the development of his project. The PayPal email address he provides for receipt of funds is a Me.com address, a domain owned by Apple. Presumably this will simplify Apple's effort to identify the hacker, though doing so won't stop the spread of his code: ZonD80 notes on his blog that he has sent the source code and control of the hosting server to someone else.

In-app purchasing has become one of the leading sources of revenue for app developers. ABI Research in February predicted that revenue from sale of content in apps will outpace revenue from selling the apps themselves in 2012.
Apple appears to be taking steps to limit the damage. Russian blog i-ekb.ru includes a note, purportedly from ZonD80, indicating that Apple has filed a takedown notice with the service provider of his website.
It's doubtful that Apple will ask Google to remove the hacker's Blogger site--it isn't hosting any code so there might not be any legal foundation to request that Google remove it, unless Apple claims that the domain, in-appstore.com, violates its trademarks.

The hack appears to work on iOS versions 3.0 through 6.0, presently available only in beta form to iOS developers. But not all apps with in-app purchasing are vulnerable. Apple provides a mechanism to validate in-app purchases, in order to allow purchases to be restored on erased or new devices. Developers who have implemented receipt verification, which requires tracking in-app sales using a separate server, can query Apple to confirm the authenticity of purchased items.