24

My goal is to sniff the HTTPS traffic of some digital devices (AppleTV, game consoles, etc.), and decrypt the HTTPS packets in my local network.

I cannot figure out a way by using some HTTPS debugging proxy tools like Charles or Fiddler, because they need to have a certificate installed on the device. I don't have access to the file system on the device, I cannot copy certificate. But I can set the proxy of the device to point to my laptop or using my laptop's hotspot.

schroeder
  • 123,438
  • 55
  • 284
  • 319
Yifei
  • 359
  • 1
  • 2
  • 7
  • You do not need file system access, but you do need access to the browser - do you have that kind of access? Can you expound on what "digital device" you are talking about? – schroeder Mar 04 '15 at 21:48
  • @schroeder For example, an Apple TV, or game console that does not get cracked. And I want to sniff the traffic from an app on that device. On smartphone I can install customized certificate, but I don't have this kind of access on the devices I mentioned above. – Yifei Mar 04 '15 at 21:57
  • 4
    Unless you have an access necessary to install a certificate, it's not a 100%-ly your device, so you are not supposed to inspect traffic. Figuratively speaking, you own AppleTV's "body", but not "soul". – Vi. Mar 05 '15 at 02:42

6 Answers6

43

The entire point of SSL is its resistance to eavesdropping by man-in-the-middle attacks like the one you're proposing. If you cannot make the client device trust your self-signed certificate, then your only options are:

  • Intercept an initial HTTP request and never let the communication be upgraded to HTTPS (but this will not work if the if the client explicitly goes to an https://... URL)
  • Pretend to be the server with your own self-signed certificate, and hope that the system making the request naively accepts a self-signed certificate (which is the decision-making equivalent to a user who ignores the browser's stern warnings about a possible MITM attack in progress)
  • Check for susceptibility to known past attacks on SSL (Heartbleed, BEAST, etc.). Note that this option is most likely to be illegal, since it may require an attack on the server (which you don't own) rather than an attack on the client (which you do possibly do own)

If you have many trillions of dollars available to you, you may have a few other options:

  • Successfully compromise a worldwide-trusted certificate authority and use their secret signing key to produce forged certificates for your own keypair
  • Purchase or discover a zero-day security vulnerability in a Web client, Web server, or (most preferably) SSL/TLS library used by the client or server
  • Discover a crippling weakness in some underlying cryptographic primitive used by SSL (for example, completely breaking AES might do nicely)
  • Spend trillions of dollars on computer hardware to perform brute force attacks on intercepted encrypted communications

If you have unlimited physical access to the device, almost certainly an attack on the device's own trusted certificate store would be easier than an attack on SSL (though it may also be far from easy).

apsillers
  • 5,780
  • 27
  • 33
  • 5
    "and hope the user ignores the browser's stern warnings about a possible attack in progress" And we have services that explicitly train their users to do exactly that in lieu of actually fixing themselves. If all browsers would flatly refuse a bad certificate, we wouldn't have this problem, but then a bunch of malformed but legitimate services would be broken. – AaronD Mar 05 '15 at 00:07
  • 1
    Your third bullet point (exploiting vulnerabilities to extract private data) is probably illegal if used against a server you don't have permission to use it against (which you probably wouldn't if you have to resort to this). – nobody Mar 05 '15 at 02:54
  • 8
    +1 for "If you have many trillions of dollars..." –  Mar 05 '15 at 04:04
  • 9
    If you have some trillions of dollars you could probably buy the manufacturer company of the device and have a look at the actual sources. – SpaceTrucker Mar 05 '15 at 08:44
  • 2
    Standing behind the user and looking over their shoulder also works. – A E Mar 05 '15 at 11:22
  • @AE unlikely, as users don't type in certificates. – Mooing Duck Mar 05 '15 at 18:15
  • It doesn't take trillions of dollars to do these things. These are basically done every month. – d33tah Mar 05 '15 at 21:43
  • 1
    @d33tah But it takes trillions of dollars to make it a bit more possible that it is **you** who do these things. – Cthulhu Mar 06 '15 at 11:36
11

Any suggestions? Is is doable?

You need to own a certificate trusted by the device to intercept the traffic. How this can be achieved depends on how proper and open the certificate validation on the device is.

  • The device might have a buggy or non-existing validation of certificates. This is typically
    • No validation at all, in which case you could use any certificate.
    • Only validates the trust chain, but not the name inside the certificate. In this case you could use any certificate signed by a CA the device trusts.
  • The device has proper certificate checking but allows the installation of custom trust anchors. In this case you could create your own certificates and import them as trusted.
  • The device has proper certificate checking but is closed against adding new trust anchors. This is bad for you unless you get one of the trusted CAs to sign a new certificate for you which is acceptable by the device. Probably no CA will do this.

If this does not help there might be some other bugs. Look at the SSL problems from the last years and see if you could employ any of these bugs. Also you might try to use non-SSL bugs to hack the device and change the behavior of the software.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
3

No, the very nature of HTTPS is that the certificate is required to decrypt it. You could sniff the traffic, but it would be encrypted and useless to you.

armani
  • 2,658
  • 19
  • 20
3

No. This is the point of SSL, to prevent this kind of unauthorized snooping. To authorize your proxy you need to tell the device to trust the proxy certificate, and tell the device clients to trust your certificate or use the devices private key, which it sounds like you don't have access to. For more information:

https://en.wikipedia.org/wiki/Transport_Layer_Security

Antonius Bloch
  • 507
  • 2
  • 9
3

Take a Look at the FREAK tls vulnerability. you should be able to inject data into the SSL negotiation to trick the device into a RSA Export cipher, and from there the decryption of traffic by a man in the middle is significantly easier ( aka possible. )

Charles is written in java, shouldn't be too hard to modify to exploit this automatically.

Damian Nikodem
  • 769
  • 4
  • 8
  • 3
    Have you exploited FREAK? I'm not sure that you can casually suggest it as a viable solution. – schroeder Mar 04 '15 at 23:40
  • its funny that you mention it because I commented on a post regarding FREAK the other day and it spiked my intrest to the point where I started to take apart some of the 'client test' tools and prod around and read their paper, as I have a device which I am currently working on which happens to have a certain public key encoded in ROM (and is similar to the OP's question. ) While I have not gone-to the effort of cracking a RSA-Export 512 key for a given server just yet I do happen to have about 20 odd handshakes and 7 or so 1gb (ready to decrypt) transfers waiting for me at home. – Damian Nikodem Mar 05 '15 at 02:19
1

This all depends on which traffic your interested in. If you want to decrypt the traffic between your client and the device, then it is possible with a proxy. In fact, it is very similar to how Superfish works. See Lenovo Is Breaking HTTPS Security on its Recent Laptops for an outline of how superfish works.

On the other hand, if you want to decrypt the information your device is sending/receiving from other points, such as what Apple TV might be sending/receiving from Apple, that is much more difficult. I suspect this is likely the traffic you are more interested in.

While the same principal applies - essentially a MiTM (Man in The Middle) attack, you would need to somehow get your device to trust a certificate you own or compromise the private key of the certificate the device uses. This may be easier than it should be or very difficult, depending on how thorough the vendor has been in ensuring adequate security and management of SSL keys. For example, recently it was reported that a well known consumer router and modem manufacturer used the same certificate key on many of their devices, which meant that once you extracted the key from one device, you had access to all the devices using that key. If the manufacturer of your device has implemented similar poor security protection, then there is probably a hole you can exploit. However, finding it is not necessarily trivial. It requires some hacking skills and just the right type of deviant mind to find the weakness. Some people are naturals at this, others not so much.

What you would need to do is get your device to trust a certificate you own and then setup a proxy which has your certificate which will function as a man in the middle. Setting up the proxy is trivial if it is your network i.e. a home network, but getting the device to trust a certificate you have created is much more difficult and does come with some risks i.e. you could corrupt the certificate store on your device and pretty much turn it into a brick and is almost certainly illegal.

Tim X
  • 3,242
  • 13
  • 13