In 2021, ERNW collaborated with Hochschule Mannheim for their CEP (Cyber Security Entwicklungsprojekt) to build an auditing framework for testing operating system configurations against security procedures. This project is part of the education program of the university to give the students the chance to utilize the knowledge gained throughout the first semesters in a real world project. ERNW posed as the fictitious customer, providing a requirements document and regular meetings with all project groups for feedback. We planned to process and adapt the results for an open source auditing framework. Unfortunately, we were not able to finish this project yet, but we think the students should get some attention for their work independent from our side. So here is a short summary of what the students created and the corresponding repositories. Continue reading “Student Project – Audit Framework”
Two weeks ago, I was at the c0c0n conference in Cochin (India). This conference is quite special for at least two considerations. At first, this is – to the best of my knowledge – one of the few conferences which officially brings together hackers, industrials, politics, and security forces. This is not always obvious for all these different persons to talk together, may be due to a lack of mutual understanding 😉. But for a couple of days, all of them meet, talk, exchange, and they share mutual needs and appropriate solutions. And this may explain the second consideration, why c0c0n is one of the oldest cyber security conferences in India (more than 15 years). And yes, this is the conference where police forces directly pick you up from the gates of your plane at airport, sitting you at the back of a police car to drive you to your hotel with emergency lights 😊
During this event, we provided a workshop and a talk (slides), both talking about the security of device drivers in Windows. For short, a device driver is a piece of software that is used to manage a given device (whatever the notion of device covers, from removable ones such as USB sticks to those definitively set to your motherboard). In an organization, it is perfectly possible to control the list of software and potentially the list of devices allowed on machines. But there is sometimes a blind spot to know exactly which device drivers are really used (from those setups by the OEM to the ones installed automatically when a device is plug in the system). In addition, the security issues associated with this kind of drivers is sometimes a real concern. Why? Because some device vendors do not provide enough security (not to say basic quality) in their software. A lot of the vulnerabilities exploited in drivers are always the same: exploiting a feature that “should not be here” and whose access is not “enough secure”, at least far from our today’s standards, to say the few. In fact, a lot of device drivers are unfortunately written reusing part of some public but highly deprecated projects, including codes coming from the Windows Driver Kit (WDK) initially distributed with Windows NT 4.0, back in the good old days where Windows 98 was the norm and the security was the exception 😉. In some cases, it is not hard to find samples reusing code coming from 1993 in modern drivers.
The point is not to blame the past. Some pieces of code are still relevant to be used, even nowadays. But some software architectures and system security of that legacy time are nowadays totally deprecated. And some drivers keep using dangerous features from that time, when they do not directly provide security bypasses, for dubious reasons. The reasons have as much to do with the fact that some drivers have never been updated (“why changing something since it works?”) in the past as with the fact that some drivers may simply never be updated (by design issue, no update capabilities, signed drivers still exploitable, software provider bankrupted, …). The fact is that driver vulnerabilities are not close to disappear.
Answering the problem is half technical and half organizational. On the first hand, on the technical side, there is the ability to analyze the vulnerabilities in drivers, mostly with reverse engineering, understanding the potential consequences and deploying some technical mitigations. On the other hand, there is a real topic about how to deal with existing drivers, potentially vulnerable. From the strict management of device and security policies improvement for clients to the enhancement of drivers’ code quality for software providers, there are plenty of aspects to consider. And that was exactly the point we highlighted during this conference, first in details during the workshop with more than twenty participants [😊] and then during the talk. By the way, we will give a similar online workshop (but focus on malware) in the end of November, where “seats” are still available 😊.
Last but not least, the c0c0n conference is also the place where there is a track regarding Counter Child Sexual Exploitation, talking about this highly humanitarian topic. I met very experienced police officers from different nationalities and other people involving in protecting children from abuse. These persons do such a hard job to make the world a safer place for our children. I also wanted to stress the importance of this conference, which also helps to protect children.
I was writing some challenges for PacketWars at TROOPERS22. One was intended to be a JWT key confusion challenge where the public key from an RSA JWT should be recovered and used to sign a symmetric JWT. For that, I was searching for a library vulnerable to JWT key confusion by default and found lua-resty-jwt. The original repository by SkyLothar is not maintained and different from the library that is installed with the LuaRocks package manager. The investigated library is a fork of the original repository, maintained by cdbattags in version 0.2.3 and was downloaded more than 4.8 million times according to LuaRocks.
While looking at the source code I found a way to circumvent authentication entirely.
This blog post is the continuation of our parcel research. We already reported about how we broke parcel tracking at DHL and the disclosure process of the identified problems. As DHL is not the only parcel service in Germany, we also investigated the other available parcel services. In this blog post, we want to talk about DPD, also called Geopost, which belongs to the French Post Office.
I’m happy to announce the publication of the paper Windows memory forensics: Identification of (malicious) modifications in memory-mapped image files at this years DFRWS USA, and the release of the corresponding volatility plugin. With this research came also an update to the Ptenum family (affecting especially the ptemalfind plugin), which makes the plugins reliable in identifying modified pages despite memory combining, so make sure to grab the newest version from the Github repository.
This blog post will mainly cover the imgmalfind plugin and some use cases. For detailed information on the theory behind the plugins, see the paper.
Although, more and more companies start to move their IT-Infrastructure from on-premise to public cloud solutions like Amazon Web Services (AWS) and Microsoft Azure, public cloud providers are not an option for every organization. This is where private cloud platforms come into play as they give organizations direct control over their information, can be more energy efficient than other on-premise hosting solutions, and offer companies the possibility to manage their data centers efficiently. OpenStack is a widely deployed, open-source private cloud platform many companies and universities use.
With companies and organizations moving their resources to the cloud, the security of the cloud deployment moves into focus. To ensure security in private and public cloud deployments, cloud security benchmarks are developed. The Center for Internet Security (CIS) maintains several benchmarks for public cloud providers like the AWS Foundations Benchmark or the Azure Foundations Benchmark.
As the number of deployed resources in cloud deployments can be extensive, tools for automated checking of these benchmarks are needed. Steampipe is such a tool. It offers automated checks for various cloud providers with good coverage of security standards and compliance benchmarks.
Since for OpenStack no Steampipe plugin existed, we implemented it. This blog post aims to provide a deeper understanding of how OpenStack and Steampipe work and how the Steampipe plugin for OpenStack can be used to query deployed cloud resources for insecure configuration via SQL.
TL;DR; In this blog post we present our Steampipe plugin for Openstack we’ve just released as open source. It can help you to automate checking your OpenStack resource configuration for common security flaws.
At Troopers 2023, we gave a talk on how to attack DHL parcel tracking information based on OSINT. Since we previously had an exemplary disclosure process about this attack with DHL, Mr. Kiehne (from DHL) joined us to provide interesting background information and insights on how they addressed our findings.
In symmetric-key cryptography, we typically distinguish two types of encryption schemes: block ciphers and stream ciphers. Block ciphers divide a plaintext into blocks of a fixed size (e.g., 64 or 128 bits) and encrypt one such block of data as a whole. Stream ciphers, on the other hand, consider the plaintext as a continuous stream of data. The stream cipher maintains an internal state and in each step it outputs one bit or several bits and updates its internal state. The output bit stream is then combined with the plaintext, usually using the XOR operation. One advantage of stream ciphers is that their resource requirements are lower than those of block ciphers in many application scenarios. This makes them particularly useful in lightweight cryptography targeting resource constrained devices such as low-cost RFID tags.
In this blog post, we provide an overview over current developments in this area and introduce our new lightweight stream cipher DRACO, which was developed in cooperation with the Universität Mannheim (Alexander Moch, Matthias Krause) and the Universität Siegen (Vasily Mikhalev) and has recently been presented at FSE 2023 in Kobe, Japan.
During the past year we had several projects where our target application used Jasper Reports in some way. In a few of the cases we found an API that offered to render a template along with some arguments into a PDF file. This was done with the help of the Jasper Reports Java library. Due to the way the library and the expression mechanism works, this endpoint gave us the possibility to inject Java code and gain remote code execution on the target systems.
In this blog post we want to provide an overview over the Jasper Reports Java library in terms of security especially with regard to expression injection attacks.
TL;DR; If you come across an API that lets you freely define a Jasper Report template you very likely have code execution. Or to put it differently: Never let Jasper Report templates be user or attacker controlled.
The IMF Conference is the International Conference on IT Security Incident Management & IT Forensics. This year it took place from May 23 to 24 in Munich. The schedule lists a lot of interesting talks. One of the talks was my presentation on a paper about Ceph forensics, based on my Master Thesis:
