This blogpost contains summaries of talks from this year’s TROOPERS18 Next Generation Internet Event.
NGI Keynote by Graeme Neilson
Before his infosec career Graeme was a street performer, then security researcher, now he calls himself a defender. The talk was built around the following sentence: “The infosec industry and community have completely failed to create meaningful change in the behavior of people”.
The following example is a resume of how hacking worked from 1988 to 2017:
- In 1988 the Morris worm named after his programmer Robert Morris infected more than thousend computers utilizing the fingerdaemon, a buffer overflow and weak passwords.
- Ten years later in 1998 a security researcher named Rainforest Puppy explained how to do a sql injection by utilizing an untrusted input. This behavior is much like a buffer overflow, because the program trusts the input and does not validate nor sanitize it.
- In 2008 the worm Conficker appeared and infected about one million computers all over the world in one year. This time the worm used a buffer overflow and weak passwords, just like the Morris worm back in 1988.
- Then again ten years later in 2017 the worm WannaCry infected numerous computers with techniques like a buffer overflow. The worm Mirai only used common passwords and is by itself vulnerable to a buffer overflow.
The big problem why people’s behavior does not change is because people don’t experience the vulnerabilities in a proper way. Maybe they hear about them, but they don’t experience them. This leads to an optimism bias. As a street performer Graeme learned how to stop people by addressing them emotionally. When building a crowd there is a critical mass to be reached. Now he uses this knowledge for making people experience security issues by distributing jokes over vulnerabilities. In Graeme’s opinion, people experiencing vulnerabilities become empowered to fix them by themselves and choose their manufacturers more carefully.
Conclusions
The responsible disclosure process is only responsible to vendors, but not to the wider public and because of this the approach to disclosure has to be changed. Be funny and do not harm people by disclosing the vulnerabilities to all of us.
For the full video of Graeme’s talk click here.
Slides are not currently available for this talk.
Swimming IoT or how to hack a Yacht by Stephan Gerling
In the Talk “Swimming IoT or how to hack a Yacht” on the “Breaking IoT” NGI Track the speaker Stephan Gerling gave an overview of the computer systems and the attack surface present inside modern yachts.
In general a yacht is a boat between 10 and sometimes more than 50 meters whose primary purpose is recreation. This means that in the modern day, they include many technological gimmicks amenities such as onboard wifi and uplink (e.g. LTE) and entertainment systems in addition to more functional features like Vessel Traffic Service(VTS), Automatic Identification System(AIS) GPS, Radar and even cloud based engine control and monitoring.
The underlying system connecting the non recreational parts is either NMEA 0183 which is an older standard by the National Marine Electronics Association, or NMEA 2000 which has a CAN like standard similar to the one found in cars, while typical TCP/IP is used for the recreational features.
The speaker then gave an overview of the various systems, their functionality and how they work together, i.e. which systems rely on which other systems, to present the attack surface and then the possible attack vectors:
One of the well known attacks is simply spoofing the GPS signal because many other systems rely on this data, which is a real threat because some nations will actively spam and spoof the GPS signal in some parts of the world. If you are interested in the technical details you can read up on this here
The technological details of AIS system which operates around 162MHZ and the autopilot which sometimes provides a mobile remote control, can also be attacked.
But the most obvious vector in all of this, is that yachts have internet uplink and thus a router. The hardware needed for internet access while being miles away from land is fairly unusual and has custom software, which comes with some typical vulnerabilities like using plaintext FTP as a control protocol to download the config, edit it and re-upload it. Other issues were, that the hardcoded credentials were also included in the package that could be downloaded from the manufacturer. This is especially important because the router lacks any kind of firewall and exposes everything to the outside world, including the management interface which uses the hardcoded credentials for full access.
The bright side was, that the vendor was quite responsive and some of the bugs were instantly fixed. They even supplied a test router for Stephan to verify the fixes.
In conclusion there is stil much work to do on the security of “Swimming IoT” and it is plagued by the usual issues in IoT environments. If this topic interests you, check out the recording and follow Stephan Gerling on twitter.
Are you sure – you are alone? Pwning IoT-CCTV devices! by Robert Kugler
First-time Troopers speaker “Robert Kugler” describes himself as an information security & human rights enthusiast whose interest in IT-security started at the age of 14. With his talk “Are you sure – you are alone? Pwning IoT-CCTV devices!” (slides here) now 21 years old Robert Kugler lets us dive into the world of insecurities of IoT (the Internet of Things) camera devices.
As IoT devices have become increasingly more popular and widespread over the last few years, they have also more and more become a favored target for attackers. Where older CCTVs only provided eyes into private rooms and areas, nowadays these devices may feature audio communication and recording as well as a variety of sensors.
Robert starts off by describing his general approach of getting to know the device he wants to investigate, beginning with simple aspects like scanning for open ports, reading the manual, down to extracting the devices firmware image with tools like binwalk. Sadly unsurprising, even such basic steps already reveal valuable attack vectors, namely the use of basic auth, lack of CSRF protection, easy to guess default credentials and stored XSS.
Going a little bit deeper by looking at the extracted filesystem of the firmware image, Robert continues by checking for the more “juicy files” as he calls them. In particular, private keys, password hashes and basically anything that would give you an idea of the available users of the system.
As previously noted, there was a prompt for basic auth before, so Robert expects to find an .htpasswd which would contain access credentials. It appears the file is only created during runtime which makes him track down the binaries responsible for creating them, then generating wordlists from strings included in those binaries for later use.
As Robert’s goal for the device is to get code execution on it, he starts looking for potential points for command injection. By looking through the extracted filesystem, Robert identifies two CGI scripts, one responsible for configuring WLAN parameters, one for a local SMTP server, which both respond to his probing payload. Knowing that command injection is possible, modifying the injected command to start a local telnet server is his next logical step. With the service being configured for passwordless root access, Robert is now able to check for .htpasswd during runtime.
The file reveals two accounts: one being ‘admin’, which is also described in the manual but also a second one called ‘supervisor’, which appears to be an undocumented account. As the file also contains the password hashes, Robert goes on by cracking the hash which once again proves to be trivial, especially with the previously created wordlist. The password is ‘dangerous’.
Some quick 15 lines of python later, there is an initial PoC for the remote code execution.
But Robert is not satisfied yet. He shows, that according to Shodan (a search engine which lets you find specific types of systems connected to the internet), there are about 100.000 devices directly connected to the internet. But what about those not directly connected…?
Robert puts together a small demo website via JS-Recon which basically allows Javascript based port scanning and host detection with cross-origin requests and websockets and combines it with some device specific markers, eg. the path and filename of the vendor logo on the device. Once a device is identified this way, an automatically submitting form pushes the payload to the vulnerable device.
The scanning itself takes several seconds depending on the size of the network and is also mostly limited to browser targets that run Chrome on Windows, so the user has to be keptne on the attacking website until the scan finishes. On the plus side, you gain access to a lot more targets.
Robert closes his talk by mentioning that at least 5 different vendors at this time are vulnerable, but that it could potentially be more. Most were of Chinese origin and there is no easy way to contact them. What makes matters worse, and also is a still often encountered problem with IoT devices: the device has no patch/update mechanism.
But we all already know: this is fine, right?!
Advances in IPv6 Network Reconnaissance by Fernando Gont
Fernando describes how to discover IP addresses belonging to the same network. The knowledge about related IP addresses is crucial for pentesting.
The main task is to get IPv6 addresses and their prefixes. Then you can tell which IP addresses belonging to a single network. The first step is to get domain names of the target network and then the corresponding sub domain names. This can be accomplished by utilizing common search engines like google and bing. When you’ve got all possible results perform DNS requests for them.
With the list of IPv6 addresses look which IP addresses can be combined to a single IP address with a corresponding prefix. Now do a rDNS (reverse domain name) lookup for every IP address in the address space determined by its prefix. If your domain name list increased go to step one.
In theory it is easy to get IPv6 addresses with their prefixes, but when it comes to automate the task of getting new IPv6 address spaces, problems will arise. Most search engines obfuscate their output to not be machine readable and even temporarily ban you from using their service.
The tools to automate the tasks are available at Github
If you would like to see the full talk it is available here. Slides are currently not available for this talk.
Hacking Robots Before Skynet by Lucas Apa
In this talk Lucas introduced us to the research he and his partner Cesar Cerrudo conducted regarding the security of robots.
As the term “robots” could span a wide range of products his talk was mainly focused on some specific brands, namely UBTech’s Alpha2, Softbanks NAO and Pepper as well as a manufacturing/industrial/assembly robot arm found e.g. in facturies.
The presentation was packed with proof of concepts on how to use weak or nonexistent security measures in order to harm the robot’s owner. To illustrate this Lucas picked up a marketing commercial of the Alpha2 where it assists his owner repairing a sink by passing him a screwdriver. To show the dangers of insufficient security when it comes to robots Lucas turned the Alpha2 into a murderous Chucky doll stabbing a tomato with said screwdriver by simply launching a python script.
Moving on to industrial robots, which clearly implemented safety protection mechanisms for operators and bystanders since they have way more potential to harm someone than, say, a roomba. In order to circumvent the safety features Lucas exploited a stack based buffer overflow in an exposed network service. With the gained root privileged on the linux based robot he overwrote the safety boundaries and speed limits of the assembly arm. After that he let the assembly arm go bonkers by launching his crazy.py script which injected arbitrary movements into the system, potentially harming operators, bystanders and other surroundings.
In conclusion, the problems with robots are very similar to every other IoT devices, with the difference that robots are more likely to interact physically with their surroundings. Lucas pointed out that probably the expectations of the public, dreaming about robots in their every day lives for decades, might force companies to invest more into marketing than securing their systems which is partially reflected by the vendors reactions to his identified vulnerabilities.
Slides:
Are currently unavailable for this talk.
Recording:
here
IPv6 in the Cloud – Back to Square One? by Gabriel Müller
Hello everybody and I am really excited to write you again about one of the talks of the second day of Troopers 18 NGI event. As you might have heard or already familiar with, we are organizing two days of a small sub conference of our lovely TROOPERS, which is NGI. While the first day of NGI event mainly focuses on Hacking and Building NGI stuff presented in two different tracks, the second day we run one of these tracks a dedicated one for hot topics on IPv6. The speaker for the topic I am summarizing this time is again one of Troopers regular speakers Gabriel Müller, who works precisely as a project manager and a network expert. The aim of Gabriel’s topic is to shed light on the extent to which IPv6 is supported by the cloud computing vendors, which in turn would give an idea to those already planned their IPv6 and want to place their data centers in there. Additionally, the topic gives an insight into some of the pros and cons of each of the clouds, which he used in his research.
Summary
Actually, I thought it would be a good idea to reference the related video parts of the talk while I am telling you some of the mentioned key points. So, feel free to jump directly to the linked parts to digest more information from Gabriel. The talk started with a motivation and introduction. Gabriel started his introduction by warming up with a definition of the cloud computing and the important elements, which usually help to understand the basic of the virtual environments within clouds. These elements are the essential characteristics, service model and deployment models. The essential characteristics represent the main cloud traits such as computing resources and the ability to be easily extended and others. For the different available service models, Gabriel as usual used a tidy and nice chart, which clearly listed each model and gave understanding of other factors to be considered when a model is chosen. Finally, The deployment model classifies the cloud into private, community, public (most common) and hybrid.
The second part of the presentation was related to how he ended up choosing four different cloud service providers to be his focal focus of research, regarding the support of IPv6. These service providers are Alibaba, Amazon, Google and Microsoft Azure. In the test he made against the four providers, he used the Infrastructure as a Service (IAAS) model and designed a simple network topology to be similarly hosted in each cloud. The third and the big part of the talk was the result, which Gabriel concluded about the support of IPv6 in the four aforementioned cloud service providers. In general, Amazon was the only service provider out of the four that has the best support for IPv6, but not completely as IPv6 VPN and DNS server are not yet supported.
As also mentioned, Amazon has a restriction regarding the IPv6 prefix to be used, which has to be maximum “/56” assigned of course from Amazon IPv6 space. For the other cloud service providers, Alibaba does not offer IPv6, while Google and Microsoft Azure utilize a load balancer for IPv6 communication. Google cloud uses IPv6 address on the interface of the load balancer facing the external world and IPv4 for communication with the private virtual computing network. The communication between the external and the internal networks is done by the help of NAT64, which translates the traffic back and forth. For those are interested in knowing which client IP is connected to their connected service/application, is to look at the HTTP header “X-Forwarded-For”. The header specifies the value of the IPv6 of both client and load balancer. Microsoft Azure support of IPv6 is somehow similar to Google, but rather terminating the IPv6 traffic at load balancer to IPv4, Azure terminates it to other internal IPv6 space, by using NAT66. All the previous information were well covered and explained by Gabriel, by showing organized contents on the slides and also a live demo for the each deployment on the presented clouds.
The end of the talk was an open discussion on the challenges, which might be faced when it comes to choose one of the service models on the cloud. There were really constructive questions brought into this discussion with regard to the security and maintenance effort when selecting a model over another. From my humble experience this discussion cleared some ambiguity with respect to what should be taken into consideration in addition to IPv6 support.
Conclusions
The topic touched really important points regarding the IPv6 support in the cloud. It also shows, how different aspects can contribute in making the decision of whether moving to the cloud visualization is the right choice or not. Beside the speaker spirit, as usual the attendees shared their knowledge and participated in the talk with handful and valuable questions. If you are interested in more details please have a look at the slides of the talk and again watch the video on Troopers YouTube channel.
Securing your in-ear fitness coach: Challenges in hardening next generation wearables by Kavya Racharla & Sumanth Naropanth
Wearables such as smart watches, fitness trackers and implants are becoming more popular among users of different age groups. Their abilities to collect user data and communicate with external entities have rapidly increased, which makes them a popular example of the involvement of IoT technology in our lives. Hence the significance of this interesting talk that took place on the second day of Troopers 18 on NGI track. It was held by Kavya Racharla, a security research manager at Intel and Sumanth Naropanth, a founder and CEO of Deep Armor.
Security of IoT devices is a very hot topic and has been proven essential to their users’ other devices, networks and even their own safety. Additionally, wearables such as fitness trackers collect much data about their users and often transfer this data to other entities, whether the cloud and/or Mobile apps. Therefore, the speakers believe that developing such products should be handled a bit differently. In general, developers are highly recommended to integrate security in every step of developing their products, following Security Development Lifecycle model (SDL). This model ensures that the product is developed in a secure way, helps to discover security vulnerabilities at early stages and offers better response to any security incident that might happen in later stages. However, the speakers see several challenges that still faces securing IoT devices. The development cycle of IoT devices is usually short, in order to hit the market as soon as possible. Moreover, there are many standards of IoT technologies and protocols, which in turn are implemented in different ways. Furthermore, the limited Software stack and hardware capabilities of IoT devices does not allow proper security measures, such as strong cryptographic actions.
Therefore, the speakers believe that the traditional SDL should be enhanced to secure IoT devices and users’ sensitive data handled by them. The speakers propose a modified model, which they call Security and Privacy Development Lifecycle (SPDL). It basically integrates not only security in every step of the development cycle, but also privacy and legal prospectives. At early stages of development, it should be clear what Personally Identifiable Information (PII) will be collected from users and how it will be shared with third parties. The products should be designed to allow users to opt out and decide whether they are willing to share their data. Additionally, unauthorized parties, including system administrators, should not be able to access users’ private data in the cloud. Static code analysis and penetration testing in alpha and beta stages in the development lifecycle should focus on the aforementioned privacy and legal points.
After introducing SPDL model, the speakers showed some real-life cases of security and privacy failures that exist in IoT solutions in the market. The first case addresses a serious problem of Bluetooth communication with Mobile apps. Many wearable IoT devices communicate with a dedicated Android or iOS apps over Bluetooth Low Energy (BLE) to transfer information or to be controlled. The standard of BLE allows authentication of the Mobile device, however the device does not specify to which app the data belongs to. Therefore, any malicious app on the device with Bluetooth permissions can access all Bluetooth traffic of the wearable device. This significantly impacts user’s privacy. Moreover, they discovered that only the first request from the dedicated mobile app and the wearable device is authenticated. Therefore, a malicious app on the device can wait for the legitimate app to send an authenticated request to the wearable, then piggyback malicious messages and requests and they will be accepted.
Insecure legitimate mobile apps can also highly impact on user’s privacy, if the mobile app saves sensitive information insecurely. This includes storing sensitive information in an unencrypted form, which allows malicious apps with escalated privileges to access and manipulate such data. Additionally, such sensitive data can be included in unencrypted backup of the mobile device. Furthermore, storing such information on shared storage of mobile devices (such as SD card memory of Android devices) allow every app on the device to access it. The third case was an example of vulnerability on the backend side. It discusses a wearable device that provides a user portal, which allows users to communicate with each other and share information. A Cross Site Scripting (XSS) vulnerability in the Friend request functionality of the portal allows an attacker to steal the victim’s cookies and therefore access his account.
A video footage of this interesting talk can be found here
Cheers and until TROOPERS19!
Rene Puder, Raphael Pavlidis, Florian Magin, Ahmad Abolhadid, Florian Kiersch, Ali Hardudi, and Pascal Turbing