This is the first blog post in a series about issues we think are currently relevant in the field of AI-Security. The intention is not to get full coverage of the topic, but to point out things that seem practical and relevant. We will base some of our statements on lab setups and real-life examples. The technology that we will focus on is chat bots based on generative AI, mainly OpenAI’s ChatGPT. Right now, this specific application of AI in the wild seems to be the best way to demonstrate issues and pitfalls when it comes to IT security.
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.
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.
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.
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:
In this blog post, we are sharing summaries of talks from the Hack in the Box Conference in Amsterdam (HITBSecConf2023), the final HITB conference in Amsterdam. Before we do that, however, we would like to extend a heartfelt thank you to the organizers of the conference for putting together such an insightful and engaging event.