Black Hat USA 2015 – part 1

Black Hat USA is the most famous IT security conference in the world that every year congregate thousands of security experts and interested to Las Vegas. For its 18th year the conference took place in the glamorous Mandalay Bay Conference Center in Las Vegas. And as every year, two security analysts of Compass Security have attended the conference to learn about the latest trends in IT security.

Mandalay Bay Resort & Casino

For the first part of the post we have chosen two talks concerning web security that show elegant techniques for a penetration tester or attacks on new frameworks. We encourage you not only to read this summary but also to go online and take a closer look at the videos or the slides. We aimed at giving you all the relevant links for each talk.

FileCry XXE

Presented by Xiaoran Wang & Sergey Gorbaty – slideswhitepapervideo

External Entity Attacks (short XXE) is not a new attack vector and the possibilities to exploit these have been already studied by many researchers.

In a nutshell, XML allows inclusion of external resources and the parser will include these automatically. This type of attacks was mostly seen as a server side vulnerability to achieve server side resource inclusions and potentially arbitrary command executions. The two researchers of Salesforce presented a very elegant attack that exploits XXE on client side bypassing the Same Origin Policy.

Many libraries in the past were affected by XXE, so also the Microsoft library MSXML3.0. This library is deprecated and replaced by the non-vulnerable MSXML6.0 library. However, it is still available in older version of IE, for example IE 6. In IE it is possible to force the browser to switch to compatibility mode. By just putting the meta tag <meta content=”IE=6″ http-equiv=”X-UA-Compatible”> in a web page the browser is forced to switch mode and loads also the dll of the deprecated library. Afterwards, the deprecated library can be used, as showed in this short code snippet:

xmlDoc = createDocumentFromText(text,"3.0",null);

The next step was to think about a method to bypass the SOP. The parser uses the browser engine as a resolver for external entities in order to enforce SOP. A redirection handler on the attacker controlled site was introduced that made a redirection to the external entity. IE only checks SOP for the initial request but does not enforce SOP in the case of a redirection.

With this method it was possible not only to bypass SOP but also to read out arbitrary files on the filesystem of a victim visiting the hacker website. There are some limitations in the attack: First the content of the file read should not contain characters like \x00, &, %. Therefore, most of the html pages cannot be retrieved with this method. Second, in order to retrieve files on the filesystem, the exact filename and path should be known to the attacker. Here the list provided by the researchers:

  • victim file/site cannot contain null-byte
  • most HTML pages are not vulnerable
  • the first few hundred characters are vulnerable
  • JSON pages are vulnerable
  • binary files are not vulnerable
  • works only on Windows 7 and below
  • all IE versions though

The patch for this vulnerability was released by Microsoft on April 2015 therefore, if you have patched your system, you should be safe.

Server-Side Template Injection: RCE for the modern webapp

Presented by James Kettle – whitepaper – video

Template engines are nowadays popular frameworks to represent dynamic data via web pages. If unsafely used, application could be misused to perform server side template injections. This talk focused on how to detect such vulnerabilities and determine which template engine is used. In case of a template injection the consequences could be fatal: remote code executions can be achieved, turning every vulnerable application into a potential pivot point.

The speaker presented a very well structured approach on how a penetration tester can analyze an application to find such flaws. The first step would be detect a template injection. This is in general the most difficult step. This vulnerability can appear in two distinct contexts, a plaintext and a code context.

For example sending the request {7*7} and receiving 49 in the response could be an indicator for a plaintext context template injection. In most of the cases where a plaintext context template injection is present, it is also possible to find a XSS vulnerability. Otherwise, with a code context template injection, XSS is in general not possible. But it is possible to inject HTML tags, for example by sending }}<tag>.

After having detected the vulnerability, the second step is to determine the template engine in use. If it is not possible to find it out by inspecting error messages or server banners, a penetration tester can send different payloads to evaluate differences in the response. The speaker showed a very useful diagram to accelerate this task:


Afterwards, the possibilities to exploits such a vulnerability are infinite. For example, with the FreeMarker template we can send the following payload to extract the user running the service:

<#assign ex="freemarker.template.utility.Execute"?new()> ${ ex("id") }

As one can directly see, the consequences of having such a vulnerability in his own web page would be terrible. However, during the presentation, the speaker didn’t explain in depth how such a flaw would arise. The developer has to completely misunderstand the usage of a template to make such error occur. This could happen if template code is not loaded statically from the filesystem but created dynamically with some input taken from the user. Or it could occur through the intentional exposure of template markdown in an attempt to offer rich functionality to the end-user.


Compass Security at CYBSEC15 in Yverdon-les-Bains


As in past years, Compass Security will participate in the upcoming CyberSec Conference in Yverdon-les-Bains (formerly Application Security Forum – Western Switzerland). This year, we will contribute in two events:

First, Antoine Neuenschwander and Alexandre Herzog will conduct a day long training session on Tuesday, November 3rd. Participants will be able to exercise their skills and learn with step-by-step instructions on how to exploit vulnerable web applications at their own pace and with the support of the trainers within the CTF environment.

