Wrap-up: Hack-Lab 2017#1

What is a Hack-Lab?

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

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

   

Topics

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

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

Wrap-Up

Topic #1 – SharePoint Security Lab and Knowledge Sharing

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

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

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

TECHNOLOGY:

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

Topic #2 – Bypassing Android 7.0 HTTPS Apps Certificates Restriction

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

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

Technology:

  • Android Studio
  • Android 7.0
  • Apktool

Topic #3 – JWT4B

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

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

Technology:

  • Java
  • JJWT (library)
  • JWT

Topic #4 – CodeInspect

Evaluation of CodeInspect’s features.

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

Technology:

  • Java
  • Android

Topic #5 – Smart Meter

Description:

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

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

Technology:

  • TCP/IP
  • Modbus
  • HTTP Web Application

Topic #6 – DNS Tunnel Debugging

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

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

Technology:

  • C++

IoT (in)security

Quote

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

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

Mirai

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

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

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

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

Standardization and governing body pressure

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

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

Secure development and the OWASP angle

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

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

Compass IoT challenge for European Cyberstorm

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

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

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

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

So what do you need to consider, to go from

Schema Compass bIOTech v1.0

design

to

Versuchsaufbau Compass bIOTech v1.0

prototyping

to source code to

dsc_0030

ready device

?

What to consider when designing IoT devices

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

layout-v0-03

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

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

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

References

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

Blackout: Wenn Hacker den Strom abschalten

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

blackout

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

Wer ist Compass Security

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

Vorgehen bei einem Hacker Angriff

Direkte Angriffe

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

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

Indirekte Angriffe

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

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

Indirekte Angriffe

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

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

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

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

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

Sechs Tipps zur Abwehr

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

Wie kann Compass Security Ihre Firma unterstützen?

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

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

Referenzen

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