brannondorsey/radio-thermostat

Why do you need DNS rebinding for this to work?

cpitclaudel opened this issue · 2 comments

Hi there,

Neat write-up! One question, though — why do you need DNS rebinding for the attack to work? AFAICT, because of the way the API works, you don't need to read the responses returned by the thermostat — you can just use a cross-origin write to set the temperature to below-freezing and ignore the response. Can't you?

Also, the CVEs (https://www.cvedetails.com/cve/CVE-2013-4860/ and https://www.cvedetails.com/cve/CVE-2018-11315/) mention version numbers, but nothing has changed since then, right?

Thanks!

Hi!

You are absolutely correct. DNS rebinding is not required to change the temperature or to change the state of the device through any POST request. It is, however, required if you are looking to read the results from a GET via a cross-origin page.

Also, the CVEs (https://www.cvedetails.com/cve/CVE-2013-4860/ and https://www.cvedetails.com/cve/CVE-2018-11315/) mention version numbers, but nothing has changed since then, right?

Best I can tell, you are correct. A brand new model that I purchased ~6 months ago was vulnerable to these same problems, even 4+ years later. The Radio Thermostat of America company has been completely unresponsive to my advisory. To be honest, I wouldn't be surprised to learn that they no longer have an engineering team...

It is, however, required if you are looking to read the results from a GET via a cross-origin page.

Makes complete sense. Thanks so much for taking the time to reply! :)

The Radio Thermostat of America company has been completely unresponsive to my advisory.

Not surprising. I wonder whether this kind of insecure API is covered under California's new IoT law ^^

Thanks again for documenting this issue and responding to my question!