0

This is a bit of a super duper specific question, but who knows there's someone out there that can help me. I happen to have Philips Hue Bridge and I would love to know what personal information it is sharing with the outside world. Using tcpdump on my router I figured the Hue Bridge has a rather talkative personality. But because it talks over SSL tunnels, I have no idea what it says. So what I did is I setup a SonicWall with SSL-DPI with a CA, got root access to the Hue Bridge and found the application that does the talking to wws://ws.meethue.com (its called websocketcd). I then replaced the root certificate on the Hue Bridge, adjusted the cipher to match the Sonicwall and now I am stuck due to boost.asio trowing an validation error of my certificate: error:14090086:lib(20):func(144):reason(134)

For those not too familiar with the error codes, this is what they mean:

lib(20) is ERR_LIB_SSL
func(144) is SSL_F_SSL3_GET_SERVER_CERTIFICATE
reason(134) is SSL_R_CERTIFICATE_VERIFY_FAILED

To verify it's not my SonicWall or certificate that is causing the problem, I executed openssl s_client -connect ws.meethue.com:443 -CAfile ca.pem from the Hue Bridge and that validates the chain perfectly fine, the same way as the original certificate. I also verified that the application is loading my root certificate and cipher correctly (because if change the cipher, I get a cipher error error). Also in my browser, I can visit https://ws.meethue.com without certificate errors. Here's my self made certificate chain, in case someone wants to check it: https://gofile.io/d/5msjoJ (password for download/key 1020304050, it's a temporary key that only exists in my local test env. so it's safe to share ;-)

If websocketcd wasn't a binary file, the problem was super easy to solve using set_verify_mode, but unfortunately it is a binary and that makes life significantly more complicated.

Is there anyone who can give me advice how to make this blob called websocketcd with boost.asio in it accept my root certificate? What I tried too: letting it communicate without ssl and with ssl without encryption (eNULL:aNULL ciphers). I am a bit hesitant to share the blob but for those who have a Hue Bridge too, it's located at /usr/bin/websocketcd.

Elmer
  • 255
  • 1
  • 2
  • 10
  • Why are you heistant to share the `/usr/bin/websocketcd`? Surely that's not under any NDA. On the contrary, I could just buy a bulb and examine it anyways. – sehe Nov 23 '20 at 13:48

2 Answers2

1

Perhaps you can use strace (or maybe even ltrace) to spot which certificate paths it is using for root authorities.

If it uses a single file, you might be abel to hack it by replacing it with a CA that verifies your MITM certificate. Sometimes the file can contain multiple certificates, so worth appending/prepending yours.

If you're in luck, there will be a readdir on a directory containing certificates. If so, you should be able to add your root certificate (in PEM form) there and **remember to run c_rehash on that directory.

sehe
  • 374,641
  • 47
  • 450
  • 633
  • 1
    Thanks!!! You just boosted my energy. Suggesting strace is a great advice and I just installed opkg on the Hue Bridge (had been removed by Signify) and subsequently installed strace. I am now analyzing the output. By the way, websocketcd has a commandline argument for paring a specific CAfile (instead than a directory) and I adjusted the init.d script to use my CAfile instead of the one that is loaded by default. That didn't help yet. I will keep you posted! – Elmer Nov 23 '20 at 16:46
  • Hmmm if that doesn't work that doesn't really bode well. At least it doesn't suggest they're trying to obfuscate any of the trust details, since that's basically advertising "how to" MITM, it seems. Good luck! – sehe Nov 23 '20 at 18:44
0

For those interested: after some 20hrs, I figured that websocketcd requires a certificate revocation list for each CA in the chain (which do not have to have any revoked serials). These CLRs need to be included in the root CA file that is loaded using the ca-filename argument. I was not aware that Boost Asio could demand that a CLR is present for each CA, but apparently, they (Signify) managed to do so.

Elmer
  • 255
  • 1
  • 2
  • 10
  • So how did you finally solve it? Currently I met the same problem with you. I tried keeping the original CRL contents in my fake certificate, but it doesn't work. – Sooner Jan 12 '21 at 09:49
  • So what I did: created a root CA certificate, created an intermediate CA certificate and signed the intermediate CA with root certificate. Created a certificated for FQDN and signed with with intermediate CA. Created CRL for root and intermediate CA certificates. And finally fed the root certificate along with CRL of root and intermediate to websocketcd (which feeds it to libasio, I just pasted the CRLs after the root certificated in the same file). This was a useful tutorial for me: https://jamielinux.com/docs/openssl-certificate-authority/introduction.html – Elmer Jan 13 '21 at 12:44