[HN Gopher] Instructions Show How Cops Use GrayKey to Brute Forc...
___________________________________________________________________
Instructions Show How Cops Use GrayKey to Brute Force iPhones
Author : elorant
Score : 139 points
Date : 2021-06-23 12:36 UTC (10 hours ago)
(HTM) web link (www.vice.com)
(TXT) w3m dump (www.vice.com)
| gnu8 wrote:
| > The instructions open with asking readers to make sure they do
| have legal authorization to search the device; this can be in the
| form of a search warrant.
|
| This is a joke. As a rule, law enforcement does not respect
| fourth amendment rights and see the constitution only as red tape
| to be ignored or circumvented whenever convenient.
| 2OEH8eoCRo0 wrote:
| Do you have a source for that claim?
| 4ec0755f5522 wrote:
| This is, unfortunately, in the 'water is wet' category of
| observable reality.
| 2OEH8eoCRo0 wrote:
| No. I personally know law enforcement officers who go above
| and beyond, often getting warrants they think they don't
| need to err on the side of caution.
|
| So. Do you have a source for that?
| jborichevskiy wrote:
| https://en.wikipedia.org/wiki/Parallel_construction
| 2OEH8eoCRo0 wrote:
| Meaningless without some point of reference. I'm not
| arguing that law enforcement is always ethical but the
| parent comment claimed that law enforcement ignores
| warrants, "as a rule".
| cbsks wrote:
| "GrayKey also allows agencies to install the agent which
| surreptitiously records the user's passcode if authorities hand
| their phone back to them"
|
| Yikes. This is something that probably would trip up a lot of
| people. After arresting you and taking your phone, they say you
| can make a phone call and pass your phone back to you. You unlock
| and it's game over.
| gjsman-1000 wrote:
| Good to know though - if you are ever arrested, reboot your
| iPhone before entering the PIN. At least for the last 5 years
| since (I believe) the A9, no malware or jailbreak has managed
| to be persistent on an iPhone beyond a reboot that we know of.
|
| This is likely because all of the exploits jailbreaks or
| malware use are flaws in already running processes, but when
| the phone is rebooted, hardware root of trust verifies
| everything that loads is signed by Apple, clearing out the
| virus/jailbreak unless it was manually invoked (or plugged into
| the GrayKey) again to re-exploit those processes.
|
| Of course, in the unlikely event that you happened to have an
| iPhone without the new Secure Storage component mentioned on
| this thread, be arrested, and the cops were trying to "Hide UI"
| on you, it would be really awkward for them if you rebooted
| your phone first ruining the trap. "Wait, no, you're supposed
| to enter your PIN right now!"
| gruez wrote:
| >Good to know though - if you are ever arrested, reboot your
| iPhone before entering the PIN.
|
| how do you trust that the phone was actually rebooted? ie.
| the ui fakes a reboot screen.
| alias_neo wrote:
| Do iPhones have the hard-reset like Android where you hold
| power for a while, ignoring the on-screen prompts until
| it's forcefully reset?
|
| That might be an option. If it's not, I guess it's much
| easier on iOS to fake a reboot as the boot process
| (visually) is known, on Android it could be anything
| because it's manufacturer customisable.
|
| EDIT: Fixed some grammar.
| JoshTriplett wrote:
| You can't even trust that it's _your phone_ ; it wouldn't
| be that hard in many cases to provide an identical-looking
| device that just records the entered PIN. It won't hold up
| to inspection once unlocked, but it doesn't have to; once
| you've provided the PIN, you've lost.
|
| If the device has left your possession, don't accept it
| back or interact with it. Get a new device, and restore it
| from backup.
|
| Also, if you fill out the emergency contacts in your phone,
| you can call those contacts without unlocking your phone.
| kelnos wrote:
| There's an easy defense against this: when you're handed
| the phone, intentionally enter a passcode that isn't
| yours. If it unlocks, then you'll immediately know it
| isn't your phone, and won't have given away your
| passcode.
|
| If it doesn't unlock, it's probably your phone.
| neuralRiot wrote:
| Use siri to dial without unlocking.
| throwaway345kkz wrote:
| Fortunately, the crack in my screen is quite uniquely
| identifiable :)
| viktorcode wrote:
| To fake reboot UI it would need to root the OS. A
| tremendous and very unlikely achievement.
| gjsman-1000 wrote:
| Incorrect. When the person press and holds the power
| button, just show a fake graphic onscreen for "swipe to
| turn off". When person does that, show a black screen for
| 3 seconds, show the Apple logo for 8 seconds, do an
| animation, and the phone hasn't rebooted while the
| person's been tricked.
| gjsman-1000 wrote:
| There is always that risk. However, if you are this
| paranoid, you need to remember that you can do a Force
| Restart. This is handled by hardware, not by software, so
| if you know what to look for it cannot be faked.
|
| https://support.apple.com/guide/iphone/force-restart-
| iphone-...
| TwoBit wrote:
| Doesn't that require the device to have been unlocked in the
| first place?
| codezero wrote:
| Searching for some of the phrases in that list, you can find some
| interesting PasteBin texts from 2018...
|
| https://pastebin.com/ytdUCrwV https://pastebin.com/uTdSyUj4
| Tangokat wrote:
| 183 days to try 63 million passwords. Roughly 4 per second by my
| math.. that seems pretty low to me. Any decent password would be
| uncrackable in that case - but of course if people mostly use
| numerical 4 digit passwords that's plenty fast.
| tempay wrote:
| I believe the secure enclave, which is responsible for mapping
| the passcode to an encryption key, has hardware level rate
| limiting so I suspect GrayKey is limited by that.
| jackric wrote:
| Who was smart enough to implement rate limiting there, but
| not an exponential lockout period?
| Scoundreller wrote:
| Someone who never got DDoS'd by their own app after their
| server went down, that's who.
| dylan604 wrote:
| Haven't there been stories of parent's losing their phones
| because their kids randomly entering in passcodes forced
| the exponential time outs to be into the years (and longer)
| time frames?
| alias_neo wrote:
| I can see it happening. My 1.5 year old daughter
| routinely locks me out of my phone by touching the in-
| screen fingerprint reader when she takes my phone from
| the desk or wherever it's lying around at home.
|
| I have a password the maximum length allowed so it's not
| trivial to unlock when she does that.
| FearlessNebula wrote:
| Reset the phone and restore from backup
| russh wrote:
| Not possible, it is now a paper weight. Found this out
| when a disgruntled employee "forgot" the passcodes to
| several devices before quitting.
| dylan604 wrote:
| Seems like it would be safer to enable wipe device after
| 10 wrong entries than allowing the exponential time out
| to increase
| tinus_hn wrote:
| That happens when you can't access the Apple account that
| has the activation lock for the device. You don't need
| the device passcode to reinstall it.
| spideymans wrote:
| The lockout period progresses something like 60 seconds,
| 5 minutes, 30 minutes, 1 hour, 3 hours, 6 hours, 1 day
| and so on. This should only be possible if the child had
| sole possession of the phone for days. Not saying it's
| _impossible_ , but this appears to be an extreme edge
| case.
|
| I suspect most of these reports come from either bugs in
| the software (and some quick Googling suggests this has
| been the case), or perhaps that even someone (heck, even
| a savvy child) was trying using some sort of brute force
| exploit to unlock the phone.
| bildung wrote:
| The probable standard answer for every large organization:
| Those were the responsibilities of different teams.
| vxNsr wrote:
| They did, the exploit here is shutting down the phone
| before it has a chance to log there was a password attempt.
| TwoBit wrote:
| Doesn't that apply only to older phones?
| 2OEH8eoCRo0 wrote:
| Isn't this common? I think Intel TPMs use that as well. They
| have their own clocks. I wonder if you could tamper and
| inject your own faster clock signal though.
| hunter-gatherer wrote:
| That's correct. I haven't used graykey for a year or so, so I
| can't speaj to any updates that have happened in that time.
| This article wasn't very interesting, and all this
| information can be found by calling grayshift sales support
| staff.
|
| Ay my shop we didn't actually have a ton of success with
| graykey because most the devices were BFU. Once the agent is
| loaded, you can plug the phone into a regular charger and let
| it brute force itself into the next millenia. But after it
| tries te first few hundred passcodes, the rate drops
| significantly.
| gruez wrote:
| >Any decent password would be uncrackable in that case
|
| most people don't use "decent passwords" on their phones,
| because they have to enter it multiple times a day.
| Scoundreller wrote:
| I've had enough of trip crap.
|
| Has anyone rewired their lightning connector so it only works
| with your own cables and everything else fails?
| gruez wrote:
| That's an interesting idea, although I suspect for it to be
| effective you have to make it self-destruct the data if a wrong
| cable is inserted. Otherwise they'll plug the cable in, see
| it's not working, and send it off to a forensics lab to "fix"
| the phone at which point they'll discover your modification and
| revert it.
|
| Based on the teardown photos[1][2], it doesn't look like
| there's much space to work with here, so getting any sort of
| modification in there would be non-trivial.
|
| [1] https://guide-
| images.cdn.ifixit.com/igi/v16ARReBbanfWoOb.hug...
|
| [2] https://guide-
| images.cdn.ifixit.com/igi/VP4BE2cGikTdBXKi.hug...
| zionic wrote:
| You could always physically destroy the port and just use
| wireless charging
| gruez wrote:
| Destroying the port would also be a minor roadblock,
| because they can just solder on a new port (see prior
| comment about shipping off the phone to a forensics lab to
| fix it).
| Scoundreller wrote:
| Still prevents an evil maid attack malware upload.
|
| Security isn't about being 100%, it's about making your
| stuff as a target unworthwhile, or delaying things until
| long after you're dead (where apple's password cracking
| prevention obviously lacks)
|
| With enough epoxy when you reconstruct, resoldering isn't
| so straightforward.
| gruez wrote:
| Yes, but in the context of this thread (Cops Use GrayKey
| to Brute Force iPhones), the attacker isn't really
| constrained by time, nor are they opportunistic.
| Scoundreller wrote:
| I'm partly operating on the assumption here that a "cold"
| device is more immune:
|
| Maybe a brownout supervisory SOT23 (tiny) that resets the
| phone device the second a wrong cable is plugged in:
|
| https://www.onsemi.com/pdf/datasheet/max803-d.pdf
|
| There might even be one on there to begin with to prevent
| excessive lithium battery discharge.
| gjsman-1000 wrote:
| This is also interesting and something VICE missed, look at the
| first image which was from the FOIA Request!
|
| It's Firefox, and in the bookmarks bar, you have GrayKey login,
| GrayKey/GrayShift Support, and a certain page from Apple support
| explaining how to enter _recovery mode_...
|
| https://support.apple.com/en-us/HT201263
|
| To me, that suggests that these cops have it bookmarked because
| GrayShift is using some sort of Recovery Mode exploit, similar to
| Checkm8 did through Checkra1n for the A10 and below, and the cops
| have it bookmarked so they remember how to do it.
| airza wrote:
| Does being at low battery make attacks against the device easier?
| Seems like it does from the report here but i'm not sure why.
| alias_neo wrote:
| I too wondered why this is significant, couldn't you simply
| charge the device first? Wouldn't it be charging while
| connected to the GreyKey?
| lazide wrote:
| Speculation - maybe it turns off some rate limiting, or
| disables some sanity checking that is more CPU/energy intensive
| or similar?
| kadoban wrote:
| I read that as just being a list of what circumstances you can
| still use the attack that you might otherwise think you
| couldn't. For example having a broken screen it seems clear
| couldn't provide any benefit, but that's also in that same
| list.
| musicale wrote:
| Does Apple encrypt iCloud backups now?
| thetinguy wrote:
| No. https://support.apple.com/en-us/HT202303
| beermonster wrote:
| You can encrypt them locally using Finder. Then they can also
| make it onto your Time Machine backup too. Just need an offsite
| copy after that. Though looking at what iCloud backup includes
| it mainly seems to be settings and app data. App data is often
| centralised anyway or uses iCloud Drive
| gjsman-1000 wrote:
| Of notable curiosity not mentioned by VICE, but Apple actually
| modified their A12, A13, and A14 (I believe) CPUs _while still in
| production_ to have a new second-generation Secure Enclave
| embedded within them sometime around Fall 2020. We don 't know
| the full extent of the changes, but it sounds like the 2nd-
| generation enclave comes with much stronger hardware-based rate
| limiting on PIN code guessing through a "mailbox" system.
|
| For me, that means I have my eyes all on whether an iPhone 12,
| iPhone 12 Pro, or (new) iPhone SE 2nd Gen get hacked. Right now
| the highest confirmed GrayKey hack is an iPhone 11, which
| wouldn't have the change. We'll see whether Apple got them this
| time.
| gjsman-1000 wrote:
| Quote from Apple Platform Security > Hardware Security > Secure
| Enclave:
|
| "Devices first released in Fall 2020 or later are equipped with
| a 2nd-generation Secure Storage Component. The 2nd-generation
| Secure Storage Component adds counter lockboxes. Each counter
| lockbox stores a 128-bit salt, a 128-bit passcode verifier, an
| 8-bit counter, and an 8-bit maximum attempt value. Access to
| the counter lockboxes is through an encrypted and authenticated
| protocol.
|
| Counter lockboxes hold the entropy needed to unlock passcode-
| protected user data. To access the user data, the paired Secure
| Enclave must derive the correct passcode entropy value from the
| user's passcode and the Secure Enclave's UID. The user's
| passcode can't be learned using unlock attempts sent from a
| source other than the paired Secure Enclave. If the passcode
| attempt limit is exceeded (for example, 10 attempts on iPhone),
| the passcode-protected data is erased completely by the Secure
| Storage Component."
|
| https://support.apple.com/guide/security/secure-enclave-sec5...
| TwoBit wrote:
| I once had auto reset enabled on my phone after 10 attempts,
| and then somehow while it was in my gym bag it proceeded to
| accidentally get buttons pressed and reset itself. Better to
| set that number to 1000 instead of 10.
| pueblito wrote:
| Or someone tried to access your phone while you were away
| smoldesu wrote:
| My mom had the same thing happen, suffice to say that she
| doesn't trust her iPod anymore.
| gjsman-1000 wrote:
| Nowadays the time between guesses increases exponentially.
| So by the time you are close to a reset, you need to wait a
| few hours or days before the next and final guess.
| gruez wrote:
| How's that even possible? AFAIK after the first few
| attempts there's an exponentially increasing lockout time
| between passcode attempts, so the random button pressings
| would have to persist for a long time for it to reach 10
| attempts.
| draw_down wrote:
| Murphy's law, basic stuff here.
| tinus_hn wrote:
| It wasn't always like that, it used to be just 10
| attempts you could do in a minute.
| ThePowerOfFuet wrote:
| The exponential backoff existed in iOS 5, IIRC.
| motohagiography wrote:
| Surprised this wasn't implemented as whole filesystem
| encryption and then just overwriting the secret key in the SE
| instead of dealing with the time/battery cost of an
| incomplete wiping of "passcode-protected data."
|
| When you design protocols like this, the big question is
| whether there is a bias in the salt and verifier keys that
| get installed in the SE at the time of manufacture. It's a
| good design as described in principle, assuming there is
| sufficient entropy in those 128-bit values, as we tend to
| assume the field size is what provides the security, but
| really, it's that there are this many sufficiently random
| bytes from that field that provides the assurance. If you
| have seen how crypto gets backdoored in practice, key length
| doesn't matter if the RNG is hobbled in a deniable way.
|
| Personally and armchairing it, if I were solving this problem
| I would work more on brute forcing collisions in sensor/image
| sampling human fingerprints than bothering with crypto and
| side channels. But in terms of the real threat model, it
| makes more sense to approach it from the perspective of what
| the whole product truly is and what it provides.
|
| From a product perspective, designing iPhone security is such
| an interesting problem because the whole brand image is
| predicated on being the best available, so you can't do an
| "oops, sorry" like an inferior product. You can only do what
| you know you can do better than anyone else. The real threat
| model is the brand damage from a company like Cellebrite or
| NSO getting caught or leaked about.
|
| Oddly, the north star for a product like that is probably the
| U.S. 4th and 5th Amendments, as from a security feature
| perspective, you can always evaluate whether a design is
| aligned to those as the sufficient and necessary criteria.
| ThePowerOfFuet wrote:
| >Surprised this wasn't implemented as whole filesystem
| encryption and then just overwriting the secret key in the
| SE instead of dealing with the time/battery cost of an
| incomplete wiping of "passcode-protected data."
|
| It is; it zeroizes the KEK. Nothing is slowly wiped from
| end to end.
| athrun wrote:
| It's interesting how the instructions say that an agent can be
| installed on the phone even _before_ attempting to brute force
| the password.
|
| How can an application be installed if the phone is locked?
| kadoban wrote:
| My understanding was that this requires some kind of exploit,
| but this exploit does not actually give you the passcode. I'm
| guessing from context that it also doesn't allow you to unlock
| even if the phone is on? That seems somewhat surprising to me.
| gumby wrote:
| Presumably via an exploit they have found in the USB subsystem
| connected to the lightning port.
| yohannparis wrote:
| So... now I should just brake my phone in half before giving it
| to the Police. Lovely!
| junon wrote:
| Most likely will land you an obstruction of justice or evidence
| tampering charge - or both. I don't rec this.
| EMM_386 wrote:
| Easiest way to do this is probably what is mentioned at the end
| of the article:
|
| > As part of a feature called HideUI, GrayKey also allows
| agencies to install the agent which surreptitiously records the
| user's passcode if authorities hand their phone back to them, NBC
| News reported.
| csunbird wrote:
| A keylogger, as it seems. So, if you give your phone unlocked
| to authorities, e.g. during a border check, they can log your
| passcode and you are now screwed.
| squarefoot wrote:
| I think it's time for phone manufacturers, at least the few
| unknown ones that care for users privacy, to implement
| plausible deniability in the form of two or more bootable
| systems where one is the main one and the others boot would
| be triggered by a special password, so that they would not
| contain certain phone numbers, messages, etc. and anything
| installed there wouldn't have access to other
| partitions/systems.
|
| The system should be clever enough to let some innocuous
| information slip from other systems. For example, let's say a
| border guard asks me for a password and I give the one that
| boots the system I'd use when travelling, with no other stuff
| than a few family photos and cat videos, if he checked the
| phone calls he would immediately spot that I didn't make a
| phone call (with that system) in one month or more, which
| would immediately raise alarms, so there should be a way to
| tell the other systems to slip in there some information like
| phone calls to relatives or the restaurant, chats with
| girlfriend, etc. just so that one could pretend that the
| system was used daily.
| zionic wrote:
| They have probably found an exploit to non-persistently
| install a 3rd party keyboard (what a mistake that feature
| was!) that writes all content to unprotected disk. All apps
| have this ability (to write to disk that is "always
| available")
|
| That's how I'd do it anyways.
| Scoundreller wrote:
| I advise turning your phone off at border crossings. But even
| that is getting cut down on.
|
| Maybe I can set this up with automation and geofencing.
| onethought wrote:
| iPhone you can just open the power off menu then cancel,
| and Face ID is reset. (Passcode required)
| alias_neo wrote:
| What does turning the phone off solve? Can you not be
| compelled to turn it on?
|
| I always assumed a border agent in the US would simply
| insist you turn it on for them, and you have no choice.
| dangerbird2 wrote:
| According to the EFF, in most cases, you can invoke your
| 5th amendment rights to prevent CBP from making you give
| up a password, particularly if you claim the content of
| the password (as opposed to the data the password is
| protecting) is personal and protected under the right to
| avoid self-incrimination. Of course, CPB has plenty of
| perfectly legal ways to get you to "voluntarily" comply:
| from making you miss your connecting flight, to putting
| you through enhanced security in the future, to denying
| entry if you're a non-resident.
|
| https://www.eff.org/deeplinks/2017/04/bill-rights-border-
| fif...
| Scoundreller wrote:
| Depends on the country.
|
| In some places it's a gray area as customs is allowed to
| search anything but that's it. You're not compelled to
| open/do anything for them.
|
| Yes, they could deny you entry if you're a visitor, or
| they could seize it from you and give it back to you in
| pieces in 6 months, but if your encryption is good
| enough...
|
| Also reduced (but not eliminated) risk of surreptitious
| malware installation.
| null0pointer wrote:
| On iPhone at least when you restart the phone it forces
| you to use the passcode to unlock the first time. I
| believe in the US passcodes are protected by the 5th
| amendment whereas face id or fingerprints are not. So
| while you can be compelled to unlock your phone with
| biometrics, you cannot be compelled with the passcode.
| Your milage may vary in other jurisdictions.
| alias_neo wrote:
| And what is the implication for refusing in both cases,
| passcode vs biometrics? Is one likely to land you in
| hotter-water than the other due to the 5th protection?
|
| I also presume as a foreigner none of these protections
| would apply anyway?
| Scoundreller wrote:
| I think the strategy would be to not use biometrics at
| all.
|
| As a foreigner, you still have rights. It is still US
| soil. You haven't done anything illegal by asking to
| enter with your stuff, but you'll probably be refused
| entry and maybe have your phone seized anyway meanwhile a
| US citizen would be allowed in, but might still be
| without their phone.
|
| I think you're in-the-clear long-term if you asked to
| "withdraw your entry request into the USA". At least
| that's the advice I've heard if they ask start asking
| about any drug use history, if you have any, so that
| you're not lying but also don't get yourself banned from
| entering later.
|
| https://www.ctvnews.ca/mobile/canada/pot-use-admission-
| at-u-...
| yjftsjthsd-h wrote:
| I wonder if that survives a reboot
| gjsman-1000 wrote:
| Nothing that we know of in the last five years since, I
| believe, the A9 has managed to have anything non-Apple be
| persistently loaded across a reboot whether it be malware or
| a jailbreak.
___________________________________________________________________
(page generated 2021-06-23 23:03 UTC)