Recently, I had some time to play around with HEVD , an extremly vulnerable Windows driver available for 32-bit and 64-bit systems.
Since exploits for all vulnerabilities of the 32-bit variant are publically available, I was wondering why this is not the case for the 64-bit version, especially for the pool corruption and UAF vulnerabilities.
Taking a look at the CVE List for WordPress, most vulnerabilities aren’t found within the WordPress core but inside of third-party plugins and themes.
Today, let’s talk about WordPress.
Performing a WordPress assessment might seem boring at first as core functionality [tested] and configuration does not allow for extensive security misconfigurations. Luckily, most instances use plugins and themes to add features not offered by the WordPress core.
In this blog post I would like to discuss the findings and how I discovered them. Also, I will describe different vendor responsiveness reaching from not responding at all, to not understanding the issue to fast and professional responses kindly asking for a review of the updated code ready for deployment. Continue reading “A few notes on WordPress Security”
IoT is everywhere right now and there are a lot of products out there. I have been looking at an IP Gateway lately and found some serious issues. The Busch-Welcome IP-Gateway from Busch-Jaeger is one of the devices that bridges the gap between sensors and actors in your smart home and the network/Internet. It enables the communication to a door control system that implements various smart home functions. The device itself is offering an HTTP service to configure it, which is protected by a username and password. Some folks even actually expose the device and its login to the Internet. I tried to configure one of these lately and stumbled upon some security issues that I would like to discuss in this blog post. Continue reading “Security of Busch-Jaeger IP Gateway”
Lately I’ve been analyzing a .NET binary that was quite interesting. It was a portable binary that shipped without any third-party dependencies. I started looking at the .NET assembly with ILSpy and noticed that there was not that much code that ILSpy found and there were a lot of references to classes/methods that were neither in the classes identified by ILSpy nor were they part of the .NET framework.
During years, many different researches and attacks against digital and physical payment methods have been discussed. New security techniques and methodologies such as tokenization process attempts to reduce or prevent fraudulent transactions.
If you attack someone, they will defend themselves, but if you tickle them, they will eventually crack open. This surprisingly applies to Android apps as well! Therefore, I created AndroTickler, not to test apps against certain attacks or examine them for specific vulnerabilities, which developers would learn to avoid. However, it helps pentesters to analyze and test apps in their own style, but in a faster, easier and more flexible way. AndroTickler is a Swiss-Army-Knife pentesting tool for Android apps. It provides information gathering, static and dynamic analysis features, and also automates actions that pentesters frequently do and highly need during their pentests. In addition, it makes use of the powerful Frida to hook to the app and manipulate it in real-time.
Here is a short blog post that explains how you can make your own Man-in-the-Middle (MitM) setup for sniffing the traffic between a SIM card and the backend server. This is NOT a new research but I hope this will help anyone who doesn’t have a telco background to get started to play with mobile data sniffing and fake base stations. This is applicable to many scenarios today as we have so many IoT devices with SIM cards in it that connects to the backend.
In this particular case, I am explaining the simplest scenario where the SIM card is working with 2G and GPRS. You can probably expect me with more articles with 3G, 4G MitM in future. But lets stick to 2G and GPRS for now.
Some time ago, one of our customers contacted us with a special request. For some legitimate reason, they needed to centrally collect certain certificates including their private keys which were distributed across many client systems running Windows and stored in the corresponding user stores. Unfortunately (only in this case, but actually good from a security perspective), the particular private keys were marked non-exportable making a native export in the context of the user impossible. As if this wasn’t enough, the extraction was supposed to be executed in the context of the current user (i.e. without administrative privileges) while not triggering the existing Anti Virus solution at all. Also, the certificates needed to be transferred to some trusted system where they could not be accessed in an unauthorized way. So let’s have a look how we tackled these problems: