Jacuzzi privilege escalation/authentication bypass attack

[denbesten]

[With Jacuzzi's] “personal hot tub assistant,” users can make use of the app to control water temperature, switch on and off jets, and change the lights. ....  “The main concern is their name and email being leaked,” Zveare told TechCrunch, adding that attackers could also potentially heat up someone else’s hot tub or change the filtration cycles. “That would make things unpleasant the next time the person checked their tub,” he said. “But I don’t think there is anything truly dangerous that could have been done — you have to do all chemicals by hand.“

https://techcrunch.com/2022/06/22/jacuzzi-flaws-admin-exposed-users/ 

After a bit of immature snickering about "personal hot tub assistant" and "exposing user data", it occurs to me that hacking the temperature falls into the "truly dangerous" territory.  If the bad actor were able to bypass  the electronic upper/lower limit controls, they could waste electricity, scald users, start a fire after boiling off the water, and/or allowing the hot tub to freeze.  That said, hot tubs do have mechanical thermal breakers to mitigate much of this risk.

[cindelicato]

An interesting read, no doubt, where personal information can be leaked. However, the threat of wasting electricity or allowing the tub to freeze are hardly 'dangerous' concerns; I haven't used a Jacuzzi in a number of years, but I doubt one could raise the water temps to scalding.

[denbesten]

Freezing is a property danger.  A hard-freeze risks totaling the tub itself, an economic loss of thousands of dollars.  

You are correct that hot tubs are designed to only permit safe temperatures.  The relevant CPSC/UL rule is "A unit shall be provided with a water temperature regulating control that has a maximum set point of 40°C (104°F) in the tub" (UL 1563 §32.1).  This is all good when using its controls as intended.

But that is not what a bad actor does.  More than once, we have seen developers range-check data in the frontend (web-browser/App/GUI) and the backend (API) accepts whatever is sent to it with the presumption that their front-end already did the check.  Although such a design would comply with §32.1, it also fails when there is  a bad actor with fiddler in the middle.  Without proper backend range checks, the bad actor could conceivably  raise the temperature to somewhere between 1st degree (118F) and 2nd degree (131F) burns.   The good news is that manufacturers attach a mechanical "thermal cut off" to the heater that deenergizes it at about 130F. Presuming the TCO has not failed-closed, it will prevent 3rd degree (150F) burns.  

The real problem is that in the name of economy, the same controller often both implements critical safety controls and online convenience features, resulting in the compromise of one risking the failure of both.  The mitigation is to use discrete safeties, such as the above TCO.