iPhone flaw - no PI...
 
Notifications
Clear all

iPhone flaw - no PIN required(?)

14 Posts
5 Users
0 Reactions
719 Views
(@trewmte)
Noble Member
Joined: 19 years ago
Posts: 1877
Topic starter  

This is the gist of suggested iPhone flaw I recently read about generated from an upgrade to Ubuntu Lucid Lynx (10.04 LTS) it was noted with the iPhone 3GS (3.1.3 - 7E18) mounting behaviour

Power OFF iPhone 3GS and then connect it to the Lucid Lynx PC via USB. The phone turns on and will be automatically mounted without any authentication challenge (PIN), allowing read/write access to your various local data, e.g. purchases, DCIM, Downloads, Photos, Recordings etc.

——————
The iPhone uses proprietary protocols over USB for file operations, syncing and the like – only real authentication was that the session with lockdownd eventually goes SSL. There is also device pairing but it is really trivial to do and doesn't restrict the computer at all.

Lucid Lynx appears to include libimobiledevice, ifuse/gvfs-afc and all the necessary components.

Limitation – you're jailed to your Media directory unless jailbroken and connecting to afc2.


   
Quote
(@a_kuiper)
Trusted Member
Joined: 16 years ago
Posts: 69
 

Here's an article of the guy how found that flaw

http//marienfeldt.wordpress.com/2010/03/22/iphone-business-security-framework/


   
ReplyQuote
(@trewmte)
Noble Member
Joined: 19 years ago
Posts: 1877
Topic starter  

I did see the article but it has been posted in several other places too. I could not find it here at FF though, hence why I posted. I hope that perhaps it would open up a discussion.

Would be interesting to know, did your tests corroborate the findings a_kuiper?


   
ReplyQuote
(@jonathan)
Prominent Member
Joined: 20 years ago
Posts: 878
 

This may be pedantry, but is unexpected behaviour seen when connecting an object to a system that it was not designed to be connected to a 'flaw'?


   
ReplyQuote
keelan85
(@keelan85)
Active Member
Joined: 15 years ago
Posts: 11
 

Well after doing light reading about this and discussing with a colleague, I think that this can be replicated on a Windows operating system too, as its a flaw with the iPhone.

It only happens when the iPhone has been switched off from an unlocked state, the iPhone then powers back on into this state. A small opening in the security just allows enough time to pair with the device and then the iPhone is unable to lock itself down afterwards.


   
ReplyQuote
(@trewmte)
Noble Member
Joined: 19 years ago
Posts: 1877
Topic starter  

I suppose the way I read it Jonathan if the connection has been successful then clearly there was a "not design for" approach in place at first instance which, had there been, might have prevented the occurrence in the first place. But hindsight is a wonderful thing. I didn't think though that the use of the word "flaw" to describe, in this case, an unprotected security process creating a security loop hole was unrealistic, regardless of whether iPhone foresaw it or not. Just because something hasn't been addressed doesn't exclude it from being classed as a flaw. But whatever the semantics, the position is an 'unexpected' event occurs which provides access to user data. From a privacy angle it may cause discomfort, but from an examination angle I would have thought this to be a useful experience to know.

keelan85 did you read USB article http//www.beyondlogic.org/usbnutshell/usb3.htm noting USB-protocol does not contain any authorization / authentication-mechanism?

BTW the style of thinking and exploratory approach occurring in the responses to this topic is a good example of exactly that which would be expected for the exploratory content in the Diploma reports. Hopefully that will give you a clue as to how to approach your Diploma report, for instance when discussing QA and Evidence Handling or dealing with ME and UE, maybe?


   
ReplyQuote
(@polar)
Eminent Member
Joined: 15 years ago
Posts: 48
 

The H has a good article on the issue http//www.h-online.com/security/news/item/iPhone-leak-is-getting-bigger-Update-1012575.html

Martin has come to the conclusion that the problem only occurs if the iPhone was shut down from an unlocked state. During the wake up this state is restored and the device is "open" for a short period of time before the Springboard application wakes up and locks it down. This short period is sufficient for a pairing to occur that ensures permanent access.


   
ReplyQuote
(@trewmte)
Noble Member
Joined: 19 years ago
Posts: 1877
Topic starter  

OK Polar, so how would you bring that statement to address 'cause' and 'effect'?

Do you think unlocking is the 'cause' (and which form of unlocking is relevant?) and iPhone's reaction to it is an 'effect'?

or, would you

think the iPhone is the 'cause' irrespective that the device has been treated to unlocking producing this 'effect'?


   
ReplyQuote
(@polar)
Eminent Member
Joined: 15 years ago
Posts: 48
 

Just to clarify, unlocked state, means that the passcode has been successfully entered, thus allowing a (different) computer to access the device.

The fact that the Springboard application eventually re-locks the handset suggests that whether or not the lock was active before is irrelevant. When shut down is initiated, the lock ought to be reinstated automatically, thus preventing this issue. Unless of course shut down was unexpected, but this does not seem to be the case.


   
ReplyQuote
(@trewmte)
Noble Member
Joined: 19 years ago
Posts: 1877
Topic starter  

Interesting, so your conclusion is that it is the iPhone infact is the 'cause'?

Evidentially then, how would you demonstrate you are not in breach of privacy or directed surveillance requirements? Afterall, the opportunity it might present itself and be suggested the method/treatment infact is being used to avoid legal processes (e.g. no party consent, circumventing digital signatures prior to disclosure and so on) and avoid traceability in doing so?


   
ReplyQuote
Page 1 / 2
Share: