Wednesday, January 18, 2017

Last call to replace SHA-1 certificates

(c) iStock 629455088

All major browsers will stop accepting SHA-1 certificates in January/February. An average user will then not be able to distinguish between an invalid certificate (e.g. a certificate from an attacker) and a valid certificate that is using a SHA-1 hash. Effectively, this means that Internet services that still use SHA-1 certificates will become unusable for a large portion of users within the next few weeks.

Specifically, the following dates apply for the major browsers:

Browser vendors have provided ways to still use SHA-1 certificates issued by an internal CA (often used for e.g. an internal services like webmail). However, this is a temporary measure as e.g. Google Chrome will finally remove support for SHA-1 latest in 2019.

The following Censys query demonstrates, that there are still many TLS services world-wide that are affected by this. The query includes all HTTPS services with certificates that are a) not expired, b) that would otherwise be trusted by browsers and c) are signed using the SHA-1 hash algorithm:


Is this necessary?

By disabling the trust for SHA-1 certificates, browser vendors try to prevent a situation similar to what was happening in 2008. Well before 2008, is was commonly known that the MD5 hash algorithm exhibits serious weaknesses. Despite that fact, many certificate authorities issued MD5 certificates and major browsers accepted them. The attacks against MD5 have continuously improved over the years until in 2008, a group of researchers used the weaknesses in MD5 to successfully forge a certificate. Using this certificate, the researchers were able to issue arbitrary certificates for any service on the Internet. We know now that any criminal organisation that also conducted the same research and implemented a similar attack could have successfully intercepted arbitrary TLS connections (e.g. HTTPS) on the Internet.

There are many parallels between the situation then and the situation we now have with SHA-1. The first weaknesses in SHA-1 have been published in 2005. Since then, the attacks on weaknesses in SHA-1 have continuously been improved. In 2015 researchers estimated, that finding a collision in SHA-1 would cost between 75,000 $ and 120,000 $. A collision does not necessarily allow for a practical attack, being able to find a collision severely undermines the security of SHA-1. It is very hard to estimate how long it will take to be able to advance the current attacks to successfully forge a certificate. Moreover, it is possible that organisations outside of the academia already have knowledge of even more advanced attacks against SHA-1.

Therefore, it is necessary for browser vendors to disallow the use of SHA-1 certificates now, before we are in a situation similar to the situation in 2008. Google even goes so far as to warn against "the imminent possibility of attacks that could directly impact the integrity of the Web PKI".

The abandonment of the SHA-1 hash algorithm also affects code signing certificates. Although Windows code signing certificates with SHA-1 signatures can still be obtained, Certificate Authorities would probably be forced to revoke all SHA-1 certificates once a practical attack is known. This especially affects versions of Microsoft Windows that do not support any other hash algorithm for code signing (i.e. legacy Windows versions such as XP SP3, Windows Server 2008 and Windows Vista).


As a countermeasure we recommend to immediately replace affected certificates!

If the certificates are not replaced by 2017-02-14 (for IE11 / Edge at least, or even earlier for other browsers), a large portion of the users will not be able to access the affected services.

To test whether your Internet services are affected by this issue and other issues in the TLS configuration, SSLLabs provides a very useful tool that can be found here.

Tuesday, December 6, 2016

Backdoor in Sony IPELA Engine IP Cameras

SEC Consult has found a backdoor in Sony IPELA Engine IP Cameras, mainly used professionally by enterprises and authorities. This backdoor allows an attacker to run arbitrary code on the affected IP cameras. An attacker can use cameras to take a foothold in a network and launch further attacks, disrupt camera functionality, send manipulated images/video, add cameras into a Mirai-like botnet or to just simply spy on you. This vulnerability affects 80 different Sony camera models. Sony was informed by SEC Consult about the vulnerability and has since released updated firmware for the affected models.

Further information about the backdoor, disclosure timeline, affected devices and updated firmware can be found in our advisory. This blog post has some highlights from the vulnerability analysis.

This advisory is the result of research that started by uploading a recent firmware update file from a Sony camera into our cloud based firmware analysis system IoT Inspector.

After a few minutes the analysis results were available. One result immediately caught our attention:

Excerpt from IoT Inspector results

So here we have two password hashes, one is for the user admin and was cracked immediately. The password is admin. This is no surprise as the default login credentials are admin:admin.

The second password hash is much more interesting, it’s for the user root and it was found in two different files: /etc/init.d/SXX_directory and /usr/local/lib/

We can use the file system browser of IoT Inspector to have a look at the SXX_directory.

Excerpt from IoT Inspector filesystem browser

It looks like this startup script (called by /sbin/init/rcS during boot) is responsible for creating and populating the file /tmp/etc/passwd (/etc/passwd is a symlink to this file). A line for the user including a password hash is added, the shell is /bin/sh. Not good!

So, what can we do if we can crack the hash? At this point we can assume that it's very likely we can login using UART pins on the PCB. This of course requires us to have physical access and to disassemble the device.

The other locations where we could possibly use the password are Telnet and SSH, but both services are not available on the device … or are they? A quick string search in the firmware's filesystem for “telnet” shows that a CGI binary called prima-factory.cgi contains this string a few times. IDA Pro to the rescue! It seems this CGI has the power to do something with Telnet:

The code in g5::cgifactory::factorySetTelnet() (in decompiled form below) is pretty straight forward. Based on input, the inetd daemon is killed or started:

The inetd daemon gets its configuration from /etc/inetd.conf and inetd.conf is set up to launch Telnet

So how can we reach this CGI functionality? The answer lies in the lighttpd binary. Lighttpd is an open source web server that was modified by Sony. Some custom code for HTTP request handling and authentication was added. Below is an excerpt from a data structure that maps the URI /command/prima-factory.cgi to the CGI in the file system. The authentication function is HandleFactory.

HandleFactory decodes the HTTP Basic Authentication header and compares it to the username/password primana:primana.

Now we have all ingredients to craft an attack that looks like this:

  1. Send HTTP requests to /command/prima-factory.cgi containing the “secret” request values cPoq2fi4cFk and zKw2hEr9 and use primana:primana for HTTP authentication. This starts the Telnet service on the device.
  2. Login using the cracked root credentials via Telnet. Note: We have not cracked the root password, but it's only a matter of time until someone will.

The user primana has access to other functionality intended for device testing or factory calibration(?). There is another user named debug with the password popeyeConnection that has access to other CGI functionality we didn't analyze further.

We believe that this backdoor was introduced by Sony developers on purpose (maybe as a way to debug the device during development or factory functional testing) and not an "unauthorized third party" like in other cases (e.g. the Juniper ScreenOS Backdoor, CVE-2015-7755).

We have asked Sony some questions regarding the nature of the backdoor, intended purpose, when it was introduced and how it was fixed, but they did not answer.

For further information regarding affected devices and patched firmware, see our advisoryIoT Inspector now comes with a plugin that detects this vulnerability.

Wednesday, November 30, 2016

SEC Business Breakfast: “Nothing works without data processing!”

8 Things to Know About the GDPR

Deutsche Zusammenfassung unten.

Brace yourselves, the EU general data protection regulation (GDPR) is coming. 

And companies only have around 500 days left to prepare all of the necessary data security and data privacy measures. Enough time? Just, if you start right away with an own project, said SEC Consult General Manager Markus Robin and data privacy expert Dr. Rainer Knyrim at the SEC Consult Business Breakfast on November 16, 2016 in Vienna. Both experts explained, what to know about the new regulation and which steps to take, to be “data-ready” when the law comes into force with May 2018.

Around 50 guests out of economy, finance and public service joined the SEC Business Breakfast to inform themselves about the upcoming EU general data protection regulation. Sooner, heavier and more serious than expected was the audience tenor. Companies must meet organizational and technical protection measures in the areas of privacy and data security - proven and documented. While the topic is complicated and by far more complex than two hours could ever bear (we still tried to in one previous blogpost), Markus Robin as well as Dr. Rainer Knyrim broke down the most important things to know: 

1. No one is excepted

No matter which sector, size or state – if data from EU-citizens are processed, companies will fall under the legal specifications of the GDPR. Even considering employee data. Important is to categorize all of the data for an overview and a meaningful risk analysis.

2. Two year realisation period

The EU general data-protection-regulation is part of the EU data privacy reform and came into force on May 24, 2016. In exactly two years or better said May 25, 2018 all affected companies and their applications need to prove and document organizational and technical protection measures regarding personal data.

3. Special categories of data – we all have them

By definition, sensitive data occur when facts about religion, health, sexuality or other very personal information are stored. So even if you’re not a health institute, you probably still collect data from your employee’s sick leaves, making it already sensitive data in your company.

4. From 10k to 10 Million Euro

If 10k didn’t hurt, probably 10 Million Euro will do. The penalty for not fulfilling the necessary measures will be determined by the realised preparations, but however can lead up to 20 Million Euro or four percent of the prior-year-sales. With that, the new penalty height is no joke and corresponds to several annual IT-budgets.

5. Policies and Compliance for service providers

Companies need to make sure, that their whole service chain follows the rules of the data-protection-regulation. Current and coming supplier contracts must be based on own data processing contracts – otherwise it could lead to complicity in case of abuse or lost proposals.

6. Workshops, Workshops, Workshops

The best security measures won’t be enough, if employees are not sensitized for data privacy and security. Regular workshops can help to prevent data leaks or abuse caused by unawareness / human error. Because “fake president frauds” and other easily done phishing mails alone offer enough space for crucial mistakes.

7. Everything must be documented

“Yeah, we’ve done everything we could” won’t be enough when it comes to prove all of the preparations a company took in regard to the GDPR. Everything should be documented – spreadsheets, data directories or, for example, even lists of the time and date of penetration tests, employee trainings or information mailings.

8. Sampling inspections are already held

Bad news for companies, who still believe that there is enough time left: Responsible authorities already started with sampling inspections. Of course, penalties are currently very low, but early preparations could provide examined companies with a good standing in front of state officials.

Given the short realisation period of now a mere 500 days, Markus Robin and Dr. Rainer Knyrim recommend: 

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.

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", Dr. Knyrim advices. SEC Consult itself works closely with lawyers and offers comprehensive consultation next to informative risk analysis as well as implementation of security measures.

Join the next SEC Business Breakfast to be updated about cyber security issues and 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 recommendation from security experts.


SEC Business Breakfast: "Nichts funktioniert ohne Datenverarbeitung!"

Bereitet euch vor, die EU-Datenschutz-Grundverordnung (EU-DS-GVO) kommt.

Und Unternehmen bleiben nur noch rund 500 Tage, um die notwendigen Datenschutz- und Datensicherheits-Maßnahmen umzusetzen. Genug Zeit? Nur, wenn man gleich damit anfängt und dafür ein eigenes Projekt ins Leben ruft, meinen SEC Consult General Manager Markus Robin und Datenschutzexperte Dr. Rainer Knyrim. Im Rahmen des SEC Consult Business Breakfast am 16. November in Wien erklärten die beiden Experten in wenigen Schritten, was es über die neue Verordnung zu wissen gibt und was es braucht, um mit Inkrafttreten des Gesetzes im April 2018 „data-fit“ zu sein.

Weitere Infos zur EU-DS-GVO finden Sie hier.

Nutzen Sie die Gelegenheit um mehr über aktuelle, sicherheitsrelevante Themen zu erfahren und sich mit unseren Experten vor Ort auszutauschen. MELDEN SIE SICH JEZT AN

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.”


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 (, 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(' = "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 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 ( and, 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 "" 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.