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 – slides – whitepaper – video

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);
xmlDoc.loadXML(text);

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:

payloads

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.

References: