Thursday, July 13, 2017

Reverse Engineering Hardware of Embedded Devices: From China to the World

This article covers some basic hardware reverse engineering techniques on PCB-level, which are applicable to any electronic embedded device to showcase how to analyze a previously unknown (to the researcher or public white-hat community) hardware device. SEC Consult operates a dedicated Hardware Security Lab as part of its SEC Consult Vulnerability Lab. The presented material is a glimpse into ongoing research at the SEC Consult Hardware Security Lab and pentests that involve hardware hacking techniques.

Nowadays, we are living in a world dominated by embedded systems. Everyone can be spied on through various channels. Routers, IP-cameras, phones, and other embedded devices are affected by security vulnerabilities and are therefore easily hack-able. Recent outbreaks of Mirai and other IoT-based malware reinforce this observation. To audit the firmware of such a device in-depth - either out of curiosity or for customers as part of increasingly mature security programs - we have to disassemble it and find debug interfaces. Only a debuggable and running system can reveal all of its secrets. This process is invasive and usually leads to damaged devices – hence, more than one device is mandatory for in-depth analysis!

How to proceed with known devices

A quick workaround for avoiding a costly analysis of embedded devices are alternative firmwares. Large companies can easily run acceptance tests of a vendor-built firmware by security consultants to minimize dangers of such systems before they buy a bunch of IoT devices. But there are only few alternatives for users and hobbyists. They can install alternative firmware from third parties like OpenWRT. This firmware does not always have a better performance than the original one (because of the proprietary chip-sets) but it is often a more secure alternative.
When we are charged with a security audit of a stock firmware from a known device, the hardware analysis part is often reduced to a online search in some relevant forums (mostly the OpenWRT Wiki).

Hacking hardware – identifying debug interfaces for undocumented devices

It is mostly impossible to flash a completely unknown device with generic open firmware. Therefore, we have to dissect it in order to examine the used firmware and test it for security vulnerabilities. However, reverse engineering of hardware, especially with proprietary chip-sets, does not sound really easy, but some basics can be done by most hobbyists. A scanning electron microscope (SEM) is in many cases not necessary to identify first vulnerabilities. In our example, we present a Broadcom System on Chip (SoC), which is used as a core element for the wireless repeater Belkin F9 K1106as. This ancient device is not our particular point of interest but its chip-set is used in many other devices, which are supported by the community. By getting the pinout of the used Broadcom SoC, we receive the power to reverse engineer all devices, which are based on this particular SoC. After opening the device, we can see the PCB. Our first goal is to get serial access to the device in order to gain a shell or at least access to the bootloader.

Belkin F9 K1106as PCB and its different modules

A simple way to identify the modules under the metal shields is to remove it.

Opening an ESD-shield with an electronic-pliers

To reverse the pinout of the debug interfaces hidden on the PCB, we do not need to remove the metal in all cases. The exposed UART connector helps us for initial debugging since we got a root shell on this device directly by connecting to it with an FT2232H board using 115200 Baud 8n1 as terminal parameters.
UART can be found relatively easy in comparison to other interfaces. There are only two pins, transmit and receive. When a quick level switch in strobes is performed on a trace/pin, which has the voltage level of a power supply while it is idle then this is an indicator for a possible serial communication. Serial communication does not always mean UART, but that helps to limit the possibilities. Grouped pin (3-5 pins) are very often a UART connector, which is used during development.

A popular pinout is ( GND | RX | TX | VCC ) or ( GND | TX | RX | VCC ).

But where is JTAG? This standard enables a developer or a skilled hacker to control the CPU like a puppet and debug the SoC during runtime, program and read the whole flash memory and perform self-tests. This question can be answered by using a brute force tool for JTAG. SEC Consult developed its own tools (hardware boards & software) with additional functionality for that purpose but there are some projects available online, which can also be used for that. The TP10X pins are guessed to be JTAG because there are usually 4-5 pins for that debug port.

Brute-forcing the JTAG pinout

Hardware analysis tool "SEC Xtractor" developed (HW & SW) by SEC Consult Vulnerability Lab

After bruteforcing we got the pinout! The UART connector was also outlined for the sake of completeness.

JTAG pinout

As JTAG adapter, the cheap FT2232H mini module was used. To make it even more easy, an additional adapter-board with labeled headers is used.

Connecting to JTAG via a FT2232H mini module

A quick connection attempt with OpenOCD gives us the following result:

OpenOCD output

The chip seems to have an instruction register width of 32 and the Chip-ID of 0x2535717f. All we knew before, was that the Broadcom SoC was labeled with some letters (BCM5358UB0KFBG). Now we have much more information – but only for this specific device. The JTAG port can now be used to control the chip and gain access to the system on the lowest level.

Hacking hardware – grab the firmware

To complete the information pool, which can be collected for this SoC, a firmware dump can be done as a last step. A Macronix serial flash can be located on the back side of the PCB. These serial flashes can be read with flashrom and an FT2232H board in few minutes. A quick look on its datasheet reveals the pinout.

Macronix SPI-flash pinout

After unsoldering the chip, we placed it into an adapter and started flashrom:

Reading the SPI memory with flashrom

The dump contained the whole program memory and the permanently stored information (NVRAM). Writing this flash with flashrom and soldering back the chip is another possibility to "flash" the device with own firmware. By calling "binwalk -A dump.bin" we receive many "MIPSEL" (MIPS little endian) instructions, which lead to the assumption that this Broadcom SoC is based on an ordinary MIPSEL32 CPU. A serial flash in a SOP package is one of the flashes, which are the easiest to dump. More challenging memory chips are NAND and NOR flashes, because of the interfaces, the tiny packages and the pin count.

A first analysis of this memory-dump by the IoT Inspector reveals some initial security vulnerabilities and a bunch of interesting information about the used software inside the device. Since we analyzed an old device, some of the vulnerabilities refer back to 2007:

Excerpt from IoT Inspector report

Hacking hardware – reverse the SoC pinout

