Tomorrow, I will join a meeting where I’m expected to contribute, amongst others, to a discussion on the impact of IPv6 on threat intelligence. To prepare for that I started putting together some thoughts & ideas on the topic, and I even thought I might share this in a post (the one you read right now ;-), not least to, maybe, stimulate a discussion.
The HITBSecConf or “Hack In The Box” in Amsterdam is a well known security conference in Europe. We also attended this year too, and there were quite some interesting talks at the HITBSecConf16 conference. One of the talks was about “New Methods for Exploiting ORM Injections in Java Applications” by the security researchers Mikhail Egorov and Sergey Soldatov.
Recently I’ve started some research on MikroTik’s RouterOS, the operating system that ships with RouterBOARD devices. As I’m running such a device myself, one day I got curious about security vulnerabilities that have been reported on the operating system and the running services as it comes with tons of features. Searching for known vulnerabilities in RouterOS on Google doesn’t really yield a lot of recent security related stuff. So I thought, there is either a lack of (public) research or maybe it is super secure… 🙂
Not really satisfied with the outcome of my research about previous research one day I thought I give it a shot and just take a quick look at the management interfaces, mainly the web interface. As it turns out, there could be a third explanation for the lack of security related search results on Google: obfuscation. The communication of the web interface is obfuscated, most likely encrypted, which may discourages researchers that just came around to search for low hanging fruits. Continue reading “Implementing an Obsolete VPN Protocol on Top of HTTP: Because Why Not?”
As you may have already noticed, Cisco released an urgent security advisory describing an IPv6 Neighbor Discovery DoS Vulnerability in several flavors of Cisco’s operating systems. Currently IOS-XR, XE and NX-OS are affected while ASA and “classic” IOS are under investigation. At first glance, it might look like yet another IPv6 DoS vulnerability. Looking closer, Cisco is mentioning an unauthenticated, remote attacker due to insufficient processing logic for crafted IPv6 NDP packets that are sent to an affected device. Following the public discussion about the vulnerability, it seems that these packets will reach the, probably low rate-limited, LPTS filter/queue on IOS XR devices “crowding” out legitimate NDP packets resulting in a DoS for IPv6 traffic, or in general a high CPU load as these packets will be processed by the CPU. More details are currently not available, but this might indicate the affected systems aren’t doing proper message validation checks on NDP packets (in addition to the LPTS filter/queue problem).
In November 2014, after quite some controversy in the IETF OPSEC working group (for those interested look at the archives), the InformationalRFC 7404 “Using Only Link-Local Addressing inside an IPv6 Network” was published. It is authored by Michael Behringer and Eric Vyncke and discusses the advantages & disadvantages of an approach using “only link-local addresses on infrastructure links between routers”.
After a couple of years in pentesting Telco Networks, I’d like to give you some insight into our pentesting methodology and setup we are using for testing “Mobile and Telecommunication Devices”. I am not talking about pentesting professional providers’ equipment (as in previous blogposts), it is about pentesting of devices that have a modem in place like a lot of IoT devices (you know about the fridge having a GSM Modem, right?) do. Continue reading “Some Notes on Utilizing Telco Networks for Penetration Tests”
Yesterday the US-CERT released a Technical Alert (TA16-144A) about the recently found WPAD Name Collision Vulnerability. We will give you a summary about the vulnerability as well as the basic mechanisms here.
We couldn’t be more proud to welcome such a predestined #1 hardware hacking victim, than VICTor is!
Before Brian and I gave a lecture on hardware hacking last week at DHBW Mosbach, we felt, that we needed a custom victim which is fully documented and provides a good “hackability” to the students.
Surely we could also have used some cheap $wifi_ap, but here’s the thing: Would you really want to use a device which you don’t really know? Mostly, there’s a massive lack of documentation regarding the SoCs used…not to mention the unavailability of schematics and layouts.
As we wanted to teach students the basics of hardware hacking effectively, we decided to create something by ourselves.