4 ms·

Ok, I got it clearer: somebody at Apple fucked up and left a weak SHA256 Hash and salt inside a db table that shouldn't be there. Probably used in testing for t

Ok, I got it clearer: somebody at Apple fucked up and left a weak SHA256 Hash and salt inside a db table that shouldn't be there. Probably used in testing for the betas, then nobody remembered to comment it away before the public release. Some engineer and somebody in QA will get their ass kicked pretty badly. Next iOS public release will solve it, everybody's gonna be happy. Nothing to see here folks, we can move on :)

0x0 10y ago
That sounds maybe plausible, although what could they have possibly been debugging that required a weaker hash? Of course, with the paranoid hat on, if your task was to subvert the mechanism, this is probably exactly how you'd go about it - make it seem like an accident. Just like gotofail :)
- camillomiller 10y ago
  Yeah, and hide it in plain sight. Plausible, yes. Although goto fail; had another vibe to it. It was really strangely placed and hardly explainable. Plus it made possible to perform some pretty nasty MiTM attacks over a network. Here you have a method that security experts tinkering with the betas knew of since probably last July. Everybody expected Apple to fix it in the GM, but it didn't happen. Now the cat's out of the bag with some deservedly good (and harmless) publicity for Elcomsoft and it's gonna be fixed in no time. If we even want to give credit to the malicious actor hypothesis, what's the benefit for them? Accessing iOS 10 beta backups more easily for three months? Nah, I don't see that, not this time.
  - jobu 10y ago
    > Although goto fail; had another vibe to it. It was really strangely placed and hardly explainable. Plus it made possible to perform some pretty nasty MiTM attacks over a network. The goto fail looked very much like a bad code merge. (I actually had a similar issue with a duplicated line when merging changes two days ago.) It's impossible to know without reviewing their full source control history, but it seemed like a plausible mistake to me.
    - camillomiller 10y ago
      Ok, good explanation. Let's slit that one with the Occam razor too, then :)
brazzledazzle 10y ago
I really wish the default response in dev and operations wasn't "somebody is going to get (yelled at|punished|fired|pile on layers of bureaucracy)". It would be so much better if the response was "how can we change automation in our release process to catch this and the engineer that did this is responsible for fixing it". Blameless post-mortems should be the industry standard.
- camillomiller 10y ago
  Indeed, but this is a big "you should have gotten that in QA" kind of mistake. With the aggravating factor the the company markets security as one of iOS tentpoles... Accountability is a bitch, I guess, but in this case this was really in plain sight. I mean, it's not necessarily the dev's ass that's going to be kicked. There's a nice story about accountability at Apple once recalled in a profile by Adam Lashinski. It's from the Steve Jobs' era, but I guess this kind of policy is still enforced in Cupertino: One such lesson could be called the “Difference Between the Janitor and the Vice President,” and it’s a sermon Jobs delivers every time an executive reaches the VP level. Jobs imagines his garbage regularly not being emptied in his office, and when he asks the janitor why, he gets an excuse: The locks have been changed, and the janitor doesn’t have a key. This is an acceptable excuse coming from someone who empties trash bins for a living. The janitor gets to explain why something went wrong. Senior people do not. “When you’re the janitor,” Jobs has repeatedly told incoming VPs, “reasons matter.” He continues: “Somewhere between the janitor and the CEO, reasons stop mattering.” That “Rubicon,” he has said, “is crossed when you become a VP.”
  - btilly 10y ago
    Indeed, but this is a big "you should have gotten that in QA" kind of mistake. It depends what kind of infrastructure you have. Ideally there should be NO MANUAL STEPS between dev and production. This should not be any need for a person to remember that this data should be inserted for dev and removed before prod. Instead there should be something like a documented way to insert the data or not based on a configuration file that is different for dev and production. Of course reaching that keeping that ideal requires discipline. And when you slip, it becomes easy to say, "That's QA's job." Over time QA's job will get harder and harder, and that is a guarantee of periodic slip-ups. Authority for fixing this situation really is the job of someone VP or above. They need to decide whether to fix the process and change what a lot of people do, or accept the inevitable screw-ups as the right choice to maintain the current rate of development.
dunham 10y ago
It's a little worse than that. The "file" column of the database is a binary plist encrypted with AES128-CBC using the first 16 bytes of SHA1(password||salt) as a key and 0,1,2,...,15 as a salt. So those columns could be used as an oracle to break the password, even if the hash were removed. The data in the file column doesn't really need to be encrypted. It was unencrypted previously, contains file metadata, and a properly wrapped key for the file. The cryptography on this is pretty shabby. Much more amateur than the existing / previous stuff surrounding the keybag in the backup (which uses PBKDF2). Not sure what happened here. (Why it was added, and why it wasn't vetted by their more knowledgeable engineers.)
matco11 10y ago
Well... yes... just remember to securely delete that backup made with the current version of iOS10 from your computer, after you upgrade to next iOS public release... ;-)