As we mentioned before, getting the pinout of the SoC would enable us to reverse engineer any device using a BCM5358UB0KFBG. At this point we are forced to remove the BGA with hot air from the PCB in the most cases (chip-off). This can be done with a SMT rework station.

Hot air rework station

Belkin PCB without Broadcom SoC

Following the traces, reading the datasheets of the other chips, doing some measurement between the pins and ground/power (GND/VCC) and some logical deduction skills lead us to the following partial pinout for the most important pins of the BCM5358UB0KFBG:
Partially reversed pinout of BCM5358U0KFBG

It was obvious that the whole BCM535x chip family have a similar pinout after a little search online. The web site collects information about computer hardware, and of course Broadcom SoCs.
There we found the following entry:

A quick look on pictures of other routers with these related chips shows that the pinout seems to be similar to the other types (BCM5357 / BCM5357B0 / BCM5357C0 / BCM5358 / BCM5358U). During the journey from one Broadcom base router to the other, striking resemblances between some devices were observed.

The wikidevi website contains much information about devices but besides that, the manufacturer is also specified very often. China seems to be the only country where all routers come from.

Hardware hacking – supply chains from China

All these Chinese electronics are often produced in the same factories. The chips, the peripherals and the routers. As a consequence, many products are from the same type of quality. The same engineering companies are also producing for competitive vendors. Just compare the two internal photos of an ASUS RT-N53 router and Belkin F9 K1106as wireless repeater. The labels are suspiciously equal.

ASUS PCB, Source:
Belkin PCB

Coincidence? Very unlikely, because the labeling is per default chosen automatically by the ELCAD (electronic computer aided design) program. Nobody changes the labels when he isn't forced to do that. Under the metal of the Belkin repeater picture are more similarities, that means the same schematic was reused for ASUS and maybe for many other devices from other vendors. Therefore, the same ODM (Original Design Manufacturer) was charged with the manufacturing and the branding to Belkin was done later.
This is not an unusual way to manufacture embedded devices, especially for companies from the US. The firmware is also often based on standardized or self-developed SDKs of the manufacturer in Asia.
The increased risk of backdoors is the logical consequence - as we saw in the past:

This research was done by Thomas Weber on behalf of SEC Consult Vulnerability Lab. SEC Consult is always searching for talented security professionals to work in our team. More information can be found at:

Friday, June 30, 2017

German e-Government: Details about critical vulnerabilities in core communication library

In this blog post we will go into some of the technical details of the vulnerabilities we identified in the OSCI Library version 1.6.1. German readers can find a less-technical version of the article here.

The OSCI-transport protocol is used for data exchange between public agencies. It is the obligatory communication protocol for public administrations and therefore the basis for e-government in Germany [1]. It attempts to provide a secure channel [2] for communication between government agencies [3]. Right now the protocol is used in many different areas such as the population registration [4], the public health system [5] and the justice system (currently migrating to version 2.0) [6]. OSCI-transport claims to provide confidentiality, integrity, authenticity and non-repudiation for content exchanged even over insecure channels such as the Internet [1]. This, among other things, means that an attacker should not be able to read or manipulate messages.

A commonly used implementation of this protocol is the "OSCI-Transport" Java library [1]. It is mantained by the publisher of the protocol. This library has existed at least since 2004 [8].

In our latest advisory [9] we describe how we broke some of the security claims of the OSCI library. We demonstrate that an attacker can conduct an external XML Entity Injection (XXE) attack that allows him/her to read local files from systems of the communication partners. Moreover, an attacker with access to the communication channel can decrypt certain parts of a message and under specific circumstances potentially even forge messages. A full security audit has not been performed and it cannot be excluded that further vulnerabilities exist.

The OSCI protocol

In order to understand the vulnerabilities, we have to go a little into the technical details of the OSCI communication.

The OSCI protocol (version 1.2) is an XML-based protocol that is typically transferred over HTTP. It is a content-agnostic transport protocol for communication between government agencies. The communication is always routed through a central component called the Intermediary. In order to communicate, a Sender has to send a message to the Intermediary. In order for this message to then reach the Recipient, two scenarios are defined:
  • The Intermediary actively transmits the message to the server (passive recipient). 
  • The server connects to the Intermediary to collect its messages (active recipient).

To protect the transmitted messages, the OSCI protocol defines the following mechanisms:
  • The payload (the actual content of the message) is signed (content signature) with the author's private key. This allows the recipient to verify the authenticity of the message.
  • The payload is encrypted (content encryption) with the final recipient's public key. This assures that the payload can only be read by the actual recipient (not by the intermediary).
  • The OSCI message including the payload is signed (order signature) using the sender's (or the Intermediary's) private key. This allows the intermediary or recipient to authenticate the sender and confirm that the message and metadata has not been altered.
  • The signed OSCI message is encrypted (order encryption) with the public key of the communication partner the message is directly sent to (i.e. the Intermediary or the final recipient). This assures that the communication between the sender and the intermediary or the Intermediary and the recipient cannot be read by an attacker.

All of these security mechanisms are optional.

Test setup

We conducted our tests against the version 1.6.1 of the Java OSCI library. This library's source code can be obtained freely from the vendor page [10]. Unfortunately, this library does not contain all code necessary to create a complete test setup (i.e. the code for the Intermediary is not included). We therefore had to write dummy code to model the missing component. We tested our attacks against a slightly modified1 sample implementation of a passive recipient that is also provided with the library (de.osci.osci12.samples.PassiveRecipient).

SEC Consult did not test production systems or applications using OSCI. Mitigating factors might exist in some environments. We did not conduct a full security review but rather a superficial check. We therefore cannot rule out that further vulnerabilities or attack scenarios exist.


From the point of view of an attacker, there are two main approaches for an attack:
  • Attacks against the communication partners: An attacker tries to send manipulated OSCI-messages to the communication partners in order to compromise them.
  • Attacks on the communication: An attacker has access to the encrypted and signed OSCI-messages. An attacker tries to decrypt or manipulate them.
