Tuesday, October 4, 2016

SEC Business Breakfast: The Future and Value of Penetration Tests

Deutsche Zusammenfassung unten.

The good ol’ pen tests: well-known system evaluation, but also valid documentation in light of the EU general data protection regulation (EU-DS-GVO)? At the past SEC Business Breakfast on September 23 in Vienna, General Manager Markus Robin explained, how penetration tests will need to change to provide companies with truly relevant information – as well as legal protection.

(c) Corporate Identity Prihoda 2016
Penetration testing has been a proven method to evaluate system’s durability since early 1967. While all of the attendants of the SEC Business Breakfast already use penetration tests, Markus Robin claimed three critical key points as relevant changes for the future of pen tests in companies: 

Frequence and Scenario-Cases Are Crucial

“We will know when we’re under attack.” That’s an argument Markus Robin hears often enough regarding the frequency of pen tests. “If you just realise it then, it’s too late. Waiting is not a wise and efficient measure, especially with regard to compliance regulations”, Robin sums it up. Penetration tests should be performed periodically: ideally, more than once a year and with concrete attack-scenarios in mind – considering new attack-vectors and ongoing technical innovations. To give another example, DDoS benchmark tests should be done quarterly.

Bringing Knives to a Gunfight: Equality of Arms

Facing APTs and professional cyber criminals it’s clear that penetration tests can’t run completely by themselves, even though most of them do. It’s about equality of arms, as Robin said: “Many companies use automatic tests, but it should be around 20 % automation, 80 % brain. You need people who can interpret the results, otherwise the report won’t be as meaningful as it could be.” Companies should consider appointing own experts to be able to react as soon as possible in case of anomalies.

Leading Organisations Demand Documentation

“Companies learned that security is an issue that needs to be considered from end-to-end”, said Markus Robin. Not only do companies demand documentation about set security measures from their partners or suppliers increasingly, but the legislation as well: The EU-wide data protection regulation comes into effect on 25 May 2018 and will put everyone under documentation duty. “Penetration tests can’t be the only form of documentation, that’s for sure. But it’s going to be an important evidence in question of data security and protection”, highlights Robin the upcoming added value.

Join the next SEC Business Breakfast to be updated about cyber security issues & to discuss with the SEC Consult Experts on site. Upcoming topic: EU Data Protection Regulation and its effects on your business - REGISTER NOW!

About the SEC Business Breakfast

SEC Business Breakfast is a networking series by SEC Consult about actual cyber security topics that addresses chief information officers. A casual environment with delicious breakfast provides space for networking and discussions but also insights and tips from security experts.


SEC Business Breakfast: Die Zukunft & der Wert von Penetration Tests

Die guten alten Penetration Tests: bewährte System-Beurteilung vor DDoS-Attacken, aber auch valider Nachweis im Rahmen der EU-Datenschutz-Grundverordnung (EU-DS-GVO)? Beim vergangenen SEC Business Breakfast am 23. September in Wien erklärte General Manager Markus Robin, wie sich Penetration Tests ändern müssen, um Unternehmen künftig mit wirklich aussagekräftigen Informationen zu versorgen und gleichzeitig als rechtliche Absicherung zu dienen.

Nutzen Sie die Gelegenheit um mehr über aktuelle, sicherheitsrelevante Themen zu erfahren und sich mit unseren Experten vor Ort auszutauschen. Unser nächsetes Thema: EU Datenschutzgrundverordnung und Ihre Auswirkungen auf Ihr Unternehmen - MELDEN SIE SICH JEZT AN!

Thursday, September 22, 2016

Controlling Kerio Control – When your firewall turns against you.


This blog post describes two different attacks which can be used to compromise companies which use Kerio Control in their network. Kerio Control is a hardware appliance which can be used as network firewall, router and VPN gateway. Both attacks spawn a reverse shell on Kerio Control. Since both attack payloads are delivered via CSRF (cross site request forgery) or XSS (cross site scripting) no ports must be open from the Internet.

About the vendor: “Protect your network from viruses, malware and malicious activity with Kerio Control, the easy-to-administer yet powerful all-in-one security solution. Kerio Control brings together next-generation firewall capabilities - including a network firewall and router, intrusion detection and prevention (IPS), gateway anti-virus, VPN, and web content and application filtering.”

Source: http://www.kerio.com/products/kerio-control

The following figure shows an example network of the attack scenario:

The attacker doesn’t directly attack the firewall system, instead a victim is tricked to visit his website. The website includes malicious content (images, forms, JavaScript) which instruct the victim’s browser to send all requests from the internal network directly to Kerio Control. Because of this not a single port must be open from the Internet on Kerio Control.

Kerio Control implements weak protections against these types of attacks which can be bypassed easily. Multiple critical security vulnerabilities have been identified by René Freingruber and Raschin Tavakoli of SEC Consult, which are documented in our technical security advisory.

For instance, Kerio Control uses a 6-year-old PHP binary which contains a countless number of memory corruption vulnerabilities. For demonstration, we picked one such memory corruption bug and wrote an exploit for it. The exploit is delivered blind (the website can’t read responses from requests sent to the internal network because of SOP restrictions – same-origin-policy).
It’s also important to note that it’s possible to brute-force the internal Kerio Control credentials via the below described method, even if the system is not accessible from the Internet. This is achieved via a side channel and a normally minor information leak vulnerability. It is a very good example why also internal systems should be secured by strong credentials and seemingly minor security issues have to be fixed. 

The first attack vector heavily abuses two PHP scripts, both scripts are not referenced by any other file in Kerio Control and contain two different(!) seemingly deliberate(?) CSRF check bypasses. These two scripts contain multiple vulnerabilities which attackers need for establishing reverse root shells into company networks: Remote code execution with root privileges, CSRF check bypasses (makes it exploitable from the Internet), XSS (could be used to defeat SOP), vulnerable code exploitable for heap spraying (to defeat ASLR). Moreover, one additional script can be used to defeat ASLR which leaks heap and stack pointers.

