On the 19th July 2013 I posted http://trewmte.blogspot.co.uk/2013/07/android-ddms-vulnerability.html about knowing exploits on and understanding originality and genuineness of a handset and (U)SIM Card.
Karsten Nohl on the 22nd July released details of an exploit for older type (no specifics as yet) SIM Cards using DES security. The exploit revealed a returned 'error code that contained the device's cryptographic signature, a 56-bit private key. It was then possible to decrypt the key using common cracking techniques.' http://www.theinquirer.net/inquirer/news/2283935/sim-card-encryption-exploit-leaves-mobile-phone-users-vulnerable-to-hacking
Importantly, the article goes on to identify possible exploits that may be caused when in possession of a decrypted key.
What isn't clear is whether the exploit leads to the creation of a cloned SIM Card that is operating live in the same network at the same time and whether the network detection techniques fail to pick that up? That means not just detect (VLR/HLR) but take decisive action such as call tear down, blocking and suspending IMSI subscriber etc.
Articles:
http://www.theinquirer.net/inquirer/news/2283935/sim-card-encryption-exploit-leaves-mobile-phone-users-vulnerable-to-hacking
http://nakedsecurity.sophos.com/2013/07/22/rooting-sim-cards-blackhat-speaker-says-he-may-be-able-to-own-your-phone-with-a-text-message/
http://thehackernews.com/2013/07/sim-card-cloning-hack-affect-750.html
For some background research materials specific to GSM SIM regarding Java servers and updating SIM OTA:
GSM 11.11
GSM 11.13 (Java Applets)
GSM 11.14 STK
Showing posts with label Java. Show all posts
Showing posts with label Java. Show all posts
Saturday, September 14, 2013
Tuesday, July 23, 2013
New SIM Card Exploit
On the 19th July I posted http://trewmte.blogspot.co.uk/2013/07/android-ddms-vulnerability.html about knowing exploits on and understanding originality and genuineness of a handset and (U)SIM Card.
Karsten Nohl on the 22nd July released details of an exploit for older type (no specifics as yet) SIM Cards using DES security. The exploit revealed a returned 'error code that contained the device's cryptographic signature, a 56-bit private key. It was then possible to decrypt the key using common cracking techniques.' http://www.theinquirer.net/inquirer/news/2283935/sim-card-encryption-exploit-leaves-mobile-phone-users-vulnerable-to-hacking
Importantly, the article goes on to identify possible exploits that may be caused when in possession of a decrypted key.
What isn't clear is whether the exploit leads to the creation of a cloned SIM Card that is operating live in the same network at the same time and whether the network detection techniques fail to pick that up? That means not just detect (VLR/HLR) but take decisive action such as call tear down, blocking and suspending IMSI subscriber etc.
Articles:
http://www.theinquirer.net/inquirer/news/2283935/sim-card-encryption-exploit-leaves-mobile-phone-users-vulnerable-to-hacking
http://nakedsecurity.sophos.com/2013/07/22/rooting-sim-cards-blackhat-speaker-says-he-may-be-able-to-own-your-phone-with-a-text-message/
http://thehackernews.com/2013/07/sim-card-cloning-hack-affect-750.html
For some background research materials specific to GSM SIM regarding Java servers and updating SIM OTA:
GSM 11.11
GSM 11.13 (Java Applets)
GSM 11.14 STK
Karsten Nohl on the 22nd July released details of an exploit for older type (no specifics as yet) SIM Cards using DES security. The exploit revealed a returned 'error code that contained the device's cryptographic signature, a 56-bit private key. It was then possible to decrypt the key using common cracking techniques.' http://www.theinquirer.net/inquirer/news/2283935/sim-card-encryption-exploit-leaves-mobile-phone-users-vulnerable-to-hacking
Importantly, the article goes on to identify possible exploits that may be caused when in possession of a decrypted key.
What isn't clear is whether the exploit leads to the creation of a cloned SIM Card that is operating live in the same network at the same time and whether the network detection techniques fail to pick that up? That means not just detect (VLR/HLR) but take decisive action such as call tear down, blocking and suspending IMSI subscriber etc.
Articles:
http://www.theinquirer.net/inquirer/news/2283935/sim-card-encryption-exploit-leaves-mobile-phone-users-vulnerable-to-hacking
http://nakedsecurity.sophos.com/2013/07/22/rooting-sim-cards-blackhat-speaker-says-he-may-be-able-to-own-your-phone-with-a-text-message/
http://thehackernews.com/2013/07/sim-card-cloning-hack-affect-750.html
For some background research materials specific to GSM SIM regarding Java servers and updating SIM OTA:
GSM 11.11
GSM 11.13 (Java Applets)
GSM 11.14 STK
Saturday, July 02, 2011
Windows Phone Apps reach new market levels
Windows Phone Apps reach new market levels
Back in 2006 Vodafone announced news to standardise handsets (here) and I commented then that it might be a good idea if users could profile their own handsets with the apps they actually use. There is much market evidence to suggest the evolving mobile is moving in that direction. Android, Apple, Blackberry, Java and Symbian apps stores are a good example of this. The growth in mobile apps has not been limited to the five previously mentioned, Window Phone apps, too, are storming ahead with over 25,235 apps available.
There is a brief synopsis of the Windows Phone apps growth at winrumors. The chart below is courtesy of windowsphoneapplist.
Knowing these stats can be helpful but unless there is some inter-related commentary about the technology (so to speak) that links those stats to forensics, it can all become pretty meaningless. My take on those stats is they do present challenges that the mobile forensic community will need to adapt, sooner rather than later. There is a wealth of information in apps that cannot be gleaned from using many of the evidence recovery automated handset readers. This has happened because evidence tools may not have been designed for that purpose; recovering app info and the content they store.
Firstly, it is important to understand the distinction between apps accessible through interface/emulator tools, designed for app builders and programmers (so to speak), and those tools said to be designed for collecting evidence.
Secondly, it doesn't automatically follow that just because an examiner obtains an evidential physical dump from flash memory ( a ) the examiner has dumped everything from the correct component ( b ) that the dump's content will be 'visible' and 'legible' (PACE 1984) and 'intelligible' (DPA1984).
Holding such a view doesn't mean, nor is it intented to suggest, that I think there is an impossibility here that cannot be overcome. Do I think the mobile forensic communty, working together, will find the solutions? Yes, absolutely, naturally.
Back in 2006 Vodafone announced news to standardise handsets (here) and I commented then that it might be a good idea if users could profile their own handsets with the apps they actually use. There is much market evidence to suggest the evolving mobile is moving in that direction. Android, Apple, Blackberry, Java and Symbian apps stores are a good example of this. The growth in mobile apps has not been limited to the five previously mentioned, Window Phone apps, too, are storming ahead with over 25,235 apps available.
There is a brief synopsis of the Windows Phone apps growth at winrumors. The chart below is courtesy of windowsphoneapplist.
Knowing these stats can be helpful but unless there is some inter-related commentary about the technology (so to speak) that links those stats to forensics, it can all become pretty meaningless. My take on those stats is they do present challenges that the mobile forensic community will need to adapt, sooner rather than later. There is a wealth of information in apps that cannot be gleaned from using many of the evidence recovery automated handset readers. This has happened because evidence tools may not have been designed for that purpose; recovering app info and the content they store.
Firstly, it is important to understand the distinction between apps accessible through interface/emulator tools, designed for app builders and programmers (so to speak), and those tools said to be designed for collecting evidence.
Secondly, it doesn't automatically follow that just because an examiner obtains an evidential physical dump from flash memory ( a ) the examiner has dumped everything from the correct component ( b ) that the dump's content will be 'visible' and 'legible' (PACE 1984) and 'intelligible' (DPA1984).
Holding such a view doesn't mean, nor is it intented to suggest, that I think there is an impossibility here that cannot be overcome. Do I think the mobile forensic communty, working together, will find the solutions? Yes, absolutely, naturally.
Subscribe to:
Posts (Atom)