Excuse me, where is the best site of the city? After the DOM, just turn right!

During a SharePoint 2013 penetration test I performed last November, I noticed that a dynamically constructed JavaScript constantly fetched content or redirected me to the requested pages.
Using a variation of the double-slash trick we exploited in the past, I misused this functionality in order to perform a DOM based open redirection attack. Every SharePoint 2013 server is vulnerable, as the weakness is within a component accessible anonymously even when sites are restricted to authenticated users only.

This vulnerability enables an attacker to create a malicious link, which is sent i.e. via e-mail to his target. When the victim clicks on the link, the malformed JavaScript is executed and redirects the victim to a third party site. i.e www.hacking-lab.com. This attack leaves no audit trail in the server’s log and cannot be blocked by a Web Application Firewall as the payload is executed and stays exclusively in the client’s browser. As a pentester, but especially as a social engineer, this is exactly the technical vulnerability that I’m always looking for in order to perform very effective phishing attacks abusing a trustworthy domain.

Before uncovering more technical details about the issue, we want to ensure everyone had enough time to patch their SharePoint servers adequately. While Microsoft estimated that an anonymous and by default enabled DOM based open redirect in SharePoint 2013 was not severe enough for the release of a dedicated security bulletin, they committed themselves to fix it in a product update. Update KB3054867 fixes the issue and is available since June on Microsoft’s Download Center. While the page doesn’t mention any security updates, we strongly encourage you to test and install the patch across all your SharePoint 2013 servers. Microsoft acknowledged my contribution on its page “Security Researcher Acknowledgments for Microsoft Online Services” of August 2015. Further technical details will be released after a grace period of 2 months, to leave enough time to everyone to patch the issue.

Hacklab Q2 – NoSQL mischief

At our reoccurring Hacklab days, we at Compass get the chance to hack some stuff of our own choice together for a day. For example playing with GSM in an attempt to send fake SMS or eavesdrop on voice data, comparing Encase capabilities to Unix command line forensic tools or cloning door entry badges in an attempt to gain unauthorized access to buildings or elevators.

During the Hacklab I gathered a few colleagues to create “team NoSQL” and toyed around with some of the example applications. Our project was based on a VM with several instances of “state of the art” web technologies, most of them involving a NoSQL database.

As a first task we performed a NoSQL injection on a self-developed PHP frontend with a MongoDB backend, as discussed in Hacking NodeJS and MongoDB. Additionally we wrote a python script which extracts cleartext password from the MongoDB with a binary search algorithm using the same vulnerability.

We also spent some time analyzing and exploiting race conditions in web applications, as for example described in Race Conditions on Facebook  and Hacking Starbucks for unlimited coffee. Using just the Linux command line, it was possible to generate arbitrary amount of money in a mockup Bitcoin website by sending a large amount of HTTP requests in parallel.

The slides of our presentation and the MongoDB bruteforcer script can be downloaded here:

XSLT Security and Server Side Request Forgery

Nowadays, a growing list of XSLT processors exist with the purpose of transforming XML documents to other formats such as PDF, HTML or SVG. To this end such processors typically offer a powerful set of functionalities – which, from a security point of view, can potentially pose severe risks.

Within this post, we highlight some of the threats one gets exposed when operating a misconfigured XSLT processor. The goal here is to increase people’s awareness when configuring modern XSLT processors.

Tested XSLT Processors

The subsequent table lists the XSLT processors investigated in our tests.

XSLT Processor Manufacturer License Windows Version Linux Version
libxslt Gnome Project MIT License 1.1.26 1.1.28
Saxon-HE Saxonica Limited Mozilla Public License V1.0
Saxon-EE Saxonica Limited Mozilla Public License V1.0
Xalan-J Apache Software Foundation Apache License V2.0 2.7.1 2.7.2
Xalan-C Apache Software Foundation Apache License V2.0 1.11 1.11
MSXML 4.0 Microsoft Proprietary 4.0 SP3
MSXML 6.0 Microsoft Proprietary SP2 (File Version 6.20.1099)
.NET System.xml Microsoft Proprietary 4.0.30319


We divided the security threats exposed by the XSLT processors into six categories:

  1. Information Disclosure
  2. Read Files
  3. Write Files
  4. Database Access
  5. Include External Stylesheet
  6. Code Execution

The results are summarized in following figure:

XSLT Vulnerabilities

Vulnerability Overview of Tested XSLT Processors

The above results clearly show that the great functionality of modern XSLT processors comes with a tremendous downside: If used in their default configuration, or otherwise not properly configured, XSLT processors can endanger confidentiality and integrity on XSLT servers or allow the execution of arbitrary code. Even worse, the vulnerable XSLT server might be abused to forge attacks against remote third parties, such as for instance performing anonymous port scans (see example below).

Example: Server Side Port Scanning Forgery

Here, we give a short example of how to misuse the document() function (used to access external XML documents) on a remote XSLT server to forge port scanning against an external third party. In the example, the investigated third party is located on host “example.com“, and tested against port 22 (SSH).

The attacker “Mallory“, trying to learn whether or not port 22 on “example.com” is open or closed, submits the following XSL file to a server “Alice” running a vulnerable XSLT processor.

XSLT Portscan

Port Scanning XSL File

Next, “Alice” processes the XSL file submitted by “Mallory” and as consequence tries to access the external XML resource located on “example.com“. Dependent on whether or not port 22 is open on “example.com“, a different response is sent back to “Alice“, who finally forwards the result to “Mallory“. Since the result “Mallory” receives is different for open/closed ports, she can learn the port state on “example.com“. Note that in this way “Mallory” has performed the port scan anonymously, since the only party speaking to “example.com” was “Alice“.

For the sample processor libxslt in our test set, the response received by “Mallory” might look like shown below:

Port State Response
Port Open parser error : Document is empty
Port Close (Timeout) Operation in progress I/O warning
Invalid Host No such file or directory I/O warning

In summary, “Mallory” was able to forge a port scanning request from “Alice” against “example.com“.


This blog post is based on a Seminar paper (XSLT Processing Security and Server Side Request Forgeries) written by Emanuel Duss and Roland Bischofberger, in collaboration with Compass Security Schweiz AG:

E. Duss and R. Bischofberger. “XSLT Processing Security and Server Side Request Forgeries: Analyse, Demonstration und Gegenmassnahmen“. Seminar Paper, Hochschule für Technik Rapperswil, Autumn 2014

Further Readings

Aktuelle Security Trainings

Web Application Security Training

Die Compass Security hat im Moment im Bereich Web Security zwei Kurse ausgeschrieben. Ein Basic und ein Advanced. Unsere öffentlichen Kurse dauern jeweils 2-Tage und bestehen zur Hälfte aus praktischen Beispielen (Hands-On Lab) und zur anderen Hälfte aus Theorie. Wobei die Doing-Aufgaben in der
Regel eine Schritt-für-Schritt Anleitung sind.

Der Hacker-Angriff erfolgt zunehmend über den Browser auf Web Anwendungen. Durch die grosse Verbreitung der Web Technologie steigt der Bedarf für Sicherheit und die sichere Programmierung. Das Thema beschäftigt nicht nur E-Banking und Online Trading Anbieter, sondern auch Shops mit Kreditkarten Zahlungen, eHealth, eVoting und Anwendungen mit schützenswerten Daten. Bei diesen Seminaren erlernen Sie anhand von Theorie und praktischen Laborübungen im Hacking-Lab die OWASP TOP 10 kennen und können im Anschluss selbst Sicherheitsprobleme aufdecken, sichere Anwendungen schreiben und Security Policies verfassen.

Web Application Security Basic, 03. und 04. März 2015 in Bern (Schweiz)


Web Application Security Advanced, 05. und 06. März 2015 in Bern (Schweiz)


Die Inhalte der Kurse können wir beliebig zusammenstellen. Weitere Themen, die im Moment nicht ausgeschrieben sind, wären:

  • DOM Injections (mittlerweile eine prominente Art von XSS)
  • AngularJS Security
  • OAuth 2
  • OpenID
  • XSLT

Secure Mobile Apps, 23. und 24. März 2015 in Bern (Schweiz)

Mit der wachsenden Verbreitung von mobilen Geräten stehen diese zunehmend im Fokus von Cyber Kriminellen. Mit einem guten App Design und der richtigen Nutzung der Hersteller API sind gute und sichere Lösungen möglich! Doch wo befinden sich die typischen Sicherheitslücken? Die Compass Security AG hat eine verwundbare Training Mobile App für Android und iOS entwickelt, um die Kursteilnehmer anhand von praktischen Beispielen in das Thema „Mobile Secure App“ einzuführen und sie für Self-Assessments und Sicherheitsfragen zu sensibilisieren.

Weitere Informationen sind unter http://www.csnc.ch/de/securitytraining/secure_mobile_apps_201503_bern.html vorhanden.

Falls Sie keinen passenden Kurs gefunden haben, schauen Sie doch in Zukunft unter http://www.csnc.ch/de/securitytraining/ vorbei. Compass Security bietet regelmässig neue Trainings an.

Presentation at BSidesVienna

On the last Saturday the 22nd of November, I attended BSidesVienna 2014 to deliver a talk about BurpSentinel. This tool is a Burp Suite extension giving better control over semi-automated requests sent to a given web application page. The presentation also covered aspects on automated Cross-Site Scripting and SQL injection detection. Despite talking early in the day (10 am), the room was pretty crowded a few minutes into the presentation, and the attendees quite interested.


