This blog post will give a brief overview about how a simple IoT device can be assessed. It will show a basic methodology, what tools can be used for different tasks and how to solve problems that may arise during analyses. It is aimed at readers that are interested in how such a device can be assessed, those with general interest in reverse engineering or the ones who just want to see how to technically approach an unknown device.
This post will most likely not cover any vulnerabilities per se. However, it outlines weaknesses which affect a wide range of IoT devices so various aspects are applicable to other devices and scenarios.
This year’s Hacking 101 workshop at TROOPERS16 will give attendees an insight into the hacking techniques required for penetration testing. These techniques will cover various topics like information gathering, network mapping, vulnerability scanning, web application hacking, low-level exploitation and more.
During this workshop you will learn, step by step, a testing methodology that is applicable to the majority of scenarios. So imagine you have to assess the security of a system running on the Internet. How would you start? First, you need a good understanding about the target, including running services or related systems. Just scanning an IP will most likely not reveal a lot of information about the system. The gathered information may help you to identify communication relations of services that could include vulnerabilities. A brief understanding of the target and it’s related systems/services/applications will make scanning and identifying vulnerabilities a lot easier and more effective. Then, the last step will be the exploitation of the identified vulnerabilities, with the ultimate aim to get access to the target system and pivot to other, probably internal, systems and resources.
So if you are interested in learning these techniques and methodologies, join us at the TROOPERS16 Hacking 101 training! Attendees should have a brief understanding of TCP/IP networking and should be familiar with command lines on Linux systems. Also, being familiar with a programming/scripting language is considered useful.
this is a short write up about the Maintenance Operation Protocol (MOP), an ancient remote management protocol from the DECnet protocol suite. It’s old, rarely used and in most cases not needed at all. But as we stumbled across this protocol in some network assessments, it seems like a lot of network admins and other users don’t know about it. Even various hardening guides we’ve seen don’t mention MOP at all.
our home automation research, especially with KNX, is still in progress. As part of this research we’ve implemented various tools to easy the process of identifying and enumerating KNX devices, in both IP driven networks and on the bus.
Lately we’ve written two Nmap NSE scripts to discover KNXnet/IP gateways. These allow everyone to discover such gateways in local and remote networks and print some useful information about them. One of them follows the specification to discover gateways by sending multicast packets, where all devices on the network must respond to. Due to the specification of KNXnet/IP this process is rather non-invasive because only a single UDP packet is needed to discover multiple gateways. The other script allows to identify gateways via unicast connections by a slightly different message type, which allows discovery over e.g. the Internet.
The scripts are now publiclyavailable and will (hopefully) be included in Nmap soon.
Currently we are working on a tool which allows to enumerate KNX devices on the bus either from an IP driven network over a KNXnet/IP gateway or directly on the bus. Additionally information about the discovered devices included in the bus system will be extracted, e.g. what kind of device it is a sensor or an actuator.
It is planned to be released soon, so stay tuned 😉
Recently we had the pleasure to take a look at GitHub’s Enterprise appliance. The appliance allows one to deploy the excellent GitHub web interface locally to host code on-site. Besides the well known interface, which is similar to the one hosted at github.com, the appliance ships with a separate interface called the management console, which is used for administrative tasks like the configuration of the appliance itself. This management interface is completely decoupled from the user interface.
During our assessment we focused on the management console where we found several vulnerabilities (others may have found them, too). On November 11, 2014 GitHub released a security advisory which included the most critical findings that have been fixed in GitHub Enterprise 2.0.0. Because the advisory doesn’t include any detailed information, we will discuss some of those vulnerabilities in detail.
Last week Florian and I participated at this year’s DeepSec in Vienna. We had a really good time, thanks again to the DeepSec staff for a nice conference. Although it might be a bit late, I want to share some impressions about various talks I enjoyed. Continue reading “DeepSec 2013”
This is the first part of an article that will give an overview of known vulnerabilities and potential attack vectors against commonly used Virtual Private Network (VPN) protocols and technologies. This post will cover vulnerabilities and mitigation controls of the Point-to-Point Tunneling Protocol (PPTP) and IPsec. The second post will cover SSL-based VPNs like OpenVPN and the Secure Socket Tunneling Protocol (SSTP). As surveillance of Internet communications has become an important issue, besides the traditional goals of information security, typically referred as confidentiality, integrity and authenticity, another security goal has become explicitly desirable: Perfect Forward Secrecy (PFS). PFS may be achieved if the initial session-key agreement generates unique keys for each session. This ensures that even if the private key would be compromised, older sessions (that one may have captured) can’t be decrypted. The concept of PFS will be covered in the second post. Continue reading “Vulnerabilities & attack vectors of VPNs (Pt 1)”