0x0 10y ago

That sounds maybe plausible, although what could they have possibly been debugging that required a weaker hash? Of course, with the paranoid hat on, if your task was to subvert the mechanism, this is probably exactly how you'd go about it - make it seem like an accident. Just like gotofail :)

camillomiller 10y ago
Yeah, and hide it in plain sight. Plausible, yes. Although goto fail; had another vibe to it. It was really strangely placed and hardly explainable. Plus it made possible to perform some pretty nasty MiTM attacks over a network. Here you have a method that security experts tinkering with the betas knew of since probably last July. Everybody expected Apple to fix it in the GM, but it didn't happen. Now the cat's out of the bag with some deservedly good (and harmless) publicity for Elcomsoft and it's gonna be fixed in no time. If we even want to give credit to the malicious actor hypothesis, what's the benefit for them? Accessing iOS 10 beta backups more easily for three months? Nah, I don't see that, not this time.
- jobu 10y ago
  > Although goto fail; had another vibe to it. It was really strangely placed and hardly explainable. Plus it made possible to perform some pretty nasty MiTM attacks over a network. The goto fail looked very much like a bad code merge. (I actually had a similar issue with a duplicated line when merging changes two days ago.) It's impossible to know without reviewing their full source control history, but it seemed like a plausible mistake to me.
  - camillomiller 10y ago
    Ok, good explanation. Let's slit that one with the Occam razor too, then :)

brazzledazzle 10y ago

I really wish the default response in dev and operations wasn't "somebody is going to get (yelled at|punished|fired|pile on layers of bureaucracy)". It would be so much better if the response was "how can we change automation in our release process to catch this and the engineer that did this is responsible for fixing it". Blameless post-mortems should be the industry standard.

camillomiller 10y ago
Indeed, but this is a big "you should have gotten that in QA" kind of mistake. With the aggravating factor the the company markets security as one of iOS tentpoles... Accountability is a bitch, I guess, but in this case this was really in plain sight. I mean, it's not necessarily the dev's ass that's going to be kicked. There's a nice story about accountability at Apple once recalled in a profile by Adam Lashinski. It's from the Steve Jobs' era, but I guess this kind of policy is still enforced in Cupertino: One such lesson could be called the “Difference Between the Janitor and the Vice President,” and it’s a sermon Jobs delivers every time an executive reaches the VP level. Jobs imagines his garbage regularly not being emptied in his office, and when he asks the janitor why, he gets an excuse: The locks have been changed, and the janitor doesn’t have a key. This is an acceptable excuse coming from someone who empties trash bins for a living. The janitor gets to explain why something went wrong. Senior people do not. “When you’re the janitor,” Jobs has repeatedly told incoming VPs, “reasons matter.” He continues: “Somewhere between the janitor and the CEO, reasons stop mattering.” That “Rubicon,” he has said, “is crossed when you become a VP.”
- btilly 10y ago
  Indeed, but this is a big "you should have gotten that in QA" kind of mistake. It depends what kind of infrastructure you have. Ideally there should be NO MANUAL STEPS between dev and production. This should not be any need for a person to remember that this data should be inserted for dev and removed before prod. Instead there should be something like a documented way to insert the data or not based on a configuration file that is different for dev and production. Of course reaching that keeping that ideal requires discipline. And when you slip, it becomes easy to say, "That's QA's job." Over time QA's job will get harder and harder, and that is a guarantee of periodic slip-ups. Authority for fixing this situation really is the job of someone VP or above. They need to decide whether to fix the process and change what a lot of people do, or accept the inevitable screw-ups as the right choice to maintain the current rate of development.

dunham 10y ago

It's a little worse than that. The "file" column of the database is a binary plist encrypted with AES128-CBC using the first 16 bytes of SHA1(password||salt) as a key and 0,1,2,...,15 as a salt. So those columns could be used as an oracle to break the password, even if the hash were removed. The data in the file column doesn't really need to be encrypted. It was unencrypted previously, contains file metadata, and a properly wrapped key for the file. The cryptography on this is pretty shabby. Much more amateur than the existing / previous stuff surrounding the keybag in the backup (which uses PBKDF2). Not sure what happened here. (Why it was added, and why it wasn't vetted by their more knowledgeable engineers.)

matco11 10y ago

Well... yes... just remember to securely delete that backup made with the current version of iOS10 from your computer, after you upgrade to next iOS public release... ;-)