The location of BSidesVienna, an old cinema, was awesome and located right in the middle of Vienna, close to the Art district. Noteworthy is that all drinks, food and t-shirts were completely free, which is impressive for a free event! Other presentations covered e.g. the (in)security of fitness trackers, Android malware analysis or the comparison between the Manhattan project and the Snowden revelations. The slides will be available on the website soon.

Finally, I want to thank the organizers for the cool event, and Compass Security AG to sponsor the trip to Vienna.

Slides of the presentation:

Keep your secrets really secret

Nowadays, we all relentlessly use search engines and developers extensively use version and source code control systems to keep track of their source code. Services such as Google or GitHub are great to search and retrieve information they gathered and stored. But when it comes to public indexing services, one big problem raises up: your whole repository, your code and your configuration files are by default also uploaded – in sight to everyone. Therefore, sensitive data such as license keys, passwords or cryptographic key material becomes available with simple web searches.

Different sensitive information was leaked due to improper use of such version controls or improper handling of sensitive configuration files in the past. A recent story published in October 2014 by “Krebs on Security” demonstrates that very well.

So while I was recently reading a PowerShell blog post on “Hey Scripting Guy” about the .publishsettings file for Microsoft Azure access, I immediately thought of a nice GitHub search to find all these files. As with other sensitive files (e.g. private key files), people doesn’t care much about the confidentially of such files.

This .publishsettings file includes a certificate and sometimes also clear text FTP credentials for accessing Microsoft Azure repositories. Within a Microsoft Azure article, Microsoft highlighted the importance of removing this file:

We recommend that you delete the publishing profile that you downloaded using Get-AzurePublishSettingsFile after you import those settings.
Because the management certificate includes security credentials, it should not be accessed by unauthorized users.

The article “Download and Import Publish Settings and Subscription Information for Azure” describes the file structure:

<?xml version="1.0" encoding="utf-8"?>

Searching for this configuration file within Google or GitHub returns multiple entries:


Google search for the site GitHub and the file .publishsettings:


Google search for the site GitHub and the file .publishsettings:


Other interesting GitHub searches…

Private keys
Search for private keys within GitHub:


PHP wrapper
Search for PHP wrapper within GitHub:


With this search for PHP wrappers we would find something like:

$user = "doXXXon";
$password = "pfXXXXOS";
$connection = ssh2_connect([CUTBYCOMPASS], 22);

ASP.NET machine keys
Search for machine keys within ASP.NET application configuration files.


<!--?xml version="1.0" encoding="utf-8"?-->
 <machineKey decryptionKey="Decryption key goes here,IsolateApps" 
             validationKey="Validation key goes here,IsolateApps" />



Never include your configuration files and other sensitive information within a public repository like GitHub and keep in mind that any public information will eventually get indexed by search engines. As a developer, refrain from pushing unknown files, as they might have unexpected sensitive content and as system administrator, keep an eye on the directory and file permissions of your web servers to not accidentally expose sensitive files. Exhaustive lists of other Google searches (also called “Google Dorks) can be found in this infosec institute post or in the dedicated part for dorks on exploit-db.com.

Feel free to comment below to share your preferred other search queries!

Thanks to Philipp Promeuschel, Ivan Bütler and Alexandre Herzog for some additional queries.


Security Advisories for SAP BusinessObjects Explorer and neuroML

Compass Security employees identify and report on a regular basis security vulnerabilities as part of their daily assessments (or just out curiosity).

Stefan Horlacher identified and reported back in June 2013 several flaws in SAP BusinessObjects Explorer. We’re happy to publish today the details as the flaws have been patched and a reasonable grace period given for their deployment:

Note that both the port scan as well as the XML External Entity (XXE) attack can be conducted anonymously without prior insider knowledge.

Philipp Promeuschel on his part identified multiple vulnerabilities in neuroML version 1.8.1 in May this year. The related advisory covers a wide range of vulnerabilities allowing a full compromise of the application:

Disabling Viewstate’s MAC: why you deserve having now a broken ASP.NET web application

Lots of things happened since my first (and unique) blog post about ASP.NET Viewstate and its related weakness. This blog post will not yet disclose all the details or contain tools to exploit applications, but give some ideas why it’s really mandatory to both correct your web applications and install the ASP.NET patch.

Back in September 2012 I reported an issue in the ASP.NET framework which could be used to potentially execute remote code in a typical SharePoint installation. Microsoft patched its flagship products SharePoint and Outlook Web Access. They also released guidance in security advisory 2905247 which contained an optional patch to download, removing the ASP.NET framework’s ability to alter setting “EnableViewStateMac”. It was also made clear that Microsoft will forbid this setting in upcoming ASP.NET versions. ASP.NET version 4.5.2, released in May 2014, was the first version of ASP.NET to have this setting disabled. Microsoft released as part of this month’s Patch Tuesday a patch to remove support for setting EnableViewStateMac for all ASP.NET versions.

