Google Play Protect is a built-in Android solution that enhances devices’ security. Its main job is to detect and block malware on Android devices. Several malware families were known for bypassing Play Protect checks in recent years. This brings us to an important question: “Is Google Play Protect a Reliable Malware Detector?”. This blog post shows how Play Protect deals with various Android malware in different scenarios. I deal with Play Protect as a black box.
During a customer project, we identified a logic flaw in Jitsi Meet, an open-source video conferencing and messaging platform for secure video conferencing, voice calls, and messaging. The vulnerability affects password protected Jitsi meetings that make use of a lobby. This logic flaw leads to the disclosure of the meeting password when a user is invited to the call after waiting in the lobby.
Jitsi offers two security options to meeting moderators. Firstly, the meeting can be assigned a password that must be entered when joining. Secondly, a lobby mode can be activated, which first adds joining users to a lobby, from where they can then be added to the meeting by a user with moderation permissions.
Recently, we held a talk at the Winterkongress1 of the Digitale Gesellschaft Schweiz in Winterthur, Switzerland, about our research project on breaking German parcel tracking sites. We could not name all the parcel services for which we identified vulnerabilities respecting disclosure timelines. Today, we describe our findings at GLS, another player in the German parcel market, and the disclosure process of corresponding vulnerabilities.
The German Federal Office for Information Security (BSI – Bundesamt für Sicherheit in der Informationstechnik) has published several papers ERNW created as part of the long-term SiSyPHuS Win10-Project. This project focuses on system analysis of selected parts of the Windows 10 operating system performed by ERNW.
Today, we describe our findings at United Parcel Service of America, Inc. (UPS), another German parcel market player, and the corresponding vulnerabilities’ disclosure process.
Dennis and I already published blog posts about our research project dealing with vulnerabilities in parcel tracking implementations at DHL and DPD. At the Winterkongress (winter congress) in Winterthur, Switzerland, we had the great opportunity to give a talk about the matter. The talk was recorded and can be watched here.
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.
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.