The second attack vector doesn’t use a memory corruption vulnerability, instead we use a publicly known vulnerability in Kerio Control which has not been fixed in the past 12 months (reported by Raschin Tavakoli, now employee at SEC Consult). The full exploit is publicly available on exploit-db (https://www.exploit-db.com/exploits/38450/), only the used XSS (cross site scripting) vulnerability was fixed. To demonstrate that the issue still exists we searched for two other XSS vulnerabilities to turn the XSS vulnerabilities again to a remotely exploitable reverse root shell. However, this attack has the pre-condition that the attacked victim is currently logged in as administrator (or that we can obtain administrator credentials via the brute-force attack). Kerio’s response to this reported vulnerability (and to the vulnerability that the webserver is running with root privileges) was: "I [they] do not consider this a vulnerability". It will therefore not be fixed by Kerio.

We have just discovered another XSS 0-day vulnerability which can again be used to obtain a reverse root shell on the most current Kerio Control system (version 9.1.3 build 1408). We have contacted the vendor again regarding this issue.

It’s also important to note, that the first attack scenario was not fixed by updating the 6-year-old PHP binary, instead only the problem of unserialize was fixed superficially. Kerio Control still uses PHP version 5.2.13.

Demonstration Video

Remote Identification of Kerio Control Systems

This step itself is not based on a vulnerability, however, it is a mandatory step during the overall attack. First, the attacker tricks a victim (from the internal network of the attacked company) to visit his malicious website. The website then performs the complete attack. For this the website must know the internal IP address of Kerio Control. Therefore, the first action is to somehow identify and obtain this IP address.

This can easily be done by adding images on the website which point to an image stored on Kerio Control. The perfect target for this is the logo stored at <KerioIP>:4081/nonauth/gfx/kerio_logo.gif. The attacker can add JavaScript event listeners for onload and onerror on his evil website to detect if the image was loaded or not. If the image was loaded, the attacker knows that the scanned IP address hosts Kerio Control. 
A simple JavaScript scan script is shown below:
for (i = 1; i < 255; i++) {
   ip_to_check = “192.168.20.” + i.toString();
   my_image = document.createElement("img");
   my_image.src = "https://" + ip_to_check + 
   my_image.onerror=kerio_not_alive;     // callback
   my_image.onload=kerio_alive;          // callback

For such an attack the attacker must know the internal IP range. This information can be obtained via different techniques (e.g. WebRTC leak, e-mail headers, misconfigured DNS server, information disclosure vulnerabilities on the website, social engineering) or can just be brute-forced (but this would add an additional delay to the overall attack).

Session Verification

For the first attack scenario at least a session as standard user is required (the second attack scenario requires that the victim is an administrator). The reason for this is that the vulnerability resides in code which can only be executed by authenticated users. Three situations can occur:

  1. The attacked victim is currently logged in as standard user (low privileges).
  2. The attacked victim is currently logged in as administrator (high privileges).
  3. The attacked victim is currently not logged in (no session).

Situation one and two are perfectly valid and can be used to obtain a reverse shell. Situation three is a problem because a valid session is mandatory for the attack. In such a case the attacker can start a remote brute-force attack via CSRF to identify weak credentials. This is even possible if no ports are open from the Internet because the complete attack is conducted via the web browser of the victim and the victim is connected to the internal network.

For such a brute-force attack the attacker needs a way to identify if the last tested credentials are valid or not. This is typically not possible because the attacker can’t read the response of a request which was sent to another domain / internal IP address (because of SOP – Same-Origin-Policy). For example, the attacker can send a valid login request to Kerio Control (because the login is not protected against CSRF), however, he can’t read the response and therefore doesn’t know if the credentials were valid or not.

One solution is to just assume that the credentials are valid and continue the exploit. If the exploit works, the credentials were valid. However, with this approach the complete attack would take too long and the victim may close the website before the attack finished.

A better solution is to use a side channel which bypasses SOP, namely image loading combined with JavaScript event handlers. This is possible because the URL to the user image only returns a valid image if the user is logged in. That means that the attacker can send a login request and after that embed an image pointing to <KerioIP>:4081/internal/photo with JavaScript event handlers installed for onload and onerror. If the onerror event handler triggers, the credentials were wrong, if the onload event handler triggers, the credentials were valid.

The following HTML code demonstrates this:

<img src="https://<Kerio-IP>:4081/internal/photo" onerror=not_logged_in(); onload=logged_in();></img>

Attack Vector One - Bypass of CSRF Protections

The next step is to trigger the vulnerabilities within Kerio Control. For this two vulnerable scripts on the system will be exploited. The first script sets the unserialize input (we are going to abuse the PHP unserialize function) and the second script actually invokes unserialize on the malicious input. Both scripts are stored inside the authenticated area which means that the scripts are protected by a CSRF protection. The CSRF protection should ensure that a remote attacker can’t force an action in the context of the attacked user session. In the case of the login request it was trivial because the login was just not protected by a CSRF protection.

In the case of the two scripts the CSRF protections must be bypassed, but it turns out, that this is trivial as well. The most common method is to use a XSS vulnerability, but for the first attack vector we will use another technique (the XSS technique will be described when discussing the second attack vector). Now we are going to directly exploit the vulnerable PHP code of Kerio Control.

The following PHP code can be found in the first vulnerable script:

1: $p_session->getCsrfToken(&$p_securityHash);
2: $p_postedHash = $_GET['k_securityHash'] || $_POST['k_securityHash'];
3: if ('' == $p_postedHash || ($p_postedHash != $p_securityHash)) {
4: exit();
5: }

The problem with the above code is, that the code is PHP code. Luckily for us, sadly for the programmer, the code is not JavaScript code which means that it has a completely different behavior than the programmer may have intended (except if it was deliberately backdoored). At line 2 the programmer wants to get either the GET or POST parameter k_securityHash, but || is a logical operator in PHP. The result is therefore either the boolean value true or false. At line 3 the programmer compares this result against the correct security hash (p_securityHash). The comparison is done by != , however, in PHP the operator != applies type juggling first (loose comparison). Correct would be a strict comparison via !==.

If we set k_securityHash to any value (either in GET or POST), we compare the boolean value true with a string. PHP will then interpret the string as boolean which is always true and then conclude that true equals true which means the check will always be bypassed if we set k_securityHash to any value.

So the first CSRF protection bypass was trivial. Let’s now focus on the CSRF protection in the second script:

1: $p_session->getCsrfToken(&$p_securityHash);
2: $p_hash = $_GET['k_securityHash'];
3: ...
4: if (!$p_session || ('' == $p_hash && $p_hash != $p_securityHash)) {
5: $p_page = new p_Page();
6: $p_page->p_jsCode('window.top.location = "index.php";');
7: $p_page->p_showPageCode();
8: die(); 

9: }

Now line 2 doesn’t contain the problem with the logical operator, however, line 4 contains the problem with loose comparison again. But there is also another detail, which differs…

The first code used || as a condition link, whereas this time the code uses &&. The condition can only become true if $p_hash (the GET parameter) is empty and the GET hash does not equal the correct hash. That means that it’s again enough to set k_securityHash to any value because then $p_hash is not empty.

Both CSRF check bypasses make the exploit working from the Internet to obtain reverse shells into the attacked company network.

Attack Vector One - The Exploitation

During analysis of Kerio Control we identified that Kerio uses a 6-year-old PHP binary (version 5.2.13). This version contains a countless number of publicly known vulnerabilities, including many memory corruptions leading to full code execution. To demonstrate the issue, we picked a commonly attacked PHP function – unserialize – to exploit Kerio Control. Unserialize can be called on user control input, however, the code is only available in the authenticated area (therefore the session verification step is required).

To exploit the function, we used CVE-2014-3515. The flaw exists because unserialize parses fields from the input, stores references to these fields, but doesn’t increase the reference count of these fields. As soon as the reference count from a field (or better a ZVAL, the internal data structure used to describe all kind of variables in PHP like integers, strings, objects or arrays) becomes zero, the ZVAL gets freed. Nearly all memory corruptions in unserialize work like this, only the method to decrement the reference count to zero (free the data) changes. In CVE-2014-3515 SplObjectStorage objects are used for this. When unserializing a SplObjectStorage object, a specific code path can be taken, which frees fields from the SplObjectStorage. However, the unserialize code added references to these fields (without incrementing the reference counter) and can therefore be used to access the freed data (the references became dangling pointers).

Let’s see this in action:

The code tells PHP to parse a custom object (C), the name of the class is 16-characters long (SplObjectStorage) and the data between the { and } is 49 characters long. “x:i:3” tells PHP that three elements will follow which must be attached to SplObjectStorage (This is custom unserialize-code related to SplObjectStorage. The code which parses these fields is important during exploitation, we call it in this blog post “attach code”). “m:a:1” tells PHP that the object has one member variable, a string of length one named y (s:1:”y”) with the value “i:111”. The first character always tells PHP the type (e.g. s for string, i for integer, C for custom object, and so on), so “i:111” is an integer with the value 111.

The output of the above code:

 As suspected the number 111 gets displayed. Let’s modify the code to use references:

Now R:1 is used instead of i:111 which means that the value of y is now a reference pointing to the entry with index 1 (the integer with value 777):

Until now everything works as expected. If we want to get the value 888 we have to update the reference to R:2, for 999 the reference R:3 must be used. But what happens if we use two times the same value?

Consider the following code:

What will now be printed (the second value changed from 888 to 777)? R:1 should still reference the first 777, but the code leads to the following output:

The problem is that the three values (from the “attach code” which are described by x:i:3) are added to a hash table. That means that a hash is calculated for every value and based on this hash the value gets inserted into the table. The values 777, 888 and 999 result in three different hashes and therefore all three values are stored in the table. However, if we store 777 two times, the second insertion will result in the same hash, the code then removes the first entry (with the same hash) from the table, frees the data and inserts the second data. That means that the ZVAL for the first 777 will be freed, however, there is still a reference (dangling pointer) to the ZVAL which can be accessed by the referencing code (R:1). After that PHP parses i:999 which will allocate the ZVAL of 999 over the freed memory address, therefore R:1 points to 999 (as well as R:3 would point to 999).

The problem is that the “attach code” should only process objects and no other types (and that a reference is added and the reference counter isn’t increased, but this is a problem for all PHP unserialize vulnerabilities). So typically it should not be allowed to add integers like we are doing with 777, 888 and 999. The associated code interprets these integers as objects (without checking the type) which exactly allows a collision of the hash. Here we are exploiting a type-confusion vulnerability to trigger a use-after-free bug.

We still have a problem with the above code. It only frees the ZVAL (=16 bytes of data describing the variable). We want to fully control this ZVAL, but for this the data is too small (if we for example allocate a string later, the string content will not be allocated over the freed data, instead the ZVAL of the string will be allocated over it). That means we have to free a variable which consumes more size than an integer. For this we have two possibilities: An array with additional elements or an object with member variables.

In both cases we have to add a second element with the same hash value. In the case of the array this leads to a problem because the “array-value” (source of the hash calculation) is a pointer to the heap and this pointer is randomized by ASLR (address space layout randomization). 

So the logical solution is to use objects instead. The hash of an object is calculated based on the object handle (a number incremented per object) and the object handler (a pointer to function pointers of the object). 

A first (not working) approach would be the following:

Now two objects of type “Beta” are used (currently without member variables), but the output shows that the use-after-free vulnerability isn’t triggered:

The reason is that the first Beta object has a different handle (handle 2) than the second Beta object (handle 3). It’s also possible to see this in the above output, SplObjectStorage has handle 1 (check the #1 in the output) and the referenced Beta object has handle 2 (#2 in the output). This is exactly how it should work. The code should only parse objects and every object has a different handle, therefore a hash collision should not be possible.

However, as described above, the PHP code contains a type confusion vulnerability which means that we can also add other types (integers, double values, strings, …) which will be interpreted as object and inserted into the hash table.

Let’s consider the following code:

The above code first adds an object of type stdClass and then the double value 8.784.... The double value was exactly chosen to result in the same hash as the stdClass and can therefore be used to free the stdClass object (A double value can be stored in eight bytes, the first four bytes will be interpreted as the object handle, the second four bytes will be interpreted as the “object handlers” pointer in the type confusion vulnerability). The output demonstrates that the memory of the stdClass object was freed:

We use the type confusion vulnerability to interpret the double value as object to make a hash collision to free the object to trigger a use-after-free vulnerability. The exact double value which is required for the collision depends on the PHP binary (more precise on the location of the “object handlers” pointer). Typically, this location is randomized by ASLR because PHP is loaded as library (e.g. in Apache). However, in the case of Kerio Control the code was statically compiled into the winroute binary (the main binary of Kerio Control containing the webserver, PHP, the firewall, and so on) and the binary was not compiled as PIE (position-independent-executable). Therefore, the hash is always the same because the “object handlers” are always stored at the same location.

Another problem with winroute is that stacks are marked as executable. This can be abused during exploitation (we didn’t used this flaw because the locations of the stacks are randomized by ASLR, but in combination with the identified stack pointer leakage it would be another solution for the exploit, however, with the additional dependency of a XSS vulnerability to read the stack pointer).

The next step is to control the content of the ZVAL. For demonstration we changed the ZVAL type to a string (type 6) and let the string point to the image base of PHP where the ELF-magic value is stored:

Now the stdClass object contains some fields (to increase the size of the freed data), the double value frees the object (as well as all member variables) and later we allocate a string of length 15. Length 15 is mandatory because PHP will add one to the length (null termination) resulting in an allocation of 16 bytes – exactly the size of a ZVAL. The reference was changed from R:1 to R:3 to point to one of the (freed) member variables from the stdClass object (R:1 would just point to the ZVAL of the 15-bytes string).

The content of the string now describes the referenced ZVAL, the last bytes specify the type (0x06 = string), the first DWORD (0x08048001) is the base address of the string, the second DWORD is the length of the string (0x03), the third DWORD is the reference counter which is in this case 0x01.

The following figure shows that the attack works as expected (the ELF-magic value gets dumped):

This vulnerability can be used to read the complete memory space and therefore to bypass ASLR. However, in the case of Kerio Control the result of the unserialize function is not reflected back to the attacker (moreover, because of SOP we would not be able to read the output, an additional XSS vulnerability would be required for this).

The exploit must therefore be written fully blind (and a way to bypass ASLR is required). The code execution step is trivial; the data type must only be changed from string (0x06) to object (0x05) to control the object function pointers. 

The last missing step is to bypass ASLR. A solution would be to turn the vulnerability into a write4 vulnerability (that means that we get the possibility to write 4 chosen bytes to a chosen memory location). Then we can for example overwrite the base address or length field of a string or overwrite a function pointer to point to another location (e.g. change the function address of a function called on the unserialize output to var_dump() to reflect the output back to the attacker).

This can typically be done by changing the data type to an array, however, in the case of PHP it’s not trivial because arrays are not implemented as simple arrays, instead arrays are implemented via hash tables (including memory pointers which we don’t know because of ASLR). Another possibility is to carefully choose the unserialize data and implement the write4 via the later PHP code from the attacked PHP script. But all these techniques would require that we read the response and this is not possible because of SOP (without a XSS).

Moreover, we also found a pointer leak which can be used to obtain the base address of the stack and heap, but reading this pointer also requires a SOP bypass.

We therefore decided to just use heap spraying as a method to bypass ASLR because then the exploit works blind (SOP must not be bypassed). Heap spraying is not the most elegant way, it’s also not 100% reliable, however, during tests it worked 99% of time and even if we hit the 1% cave the server just restarts three seconds after the crash and we can exploit it again. For a simple PoC it’s enough to demonstrate the issue with heap spraying.

Luckily, the programmer left (in addition to the CSRF check bypasses) some other useful code for us. One of the two attacked scripts contains the following code:

1: $p_variable = urldecode($_POST['k_variable']);
2: $p_value = urldecode($_POST['k_value']);
3: …
4: $p_session->setSessionVariable($p_variable, $p_value);

We can set any session variable to any value. We can therefore set variable “x1” to an 8 MB (max file upload) payload, “x2” to the payload, “x3” to the payload and so on. That means we can use the code for heap spraying.

The last steps are straight forward:
  • We can spray two different areas (each 250 MB in size because the target device has 4 GB RAM) to the heap. Area one contains ROP (return-oriented-programming) code pointing to a stack-pointer-shifting gadget. This gadget shifts the stack pointer to area two (on the heap). In area two we add a ROP NOP (no-operation) sled followed by a ROP chain which calls mprotect to disable DEP (data execution protection). After that we execute our shellcode.
  • Change the data type of the ZVAL to object (0x05) and set the reference counter to zero. This will immediately invoke the free-function on the object. Since we can control the “object handlers” pointer we can let it point into area one. This will then shift the stack pointer into our ROP NOP sled in area two, then execute the ROP chain which calls mprotect and then executes our shellcode. The shellcode just spawns a reverse root shell on Kerio Control.
A video demonstrating the attack can be found at the beginning of the blog post.

Attack Vector Two

In addition to the described attack vector above a second method exists to spawn a reverse root shell. This attack vector has the pre-condition that the attacked user is logged in as administrator. The likelihood for a successful attack is therefore low, but this attack works without exploitation of a memory corruption vulnerability and is therefore simpler.

The administrative interface contains functionality to upload an upgrade image. No checks are performed on the uploaded file. The included bash script will just be executed with root privileges. This vulnerability was already reported and published by Raschin Tavakoli on 2015-10-12 and is still unfixed (more information can be found in the original advisory at https://www.exploit-db.com/exploits/38450/). Only the used XSS vulnerability was fixed by Kerio.

The upgrade functionality is protected by a CSRF check which is correctly implemented. A XSS vulnerability is therefore required to bypass the check. To demonstrate that the vulnerability still exists SEC Consult searched for two different XSS vulnerabilities to demonstrate the attack.

One of these XSS vulnerabilities can be found in one of the two scripts which was used during the first attack. With this reflected XSS vulnerability an administrator can be attacked to upload an upgrade image and then perform the upgrade. This executes the uploaded bash script with root privileges allowing to spawn a reverse root shell. The attack can also be conducted via a malicious website from the Internet.

Vendor Response

The vendor was contacted on 2016-08-29. On 2016-09-01 the vendor responded with a PGP key. The advisory was sent PGP encrypted to Kerio on 2016-09-01. On 2016-09-09 the vendor responded that most vulnerabilities will be fixed by 2016-09-20.

The command execution vulnerability in the administration interface (second attack vector) will not be fixed as well as the reported issue “webserver running with root privileges”. Kerio’s statement to these vulnerabilities was: "I [they] do not consider this a vulnerability".

The explanation of Kerio was that an attacker can also use the XSS vulnerability to change the administrator password, activate the SSH service and open the SSH port from the Internet. Therefore, the attacker doesn’t have to abuse the upgrade functionality to spawn a reverse root shell.

However, SEC Consult considers this itself a vulnerability. All this should not be possible with a simple XSS vulnerability. Actions like changing the administrator password or activation of SSH access from the Internet should require the input of the administrator password. Then it’s no longer possible to abuse a simple XSS vulnerability in such a heavy way. The same applies for the upgrade functionality which must be fixed by the vendor.

SEC Consult informed Kerio about this on 2016-09-09, however, Kerio kept their decision. Hence the command execution vulnerability remains unfixed. A simple XSS vulnerability can still be used to obtain a reverse root shell on Kerio Control. 

To demonstrate the issue one more time we have just discovered another XSS 0-day vulnerability which makes all of this exploitable again (in the most current version which is 9.1.3 build 1408). Of course we have notified the vendor on this issue through our responsible disclosure but it seems a more thorough approach to securing their products and raising the quality is needed.


Here are some lessons which can be learned from the attack:

For administrators:
  • Just because a system is in the internal network it doesn’t mean that weak credentials can be configured. During the above attack the attacker was able to brute-force the credentials from an internal system via CSRF from the Internet. Internal systems must also be secured by strong credentials, patches have to be applied timely and a layered approach (zone concept) should be used for accessing critical systems.
For vendors:
  • Vulnerabilities must be fixed in-depth. It’s not enough to fix a bug superficially, instead developers have to understand why a vulnerability occurs and identify the real reason behind it. For example, in PHP the real reason was that references were added without incrementing the reference counter. Instead, only the free code was patched for all kinds of unserialize bugs. In the case of Kerio Control, the real issue is a 6-year-old PHP binary, instead Kerio just fixed the unserialize vulnerability. Same applies for the RCE vulnerability which was not fixed, only the used XSS vulnerability was fixed. 

This research was conducted by René Freingruber and Raschin Tavakoli, Security Consultants at SEC Consult.

Tuesday, September 6, 2016

House of Keys: 9 Months later... 40% Worse

In November 2015 SEC Consult released the results of our study on hardcoded cryptographic secrets in embedded systems. It's time to summarize what has happened since.

(c) fotolia #9110500 / sripfoto
To accomplish the mammoth task of informing about 50 different vendors and various ISPs we teamed up with CERT/CC (VU#566724). We would really like to report that our efforts were successful, but as it turns out the number of devices on the web using known private keys for HTTPS server certificates has gone up by 40% in the last nine months (3.2 million in November 2015 vs. 4.5 million now). There are many explanations for this development. The inability of vendors to provide patches for security vulnerabilities including but not limited to legacy/EoL products might be a significant factor, but even when patches are available, embedded systems are rarely patched. Insufficient firewalling of devices on the WAN side (by users, but also ISPs in case of ISP-supplied customer premises equipment, CPE) and the trend of IoT-enabled products are surely a factor as well.

In our initial study we analyzed SSH host key use as well. Unfortunately there is no recent scan data on SSH host keys available (however there is a ticket over at the awesome ZMap project).

In the spirit of open research we are releasing the raw data today on Github. The data we are publishing consists of 331 certificates including the matching private key as well as 553 individual private keys. We've also included the names of products that contain the certificates/keys. Cryptographic keys that were not found in Internet-wide scan data (Scans.io and Censys.io, HTTPS/SSH) are included as well. These might be used in other protocols such as EAP/802.1X, FTPS etc. The data we are publishing allows researchers to reproduce the results of our study, find more cases or cryptographic key reuse, attribute cryptographic keys to specific vendors/products, but also to develop tools for detecting and exploiting this vulnerability class in the course of penetration tests. Releasing the private keys is not something we take lightly as it allows global adversaries to exploit this vulnerability class on a large scale. However we think that any determined attacker can repeat our research and get the private keys from publicly available firmware with ease.

Some highlights from the data set were already mentioned in our initial blog post last year, including our beloved Broadcom SDK "Daniel" certificate, that is still used by 500.000 devices, or the Multitech/Texas Instruments certificate that is used by 280.000 devices on the web.

Our upcoming IoT/CPE firmware security analysis solution for device vendors and ISPs detects cryptographic key reuse vulnerabilities.

Ubiquiti Networks

Last year we published a blog post titled The Omnipresence of Ubiquiti Networks Devices on the Public Web in which we discussed why so many Ubiquiti Networks devices are on the public web. In this case we can report some improvement. The number of devices on the web has gone down by 62% (1.1 million in November 2015 vs. 410.000 now). The bad news is that the major drop is likely caused by various botnets that exploit weak credentials as well as critical vulnerabilities including an innocently titled "Arbritrary file Upload" vulnerability (straightforward remote code execution, Metasploit module available). These botnets might have forced Ubiquiti customers to firewall their devices. Symantec has released a report on one of the malware families.

Ubiquiti devices country breakdown, powered by Censys

The Ubiquiti support forums are filled with people who struggle to remove malware from customers' devices (1, 2, 3, 4, ...). Ubiquiti has even started to include functionality to remove malware in their firmware updates and released a standalone tool called "CureMalware" that promises removal of the botnets "Skynet, PimPamPum and ExploitIM". The tool comes with the helpful instructions: "NOTE: If you cannot access the devices, please try the username: moth3r and password: fuck.3r or moth3r/fucker with CureMalware.". What a mess... and Ubiquiti still has remote management on the WAN port enabled by default.

Aruba / Alcatel-Lucent

What we did not mention publicly back in 2015 is a curious certificate/private key pair we found in various Alcatel-Lucent OmniAccess firmware. Contrary to most other certificates we've found, the certificate is signed by a browser-trusted CA (GeoTrust), is issued to "securelogin.arubanetworks.com" and valid until August 2017. Turns out that Aruba Networks is the OEM for the Alcatel-Lucent OmniAccess product line. The certificate is part of ArubaOS and the certificate is used in various Aruba Networks products as well. 49.000 devices on the web are using this certificate.

Information provided by Censys

The certificate is not only the default HTTPS server certificate (captive portal and web administration) but also for WPA2-Enterprise 802.1X authentication. This allows attackers to do all kinds of nasty MITM attacks (active/passive HTTPS decryption, rogue access points, etc.). We informed Aruba back in May 2015. They will not provide a new browser-trusted default certificate in the future but move to device specific self-signed certificates instead. However they have decided against revoking the (still valid) current certificate. Aruba's "security guy" Jon Green has published particularly quotable post on the issue:  "In the past we were persuaded by the "but certificates are too complicated - just leave the factory default cert as-is and customers who care about security can update it" argument, but I now think we're doing a disservice to customers by giving them too much rope with which to hang themselves."

Update 2016-09-08:
It seems the Aruba certificate with serial number 0x1da52 has been revoked, see GeoTrust CRL.

Further information can be found in our advisory.

What can be done?

Our recommendations have not changed:

Vendors should make sure that each device uses random, unique cryptographic keys. These can be computed in the factory or on first boot. In the case of CPE devices, both the ISP and the vendor have to work together to provide fixed firmware for affected devices.

Furthermore ISPs have to make sure remote access via the WAN port to CPEs is not possible. In case the ISP needs access for remote support purposes, setting up a dedicated management VLAN with strict ACLs (no CPE to CPE communication) is recommended.

End users should change the SSH host keys and X.509 certificates to device-specific ones. This is not always possible as some products do not allow this configuration to be changed or users do not have permissions to do it (frequent in CPE devices). The required technical steps (generating a certificate or RSA/DSA key pair etc.) are not something that can be expected of a regular home user.

This study was conducted by Stefan Viehböck, Senior Security Consultant at SEC Consult.

Friday, July 29, 2016

HTL Wiener Neustadt wins World Championship of Robotics

Deutsche Zusammenfassung unten.

Team und Betreuter der HTL Wiener Neustadt bei der Robotik-Weltmeisterschaft in Florida 
v.l.n.r. stehend DI Harald Haberstroh, Nico Kratky, Christine Zeh, Christoph Heiss, Nico Leidenfrost, Florian Ungersböck, Sebastian Schaffler, Sascha Zemann, Raphael Weinfurter, Markus Pinter
v.l.n.r. hockend: Daniel Honies, Christoph Käferle, Daniel Swoboda, Philip Trauner, Dr. Michael Stifter
HTL Wiener Neustadt Winner Team (c) HTL Wiener Neustadt

Wiener Neustadt/Saint Augustine (USA) – For several years now, students of HTL WienerNeustadt have participated at Botball, an international robotic tournament. After some already good rankings in the past, this time they won the prize.

Botball aims to inspire kids and young people for science, technology and engineering. This year’s championship took place from 6 to 10 July in Saint Augustine, Florida, organized by the Global Conference on Educational Robotics (GCER).

For HTL Wiener Neustadt, the teams “items” and “Robot0nFire” met the challenge. With great success: Team “items” reached the score of 100 percent and won everything possible. For the very first time, a non-US-team could take it all. Furthermore, the team scored first place in the categories “Seedings” and “Double Elimination”. “Robot0nFire” reached fourth place in the overall ranking. The Austrian students competed against 250 other participants from seven nations.

SEC Consult supports HTL Wiener Neustadt in several ways. We offer internships for students, provide knowledge and even financial support for the trip to Florida.

Enthusing young people for science and technology is quite important. Especially regarding IoT, there will be great job opportunities in the fields of robotics and networking. For maintaining economic success and succeeding in international competition, it’s crucial to have the best educated workforce.

We are already looking forward to Botball 2017 to win again.


HTL Wiener Neustadt gewinnt Robotic-WM!

Zwei Teams der HTL Wiener Neustadt waren bei der diesjährigen Robotic-WM „Botball“ in Florida mit dabei und erzielten grandiose Erfolge. Team „items“ erreichte einen Dokumentationsscore von 100 Prozent, sicherte sich den Gesamtsieg und schrieb damit Geschichte: Zum ersten Mal holte ein Nicht-US-Team den Sieg bei „Botball“. Team „Robot0nfire“ belegte den herausragenden 4. Platz in der Gesamtwertung. 

Monday, July 18, 2016

The Winner Hacks it All

SEC Consult Part of the AppSEC EU University Challenge '16 Winning-Team

German summary below.

Even though the Austrian football team didn't get far at the UEFA Euro 2016, at least the TU Wien team (Technical University Vienna) got our backs at the AppSEC University Challenge '16. Five top-universities challenged their hacking-skills during the European security-event AppSEC 2016 in Rome (27.6.-1.7.). With incredible 300 points it was TU Wien who was able to claim victory. SEC Consult supported the team financially and with energetic manpower: Former intern, experienced competitor and now SEC Consult employee Thomas Weber led the team to their early point-lead.

Weber was one of the guys who worked on the jeopardy tasks on the first and second day of the competition, while others focused on the attack and defense part. The team was able to rank fist with 124 points by solving many technical riddles, followed by second and third place Switzerland (118) and Germany (106). By the end of the second day – and after a long race of attack-defence play, fixing vulnerabilities and trying to find unsecured spots in the opponents systems – TU Wien won

with incredible 300 points."

SEC Consult congratulates the winning-team as well as colleague Thomas Weber to the victory and wishes best of luck for the next AppSEC University Challenge '17 in Belfast. For detailed insights into the challenge and its tasks please visit catalysts blog, where TU Wien member Daniel Marth shares his experience. 


SEC Consult Teil des Gewinner-Teams der AppSEC EU University Challenge '16

Auch wenn Österreich bei der Fußball-EM 2016 nicht weit gekommen ist, hat uns zumindest das Team der TU Wien (Technische Universität Wien) bei der AppSEC University Challenge '16 nicht hängen gelassen. Fünf Top-Universitäten stellten ihre Hacking-Skills während der europäischen Sicherheitskonferenz AppSEC 2016 in Rom (27.6.-1.7.) unter Beweis. Mit unglaublichen 300 Punkten konnte das Team der TU Wien schließlich den Sieg heimtragen. SEC Consult sponserte nicht nur die Mannschaft, sondern unterstütze diese auch tatkräftig mit Manpower: Ehemaliger Praktikant, erfahrener Wettbewerbsteilnehmer und nun SEC Consult Mitarbeiter Thomas Weber führte das Team zu einem frühen Punkte-Lead.

Wednesday, May 25, 2016

EU General Data Protection Regulation Comes Into Force on May 24, 2016

The new EU law combines data privacy with data security - in future, companies need to prove organizational and technical protection measures for personal data. 

Markus Robin, General Manager SEC Consult: "Data privacy needs data security. With the new EU regulation IT-security finally plays a big role in data protection. Due to Germany's IT security law it already has a quite high protection level in critical infrastructure companies - but now all of Europe’s economy is asked to follow. Other European countries like Austria whose starting point is from a lower cyber-security-/privacy-level will have to step up their game pretty fast. For affected companies this means: Start as soon as possible with your risk analysis and prepare an implementation plan - because the two year realization period is shorter than you expect.”

With yesterday the new EU general data protection regulation came into force. The objective is to set a high and unified data protection for the whole European Union. Affected are all companies, that process personal data from EU-citizens - therefore international data-giants as Google, Facebook & Co. are regulated by this law as well. Next to data protection issues like the "Right to be forgotten"-principle, the new regulation emphasizes the importance of data security. From May 25, 2018 all affected companies and their applications need to prove and document organizational and technical protection measures regarding personal data. In case of violation, the penalty will be measured by the preparations the respective company took, but can also lead up to 20 million Euro or four percent of the worldwide prior-year-sales.

Given the short realization period of just two years, SEC Consult recommends:

1. Start a Risk Analysis and Prepare an Implementation Plan – NOW!

Companies should start to deal with the new organizational and technical legal requirements as soon as possible. First to budget possible financial investments and second to have enough time for the implementation. "The very first step needs to be a comprehensive analysis. What kind of personal data do you have and how are they classified? How high is the risk? Which protection measures are already implemented? Using these answers we are able to derive necessary actions", says Markus Robin.

2. Find an Implementation-Partner

"The new penalty height corresponds to several annual IT-budgets - negligence can't be settled out of the petty cash anymore. For a gapless implementation of the needed requirements companies should find legal and security assistance from experts", Robin advices. SEC Consult itself works closely with lawyers and offers comprehensive consultation next to informative risk analysis as well as implementation of security measures.

Find out more about the EU general data protection regulation and contact us for an appointment: send an email to office@sec-consult.com or use our international contact details

Facts & Figures // EU General Data Protection Regulation

  • Is part of the EU data privacy reform
  • Came into force on May 24, 2016
  • Validity with May 25, 2018 (two year realisation period)
  • Objective: Standardization of a high data protection level for the whole European Union
  • All companies are affected, that process personal data from EU-citizens - therefore international data-giants as Google, Facebook & Co. are also regulated by this law
  • Companies must meet organizational and technical protection measures in the areas of privacy and data security - proven and documented
  • Companies need to have a "risk-accurate protection level" 
  • Massive penalty-increase: depending on the violation up to 20 million Euro or four percent of the prior-year-sales; but penalty will be measured by the preparations the respective company took

Friday, April 22, 2016

SEC Consult Study on Smart Home Security in Germany - a first silver lining on the horizon of IoT?

The English short summary can be found further below.

Ein anstrengender Arbeitstag neigt sich dem Ende zu. Sie kommen endlich nach Hause. Schon eine Fingerbewegung am Smartphone reicht aus, um die Alarmanlage zu deaktivieren. Sie betreten Ihr Heim. Die Temperatur ist bereits perfekt, das Licht schaltet sich automatisch beim Betreten des Wohnzimmers ein und Ihre Lieblingsmusik klingt sanft durch den Raum…

Das klingt doch gar nicht schlecht, oder?

Intelligente Heimsteuerungen, sogenannte „Smart Homes“, sind stark im Kommen und zählen zu den am schnellsten wachsenden Branchen des zukunftsträchtigen „Internet der Dinge“. Doch neben zahlreichen Vorteilen und spannenden Neuerungen bringt diese Technologie auch Gefahren mit sich. Smart Home Systeme erzeugen eine direkte Verbindung zwischen der virtuellen Welt und unserem realen Leben. Dadurch haben sowohl ihre Vorteile als auch ihre Gefahren direkten Einfluss auf unser Leben.

Doch woraus besteht eigentlich ein solches Smart Home System?

Typische Architektur eines Smart Home Systems

Im Grunde sind die meisten Smart Home Systeme sehr ähnlich aufgebaut: Auf unterster Ebene befinden sich Sensoren, die Gegebenheiten wie Temperatur, Wind, den Zustand eines Fensters etc. messen, und Aktoren, um diese Gegebenheiten zu beeinflussen bzw. Geräte zu steuern. Diese Sensoren und Aktoren sind meist mit einer lokalen Zentrale verbunden, die die einzelnen Geräte miteinander verknüpft. Darüber hinaus benötigt man auch eine Möglichkeit all dies zu steuern. Das geschieht aktuell am häufigsten über einen Web-Browser oder eine Smartphone-App. Bei zahlreichen Produkten verschiedenster Hersteller verbindet sich die App zudem mit einem Cloud-Dienst, der in weiterer Folge direkt mit der Zentrale zuhause kommuniziert. [1]

Sowohl aus technologischer als auch aus Sicherheitsperspektive lässt sich ein solches System in zwei Ebenen unterteilen: Einerseits die lokale Kommunikation zwischen Zentrale und ihren Aktoren und Sensoren, andererseits die Fernkommunikation zwischen Zentrale, Cloud und Steuerungsclient.

Spricht man von Smart Home Security, so steht meist die lokale Kommunikation im Fokus der Betrachtung. Dies ist auch naheliegend, da dieser Bereich eine Vielzahl an neuen Kommunikationsprotokollen und Technologien bietet. In den vergangenen Jahren konnten einige Forscher bereits nachweisen, dass hier sicherheitstechnisch enormer Aufholbedarf besteht. [2] [3] [4] [5]

Neben der lokalen Kommunikation ist es aber auch außerordentlich wichtig, die Fernkommunikation von Smart Home Systemen näher zu analysieren. Vor allem, da es genau diese ist, über die man auch, wie der Name bereits suggeriert, aus der Ferne mit dem System interagieren kann. In diesem Bereich tummeln sich verschiedenste Arten von Web-Technologien - und mit ihnen kommen auch die guten alten, traditionellen Web-Schwachstellen. So zeigte SEC Consult bereits in Advisories zu Smart Home Produkten, dass es unabhängig von der lokalen Sicherheit eines Smart Home Systems möglich ist, über Schwachstellen in der Fernkommunikationsebene beliebige Geräte in einem intelligenten Haushalt fernzusteuern. [6] [7]

Aus diesem Grund haben die Experten des SEC Consult Vulnerability Labs die Fernkommunikationsebene von Smart Home Produkten weiterer Hersteller unter die Lupe genommen. Hierfür wurden gemeinsam mit dem führenden deutschen Wirtschaftsmagazin WirtschaftsWoche sechs Produkte - fünf aus Deutschland und eines aus der Schweiz - ausgewählt und deren Sicherheit im Rahmen eines limitierten Security Crash-Tests überprüft. Drei dieser Produkte, Gigaset Elements, RWE Smart Home und Qivicon, wurden bereits bei einem früheren Test der WirtschaftsWoche in Kooperation mit AV-Test überprüft [8]. Genau diese Produkte schnitten auch bei den Tests des SEC Consult Vulnerability Labs am besten ab.

Dies legt den Schluss nahe, dass wiederholte Sicherheitsüberprüfungen wesentlich zur Steigerung der Produktsicherheit beitragen!

Ebenso gut schnitt das neue System von eQ-3, Homematic IP, ab. Während das Vorgängersystem Homematic auf lokaler Kommunikationsebene bereits vor einigen Jahren heftige Kritik einstecken musste, präsentiert sich das neue Homematic IP zumindest auf Fernkommunikationsebene solide.

Übersicht der von SEC Consult identifizierten Schwachstellen auf Fernkommunikationsebene. Durch eine schwere Schwachstelle auf einer hohen Ebene können die darunterliegenden Ebenen ebenfalls als kompromittiert angesehen werden.

Schwachstellen wurden hingegen im deutsch-schweizerischen Produkt Digitalstrom identifiziert [9]. Dieses ist von Cross-Site Scripting und Cross-Site Request Forgery - sehr häufigen, traditionellen Web-Schwachstellen [10] - betroffen. Diese Schwachstellen erlauben es einem Angreifer, beliebige Geräte eines Haushaltes fernzusteuern und im schlimmsten Fall sogar die komplette Anlage zu übernehmen. Einen weiteren Kritikpunkt liefert der deutsche Hersteller Devolo, dessen Smartphone-App Benutzername und Passwort seines Besitzers im Klartext auf dem Telefon speichert [11]. Bei Diebstahl oder Verlust kann ein Angreifer unter Umständen die Anmeldedaten des Benutzers stehlen und das Smart Home System vollständig mit allen Rechten des Besitzers übernehmen.

Obwohl die lokale Kommunikationsebene bei keinem der sechs Produkte technisch verifiziert wurde, da sie nicht im Fokus dieser Tests stand, muss dennoch bei den Produkten von Digitalstrom und Devolo etwas angemerkt werden, das den Experten während der gesamten Testphase negativ aufgefallen ist:

Das Digitalstrom-eigene lokale Kommunikationsprotokoll ist laut Herstellerangaben vollständig ungeschützt [12]. Da es sich um ein kabelgebundenes Protokoll handelt, ist die Sicherheit rein vom physischen Zugriffsschutz abhängig. Einem Angreifer wäre es somit potenziell möglich, Schaden über das ungeschützte Datenkommunikationsprotokoll anzurichten.

Devolo hingegen setzt neben dem Powerline-Protokoll dLan auch den Funkstandard Z-Wave zur kabellosen Kommunikation mit Sensoren und Aktoren ein. Bei Betrachtung des verbauten Z-Wave Chips des Raumthermostats fiel jedoch auf, dass es sich hierbei um ein veraltetes Modell der Serie 300 (ZW0301) handelt, das über keinerlei Sicherheitsmechanismen verfügt [13]. Die Funkkommunikation zwischen der Zentrale und dem Thermostat ist somit vor Angriffen vollkommen ungeschützt.

Geht ein Angreifer einen Schritt tiefer in der Analyse von Smart Home Geräten, gelangt man an den Punkt, an dem die Firmware der Geräte analysiert werden muss. Als Firmware wird das Bindeglied zwischen Hard- und Software eines Gerätes bezeichnet. Durch bestimmte Techniken in der Hardwarearchitektur ist es möglich, den Zugriff auf die Firmware zu erschweren, um eine Analyse schwieriger und aufwändiger zu gestalten. Im Zuge des durchgeführten Security Crash-Tests wurde auch diese Ebene stichprobenartig überprüft, wobei deutliche Qualitätsunterschiede zwischen den Herstellern erkennbar waren. So ist es bei RWE für einen Angreifer ein Leichtes, die Firmware zu extrahieren und darin nach Schwachstellen zu suchen. Wohingegen die meisten anderen Hersteller dem Angreifer schon deutlich mehr Steine in den Weg legen. Die Extraktion ist aber immer noch mit überschaubarem Aufwand möglich. Lediglich das Testgerät von eQ-3, Homematic IP, erschwert einem Angreifer die Analyse durch diverse Hardware-Schutzmechanismen deutlich.

Gelangt ein Angreifer in den Besitz der Firmware, so kann er diese auf mögliche Schwachstellen untersuchen. Im Zuge einer Kurzüberprüfung zeigte sich, dass bei Gigaset, RWE und Devolo veraltete Software auf den Geräten zum Einsatz kommt, für die teilweise öffentlich bekannte Schwachstellen existieren. Zwar sind diese unter aktuellen Umständen nicht ohne Weiteres von einem Angreifer ausnutzbar, jedoch reicht beispielsweise im Fall von Devolo bereits eine bestimmte Änderung der Firmware-Konfiguration aus und das Gerät könnte potentiell vollständig durch einen Angreifer kompromittiert werden. Das grundlegende Problem hierbei liegt in der unzureichenden Sicherheitsüberprüfung zugekaufter hardwarenaher Softwarekomponenten durch die Hersteller. Die Basis der Firmware wird in den meisten Fällen von Drittanbietern zugekauft, deren Sicherheit wird jedoch nicht ausreichend sichergestellt.

Zusammenfassend lässt sich festhalten, dass der Großteil der aktuell überprüften Hersteller bereits aufgrund von früheren, systematischen Sicherheitstests die Qualität in Bezug auf sichere Software erhöht hat. Sind die Sicherheitstests jedoch nicht ausreichend oder fehlen gänzlich, tauchen klassische und bereits seit Jahren bekannte Schwachstellen auch in kritischen Smart Home Produkten auf.

Unterschiede bei den jeweiligen Sicherheitslevels diverser Smart Home Produkte sind für Endverbraucher somit aber nur durch professionelle Sicherheitstests erkennbar. Die Frage bleibt jedoch offen, warum Hersteller nicht ausreichend in Sicherheitstests investieren, bevor die Produkte auf den Markt kommen. Auch der deutsche Innenminister Thomas de Maizière denkt über Produkthaftung und Schadensersatzansprüche gegen die digitale Sorglosigkeit der Hersteller nach [14].

Traditionelle (Web-)Schwachstellen in Smart Home Systemen gehören also noch längst nicht der Vergangenheit an, sondern sind nach wie vor eine reale Gefährdung für das intelligente Zuhause.

English Short Summary

Intelligent home automation systems, the so called “Smart Homes“, are up and coming. They aim to make our life easier with fancy functions like controlling your heating system with your tablet or switching your alarm system on and off with just a fingertip. But it must also be considered, that these new systems bring along new threats. And since these systems directly connect the virtual world with our real life, the threats could have a real big impact.

Most of the security related smart home research focuses on the local communication area of smart home systems, where all the smart home devices communicate with the central base station. While in this area a lot of security shortcomings [2] [3] [4] [5] have already been identified by researchers, it is very important to also analyze the web area of smart home systems, where people communicate with the central smart home base station via their smartphone or web browser. As SEC Consult already showed in recent advisories, it is possible to take over control of a specific smart home system, simply by exploiting traditional web vulnerabilities and design flaws [6] [7]. Therefore, experts of the SEC Consult vulnerability lab examined this area for some other vendors in the scope of a limited security crash-test. This was done in cooperation with the leading German business newspaper WirtschaftsWoche.

Six products were tested in the context of this crash-test. Three of them, Gigaset Elements, RWE Smart Home und Qivicon, had already been tested before by WirtschaftsWoche in cooperation with AV-Test [8]. These products performed very well in the course of our crash-test. This indicates, that regular security audits really increase the level of application security. The new product of eQ-3, Homematic IP, also performed very well. While the previous product line had to deal with several weaknesses [4], the new product looks good at least at the perspective of a short crash-test within the web functionality.

Multiple vulnerabilities have been identified for the smart home solution of Digitalstrom. Traditional Cross-Site Scripting and Cross-Site Request Forgery attacks could be used to control arbitrary devices connected to the smart home system [9]. A further weakness was identified within the smartphone app of Devolo Home Control, which stores user credentials in plaintext on the phone. If the smartphone gets lost or stolen, the attacker can be able to steal the credentials and take over control of the system. [11]

Although the local communication area wasn’t in the scope of the conducted crash-test, it has to be mentioned that at least the protocols used by Digitalstrom and Devolo are not sufficiently protected. Digitalstrom’s communication is powerline based and according to the vendor it is unencrypted [12]. Its protection is completely dependent on physical isolation. Besides their own powerline protocol, Devolo also supports the radio-based protocol Z-Wave. The built-in Z-Wave chip of the tested room thermostat is an old model from the series 300 (ZW0301), which has no security features built-in. [13]

At a lower level, where it comes to firmware extraction, big differences between the vendors have been observed. The firmware forms the link between the software and the hardware of a device. It is very easy to extract the firmware of RWE devices. While other vendors at least make the hacker’s life a bit harder, it’s still possible with reasonable effort. Only Homematic IP devices implement different hardware-based security mechanisms.

After the extraction of a device’s firmware, it is possible to test it for further vulnerabilities. In the course of a quick check the usage of outdated software was identified for Gigaset, RWE and Devolo. Furthermore, there are publicly known vulnerabilities available for some of these outdated components. Although these vulnerabilities aren’t exploitable under the current circumstances, e.g. a certain change in the firmware-configuration would be sufficient to make the device of Devolo vulnerable to serious attacks. The basic problem here is the vendor’s insufficient security analysis of third party components. The firmware’s basis is bought from a third party but their security isn’t verified sufficiently.

Based on the conducted tests it is obvious that most of the vendors already raised their security level based on previous systematic security audits. However, if these audits are insufficient or missing, critical smart home systems still contain old and traditional web vulnerabilities.

This big difference in the security level of different smart home products is not visible for end-consumers, it could just be revealed by professional security audits. However, the question remains why vendors don’t invest in security audits sufficiently before they launch their products. The German interior minister Thomas de Maizière is already thinking about product liability and compensation regarding the digital carelessness of vendors. [14]

To sum it up, it can be stated that traditional (web-) vulnerabilities in smart home systems aren’t a thing of the past, but are still a real threat in modern and critical smart home systems.


[1] D. Schwarz, "The Current State of Security in Smart Home Systems - Threats in the Internet of Things", SEC Consult Vulnerability Lab, 2016
[2] B. Fouladi and S. Ghanoun, “Security Evaluation of the Z-Wave Wireless Protocol”, Black Hat USA, vol. 24, 2013.
[3] J. Cache, J. Wright, and V. Liu, "Hacking Exposed Wireless: Wireless Security Secrets & Solutions", The McGraw-Hill Companies, 2010.
[4] Sathya and Malli, "Attacking HomeMatic", CCC 30C3, 2013
[5] T. Zillner and S. Strobl, "ZigBee Exploited", Blackhat USA, 2015
[6] SEC Consult Vulnerability Lab, "Loxone Smart Home - Multiple Vulnerabilities", 2015
[7] SEC Consult Vulnerability Lab, "Loxone Smart Home - Multiple Vulnerabilities - Part 2", 2015
[8] T. Kuhn, "Sicherheitsrisiko Smart Home - Die Hacker kommen durch den Kühlschrank", WirtschaftsWoche, 2014
[9] SEC Consult Vulnerability Lab, "Multiple vulnerabilities in Digitalstrom Konfigurator", 2016
[10] OWASP, "OWASP Top Ten Project", 2013
[11] SEC Consult Vulnerability Lab, "Insecure credential storage in my devolo Android app", 2016
[12] digitalSTROM AG, "FAQ"
[13] C. Gomez and J. Paradells, “Wireless home automation networks: A survey of architectures and technologies”, IEEE Communications Magazine, vol. 48, no. 6, pp. 92–101, June 2010
[14] S. Krempl, "IT-Gipfel: Produkthaftung gegen die 'digitale Sorglosigkeit'", heise online, 2015