Update 4 Sep 23:38 GMT+2: The FBI issued a tweet denying that it ever had the 12 million Apple IDs in question:
Statement soon on reports that one of our laptops with personal info was hacked. We never had info in question. Bottom Line: TOTALLY FALSE—
FBI PressOffice (@FBIPressOffice) September 04, 2012
Here the complete Statement from the FBI Press Office.
Original Post: Few hours ago, the @AnonymousIRC Twitter account has announced yet another resounding cyber attack carried on in name of the #Antisec movement:
(@AnonymousIRC) September 04, 2012
In a special edition of their #FFF refrain (literally quoting the authors of the attack: “so special that’s even not on friday”), the Hacktivists claim to have obtained from FBI 12,000,000 Apple Devices UDIDs (UDID is the short form for Unique Device Identifier, the unique string of numbers that univocally identifies each iOS device), and have consequently published 1,000,001 of them in pastebin post.
In the same post they explain how they were able to obtain them:
During the second week of March 2012, a Dell Vostro notebook, used by Supervisor Special Agent Christopher K. Stangl from FBI Regional Cyber Action Team and New York FBI Office Evidence Response Team was breached using the AtomicReferenceArray vulnerability on Java, during the shell session some files were downloaded from his Desktop folder one of them with the name of “NCFTA_iOS_devices_intel.csv” turned to be a list of 12,367,232 Apple iOS devices including Unique Device Identifiers (UDID), user names, name of device, type of device, Apple Push Notification Service tokens, zipcodes, cellphone numbers, addresses, etc. the personal details fields referring to people appears many times empty leaving the whole list incompleted on many parts. no other file on the same folder makes mention about this list or its purpose.
Did you notice the misplaced detail? Actually I could not help but notice that the UDIDs were obtained exploiting a Java vulnerability, the AtomicReferenceArray vulnerability (CVE-2012-0507). A detail is not so important in other circumstances, if it had not disclosed only few days after the controversies following the discovery of a potentially devastating 0-day for Java, and the subsequent issues deriving from the release of a vulnerable patch.
There could be no worse moment for this event to happen, and I am afraid it will contribute to add fuel to the raising concerns regarding Java security… Hard days for Java… And for the FBI
Few days ago Juniper Networks has released a report on the status of Android Malware. The results are not encouraging for the Android Addicted since they show a 472% increase in malware samples since July 2011 (see the infographic for details).
This does not surprising: already in May in its annual Malicious Mobile Threats Report, report, Juniper had found a 400% increase in Android malware from 2009 to the summer of 2010. This trend is destined to further grow since the Juniper Global Threat Center found that October and November registered the fastest growth in Android malware discovery in the history of the platform. The number of malware samples identified in September increased by 28%. whilst October showed a 110% increase in malware sample collection over the previous month and a noticeable 171% increase from July 2011.
As far as the nature of malware is concerned, Juniper data show that the malware is getting more and more sophisticated, with the majority of malicious applications targeting communications, location, or other personal information. Of the known Android malware samples, 55%, acts as spyware, 44%, are SMS Trojans, which send SMS messages to premium rate numbers without the user’s consent.
The reason for this malware proliferation? A weak policy control on the Android market which makes easier for malicious developers to publish malware applications in disguise. From this point of view, at least according to Juniper, the model of Cupertino is much more efficient and secure.
Easily predictable Google’s answer came from the mouth of Chris DiBona, open source and public sector engineering manager at Google. According to DiBona, Open Source, which is widely present in all the major mobile phone operating systems, is software, and software can be insecure. But Open Source becomes stronger if it pays attention to security, otherwise it is destined to disappear. In support of this statement he quotes the cases of Sendmail and Apache, whose modules which were not considered enough secure disappeared or came back stronger (and more secure) than ever.
But DiBona’s does not stop here (probably he had read this AV-test report which demonstrates that free Android Antimalware applications are useless): “Yes, virus companies are playing on your fears to try to sell you bs protection software for Android, RIM and IOS. They are charlatans and scammers. IF you work for a company selling virus protection for android, rim or IOS you should be ashamed of yourself.”
From this point of view Google hopes that Ice Cream Sandwich will lead Android Security at the next level even if some features are raising security concerns among Infosec professionals.
It looks like the Judgment Day for iOS has finally arrived. Until today the robustness of the AppStore has always been considered one of the strengths of the Apple Model: unlike the Android Market, which is constantly under attack for its weak security model that allowed too many malicious users to upload malicious applications, a strict control policy had prevented, at least so far, the same destiny for the mobile Apple Application.
Unfortunately Charlie Miller, an old acquaintance of the Apple Supporters, thought that winning three Pwn2Owns in the last four years (2008, 2009 and 2011) exploiting practically every Apple Vulnerability was not enough. So he decided consequently to attack Cupertino directly inside its AppStore security model.
The story begins early last year, after the release of iOS 4.3 when the researcher became suspicious of a possible flaw in the code signing of Apple’s mobile devices.
As stated in the original article by Forbes:
The next step was to discover a bug that allowed to expand that code-running exception to any application, and that is exactly what he did, but still this was not enough.
After discovering the bug, he submitted an App to the App Store exploiting the vulnerability. The App was approved and behaved as expected (actually a behaviour to which the victims of Android malware are quite familiar): the app was able to phone home to a remote computer downloading new unapproved commands onto the device and executing them at will, including stealing the user’s photos, reading contacts, making the phone vibrate or play sounds, or otherwise repurposing normal iOS app functions for malicious ends.
This method will be presented at the SysCan Conference in Taiwan next week even if a video demonstrations of the exploit is already available.
Last but not least: as a reward for discovering the bug, Apple has decided to revoke to Miller the Developer’s License.
Probably Android users will be the happiest to learn that, as stated by Miller:
Android has been like the Wild West. And this bug basically reduces the security of iOS to that of Android.
At least for one thing (security), iOS and Android are identical.
The news of the day is undoubtedly the discovery that Apple devices are a bit ‘too nosy’ and regularly record the position of the device into a hidden (!!) unencrypted and unprotected file.
The unwelcome and serendipitous discovery, which was announced today at Where 2.0, has been performed by two researchers, Alasdair Allan and Pete Warden, while they were working on a project concerning visualization of Mobile Data. It looks like this unrequested feature has been introduced since the arrival of iOS 4.0 and allows the locations and their relative time stamps to be written on an easily accessible file on the device and, even worse, backed up on every PC the device has been synchronized with.
Even if the purpose of the file is unknown (at least so far), and would be appropriate to wait a reply from Apple (if any) before coming to any conclusion, this event, once again, brings to the fore privacy issues for mobile devices, strictly related to the security model for these devices, and, more in general, to the cultural approach and revolution users must face (and get used to) when dealing with mobile technologies.
For sure the main issue here is the lack of respect by Cupertino towards the users (customers?). We know that this is not the first time that a mobile applications attracts criticism for the use of private data (think for instance to the affair of Google Latitude). In the case of Apple Equipment (differently from the creature of Google) the user may not explicitly approve the sharing (would be better to say the tracking since there is no evidence of sharing so far) of his data. But even if we do not consider the ethic point of view, from a security perspective the event has a devastating impact: if the file containing the data may be easily accessed, this means that, in case of theft, could be quite easy, for a malicious user, to grab the data and reconstruct the habits of the users. If we think, for instance, to industrial espionage, this occurence has a dramatic consequence enhanced by the evidence that this kind of devices are often used by CxOs. (Who are the most targeted by the risks of consumerization of IT, of which this is yet another example).
Moreover, in most circumstances I discussed the risks of geolocation (and its correlation with users’ habits) and the importance that this data could have if massively stolen (for instance by mean of a Mobile Botnet) by Cybercrooks and conveyed to a C&C Server. In a similar scenario bad guys capable of stealing such a similar amount of data would have no difficulty at all to organize an auction “to the death” between hungry marketing agencies, which would pay gold to put their hand on them. I must admit that the thought that these “bad boys” could be just the manufacturers of my iPhone (luckily I own an Android) does not make me feel very comfortable. This situation is also paradoxical: many security vendors offer privacy advisors for (other) mobile platforms, but the evidence that one user should defend his privacy from the manufacturer itself sounds absurd and frustrating. Of course I continue to repeat that it is better to wait for an Apple official reply, but, honestly speaking the fact that these data are only available for devices provided with a cellular plan, sounds very strange.
Meanwhile, if you want to know more and enjoy (I hope so) to verify where have you been since you bought your brand new iToy, you may have a really interesting look at this link where the authors of the discovery posted an app to unleash the file and graphically map the positions.
Last but not least, there is no evidece (so far), of a similar “Feature” on the Droids.
On the other hand, these are tough times for the privacy of smartphones owners. As a matter of fact, quite curiously, today another, apparently unrelated, piece of news coming from the opposite site of the Ocean caught my attention. It concerns Michigan State Police, which has been using data extraction tools to collect information from the cell phones of motorists detained for minor traffic infractions. This has been possible by mean of Cellebrite, a mobile Forensics Tool capable to perform:
“Complete extraction of existing, hidden, and deleted phone data, including call history, text messages, contacts, images, and geotags. The Physical Analyzer allows visualization of both existing and deleted locations on Google Earth. In addition, location information from GPS devices and image geotags can be mapped on Google Maps,”
Even if the latter issue raises the question concerning to what extent the law can go when facing privacy of the citizens, the two news have in common the (mis)use of mobile data and I could not help but thinking that mobile data are continuously under attack and users should consequently consider carefully the usage of their devices (this is the reason why I used the term of cultural revolution).
Who knows, maybe Michigan State Police hoped to make further fines for speeding after detaining the motorists by tracking GPS position and timestamps. Probably if they had known the existence of the above mentioned feature of iOS, they would have avoided to buy the software and grab directly the data… At least for iOS 4 users…