How to avoid this Apple hack scenario?
After reading the post about " cracking Siri " I understand that HTTPS traffic from iPhone to Siri Https server has been "cracked", (decrypt) by creating:
- custom DNS server
- fake HTTPS server (pretending to be "guzzoni.apple.com")
- dedicated SSL certification authority
and by changing the DNS and SSL Center settings of the client (iPhone), they were able to spoof the complete "environment" and decrypt the traffic.
But how does Apple (or anyone else) avoid this type of crack / hack?
source to share
After some reading, it seems the only way to avoid this type of hack (which I understand is a famous person in the middle attack) is to do correct authentication. Explained well here :
Public key algorithms can guarantee the secrecy of a message, but they do not necessarily guarantee secure communication, since they do not authenticate the identity of the communicating parties. To create a secure connection, it is important to verify that the public key used to encrypt the message actually belongs to the intended recipient. Otherwise, the third party can communicate and intercept public key requests, replacing their own public key for the legitimate key (man-in-the-middle attack).
To avoid such an attack, the owner of the public key needs to be verified, a process called authentication. Authentication can be done through a Certification Authority (CA), which is a third party trusted by both parties.
The CA issues public key certificates containing the object name, public key, and some other security credentials. Such credentials typically include the CA name, CA signature, and certificate (date to date).
Thus, I would suggest that the only way to avoid such a hack is to allow the client (iPhone here) to use pre-defined CAs.
source to share
I would analyze the situation starting with two facts:
- From your iPhone point of view, your iPhone is trusted.
- From the iPhone's point of view, the server is not trusted.
As a first step over HTTPS, I would challenge the server to prove its identity. The challenge is something like "sign my UUID, this timestamp, and this is a nonce ." By using public key cryptography with a published key, you can verify that you are talking to a server that you know and trust.
This is vulnerable to the person in the middle to observe, but the task is difficult enough that a re-attack will not work. Once you know how to answer a call, you will never see this problem again.
I think that observing the Siri protocol is not an issue if it cannot be re-attacked, and we have all seen it anyway, but the person in the middle can be blocked by a trusted CA. If guzzoni.apple.com is not what it should be, the odor test will fail. Some Netflix customers check with VeriSign that they are talking to real Netflix.
This is an analysis from your point of view of an iPhone that implicitly trusts itself. Obviously, your phone is the untrustworthy party and Apple is the trusted party. Once iOS is jailbroken, all bets are disabled. There are two absolute solutions, and none of them is technological.
- Backport Siri for iPhone 3GS, iPhone 4, iPad and iPad 2. Then no one needs to fake Siri.
- Don't worry about prisons, and just let them have fun. Seems to work so far.
(As a side note, a long-standing replay vulnerability was discovered during the iOS firmware validation process. The validation server gave you a signature based on a hardware token and a firmware version that Cydia could reproduce at a later date. It was fixed in iOS 5 , several years by contractors which makes me think Apple deliberately chose # 2.)
source to share
You have three problems here. One of them is the problem with the SSL / TLS hierarchy and Public CA. Secondly, the problem of insecure DNS. Third, Apple Security. We can fix two out of three with technical controls.
Almost all SSL / TLS, DNS, Public CA problems can be fixed with a public key (or certificate). Pinning is a whitelist of expected public keys or certificates in an application. Public key binding is equivalent StrictHostKeyChecking
in SSH. It solves problem (1) and problem (2). You can see an example of how to bind public keys in Cocoa / CocoaToauch in Graham Lee On. SSL connection for Cocoa [Touch] .
There are a few more infrastructure issues (carriers, phone makers, hijacking proxies, invalid CAs, corrupted CAs, untrusted browsers, DNS, PKI revocation, etc.) and most of them are discussed on the OWASP Mobile mailing list: Mobile, SSL / TLS and also a certificate or public key . The good news is that pinning will close most of the holes other people have created.
You won't be able to fix problem (3). When the ZonD80 made the equivalent for In-App purchases, Apple sent lawyers to carry out the hack instead of putting tech controls on StoreKit to ensure it didn't happen again. Here technical control is consolidated. Another Apple Security bug. (See Hacker bypasses Apple iOS purchases for more details).
Two parts of the reading that might interest you (these problems have been well known for years): PKI is broken and the Internet is broken .
source to share