While this patch may break ASP.NET applications, remember that without this patch you’re vulnerable to a much bigger threat. Fixing the web application is in the very vast majority of the cases easy from a technical perspective (e.g. set up dedicated machine keys within a given web farm). But as pointed out in the ASP.NET article, the management and distribution of these machine keys must follow a strict process to avoid being disclosed to unwanted parties. Think of machine keys being an essential element of your application. If these keys have ever been disclosed, you have to change them immediately. Ensure software purchased or downloaded from the Internet does not contain pre-defined keys in the application’s web.config.

If you want to know more but missed my Area41 talk about this flaw, come over to the AppSec Forum Western Switzerland on November 4th to 6th in Yverdon-les-Bains . I will be presenting an updated version of my “Why .NET needs MACs and other serial(-ization) tales” talk about the underlying flaws, their history and how to exploit them.

Advisories regarding Leed and Secure Entry Server (SES)

Today I’m happy to release the following security advisories:

I would take the opportunity to thanks Valentin CARRUESCO aka Idleman for the timely patches he implemented within Leed.

Of further interest is the vulnerability which affected the SES as it was due to a common mistake made when validating URLs. Let’s illustrate the issue with another occurrence of the same flaw, which affected LinkedIn and was reported back in November 2012.

Back then, attempts to visit a page reserved to LinkedIn members only triggered a redirect to the following login page:


Variable session_redirect was used to keep track of the initially desired page. Once successfully logged in, the web application would redirect us straight to this page using the following AJAX response:


Attempts to misuse this mechanism and inject a full URL in parameter session_redirect (e.g. session_redirect=https:%2F%2Fwww.csnc.ch) would fail, presumably because the developers ensured that the first character of value session_redirect had to be a slash (or its URL-encoded hex value %2F).

But what about partial URL //www.csnc.ch? Based on the aforementioned logic, such an URL would be considered as safe by the code, as it starts with a slash. But modern browsers don’t interpret a redirection to //www.csnc.ch as being http(s)://[victim]//www.csnc.ch, but in fact as a redirection to http(s)://www.csnc.ch. This behaviour is RFC conform and commonly used over the Internet to embed resources regardless of the URL scheme (http if the initial page was called over http, https if called over https).

Was it possible to abuse LinkedIn and the SES with such a trick? Yes, here’s an illustration of it:

Attempt to login on LinkedIn using forged URL (note the double slash – %2F%2F) https://www.linkedin.com/uas/login?session_redirect=%2F%2Ftest%2Fphishing.html

2013-12-04 12_52_00-Clipboard

Pressing button “Sign In” would submit the entered credentials. An extract of the AJAX response is shown below:

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
[removed various Set-Cookies directives]
X-LI-UUID: B[base64_stuff]nsg==
[removed various Set-Cookies directives]
Pragma: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Cache-Control: no-cache
Cache-Control: no-store
Vary: Accept-Encoding
Content-Type: application/json;charset=UTF-8
Content-Language: en-US
Date: Sat, 10 Nov 2012 11:45:45 GMT
Age: 1
Connection: keep-alive
Content-Length: 52


The browser would then interpret this redirection as being meant for [scheme]://test/phishing.html and perform the according request as seen below:

GET /phishing.html HTTP/1.1
Host: test
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20100101 Firefox/16.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Referer: https://www.linkedin.com/uas/login?session_redirect=%2F%2Ftest%2Fphishing.html

2013-12-17 11_58_10-Clipboard

The issue was reported to LinkedIn in November 2012 and fixed without further acknowledgement.

As a conclusion, do not assume that a partial URL value starting with a slash will always represent a path on your website. It may as well be a valid URL representation pointing to another domain. Furthermore, always perform redirections using a full qualified domain name and don’t just rely on a partial URL representation.

ASFWS slides and OWASP meeting tomorrow

As announced a while ago, I had the chance to organize both a workshop about our hacking-lab.com and present my talk “Advances in secure (ASP).NET development – break the hackers’ spirit” at the AppSec Forum Western Switzerland in Yverdon-les-Bains last week. I hope to soon summarize the conferences I attended in an upcoming blog article.

In the meantime, the Swiss French television RTS was part of the workshop and did a reportage aired during the 12:45 Téléjournal:


As the slides are not yet published by the conference, you can already download them from this blog:

For those interested in seeing my talk live, join us tomorrow evening at 18:00 for the OWASP Zürich meeting. Registration is required and further details are available on http://lists.owasp.org/pipermail/owasp-switzerland/2013-October/000257.html.