SIK-2016-052
Title:
Denial-of-Service Vulnerability in RWE Smarthome
Report ID
SIK-2016-052
Summary:
- Vendor: RWE AG
- Product: RWE Smarthome
- Affected Version: n/a
- Severity: low
- Short summary: The web server on the RWE smarthome appliance can easily be made unresponsive for a notable period time (i.e., minutes per blocking request).
Details:
By sending specially-crafted requests, one can block legitimate users from accessing the appliance using the management program (the Windows program based on Microsoft Silverlight).We have found two possibilities for achieving a denial-of-service:
- When sending a request with an invalid session id and then sending a second request with a proper session id, this second request is denied. This means that the appliance likely kills all open sessions once it receives an invalid session id. This can be used for a denial-of-service request by constantly feeding the box with invalid session ids. As a consequence, the legitimate owner cannot execute any actions anymore.
- The web server also seems to either employ rate limiting or break when flooded with messages from a fuzzer. This can also be exploited for a denial-of-service attack. After such a flood, it takes a short while until the box is accessible again.
While the first technique is used to cancel individual legitimate sessions, the second technique is used to make the appliance unresponsive altogether.
An attacker with control over the local network can prevent the legitimate user from accessing his appliance using the management program. This can be used for plain disruption or to hide other attacks that are being conducted.
Workaround
None that really works.
Suggested Mitigation
Do not close legitimate sessions even when receiving invalid requests. Make sure that the box employs rate limits to prevent simple denial-of-service attacks. Only block / rate limit IP addresses that flood on a per-IP basis, do not lock out other devices that are not part of the attack. Make sure that the server implementation cannot easily be overloaded with bogus requests that consume all processing power.
Timeline
- 2016-08-26 Vulnerability Discovered
- 2016-08-29 Vulnerability Reported