Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cracking Siri

applidium.com

Post reply on HN
Print view View original

21–30 of 105 posts

Re: Cracking Siri

#21

Post by ajross »

victoknight wrote: post #5

guess who doesn't verify the root CA. Think of all the fun to be had with a Siri man-in-the-middle

Missing the point, I think. There's no security bug here. The application isn't responsible for verifying the root CA in typical security models (though some, like Chrome, do something similar -- that's how the compromised Dutch CA was discovered). The idea is that the CA list is populated by your platform vendor and you trust it.

The trick here was that Siri was asking for an HTTPS connection to a named server, and you can't MitM that without having a signed cert for that server. So they added a new CA to their local (jailbroken) iPhone platform data and signed a cert for the Siri server.

Re: Cracking Siri

#22

Post by jakubw »

I wonder if there are any characteristics about the microphone in Apple devices that the servers could check the audio against to prevent this sort of a thing. There should be a way to somewhat distinguish the device used to record a stream given Apple's control over the devices on which Siri runs and overcoming that would be hard enough for anyone to bother.

Re: Cracking Siri

#23

Post by cjoh »

It'd be interesting to see whether or not Apple changed the Siri protocol since the acquisition. Was this originally how Siri worked when it was independent?

Because Siri has roots in government contracting (it's named after SRI International, and was originally funded by DARPA) I wonder if the roots of the obfuscation start there rather than at Apple.

Re: Cracking Siri

#24

Post by jevinskie »

ajross wrote: post #21
victoknight wrote: post #5

guess who doesn't verify the root CA. Think of all the fun to be had with a Siri man-in-the-middle

Missing the point, I think. There's no security bug here. The application isn't responsible for verifying the root CA in typical security models (though some, like Chrome, do something similar -- that's how the compromised Dutch CA was discovered). The idea is that the CA list is populated by your platform vendor and you trust it. The trick here was that Siri was asking for an HTTPS connection to a named server, and…

And for anyone thinking about ways to fix that problem, the researchers could have hooked SSL's read/write calls using a DYLD interposing library. Once you get superuser access on the phone, you can't trust your code to be safe.

Re: Cracking Siri

#25

Post by Xuzz »

ajross wrote: post #21
victoknight wrote: post #5

guess who doesn't verify the root CA. Think of all the fun to be had with a Siri man-in-the-middle

Missing the point, I think. There's no security bug here. The application isn't responsible for verifying the root CA in typical security models (though some, like Chrome, do something similar -- that's how the compromised Dutch CA was discovered). The idea is that the CA list is populated by your platform vendor and you trust it. The trick here was that Siri was asking for an HTTPS connection to a named server, and…

No, it's not jailbroken (there's no jailbreak for the iPhone 4S). This is just a feature of the iPhone: if you embed a SSL certificate in a mobile provisioning profile, it will add it to the system list. This is mostly intended for enterprises who might have a special SSL cert for their intranet, but it also works for this purpose as well.

Re: Cracking Siri

#26

Post by Xuzz »

jevinskie wrote: post #24
ajross wrote: post #21

Earlier quoted context omitted.

Missing the point, I think. There's no security bug here. The application isn't responsible for verifying the root CA in typical security models (though some, like Chrome, do something similar -- that's how the compromised Dutch CA was discovered). The idea is that the CA list is populated by your platform vendor and you trust it. The trick here was that Siri was asking for an HTTPS connection to a named server, and…

And for anyone thinking about ways to fix that problem, the researchers could have hooked SSL's read/write calls using a DYLD interposing library. Once you get superuser access on the phone, you can't trust your code to be safe.

There is no jailbreak for the iPhone 4S (at least not publicly available), so any hacks like this must be done from outside the device.

Re: Cracking Siri

#28

Post by pflats »

planb wrote: post #18
sjs wrote: post #6

Earlier quoted context omitted.

Probably so it'll work through strict proxies.

Unfortunately, Siri does not use the system wide proxy. At least it does not on my iPhone. I tried intercepting the traffic with sshmitm which did work for all other iOS services (e.g. game center) but not for Siri. I'm wondering how these guys sniffed the traffic.

Did you read the article?

When the proxy failed, they "ressorted (sic) to using tcpdump on a network gateway". They eventually had to "setup a custom SSL certification authority, add it to our iPhone 4S, and use it to sign our very own certificate"

Re: Cracking Siri

#30

Post by LaGrange »

hmottestad wrote: post #20
planb wrote: post #14

Earlier quoted context omitted.

No, you don't. Installing a root ca an iOS device is as easy as sending it via mail to the device and then clicking on it (with a few more clicks to confirm). edit (because I can't reply): It does show a big warning and you have to enter the device unlock code to do this, so it should be reasonably safe.

Hmm. That sounds like a big security hole. Phishing attacks in particular. Though I guess the extra clicks should discourage users.

It is necessary — some places have custom non-public CA's, for things like S/MIME and internal servers.

On the other hand, I'm pretty sure Siri doesn't have to communicate with your company's internal servers (and my paranoia already suggests a malicious IT department, reckless — and probably illegal — as that would be), so the code should, in my opinion, accept only specific CAs.

Post reply on HN