SEC Consult found vulnerabilities in version 1.6.1 of the OSCI-transport library. These vulnerabilities were verified in at least one OSCI communication scenario4. Since the vulnerabilities may affect critical e-Government infrastructure, we will refrain from providing exploit code.

The following section refers to version 1.6.1 of the OSCI-transport Java library.

Attacking OSCI servers

The XML standard, which the OSCI message format is based on, includes a feature allowing the inclusion of external content ("external entities"). Parsers that have this feature turned on are usually vulnerable to external entity injection (XXE). The OSCI library has this feature explicitly enabled and is therefore vulnerable to this attack. Besides other security impacts such as denial-of-service, this vulnerability could allow an attacker to read files from the system. However, as with any XXE vulnerability there are restrictions: If the file contains specific characters (e.g. &, non-printable characters) an attacker cannot retrieve them.

For this attack to work, the attacker does not need to have access to an original message. For the passive recipient scenario, the attacker just needs to reach an OSCI participant over the network.

In order to conduct an XML External Entity Injection (XXE) attack we used the OSCI Challenge-Response feature. This feature allows a sender to specify an arbitrary value in the Challenge element. The recipient has to specify this value in the Response element of the OSCI response. Naturally, this behavior is perfect for in-band XXE attacks since we can use an external entity reference in the Challenge element and get the referenced data (e.g. a local file) in the Response element2.

In the passive recipient sample code, we verified that an attacker could send an unencrypted unsigned message to an OSCI service to read arbitrary files from the OSCI service's file system.

One practical limitation we considered is that an OSCI service might respond with an error message if the incoming message is neither signed nor encrypted. If an unsigned message is received while a signed message was expected, the specification defines that the service has to respond with an error code 9600 [11]. However, when this error occurs, according to the specification, the service still has to respond to a Challenge element, therefore reflecting our external entity inclusion. The specification does neither specify that implementations should check whether the client chose to encrypt a message ([11] section 5) nor does it define an error code for this case. When the request is not encrypted, the library does not encrypt response messages. The attacker is therefore always able to read the response.

Moreover, an external entity resolving XML parser is also exposed in a Java deserialization gadget. This means that the XXE vulnerability might be exploitable through completely different channels. The requirements for an application to be vulnerable are:
  • that it deserializes data from untrusted sources and
  • that the vulnerable OSCI library is in the application's classpath
If these conditions are met, an attacker could conduct an out-of-band XXE attack by sending crafted serialized data to the application. More information on vulnerable deserialization methods can be found here.

Attacking OSCI messages

SEC Consult does not have a holistic view on the impact, since only the OSCI-transport library, but no applications using it were available for testing. Mitigating factors or even security features that we did not consider might exist in OSCI-applications or their infrastructure to prevent successful exploitation. However, we were able to verify the vulnerabilities using a slightly modified version1 of the passive recipient sample code. A full security audit has not been performed and it cannot be excluded that further vulnerabilities exist.

In this section, we describe a scenario where an attacker is able to sniff encrypted OSCI messages. Since the communication channel is considered to be insecure, this is a legitimate attack assumption.

The following diagram illustrates the attack scenario we refer to in this section:

Breaking order encryption

The first security layer to circumvent is the transport encryption. Let's have a look at the supported encryption schemes:
  • 3DES-CBC
  • AES-128-CBC
  • AES-192-CBC
  • AES-256-CBC
We can see that OSCI only supports block ciphers in CBC mode. When this mode is used incorrectly, several attacks are possible (the W3C no longer recommends to use those ciphers [7]). The most straight-forward attack against CBC is a padding oracle attack. To conduct such an attack the attacker has to send invalid encrypted data to the recipient. The recipient is vulnerable to padding oracle if it reveals whether the decrypted message has the correct format (i.e. has a valid padding). A successful exploitation would allow an attacker to decrypt any encrypted messages.

As the OSCI standard specifies and the OSCI library implements, there is a special error code for failed decryption (in this case indicating that the padding is invalid). So in order to break the transport encryption, we were able to implement a simple padding oracle attack.

Practical applicability

