Part of the Cure53 security audit of Home Assistant.
Whilst auditing the frontend code to identify hidden parameters, Cure53 detected auth_callback=1
, which is leveraged by the WebSocket authentication logic in tandem with the state parameter. The state
parameter contains the hassUrl
, which is subsequently utilized to establish a WebSocket connection. This behavior permits an attacker to create a malicious Home Assistant link with a modified state parameter that forces the frontend to connect to an alternative WebSocket backend. Henceforth, the attacker can spoof any WebSocket responses and trigger XSS. Since the XSS is executed on the actual Home Assistant frontend domain, it can connect to the real Home Assistant backend, which essentially represents a comprehensive takeover scenario.
Permitting the site to be iframed by other origins, as discussed in this advisory, renders this exploit substantially covert since a malicious website can obfuscate the compromise strategy in the background. However, even without this, the attacker can still send the auth_callback
link directly to the victim user.
To mitigate this issue, Cure53 advises modifying the WebSocket code’s authentication flow. An optimal implementation in this regard would not trust the hassUrl
passed in by a GET parameter.
Cure53 must stipulate the significant time required of the Cure53 consultants to identify an XSS vector, despite holding full control over the WebSocket responses. In many areas, data from the WebSocket was properly sanitized, which hinders post-exploitation. The audit team eventually detected the js_url
for custom panels, though generally, the frontend exhibited reasonable security hardening.
Part of the Cure53 security audit of Home Assistant.
Whilst auditing the frontend code to identify hidden parameters, Cure53 detected
auth_callback=1
, which is leveraged by the WebSocket authentication logic in tandem with the state parameter. Thestate
parameter contains thehassUrl
, which is subsequently utilized to establish a WebSocket connection. This behavior permits an attacker to create a malicious Home Assistant link with a modified state parameter that forces the frontend to connect to an alternative WebSocket backend. Henceforth, the attacker can spoof any WebSocket responses and trigger XSS. Since the XSS is executed on the actual Home Assistant frontend domain, it can connect to the real Home Assistant backend, which essentially represents a comprehensive takeover scenario.Permitting the site to be iframed by other origins, as discussed in this advisory, renders this exploit substantially covert since a malicious website can obfuscate the compromise strategy in the background. However, even without this, the attacker can still send the
auth_callback
link directly to the victim user.To mitigate this issue, Cure53 advises modifying the WebSocket code’s authentication flow. An optimal implementation in this regard would not trust the
hassUrl
passed in by a GET parameter.Cure53 must stipulate the significant time required of the Cure53 consultants to identify an XSS vector, despite holding full control over the WebSocket responses. In many areas, data from the WebSocket was properly sanitized, which hinders post-exploitation. The audit team eventually detected the
js_url
for custom panels, though generally, the frontend exhibited reasonable security hardening.