The below post was originally written on February 9th as a little educational exercise & follow-up to my BinDiff post. (This research was actually triggered by a relative asking about that strange Fritz!Box vulnerability he heard about on the radio). Once we realized the full potential of the bug we decided against publishing the post and contacted several parties instead. Amongst others this contributed to the German BSI press release. Given the cat is out of the bag now anyway, we see no reason to hold it back. We will further take this as an opportunity to lay out our basic vulnerability disclosure principles in a future post. This topic will also be discussed in the panel “Ethics of Security Work & Research” at Troopers
Fritz!Box is series of DSL and WLAN routers produced by AVM. They are extremely popular in Germany and are the uncontested market leader for private DSL customers. Recently, a significant number of Fritz!Box owners became victim of an attack that resulted in calls to expensive international numbers. The newspaper “Der Westen” reported about a case where phone calls valued over 4200€ were initiated from a compromised Fritz!Box. Few days later AVM published a security update for a large number of Fritz!Box models and urged customers to apply the patch as soon as possible.
However, no further details about the vulnerability were published. This blog post describes our analysis of the vulnerability that we performed directly after the first updates were released.
I recently got in contact with Intel AMT for the first time. Surely I had heard about it, knew it was “dangerous”, it was kind of exploitable and had to be deactivated. But I hadn’t actually seen it myself. Well, now I have, and I simply love it and you will probably, too (and don’t forget: love and hate are very very close to each other 😉 )
The following blogpost will be a set of features and instructions on how to own a device with an unconfigured copy of Intel AMT without using any complicated hacks or the famous magic! Continue reading “How to use Intel AMT and have some fun with Mainboards”
This is a guest post from Antonios Atlasis
==============================
Hi,
my name is Antonios and I am an independent IT Security Researcher from Greece. One of my latest “hobbies” is IPv6 and its potential insecurities so, please let me talk to you about my latest experience on this.
This week, I had the opportunity to work together with the ERNW guys at their premises. They had built an IPv6 lab that included several commercial IPv6 security devices (firewalls, IDS/IPS and some high-end switches) and they kindly offered their lab to me to play with (thank you guys 🙂 – I always liked …expensive toys). The goal of this co-operation was two-fold: First, to test my new (not yet released) IPv6 pen-testing tool and secondly, to try to find out any IPv6-related security or operational issues on these devices (after all, they all claim that they are “IPv6-Ready”, right?).
Within the last months I had some time to work on my code and today I’m releasing some of that: a new version of dizzy as well as two new loki modules.
We just got credits for a flaw we found in SAP Netweaver. The issue is a reflected Cross-Site Scripting (XSS). It can be triggered in the administrative interface for the Internet Communication Manager (ICM) and Web Dispatcher. This means that the targets for this XSS will definitely be users with administrative privileges. This makes it especially juicy for an attacker. Continue reading “XSS in SAP Netweaver”
In the course of our virtualization research, we came across a certain technical issue we couldn’t find an easy solution on knowledge bases and the like. However, as we found the question several times on the web, the following post gives just a short hint on a technical detail.
If you want to connect two virtual machines in VMware Fusion using a serial port (e.g. for debugging purposes), Fusion doesn’t provide you an GUI option to configure that. However, if you just add the following config to the debugger system’s VMX file:
During a recent research project we performed an in-depth security assessment of Microsoft’s virtualization technologies, including Hyper-V and Azure. While we already had experience in discovering security vulnerabilities in other virtual environments (e.g. here and here), this was our first research project on the Microsoft virtualization stack and we took care to use a structured evaluation strategy to cover all potential attack vectors.
Part of our research concentrated on the Hyper-V hypervisor itself and we discovered a critical vulnerability which can be exploited by an unprivileged virtual machine to crash the hypervisor and potentially compromise other virtual machines on the same physical host. This bug was recently patched, see MS13-092 and our corresponding post. Continue reading “Exploiting Hyper-V: How We Discovered MS13-092”
First of all, I hope you all had a good start to 2014. Having some time off “between the years” (which is a German saying for the time between Christmas and NYE), I caught up on several virtualization security topics.
While virtualization is widely accepted as a sufficiently secure technology in many areas of IT operations (also for sensitive applications or exposed systems, like DMZs) by 2014, there are several recent vulnerabilities and incidents that are worth mentioning.
First of all, a rather old vulnerability (codename “VMDK Has Left the Building“) was eventually patched by VMware, the day before Christmas’ eve (honi soit qui mal y pense… 😉 ). While the initially described file inclusion vulnerability cannot be exploited anymore, first tests in our lab show that attempts to exploit the vulnerability lead to a complete freeze of the shared ESXi host. We still need to dig deeper into the patch and will keep you posted.
On November’s patch Tuesday, an important vulnerability in Hyper-V was patched by Microsoft. The bulletin does not provide a lot of details as for the vulnerability, but the relevant sentence is this one: “An attacker who successfully exploited this vulnerability could execute arbitrary code as System in another virtual machine (VM) on the shared Hyper-V host.”. This does not allow code execution in the hypervisor. However, Hyper-V’s architecture comprises the so-called root partition, which is a privileged virtual machine used for all kinds of management functionality. This means that code execution in this particular virtual machine most probably will still give an attacker complete control over the hypervisor. Even without this root partition, the vulnerability would be one of the worst-case vulnerabilities in the age of Cloud computing, provided that MS Azure employs Hyper-V (which can be considered a fair assumption. Still we have no distinct knowledge here). Again, we’ll have a closer look at this one in the near future.
At the end of December, OpenSSL suffered from a virtualization-related incident. The shared hypervisor was compromised using a weak password of the hosting provider. While password-related attacks are not specific to virtualized environments, it emphasizes the need for secure management practices for virtualization components. This sounds like a very basic recommendation, but many security assessments we conducted in this space resulted in the need to include “attacks against management interfaces” in the top ERNW virtualization risks, which we cover in our virtualization and cloud security workshops. Also we mentioned this in some presentations and research results.
As the described events show, virtualization security will remain an important topic in 2014 (even though marketing material suggest to simply adopt virtualization – I won’t give any links here, you’ve probably already seen plenty 😉 ). We will cover several aspects during this year’s Troopers edition. While our workshop on “Exploiting Hypervisors” is already online (for the detailed description, see here), one talk is missing: Due to some rather strict NDAs, we can’t provide any details so far (but if you’ve read the MS13-092 credits carefully, it shouldn’t be too hard to guess 😉 ).
I hope you’re looking forward to 2014 as much as I do, stay tuned,
One of our guiding principles at ERNW is “Make the World a Safer Place”. There could not be a topic that matches this principle more than the security or insecurity of medical devices. This is why we started a research project that is looking at how vulnerable those devices are that might be deployed in hospitals around the world. Recently the U.S. Food and Drug Administration (FDA) has put out a recommendation concerning the security of medical devices. It recommends that “manufacturers and health care facilities take steps to assure that appropriate safeguards are in place to reduce the risk of failure due to cyberattack, which could be initiated by the introduction of malware into the medical equipment or unauthorized access to configuration settings in medical devices and hospital networks”. We thought that we should take a look at how manufacturers deal with security for these devices. Continue reading “Medical Device Security”
