Taking advantage of design flaws

Introduction

This article will explain something interesting and a little different, as a security researcher who has the power of development behind their belt I have always wanted to use programming to take advantage of design flaws in systems. In today's article, we will be going through a design flaw found in google cast SmartTVs. This is not an exploit but rather abusing and taking control over IoT devices that use APIs and other forms of communication remotely with the device itself. These are design flaws because of the way they communicate with the factor that almost anyone who has a laptop and has a valid operating system even if it is a CLI-only OS can make requests to these API endpoints without any form of authentication and abuse it. While you may be thinking “How can you abuse an endpoint “ that is exactly the question anyone would think. Some of these endpoints have broken authentication behind them which allows you to bypass authentication systems set in place to use system functions such as reset, power off, turn on, factory reset, discover modes, change settings, and much more. This article will first introduce you to the basic ideas of how design flaws can be dangerous and move on to talk about a program I developed to abuse multiple forms of IoT API endpoints using ARP modules, setters, and various ideas and forms of logic to seriously cause some damage. I will also then walk through the process of how and why I came across this program then go into the deep depths of recon used to find these endpoints and use cases. I will also be explaining how my framework Caster works to enumerate and control these devices by abusing their API’s. This is a long road of brain confusion and general understanding of how protocols like HTTP and SSDP work with each other as well as other devices may connect to each other. Without further to do lets get into it.

What exactly defines a design flaw

A design flaw is exactly what it sounds like, a flaw in the design of a system that was implemented and may have caused issues with the resulting product. Design flaws can be something as small as a simple formatting change which may only create front-end issues or something as big as the one today which leads to major security vulnerability issues. What we will be exploring today in this article is not an exploit but rather taking advantage of an API endpoint within Chromecasts. This API endpoint is not secure, can be found and sniffed even on a private network by listening for SSDP or HTTP requests, and can even be controlled and visited by random hosts. This is a major security issue especially if the URLs like the ones in this post require next to no authentication and can be reached via curl. These APIs in deeper cases can be detrimental to a network or can inflict some interesting ideas on people that are not so good to start off with. Design flaws like this which have no general idea of cyber security can be a major issue, upon building my program I also figured out that routers, apple TVs, Amazon TVs, and even something as simple as Alexa have their own APIs and individual URLs. These can lead to major security issues especially if you have IoT devices like IP-Cameras which are already vulnerable by themselves. Design flaws can be dangerous in many ways, they can be the reason a bug becomes a full-fledged vulnerability and the reason that applications may be shut down for days. It is important that during the design process, you work with the team to create an amazing but secure option for your application, then when application and implementation development time role around collaborate with your team and ensure they check for vulnerabilities.

Understanding why devices have these API’s

We live in a modern world where every device just has to be smart, this can range from Alexa to a simple small-screened TV it just has to be smart for people to buy it, after all, it is marketing! However, with these smart technologies and marketing techniques, they may also need to build a system that is advanced and unique, well that just so happens to be an API for developers who have an interest in using those apis. The downside to this? Hackers like myself and other security researchers may find a way to abuse these APIs, but why exactly do these APIs exist? APIs help devices and developers in many ways, it can be to debug a program or issue that may be happening with the device or make it easier for the remote or controller to access system-level functions all through a simple HTTP request. Devices however may use these endpoints without requiring a developer to mess with them. In fact, unlike some brands, the APIs and endpoints on the device are never meant to be found by anyone, however, due to the horrible implementation and design flaws this endpoint and API can now be exposed to almost every host on the network and is practically being broadcast-ed.

Understanding ECP

ECP also known as External Control Protocol is a common protocol used amongst some devices which may give you access to system functions of that device outside of its own network. For example, say you have a SmartTv or SmartHome device running on your network with an address 10.0.0.120 but you are on host 10.0.0.75 in the real world you would think that you can not access the system functions of that device due to your network difference and the fact that you are two different hosts. Truthfully speaking that is true but also false at the same time. Obviously, you will not be able to load system commands like ls, dir, pwd, whoami etc etc without spawning a shell or logging onto the device but rather run a few if not many system functions which may allow you to take advantage of the device from a remote location on that network. When IoT devices use ECP it can lead to a million different functions and in the end, it all depends on the device and manufacturer. Sometimes ECP is used by the device itself to fetch or store information because devices store information locally and start essentially what can be known as a file server, the device will handle files such as XML or JSON files over this “ file server “. Because of this, any host on the network can visit the host-name given a certain port and access files and output device information. ECP itself is not always the issue but can you see how this in the future and on some devices can become an issue? Imagine being able to view system data just within your browser.

Understanding the logic

Logic is a prime point in enumeration, especially when it comes to IoT devices. Because we are not going to be exploiting the device itself rather than abusing API we need to start some sort of logical flow to our thinking. Say we discover a device such as a Google cast but even after hours of googling can not find valid endpoints and can not figure out if it has an API or whatnot. Our best bet here would be to develop a path of logic and develop a few physical logical paths for us to take. The next few paragraphs will show and explain exactly how I developed my own logic, step by step, line by line.

• Step 1: This was before the project was even an idea but to get some ideas I popped open wireshark and started listening on different interfaces to see if anything gave me an idea. I realized at the corner of my eye that an MDNS packet was found or rather sniffed, it had the following query.

_googlecast._tcp.local: type PTR, class IN, "QM" question