Since roughly 128 requests are required to decrypt a single byte, one might assume that this attack cannot be applied in practice. However, we have created an optimized version of this script that runs significantly faster:

  • It prefers more common bytes (i.e. digits, letters, printable characters).
  • It tries to predict the contents of blocks based on previous blocks (e.g. the block xmlns:ds="http:/ is very likely followed by the block /

In our test setup we were able to decrypt an OSCI processDelivery message on a local machine within half an hour.

Demonstration of an optimized padding oracle attack script.

Bypassing order signature verification

OSCI uses XML signatures to provide authenticity. In the past, the go-to attack against XML signatures has been XML signature wrapping. Naturally, this was the first attack we tried.

To do so, we first examined which parts of the XML content are signed and how the verifying application accesses signed content. If the recipient application can be tricked into verifying one part of the XML message, while actually using another part for further processing, it is vulnerable to XML signature wrapping. The OSCI library uses a plain SAXParser, which means that a lot of parsing logic is implemented by the library itself. This might provide more flexibility and better performance, but this approach is also prone to implementation errors.

The following shows a schematic representation of a signed OSCI order:

    <ds:Reference URI="#body">...</ds:Reference>
  <osci:DesiredLanguages />
  <osci:processDelivery />
 <soap:Body Id="body">(original content here)</soap:Body>

The message header contains an XML signature (the ds:Signature element). The ds:Reference element's URI attribute describes which parts of the XML document are signed. In this case it refers to the element with the id "body" which is in this case the soap:Body element. To forge the contents of the SOAP Body we need to create a request with two SOAP Bodies. We need to make sure the parser checks the signature of the original SOAP body while the code that actually processes the contents of the SOAP Body uses our second manipulated body.

The library shows the following behavior:
  • All elements underneath the SOAP header except for the ClientSignature element3 have to be signed.
  • The SOAP Body has to be signed too.
  • The library is supposed to check that IDs within the document are unique - there is a bug that renders this check ineffective. In practice this means that the last element with a given ID is used for signature verification.
  • For further processing the SOAP Body is expected to be just below the SOAP Envelope element. For signature verification, the SOAP Body can be anywhere in the document.
We were able to abuse this bug to successfully conduct an XML signature wrapping attack.

How these vulnerabilities affect OSCI security

As we have shown, we were able to completely circumvent the security mechanisms on the order level (order signature, order encryption). If all OSCI security measures are used, an attacker could decrypt the order data (metadata) and use a signature wrapping attack to modify orders (metadata).

However, if certain OSCI security features are not used, we found several scenarios with a high security impact:
  • If content signature is not used, an attacker could exchange encrypted payload with different encrypted payload while preserving the validity of the original signature. The attacker is able to create encrypted content, because asymmetric encryption is used and the public key certificate of the recipient is included in the message. This applies similarly to order encryption. We have verified this fictitious attack scenario to work with the sample passive recipient provided with the OSCI library.
  • If content encryption is not used, an attacker could retrieve the plaintext payload after using padding oracle to bypass order encryption.
  • If a communication scenario only relies on order level security features, an attacker could retrieve and modify any transferred payload.
SEC Consult does not have quantitative data on how OSCI is used in practice (communication scenarios, utilized security features). We therefore are unable to estimate the practical impact.

Who is affected?

According to KoSIT, the OSCI-transport protocol is the technical foundation of e-government in Germany and was made an obligatory standard for electronic transactions in federal administration [1]. Due to a federal regulation, it is extensively used and the basis of multiple successful projects in Germany's e-government [1].

Due to the role of this protocol in Germany's e-government strategy, we assume that multiple administrations use OSCI-transport and the affected library.

The XOEV website lists public standards, some of which use OSCI-transport 1.2, for example:

SEC Consult does not have precise data about the exact use of the OSCI transport library in practice4.


KoSIT released a patched version (1.7.1) of the OSCI library on 2017-03-13. In the course of fixing the vulnerabilities we found, KoSIT released an update to the specification [12] that (among other changes) allows implementers to use more secure encryption algorithms.

KoSIT informed affected users of the library. SEC Consult does not have information on the patching process.

SEC Consult coordinated the release of the advisory with KoSIT, Governikus KG and the BSI. KoSIT, BSI, Governikus KG and SEC Consult recommend all affected parties to upgrade the OSCI library as soon as possible.

Moreover, SEC Consult recommends to encapsulate OSCI communication in well established and secure transport protocols (e.g. IPSec, TLS).

Since the first version of the library has been released in 2004 [8], SEC Consult assumes that vulnerable versions of the OSCI library have been used for quite a while. SEC Consult recommends to gather evidence of a potential compromise through a forensic analysis. SEC Consult does not have any information on whether attacks have already happened.


This research was done by Wolfgang Ettlinger (@ettisan) and Marc Nimmerrichter (@mnimmerrichter) on behalf of SEC Consult Vulnerability Lab. SEC Consult is always searching for talented security professionals to work in our team. More information can be found at:




1 We modified the sample passive recipient to accept content encrypted messages and to disallow unsigned orders.
2 Of course an out of band XXE attack can be conducted as well. Firewall rules, however, might block outgoing traffic.
3 This element is exempt from this rule since it contains the signature; signing it too would create a chicken-and-egg dilemma.
4 The OSCI-transport protocol can be used in different communication scenarios. During our research we only looked at one of them (passive recipient). Many of OSCI's security features (e.g. content encryption) are optional.

e-Government in Deutschland: Kritische Schwachstellen in zentraler Transportkomponente

You can find the English version of this post here containing further technical details.

Die "OSCI-Transport" Java-Bibliothek ist eine Kernkomponente im deutschen e-Government. Schwachstellen in dieser Komponente erlauben es einem Angreifer, bestimmte zwischen Behörden ausgetauschte Informationen zu entschlüsseln oder zu manipulieren bzw. sogar Daten von Behördenrechnern auszulesen.

OSCI-Transport ist ein Protokoll, das dazu dient Daten zwischen Behörden sicher auszutauschen. Es wurde 2002 definiert und gilt als obligatorischer Standard für die elektronische Kommunikation in der Bundesverwaltung [1]. Das Protokoll findet Einsatz in verschiedenen Bereichen der öffentlichen Verwaltung wie der Justiz (XJustiz), dem Gesundheitswesen (XÖGD) oder dem Meldewesen (XMeld) [2]. OSCI erhebt den Anspruch Integrität, Authentizität, Vertraulichkeit und Nachvollziehbarkeit bei der Übermittlung von Nachrichten zu gewährleisten [1]. Das bedeutet, dass ein Angreifer Nachrichten nicht mitlesen oder verändern, die Erstellung einer Nachricht abstreiten oder sich als ein gültiger Kommunikationsteilnehmer ausgeben können sollte. Dies gilt selbst dann, wenn die Kommunikation über ein nicht vertrauenswürdiges Netzwerk (z. B. das Internet) erfolgt [1].

Die OSCI-Transport Bibliothek ist eine häufig eingesetzte Java-Implementierung der Version 1.2 des OSCI-Transport Protokolls1. Diese wird von den Herausgebern dieses OSCI-Transport Protokolls bereitgestellt und ist in älteren Versionen bereits seit 2004 verfügbar [7]. Im Rahmen einer oberflächlichen Sicherheitsüberprüfung [3] dieser Komponente (Version 1.6.1) wurden mehrere Sicherheitslücken festgestellt. Mithilfe dieser Schwachstellen kann ein Angreifer bestimmte zwischen Behörden ausgetauschte Informationen u. U. manipulieren, entschlüsseln bzw. sogar Dateien von Behörden-Servern auslesen. Es wurde keine vollständige Sicherheitsanalyse durchgeführt und es kann daher nicht ausgeschlossen werden, dass weitere Schwachstellen oder Angriffsszenarien existieren.

Einführung in OSCI-Transport 1.2

Um die gefundenen Schwachstellen verständlich zu machen, gibt folgender Abschnitt eine kurze Einführung in das OSCI-Transport Protokoll Version 1.2 [4].

Grundsätzlich versucht in einer OSCI Kommunikation ein Sender eine Nachricht an einen Empfänger zu übermitteln. Das Protokoll kann für jegliche Nachrichteninhalte verwendet werden. Das Nachrichtenformat ist XML. In der Regel sind an einer OSCI 1.2 Kommunikation drei Parteien beteiligt, da die Nachricht vom Sender über einen Intermediär an den Empfänger geleitet wird. Der Intermediär dient dazu die Kommunikation zu vermitteln, diverse Prüfungen durchzuführen sowie den Datenaustausch nachweislich zu protokollieren. Um die Kommunikation vor Angriffen zu schützen, werden u. a. folgende Sicherheitsmechanismen definiert:
  • Die Signatur von Inhaltsdaten erlaubt es einem Empfänger sicherzustellen, dass die empfangenen Daten tatsächlich vom angegebenen Sender stammen.
  • Die Verschlüsselung von Inhaltsdaten stellt sicher, dass der eigentliche Inhalt einer Nachricht nur vom Empfänger gelesen werden kann. Der Intermediär kann die Inhaltsdaten nicht entschlüsseln.
  • Die Signatur von Aufträgen ermöglicht dem Intermediär bzw. dem Empfänger sicherzustellen, dass die Nachricht tatsächlich vom angegebenen Sender bzw. Intermediär stammt und nicht verändert wurde.
  • Die Verschlüsselung von Aufträgen stellt sicher, dass die Kommunikation zwischen Sender und Intermediär bzw. die Kommunikation zwischen Intermediär und Empfänger von einem Angreifer nicht mitgelesen werden kann.

Alle diese Sicherheitsmechanismen von OSCI sind optional.


Aus Sicht eines Angreifers bestehen prinzipiell zwei Möglichkeiten für Angriffe auf OSCI-Transport:
  • Angriffe gegen die Kommunikationsteilnehmer: Ein Angreifer versucht vom Standard abweichende Protokollnachrichten an Kommunikationsteilnehmer zu senden, um diese zu kompromittieren.
  • Angriffe auf die Kommunikation: Ein Angreifer hat Zugriff auf die verschlüsselten und signierten OSCI-Nachrichten. Der Angreifer versucht diese zu entschlüsseln bzw. zu manipulieren.

SEC Consult konnte in der Version 1.6.1 der OSCI Bibliothek für Java Schwachstellen feststellen, welche beide Angriffsszenarien betreffen. Die gefundenen Schwachstellen wurden in zumindest einem OSCI Kommunikationsszenario verifiziert3.

Der folgende Abschnitt bezieht sich auf die Version 1.6.1 der OSCI-Transport Bibliothek für Java. Eine tiefergehende technische Beschreibung der Schwachstellen ist in der englischen Version des Blogposts zu finden.

Angriffe gegen die Kommunikationsteilnehmer

Das OSCI-Transport Protokoll basiert auf dem XML-Format. Eine häufig identifizierte Schwachstelle bei XML-verarbeitenden Komponenten ist XML External Entity Injection (XXE). Neben anderen Auswirkungen, wie z.B. Denial-of-Service, kann es dieser Angriff erlauben Dateien des Systems auszulesen6.

Wir konnten feststellen, dass die OSCI-Bibliothek verwundbar auf XXE Angriffe ist. Ein Angreifer muss eine manipulierte Protokollnachricht an einen OSCI-Teilnehmer senden, um z.B. Konfigurationsdateien mit Passwörtern, private Schlüssel oder andere interne Informationen auszulesen. In zumindest einem OSCI Kommunikationsszenario muss ein Angreifer dazu lediglich eine manipulierte Nachricht an einen OSCI Server senden. Für einen Angreifer ist es nicht nötig eine originale Nachricht abzufangen, sondern Voraussetzung ist lediglich die Erreichbarkeit eines OSCI-Teilnehmers welcher in einem bestimmten Kommunikationsszenario agiert (passiver Empfänger)4. Es ist auch nicht erforderlich, dass ein Angreifer für die Kommunikation verwendete Zertifikate oder private Schlüssel kennt.

Angriffe auf die Kommunikation

SEC Consult hat keine gesamtheitliche Sicht auf die Auswirkungen, da lediglich die OSCI-Bibliothek, nicht jedoch verwendende Anwendungen zum Test zur Verfügung standen. Mögliche hier nicht berücksichtigte mitigierende Faktoren oder nicht betrachtete OSCI-Features könnten dadurch in OSCI-Anwendungen oder deren Infrastruktur eingesetzt werden um Angriffe zu verhindern. Wir konnten die beschriebenen Szenarien jedoch mit einer geringfügig veränderten Version5 des Beispielcodes für einen passiven Empfänger nachvollziehen. Weiters wurde keine vollständige Sicherheitsanalyse durchgeführt und es kann daher nicht ausgeschlossen werden, dass weitere Schwachstellen oder Angriffsszenarien existieren.

Da OSCI-Transport den Anspruch erhebt, dass Kommunikation auch dann sicher erfolgen kann, wenn diese über unsichere Netzwerke erfolgt [1], muss man davon ausgehen, dass ein Angreifer Protokollnachrichten beliebig abfangen bzw. verändern kann. Erhält ein Angreifer eine Protokollnachricht, so ist diese i. d. R. auftragsverschlüsselt. Der Angreifer muss also im ersten Schritt diesen Sicherheitsmechanismus überwinden.

Das OSCI-Transport Protokoll sah bis zur Korrektur, welche aufgrund unserer Analysen durchgeführte wurde [5], folgende mögliche Verschlüsselungsalgorithmen vor:
  • 3DES-CBC
  • AES-128-CBC
  • AES-192-CBC
  • AES-256-CBC

Das W3C (World Wide Web Consortium) ist der Herausgeber des Standards auf dem die Verschlüsselung beruht. Es empfiehlt seit 2013 diese Algorithmen nicht mehr zu verwenden [6]. Der Grund dafür ist, dass der Verschlüsselungsmodus (CBC) in bestimmten Szenarien anfällig auf diverse Angriffe ist. Wir konnten einen dieser Angriffe (Padding Oracle) in der OSCI-Transport Bibliothek nachvollziehen. Einem Angreifer ist es so möglich, durch wiederholtes Senden besonders gewählter Nachrichten, den Empfänger oder Intermediär dazu zu bringen den Klartext preiszugeben. Dieser Angriff erlaubt es einem Angreifer an die Metadaten des Auftrags zu gelangen.

Demonstration eines Padding-Oracle Angriffs gegen die OSCI-Transport Bibliothek.

Ein bekannter Angriff, um das bei der Auftragssignatur verwendete Signaturschema (XML Signatur) zu manipulieren, ist XML Signature Wrapping. Bei einem solchen Angriff können signierte Daten durch beliebige Daten ersetzt werden. Wir konnten ein Szenario konstruieren, welches einem Angreifer erlaubt XML Signature Wrapping Angriffe gegen die OSCI-Transport Bibliothek erfolgreich durchzuführen.

Mit diesen Angriffsmitteln sind sämtliche Sicherheitsfeatures auf Auftragsebene (Signatur von Aufträgen, Verschlüsselung von Aufträgen) umgehbar. Die Sicherheitsmechanismen auf Inhaltseben sind, so diese aktiviert sind, von diesem Angriff nicht betroffen.

Da sämtliche Sicherheitsmechanismen von OSCI-Transport 1.2 optional sind, sind weitere Angriffsszenarien denkbar:
  • Ist die Inhaltsdatensignatur deaktiviert, hat ein Angreifer die Möglichkeit unter Beibehaltung einer gültigen Signatur verschlüsselte Inhaltsdaten durch beliebige andere verschlüsselte Inhaltsdaten zu ersetzen. Da asymmetrische Verschlüsselung eingesetzt wird, muss der Angreifer nicht in der Lage sein die originale Nachricht zu entschlüsseln. Dieser muss lediglich das Zertifikat des Empfängers besitzen und da dieses in jeder OSCI-Nachricht mitgesendet wird, ist es dem Angreifer bekannt2. Ähnlich kann ein Angreifer vorgehen, um die Auftragsverschlüsselung auf die manipulierte Nachricht anzuwenden.
  • Ist die Inhaltsverschlüsselung deaktiviert, so erhält der Angreifer nach einem Padding Oracle Angriff den eigentlichen Inhalt der Nachricht. 
  • Wenn eine OSCI-Kommunikation ausschließlich auf die Sicherheitsfeatures auf Auftragsebene vertraut, kann ein Angreifer beliebige Nachrichten mitlesen oder verändern.

SEC Consult ist nicht bekannt ob diese Bedingungen in der Praxis tatsächlich gegeben sind. Eine genauere technische Auswertung ist hier zu finden.

Wer ist betroffen?

Das Protokoll bietet die technische Basis von E-Government in Deutschland und wurde als obligatorischer Standard für elektronische Transaktionen mit der Bundesverwaltung gesetzt [1]:

OSCI-Transport in der Version 1.2 ist Grundlage für einige der erfolgreichsten Projekte im deutschen E-Government. Auf Grund von Verordnungen des Bundes zur länderübergreifenden Datenübermittlung ist die flächendeckende Verbreitung sichergestellt.

Aufgrund der Rolle des OSCI-Transport Protokolls in der deutschen e-Government Strategie gehen wir davon aus, dass mehrere Behörden dieses Protokoll und die betroffene Bibliothek einsetzen.

Die XOEV Webseite führt zahlreiche öffentliche Standards auf, von denen einige das OSCI-Transport Protokoll einsetzen. Das OSCI-Transport Protokoll in Version 1.2 wird zum Beispiel von folgenden Standards unterstützt bzw. vorgeschrieben:

SEC Consult liegen keine genauen Daten über die konkrete Verwendung der OSCI-Transport Bibliothek in der Praxis vor3.


Die KoSIT hat am 13.3.2017 eine fehlerbereinigte Version (1.7.1) der Bibliothek und am 30.3.2017 eine Korrektur des Standards veröffentlicht und arbeitet daran alle ihnen bekannten Nutzer der Bibliothek darüber zu informieren. SEC Consult hat keine Daten über den aktuellen Behebungsstatus.

Im Zuge der Behebung wurde eine Korrigenda der Spezifikation veröffentlicht [5]. Diese erlaubt u. A. die Verwendung verbesserter Verschlüsselungsalgorithmen.

Im Rahmen der Zusammenarbeit mit der KoSIT, dem BSI und der Governikus KG wurde die Veröffentlichung des Security Advisories abgestimmt. KoSIT, BSI, Governikus KG sowie SEC Consult empfehlen allen betroffenen Parteien die verwundbare Version der OSCI-Transport Bibliothek schnellstmöglich auszutauschen.

SEC Consult empfiehlt darüber hinaus OSCI-Kommunikation ausschließlich über etablierte gesicherte Verbindungen (z. B. IPSec, TLS) durchzuführen.

Die erste Version der OSCI Bibliothek wurde bereits 2004 veröffentlicht [7]. SEC Consult geht daher davon aus, dass verwundbare Versionen der Bibliothek seit mehreren Jahren im Einsatz sind. SEC Consult empfiehlt eine mögliche Kompromittierung im Rahmen einer forensischen Analyse zu untersuchen. SEC Consult hat keine Informationen dazu, ob Angriffe auf die OSCI-Bibliotheken bereits stattgefunden haben.


Diese Forschungsergebnisse wurde von Wolfgang Ettlinger (@ettisan) und Marc Nimmerrichter (@mnimmerrichter) im Auftrag des SEC Consult Vulnerability Lab erarbeitet. SEC Consult ist immer auf der Suche nach talentierten Sicherheitsexperten, die Teil unseres Teams werden wollen. Weitere Infos dazu finden Sie unter




1 Es werden derzeit die Versionen 1.2 sowie 2.0 des OSCI-Transport Protokolls unterstützt und eingesetzt.
2 Element CipherCertificateAddressee
3 OSCI-Transport kann in verschiedenen Kommunikationsszenarien eingesetzt werden. Im Rahmen unserer Analyse wurde nur ein Szenario betrachtet (Passiver Empfänger). Viele Sicherheitsfeatures von OSCI (z.B. Inhaltsdatenverschlüsselung) sind optional. Unter Umständen ist bei Deaktivierung bestimmter Features ein erhöhtes Risiko gegeben.
4 Das Kommunikationsmodell des passiven Empfängers wird hier genauer erklärt.
5 Wir veränderten den Beispielcode um Inhaltsverschlüsselte Nachrichten zu akzeptieren und unsignierte Aufträge zurückzuweisen.
6 Auf die angeführten Beschränkungen werden hier genauer erklärt.

Wednesday, June 7, 2017

Ghosts from the past: Authentication bypass and OEM backdoors in WiMAX routers

Update 2017-06-29: ZyXEL has released a statement and a plan to release fixed firmware.
Update 2017-06-09: Huawei has released a Security Notice. They recommend "that users replace old Huawei routers with those of later products".

SEC Consult has found a vulnerability in several WiMAX routers, distributed by WiMAX ISPs to subscribers. The vulnerability allows an attacker to change the password of the admin user. An attacker can gain access to the device, access the network behind it and launch further attacks, add devices into a Mirai-like botnet or just simply spy on user. This vulnerability affects devices from GreenPacket, Huawei, MADA, ZTE, ZyXEL, and others. Some of the devices are accessible from the web (estimate is from 50.000 to 100.000). Affected vendors were informed by CERT/CC who released a vulnerability note (VU#350135, CVE-2017-3216).

Further information about the disclosure timeline and affected devices can be found in our advisory. This blog post has some highlights from the vulnerability analysis.

While doing research on HTTPS Certificate and SSH Key Reuse we stumbled upon a group of 80.000 devices that are using a certificate issued to "MatrixSSL Sample Server Cert" for the HTTPS web interface. The devices in question are WiMAX gateways likely developed by ZyXEL or its sister company MitraStar. We managed to get our hands on one device and did a bit of analysis.

WiMAX is a technology similar to LTE. Altough LTE is more popular nowadays, still many WiMAX networks exist all over the world.

Based on the information we got from internet-wide scan data, we know that a lot of devices expose a web server on the WAN interface. This is caused by a misconfiguration, or more likely carelessness by the ISPs that provide WiMAX gateways to customers. Web interfaces are usually a good place to hunt for vulnerabilities.

Like in all IoT pentests we grabbed a copy of the firmware (luckily available on ZyXEL's website, no hardware hacking via UART, JTAG and desoldering this time!) and uploaded it into our cloud based firmware analysis system IoT Inspector. After a few minutes the analysis results were available.

We start by looking at the file system structure. There are a bunch of HTML files in the /var/www/ directory, but usually these files are just HTML templates and do not contain any further logic.

excerpt from IoT Inspector file system browser

There are no traditional CGIs as well, so the web interface logic is likely embedded in the web server itself. The web server is implemented in /bin/mini_httpd.elf. The name mini_httpd would indicate that this is somehow related to the mini_httpd open source project, but either we are dealing with something completely different or a heavily modified version of the open source project. On first sight the web server does not contain the web interface logic as well, but there is a function that loads libraries located in the /lib/web_plugin/ directory using dlopen() and resolves several symbols.

Looking at /lib/web_plugin/ there is only one library called At the location of the symbol mime_handlers there is an array of structures that describe how different URI patterns are handled. This library also contains the implementation of the request handlers.

For each incoming request the web server tries to find a matching pattern in the mime handlers array and if a matching pattern is found, a function pointer to the function that handles the request will be called. Because we are in a good mood, we tell IDA Pro how we think how such structure looks like and convert the entries in the mime_handlers list.

We now have a pretty good understanding which URIs exist and how they are processed. The structure even contains an enum that specifies if the user has to be authenticated or not (we called it AUTH_REQUIRED/UNAUTHENTICATED). There are lots of URIs that do not require any authentication and are worth having a closer look, but we will focus on commit2.cgi.

The handler of this function just stores the arguments and values of an URL-encoded HTTP POST request into the internal database (key-value store, probably persisted in NVRAM). The simplest exploit for this vulnerability is to change the administrator password (argument ADMIN_PASSWD). Afterwards one can log in via the web interface and do some post-exploitation.

So what can we do from here on? Depends on the goal of the attacker. The web interface has a ton of functionality that could be of interest. This functionality allows changing the DNS servers (banking fraud, ad fraud), uploading malicious firmware that for example contains a botnet client or monitors the WiMAX customers internet activity. The SSH/Telnet daemon is quite interesting too...

OEM Backdoors in practice

The SSH/Telnet daemon can be enabled via the web interface. One can login using the same credentials as for the web interface and get a simple Cisco-style CLI. There are various commands that likely allow an attacker to escape it and get a regular Linux shell. But there is more:

While we focused on manual analysis of the web server for now, the results from IoT Inspector's automated analysis are quite interesting as well. One of the IoT Inspector plugins collects hardcoded Unix-style password hashes and submits them to our GPU-Server for cracking.

excerpt from IoT Inspector results

Some of the password hashes seem to be default password or placeholder files. The hashes in the file minihttpd.trans are quite interesting.

Despite its name, minihttpd.trans sets up the Linux /etc/passwd and /etc/shadow files at system boot. Below is an excerpt from the script.

This part of the script adds two backdoor users to the /etc/passwd and /etc/shadow files. The user mfgroot always has the same password hash $1$.3r0/KnH$eR.mFSJKIiY.y2QsJVsYK. (%TGBnhy6m), the password of the user root depends on the system variable ZY_CUSTOMER. The list contains the hashes we found in various firmware files.






Cracking the password hashes in the list an exercise left to the reader. Regardless of which OEM customer credentials are set, one can login using the credentials mfgroot:%TGBnhy6m and get a root shell.

Down the IoT supply chain...

The supply chain for IoT devices is often complex. The "commit2.cgi vulnerability" is located in libMTK hints that this library is part of MediaTek software, possibly an SDK that MediaTek provides for customers who build their products on MediaTek SoCs. This makes sense because the affected devices are all based on MediaTek hardware. These SDKs often come with everything that is required to use the hardware and even contain a working web interface. Vendors can choose to use the whole SDK to build their product or just use some drivers/middleware and build the rest themselves.

CERT/CC contacted MediaTek regarding the vulnerability. They responded that their SDK code is not vulnerable and stated that they suspect that ZyXEL likely added the vulnerable code. Based on the information we suspect it went down like this:
  1. MediaTek manufactures a SoC for WiMAX products, provides SDK with sample web interface code to vendors.
  2. ZyXEL and their sister company MitraStar develops firmware based on the MediaTek SDK, introduces the "commit2.cgi vulnerability" and the "OEM backdoors".
  3. ZyXEL sells the products to ISPs.
  4. MitraStar works as an OEM for GreenPacket, Huawei, ZTE... who also sell the products to ISPs.
  5. ISPs sell/lease the devices to their subscribers as customer premises equipment (CPE).

Usually OEM customers will not even admit that there is an OEM. We specifically asked Huawei and got this response:

Long supply chains and OEMs make it hard to determine which products are affected by a vulnerability. This is one of the reasons why we developed IoT Inspector. One of the use cases is to see if a specific vulnerability exists in firmware loaded into IoT Inspector. We have used this approach successfully in the past, e.g. for the KCodes NetUSB and the AMX vulnerabilities.

excerpt from IoT Inspector results 

So we created a simple IoT Inspector plugin that detects the "commit2.cgi vulnerability" and used it on a firmware data set that contains the firmware of a few thousand products including all WiMAX CPE firmware we could find on the web. Using this approach we could determine which products from GreenPacket, Huawei, MADA, ZyXEL and ZTE are affected. For a list of affected devices see our advisory.

IoT device life cycle

The affected products are quite old, likely manufactured in the early 2010s. According to Huawei, all of their affected products are end-of-service since 2014, and will not receive any updates. Researcher Pierre Kim has found vulnerabilities in another set of Huawei WiMAX CPEs back in 2015 that suffer the same fate. We reported this vulnerability to CERT/CC who coordinated the vulnerability and released a vulnerability note (VU#350135), thanks! They unfortunately did not get a response from ZyXEL .
It's unlikely that any of the affected devices will receive updates, so the only solution is to replace them.

ISPs should limit the attack surface on CPEs as much as possible. This is not just limited to the web interface and SSH/Telnet but also to the TR-069 Connection Request Server.

For further information regarding affected devices see our advisory. IoT Inspector now comes with a plugin that detects this vulnerability.


This research was done by Stefan Viehböck (@sviehbon behalf of SEC Consult Vulnerability Lab. SEC Consult is always searching for talented security professionals to work in our team. More information can be found at:


Wednesday, May 17, 2017

Tracking the culprit: SEC Technologies and Fraunhofer IPK develop technology to identify criminal activities in enterprise networks

Violence, extremism and child abuse: A lot of criminal activities are captured in images and distributed via internet and social media. But how can companies protect their network if being abused for such a purpose? If operators do not want to be unwilling accomplices, they must meet necessary measures to prevent these crimes. SEC Technologies, SEC Consult’s subsidiary for technical innovation and development, and Fraunhofer IPK set a technical milestone in identifying criminal images: Traffiic (Traffic analysis for incriminating image content) is able to recognize acts of abuse by combining text and image analysis and machine learning, which makes it possible to evaluate the image content and raise alarm, if necessary.

The aim of the jointly-developed technology was a software, which is able to discover such content and helps to antagonize against the misuse of infrastructure. A modular system emerged, which can be integrated in the enterprise network as a passive component. Least possible delay in the network traffic and minimal hardware requirements make it easy to work with this technology in the background. Heart of the system is the possibility of data extraction: In case of findings the network operator gets informed immediately and is able to set countermeasures.

High quality technology against violent crime

Fraunhofer IPK developed a new system which detects acts of abuse by combining text and image analysis with machine learning. To achieve a high detection rate with a low error rate a few different, specialized and intelligent “classifieres” are used. So for example, the first “classifier” recognizes erotic figures. Such a “positive” finding activates another “classifier”, which was trained to recognize child abuse. Apart of image information also filename and eXiF-information, which shares facts about the used camera, are analyzed.

Markus Robin, General Manager SEC Consult: “Apprehending criminals and safeguarding victims was our guiding idea during the development of this technology. Studies show that in hidden services, 80 % of site visits were related to child abuse content. As cybersecurity experts it is also our responsibility to enable a safe world. More and more frequently, companies register a misuse of their network and infrastructure. That’s why we developed Traffiic – to support companies in their network protection, save them from the act of accomplice and set measures against the horrible sharing of violent crimes.”

In the course of this project SEC Technologies developed solutions for detecting and analyzing critical content in networks. The module implemented for data extraction allows to identify images and videos in the networks’ data streams and to extract and store them for analysis. Additional to extracting the files, evaluating the source of an image is of central importance. Based on former data analyses another module for the evaluation of network sources investigates the reputation of the system in question, by linking and examining different data sources like Who-is-data bases and IP reputation services. As a result, the system’s reputation can be included in the evaluation of an image and significantly enhances the accuracy of the whole evaluation. Dr. Franz Fotr, court-certified IT-security expert, said at the workshop in Berlin: “I am delighted that the cooperation between SEC Technologies and the Fraunhofer IPK (Institute for Production Systems and Design Technology) bears fruit. The developments of the project Traffiic empower companies of all sizes to monitor their infrastructure and to protect it from attacks. That makes it significantly more difficult for criminals to misuse infrastructures and contributes to stopping the spread of child pornography.”