Shooter's Apple ID Passcode Changed While in Government Possession, Apple Says

Discussion in 'Technical' started by stg58, Feb 19, 2016.


  1. stg58

    stg58 Monkey+++ Site Supporter+ Founding Member

    All kinds of questions on this.
    Did the idiot technology employee really do this?
    If so why?
    Was the IT employee part of the plot?
    Does the IT employee pray five times a day?
    Is Apple full of crap?



    "The auto reset was executed by a county information technology employee, according to a federal official. Federal investigators only found out about the reset after it had occurred and that the county employee acted on his own, not on the orders of federal authorities, the source said."

    ..........................................
    San Bernardino Shooter's Apple ID Passcode Changed While in Government Possession, Apple Says

    The Apple ID passcode for the San Bernardino shooter's iPhone was changed less than 24 hours after authorities took possession of the device, a senior Apple executive said today.

    And Apple could have recovered information from the phone had the Apple ID passcode not been changed, Apple said.

    If the phone was taken to a location where it recognized the Wi-Fi network, such as the San Bernardino shooters' home, it could have been backed up to the cloud, Apple suggested.

    The Justice Department acknowledged in its court filing that the passcode of Syed Farook's iCloud account had been reset. The filing states, "the owner [San Bernardino County Department of Public Health], in an attempt to gain access to some information in the hours after the attack, was able to reset the password remotely, but that had the effect of eliminating the possibility of an auto-backup."

    The auto reset was executed by a county information technology employee, according to a federal official. Federal investigators only found out about the reset after it had occurred and that the county employee acted on his own, not on the orders of federal authorities, the source said.

    Apple executives say the phone was in the possession of the government when that passcode was reset. A federal official familiar with the investigation confirmed that federal investigators were indeed in possession of the phone when the reset occurred.

    Missing the opportunity for a backup was crucial because some of the information stored on the phone would have been backed up to the iCloud and could have potentially been retrieved. According to court records, the iPhone had not been backed up since Oct. 19, 2015, one-and-a-half months before the attack and that this “indicates to the FBI that Farook may have disabled the automatic iCloud backup function to hide evidence.”
     
    Ganado, Garand69 and Motomom34 like this.
  2. BTPost

    BTPost Old Fart Snow Monkey Moderator

    You see here, simply, that the FEDs were not giving Apple, the whole Story, and NOW, they are trying to fix, the mess, they made of the Chain of Evidence, and blame it ALL on Apple, when the truth is, that they messed up, And screwed themselves out of any evidence that they might have recovered, it they had just not "Gone, off Half-Cocked". What they should have done, is put the iPhone in an RF Proof Evidence Container, so that NOTHING could change ANYTHING on the iPhone, until it was in a Proper RF FREE Location, and a plan in place to extract, what information, that could be obtained... The FEDs plainly messed it up, and NOW are whining about it, after the FACT...
     
    Ganado, Garand69, kellory and 3 others like this.
  3. HK_User

    HK_User A Productive Monkey is a Happy Monkey Site Supporter

    That was why I mentioned that the phone was the property of the employer [San Bernardino County Department of Public Health], thus under their control and they could have provided the source to the Feds but somebody else beat them to it. Court cases have already been made that an employee does not have any expectations of privacy when they use company property for personal use.

    The whole world missed that point and was trying to make a case for personal privacy case when none existed.

    Smoke and Mirrors and misinformed people.
     
    Last edited: Feb 20, 2016
    Tikka likes this.
  4. VisuTrac

    VisuTrac Ваша мать носит военные ботинки Site Supporter+++

    a previous employer wipes performs brick and reset to factory on all phones once an employee no longer is employed by the company.
    lock down computer, disable network credentials, brick and reset mobile, disable access card, turn in keys and access card and then you get your final check.
    the first 4 happen in about 10 - 20 minutes.
    standard procedure.
    Somebody may have just been following the rules.
     
    Ganado likes this.
  5. I've been working in the computer security industry for many years, and what little I've learned along the way is mostly that perfect security is like Communism: it only works in theory.

    As Mark Cooper pointed out, the Public-Key Infrastructure (PKI) which underlays Apple's iPhone security is "90% process, 10% technology" - and those who try to find an explanation (for this impasse between Apple and the FBI) inside the technology soon discover that the process includes, as it must, provisions for recovering from human errors, forgetfulness, lack of training, laziness, avarice, and run-of-the-mill stupidity.

    I doubt that the county employee who reset that password had any hidden motive or secret agenda: at worst, (s)he was probably ordered to reset the password by a manager who was having a knee-jerk reaction to the news of the shootings. You can never tell from the press reports: they're never what really happened, and they are always dumbed-down to a sixth-grade level whenever they have anything to do with computers.

    This whole situation, though, is a good illustration of how the 90 percent of process can rear up and bite the FBI in the behind: like most government agencies, the feds are deathly afraid of bad publicity, and having to admit that they can't just put a common item like an iPhone in an evidence bag and send it off to the world-renowned FBI laboratory for [insert magic explanation here, with time out for commercials and a PSA by Efrem Zimbalist, Jr.].

    The simple fact is that corporate resources have to be recoverable after unexpected events: that's what insurance and Iron Mountain are for. Any "security" must serve the stockholders' interests, not the employees' wishes: any system designed to protect corporate data will, of necessity, need to be able to sacrifice the user's phone book, memo pads, or emails in order to assure that corporate assets remain safe.

    In other words, Apple's system did what it was designed to do. The feds don't want to admit that: what the FBI is demanding is that Apple provide them with a magic box which can be put on a shelf at the Effa-Bee-Eye lab, to keep we taxpayers from thinking that we might be able to hide anything from the great father-figure in Washington.

    William Warren
     
    ghrit likes this.
  6. BTPost

    BTPost Old Fart Snow Monkey Moderator

    No, Apple Has Not Unlocked 70 iPhones For Law Enforcement
    Posted yesterday by Matthew Panzarino(@panzer)

    The more highly technical the basis of a story, the more likely it is that some key detail will get jacked up by a journalist trying to translate it for the public. Call it Panzer’s Law.

    It’s only natural, especially when it comes to stories about security and privacy, such as Apple vs. the FBI. There are a myriad of complex technical mechanics at play, fiercely difficult Gordian Knots of encryption and hardware solutions to unravel and a number of previous interactions between Apple and the government that have set one precedent or another.

    But no matter how hard it is, it’s important to get this stuff right. The press has the ability not only to act as a translator but also as an obfuscator. If they get it and they’re able to deliver that information clearly and with proper perspective, the conversation is elevated, the public is informed and sometimes it even alters the course of policy-making for the better.

    When it comes to the court order from the FBI to Apple, compelling it to help it crack a passcode, there is one important distinction that I’ve been seeing conflated.

    Specifically, I keep seeing reports that Apple has unlocked “70 iPhones” for the government. And those reports argue that Apple is now refusing to do for the FBI what it has done many times before. This meme is completely inaccurate at best, and dangerous at worst.

    There are two cases involving data requests by the government which are happening at the moment. There is a case in New York — in which Apple is trying really hard not to hand over customer information even though it has the tools to do so — and there is the case in California, where it is fighting an order from the FBI to intentionally weaken the security of a device to allow its passcode to be cracked by brute force. These are separate cases with separate things at stake.

    The New York case involves an iPhone running iOS 7. On devices running iOS 7 and previous, Apple actually has the capability to extract data, including (at various stages in its encryption march) contacts, photos, calls and iMessages without unlocking the phones. That last bit is key, because in the previous cases where Apple has complied with legitimate government requests for information, this is the method it has used.

    It has not unlocked these iPhones — it has extracted data that was accessible while they were still locked. The process for doing this is laid out in its white paper for law enforcement. Here’s the language:

    It’s worth noting that the government has some tools to unlock phones without Apple’s help, but those are hit and miss, and have nothing to do with Apple. It’s worth noting that in its statements to the court in the New York case, the government never says Apple unlocks devices, but rather that it bypasses the lock to extract the information.

    The California case, in contrast, involves a device running iOS 9. The data that was previously accessible while a phone was locked ceased to be so as of the release of iOS 8, when Apple started securing it with encryption tied to the passcode, rather than the hardware ID of the device. FaceTime, for instance, has been encrypted since 2010, and iMessages since 2011.

    So Apple is unable to extract any data including iMessages from the device because all of that data is encrypted. This is the only reason that the FBI now wants Apple to weaken its security so that it can brute-force the passcode. Because the data cannot be read unless the passcode is entered properly.

    If, however, you assume that these stories are correct and that Apple has complied with requests to unlock iPhone passcodes before and is just refusing to do so now, it could appear that a precedent has already been set. That is not the case at all, and in fact that is why Apple is fighting the order so hard — to avoid such a precedent from being set.

    The New York case has another wrinkle, which is a separate issue. Apple can theoretically comply with the data extraction request there, but is refusing to do so on two bases: extracting data from devices diverts manpower and resources, and that the government is trying to use a wide application of the All Writs Act of 1789.

    At the behest of Judge Orenstein, the federal magistrate in the NY case, Apple filed a response in which it questioned the new application of the AWA. Apple also argues that since its reputation is based on security and privacy, complying with the court’s demands based on an expanded application of a 200-year-old law could put it at risk of tarnishing that reputation. Apple is still waiting for a final order on whether to comply from the judge there. The All Writs Act is also being used in the case in California.

    Still, even if Apple were to comply in New York, it would not be unlocking the device, merely extracting data off of it with standard methodology for pre-iOS 8 devices. If the FBI succeeds in ordering Apple to comply in California, it would have to build a new software version of iOS that allowed electronic brute-force password cracking. This is an important distinction to make when talking about such an important precedent-setting case.

    Article updated to clarify what data Apple can extract.
     
    kellory, ghrit and DarkLight like this.
  7. melbo

    melbo Hunter Gatherer Administrator Founding Member

    I just did a test to see if I can 'reset' my Apple ID with my device locked. Since I use 2FA on my AppleID, it requires a recovery key or physical unlocked access to one of my devices. You can't reset me out of my account...

    upload_2016-2-20_14-52-23.

    The only way in is with access to one of these 3 things:

    upload_2016-2-20_14-53-47.
     
    kellory, BTPost and HK_User like this.
  8. DarkLight

    DarkLight I self identify as a Blackhawk Attack Helicopter! Site Supporter

    Don't know how this would work in a Microsoft Exchange environment where you have an OWA (Outlook Web Access) policy. It may only allow you to wipe the device, but not sure. Then again, the OWA policy for mobile devices may actually disable two-step verification in order to get around that. Haven't had an iPhone on an Exchange system in a couple of years so I can't even check.
     
  9. melbo

    melbo Hunter Gatherer Administrator Founding Member

    I'm pretty sure OWA grants wipe permissions to any device that connects to it. I haven't checked that.
     
  10. DarkLight

    DarkLight I self identify as a Blackhawk Attack Helicopter! Site Supporter

    Right, remote wipe is always a thing, but remote password reset may not be absolutely required.

    We don't know or it hasn't been said, but I'm wondering if that's where the ef-up happened.
     
  11. melbo

    melbo Hunter Gatherer Administrator Founding Member

    Oh, Understood.
    OWA can wipe a device but not change its password (the device password).
     
  12. melbo

    melbo Hunter Gatherer Administrator Founding Member

    Just checked although we're not really on OWA anymore (Office365) and the options are to wipe or remove. IT has no way to change my device password.
    upload_2016-2-20_16-0-43.
     
  13. Ganado

    Ganado Monkey+++

    NOTE: Microsoft outlook access is the culprit not the phone. So again, its a software problem if you are employed by a company that uses OWA. Always make your company give you a phone they pay for when using OWA. =)
     
    DarkLight likes this.
  14. melbo

    melbo Hunter Gatherer Administrator Founding Member

    Agreed but all that IT can do through OWA is wipe your device if you leave without turning it in. They can't change your device password or 2FA. I'm going to try a wipe through Office365 later and see what happens. My bet is that >iOS 9 won't let it happen but I'd like to know. A wipe doesn't really hurt me since I can restore in ~15 minutes to the former state. I've tested this a few times before I put my trust in iCloud backups for recovery.
     
    kellory and Ganado like this.
  15. Ganado

    Ganado Monkey+++

    @melbo I can see that would work if you stored in the cloud outside of the work environment. I never did do that when I worked for xyz agency. I didn't want the liability.
     
  16. kellory

    kellory An unemployed Jester, is nobody's fool. Banned

    Bluetooth devices. I don't know if it's true with iPhone, but with Android I know it is true. Android products present an option of allowing a Bluetooth device to be a trusted key your phone.
    Do not accept this option. It is a lazy man's key, and one that can be turned by anyone with your Bluetooth. ( something that can be taken from you just as easily as your phone)
     
  17. Tikka

    Tikka Monkey+++

    I used tethering and now mobile hot spot to let my tablet access the internet using my phone.

    I don't know if an iPhone supports either.

    Personally, any messaging I'd use would be innocent.
    "In preparation for Operation Overlord, the BBC had signaled to the French Resistance that the opening lines of the 1866 Verlaine poem "Chanson d'Automne" were to indicate the start of D-Day operations. The first three lines of the poem, "Les sanglots longs / des violons / de l'automne" ("Long sobs of autumn violins"), meant that Operation Overlord was to start within two weeks. These lines were broadcast on 1 June 1944. The next set of lines, "Blessent mon coeur / d'une langueur / monotone" ("wound my heart with a monotonous languor"), meant that it would start within 48 hours and that the resistance should begin sabotage operations especially on the French railroad system; these lines were broadcast on 5 June at 23:15."

    Interesting something as important as the Normandy invasion used something so open and simple...
     
    kellory likes this.
  18. BTPost

    BTPost Old Fart Snow Monkey Moderator

    The iPhone does NOT allow a BlueTooth device to be a Trusted Key.... iPhones can be set up, and used, as a Mobile Hot Spot for other WiFi, and BlueTooth, devices....
     
    kellory likes this.
  19. Tikka

    Tikka Monkey+++

    Android has Smart Lock which allows a previously pared device to bypass the lock screen. Early implementation of Smart lock had a spoofing weakness which has been fixed. However, I don't use the phone or tablet for anything of importance.

    With some luck and Ubertooth1; there are ways to beat the system.
    Project Ubertooth - Ubertooth One

    People with key less entry and remote start for their vehicles have more to worry about as it can't be fixed...

    This is only one way:
    Hacker's $30 Device Unlocks Just About Any Keyless Entry Car

    Hackers reveal flaw in car remotes kept secret for TWO YEARS

    Old info; however, most of the effected vehicles are still in parking lots.
     
  1. Legion489
  2. DarkLight
  3. DarkLight
  4. Motomom34
  5. svjoe
  6. DarkLight
  7. Gopherman
  8. Yard Dart
  9. Yard Dart
  10. Yard Dart
  11. Yard Dart
  12. sec_monkey
  13. Motomom34
  14. sec_monkey
  15. sec_monkey
  16. melbo
  17. Garand69
  18. Garand69
  19. sec_monkey
  20. melbo
survivalmonkey SSL seal        survivalmonkey.com warrant canary
17282WuJHksJ9798f34razfKbPATqTq9E7