This was interesting and started to spark some more ideas, I also noticed right after that packet the same hostname which for the case of the article 10.0.0.54 had a query where it tried to pull data from itself, it was a simple HTTP request but, to itself. Considering my experience with devices and even building applications it was quite weird that a device was making a request to itself, however, this is where the logic started to develop. At this point, we should pick apart the packet, which leads us into the second part and step.

• Step 2(Packet analytics): I figured by now I could find 90% of the data by simply sniffing the packets, however from here I formulated a logical point that worked like this

if the device the google chromecast sent a packet to itself which 
was an HTTP request then this means it must have some form of endpoint 
  continue to inspect

As I continued to inspect I found that it made that request to its same host-name but on port 8008 which seemed to be a reserve port. I went to the URL http://10.0.0.54:8008/` to see if I would get anything but all I got was a message from the browser saying No webpage was found for the address this is where having a logical map down comes in handy. You see the browser did not tell us that the host refused to connect, so obviously there is something here that can be connected to but what about different paths? Let's separate our messages. We know that if a browser says “Host refused to connect” the host is down on that port or maybe even the host itself is down, but if we get the message no page was found for the address that the host connected. From here what we can do is either manually start brute forcing file-paths or we can continue sniffing and see what we find. The more logical idea given we were finding HTTP requests within Wire Shark is to just continue to just sniff packets. After roughly an hour of letting wire-shark sit on HTTP requests only I noticed the same source 10.0.0.191 was sending HTTP GET requests to the path http://10.0.0.54:8008/setup/eureka_info which would give a response of all current device information. This gave me a secondary idea of logic, maybe if I search Google for the results of the setup path I can find a few different URLs and endpoints as to what may happen. It took roughly almost the entire rest of my day to figure this out but on the 30th page of Google, I found a forum talking about google chrome-casts and their API. Well, this guy who was experimenting with it just spit out a bunch of the URLs. It is a bit weird considering some of them all revolved around setup but in addition to that by making a request to one of the URLs I found out google chromecast has an SSDP path because it uses SSDP. By this point, I started to spin up scans to scan what port it would connect on and sure enough I found an 8008, 8443, and port 53917 which seemed to be an extra part. Logic became more and more of an insane role the more the investigation went on and the more I found out. By the end of this tiny little logical processing I was able to find URl’s that could let you factory reset the device, power the device off, and even change the name. However, the URLs were not the hard part, getting them to work was.

• Step 3(Enumerate): This was a more annoying process because I had to do a deeper dive into how these URLs worked such as if they required parameters or if they were using special authorizations used by the device etc. After about another 2 hours of inspecting wireshark requests, I came across many different endpoints that I could only get to with certain parameters. I could not get all the required parameters to get information to spit out in the browser however I was able to put some more logic behind the investigation with my current knowledge of APIs and got to work. Eventually, after constantly trying different URI’s and URLs with parameters I finally found a URL within the Google Chromecast which was named zc? and had a remark of action= this header leads me to some weird findings as with certain params you can get system information. Further down the road, I was able to make a request which had the action parameter of getInfo and because of that the browser finally spit out some information that contained the following.

{"status":101,"statusString":"OK","spotifyError":0,"version":"2.9.0","deviceID":"fffffffffffffffffffffffffffffffffffffffffffffffff","remoteName":"helooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo","publicKey":"xxo4fffffffffffffffffffffffffffffffffffffffff/bmDI1hlA","deviceType":"TV","libraryVersion":"3.200.454-g79c1e3f4","brandDisplayName":"Google","modelDisplayName":"ChromecastHD","resolverVersion": "0","groupStatus": "NONE","tokenType": "default","clientID": "ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff","productID":1,"scope": "umbrella-tv,streaming,client-authorization-universal","availability": "","supported_capabilities":3,"supported_drm_media_formats": [
{"drm": 1, "formats": 70},
{"drm": 2, "formats": 70}
],"aliases": [
]}

finally, things were looking up, after this I started to apply the same logic and was able to enumerate half of the endpoints logged and sniffed from wireshark to spit out information about the device, or output system functions. I will not talk about all of them within this article because it would take over 50 lines just to show the URLs and for the scope, it is too much. This is where I started to get busy.

Writing the programs

After realizing that some urls were not reachable without certain headers, I spun up my favorite code editor and got to work. Eventually, I landed with a program that would brute force not only file-paths but would also try accessing the URLs I have already found with different HTTP headers. This program was simple, it would open a list of files and those files contained HTTP headers or file paths and apply them to the host name I inputted. Because of this logical processing, I was able to get most of the URL at least 10 more than I did before to spit out even more information. I hit a block when I realized some of the endpoints needed to switch request formats. For example, the following URI would let you reset the URL in different ways. setup/reset however, the request to an endpoint like that would require certain headers, request types, and parameters. I finally found some dead program that would do the same thing for devices, it was written in Python and was a bit broken but looking at the code gave me a good idea of what I needed to do with the endpoints. The setup/reset endpoint required two changes which were the type of request and the parameters you needed to pass. There were two optional parameters to this endpoint which were fdr and now , FDR was the parameter that stands for Factory Device Reset which would factory reset the device, the now parameter would just reset the device but not back to factory settings. At this point, you should have a basic idea of what you need to do. Basically, we need to write a program that can take these endpoints, check if you can connect to them then finally start executing commands and making HTTP requests with different forms of data and request forms. This is where logical responses come in handy.