ivanoSecond, Ivano Somaini will share his practical experience of physically breaking into banks and other critical infrastructures in his talk “Social Engineering: The devil is in the details” on Wednesday, November 4th. Ivano looks forward to his first talk in the French speaking part of Switzerland. He was lately a lot in the news in the Swiss Italian and German part of Switzerland, due to his extensive interviews to Coop Cooperazione (in Italian), to the Tages Anzeiger (in German), and his participation to popular talkshow “Aeschbacher” on Swiss television SRF1 (video of the interview).

We are looking forward to meeting you at this occasion, either during the Castle evening networking event, the workshop or the conferences!

Aftermath of the Netgear Advisory Disclosure

Update – 13.10.2015: Netgear published a new firmware (version which fixes the reported authentication bypass.

My most recently appointed colleague, Daniel Haake, described in the previous blog article “Authentication Bypass in Netgear WNR1000v4 Router” how he found an authentication bypass in commonly used Netgear firmwares. Due to the rediscovery of the issue and its public disclosure, we decided to go public despite the fact Netgear did not yet release a fix for the identified security hole.

Shortly after the release of the Compass advisory on public mailing list Bugtraq, we were contacted by Joe Giron, who experienced troubles with his Internet connection around September 27th. On September 28th, Joe noticed that his Netgear router’s primary DNS server had been set to point to a non-standard DNS server. This timeframe means that attackers were active before the release of Shellshock Lab’s blog article (which is detailing the same vulnerability). Joe mentioned that the remote administration interface of his Netgear router was accessible via the Internet, but protected by a strong password. He therefore had high suspicions that he fell victim of an attack against an unpatched vulnerability in his router. The release of our advisory was the confirmation and technical explanation of it.

The IP of the rogue DNS server set in his router did not only expose a DNS service, but also a web server. This web server served various PHP scripts, log files and text files. The logs contained over 17’000 entries of presumably hacked routers, including their IP address, username and password of their administration interfaces. A further analysis of this list would identify more than 11’000 unique routers.


As we discovered that this authentication bypass was being exploited in the wild and that over 10’000 users were affected, we contacted Switzerland’s CERT for further help. GovCERT was very helpful and took over the case by

  • Attempting to contact Netgear again to urge them to release the patch
  • Analyzing the logs of the web server and identifying the victims
  • Taking down the command and control server to avoid further infections
  • Liaising with GovCERT’s partners worldwide to notify the Internet service providers of the victims

In the meantime, the media got interested in the advisory and Threatpost published yesterday evening an article about the flaw and its follow-up. A second person reached out to us after the publication of this article, describing the same infection vector as well as the same IP address for the DNS and C&C server. We are currently in contact with other media outlets and will update this section when further articles are released.

The debate between responsible- and full disclosure is endless and both approaches have their pro- and cons. At Compass Security, we attempt to get the best balance between these two approaches. We are confident that our approach of leaving some time for the vendor to patch the vulnerability before publicly disclosing the issue in case of no adequate response was the best. Public information has proven to work and helped identifying ongoing attacks. Coordination with the relevant authorities allowed coordinated action against the attackers and will hopefully help the victims of this hack.

Media Update, 11.10.2015:

Media Update, 12.10.2015:

Authentication Bypass in Netgear WNR1000v4 Router

Three months ago I tested the web interface of the Netgear WNR1000v4 router for some typical vulnerabilities. When playing around with the application by forcefully calling different URLs in contexts it was not meant for, I got some strange, but interesting behaviour.

I accessed different URLs and then switched back to the root web directory to have a look at some web application feature. At this moment I realized that I did not have to submit any credentials to access the administration interface. It seemed that the whole HTTP authentication process was not active anymore and I remembered that I definitely did not log in because I wanted to test the password reset feature. This was really strange, so I logged out and had a look at my Burp request history to determine which resource triggered this behaviour.

After some tests I realized that the resource /BRS_netgear_success.html is the problem. If you are not authenticated and call the URL several times the HTTP Basic Authentication temporary gets deactivated and you can access the administration interface without username and password [1].

This works because the “password deactivation feature” is used when you first plugin the router to configure some settings the first time.

I tested this vulnerability on the WNR1000v4 Netgear router with the following firmware versions:

Because this firmware is used for multiple devices, other devices are probably affected as well. This page references a list of devices which are very likely to be impacted [2]:

  • JNR1010v2
  • JWNR2000v5
  • JWNR2010v5
  • WNR614
  • WNR618
  • WNR1000v4
  • WNR2020
  • WNR2020v2

After the discovery I contacted Netgear through different channels to find a way for responsible disclosure. Unfortunately Netgear was not very responsive and it took a longer time until they responded. After about 2 months they sent me an undisclosed security fix which solves the problem. Netgear twice refused to respond to our request for a patched firmware release date. In the meantime, the issue was rediscovered and publically disclosed by another researcher [4]. This public disclosure prompted us to release our advisory to the public on October 6th.

In this case not the end of the story, but just the trigger of further events detailed in follow-up post “Aftermath of the Netgear Advisory Disclosure”.