Smart TV Security: Exploring Apple TV API Endpoints in 2024

By @R34PER | Virtual Contributor | Last Upload on Feb 2nd 2023 | Home → Cybersecurity → Research

---

For the last few weeks as I explained I was working on Caster, this framework’s only original purpose was to hunt down and just ENUMERATE not exploit or debug or log or expose but just enumerate the device by abusing the API endpoints that the google chromecast had in store. One thing led to another and I found myself going down this rabbit hole of finding API endpoints that are used by third-party apps to connect, pair, and even act as a secondary remote to the device.

The point of this research is to give me as a person a better understanding of RTSP, SSDP, mDNS, DNS, Diagrams, Network structures, streaming services, IoT, local servers, enumeration, and investigations and even get a deeper understanding of how you would go about hunting for a flaw in a system and being able to expose it. This research also gives me something interesting to teach when it comes to security research, conducting investigations as well as learning how to properly create your own data and results and then compare them to others. Remember in science class where they told you that if you are conducting your own research but there is already a file out there or report out there, then said it might be a good idea to compare your results with other peoples reports ? Well that is similar to what I did, there are very very VERY few research papers/docs explaining the protocols used within Apple devices because they are so hard to get to understand if you did not help develop it.

Target List

Today we are going to be targeting the AirPlay protocol on AppleTV devices. This is because our framework caster works with multiple methods and implementations to specifically abuse API endpoints in services used in smart TVs, to keep on this topic we can just stick with an apple TV.

Information Required

Table of Contents

Toggle

Begin data collection

For us to truly see what the device is running and try to abuse the API’s here is the information we are going to be required to collect.

• Ports that are standard with AppleTV
• mDNS servers
• Protocols used by the AppleTV
• Protocol and service names used by the AppleTV
• A scan showing service information
• Network address

and other smaller bits and pieces of information that may help us distinguish the service names.

Recon and building a base intro

I knew I had an AppleTV device active on the network but forgot where it was so I used a caster to locate the data revolving around the device itself. By sending out a single batch of ARP ( Address Resolution Protocol ) packets, Caster found an apple host in a second.

From our scan, we get the following results which are important to our current investigation.

Let us map out our current information

• Ports: Ports that are open are 3689, 5000, 7000, 7100 and 62078.
• Operating system: MacOSX
• Brand: Apple
• Services: Apple AirPlay httpd, AirTunes rtspd 220.68, Apple iTunes DAAP 11.1b37
• Supported method by RTSP services: ANNOUNCE, SETUP, RECORD, PAUSE, FLUSH, TEARDOWN, OPTIONS, GET_PARAMETER, SET_PARAMETER, POST, GET, PUT

this information is pretty helpful to us because it gives us a good idea of what we are targeting. As we did in both articles explaining abusing API’s in IoT devices our first instinct may be to try to gain access to these URL’s using a browser.

However, in our case, a browser may not be the most helpful as we want to know everything we are getting from the URLs. So for our case, we are going to actually try to make a CURL command to the main URL or HTTPD service which is on port 7100 with path /info .

Why /info ? Typically most devices that have information on them or have an endpoint are going to have a file path like that which provides information on the device or service you are trying to reach, we go for info instantly because given previous research it works best.

We formulate the following curl command

curl -v http://10.0.0.96:7000/info

This command is quite simple, it just uses the -v command for a more informative output. Why are we targeting port 7000 not 7100 even though port 7100 has httpd within its service name? We do not want to target this service for right now because we are not going to be primarily try to probe that location for responses or to send commands for now . The output is as follows

---

We see that the connection was a success, but then we see something interesting within the content type which is application/x-apple-binary-plist . If you are new to apple and their file formats let me explain. Plist stands for Property List Format, it is a file format designed by apple to store information that apps may need, this is like a more advanced version of XML as it does use XML tags to store data. A standard Plist file may in our case look like the following

<plist version="1.0">
  <dict>
    <key>sdk</key>
      <string>AirPlay;2.1.1-f.1</string>
      <key>sourceVersion</key>
      <string>377.17.24.6</string>
      <key>statusFlags</key>
      <integer>580</integer>
      <key>pi</key>
      <string>2A:1B:57:36:38:D4</string>
      <key>name</key>
      <string>Samsung 7 Series (43)</string>
      <key>build</key>
      <string>17.24.6</string>
      <key>model</key>
      <string>UNU7400</string>
      <key>txtAirPlay</key>
      <string>BWFjbD0wGmRldmljZWlkPTcwOjJBOkQ1OjI0OkIyOjkzG2ZlYXR1cmVzPTB4N0Y4QUQwLDB4MzhCQ0I0Ngdyc2Y9MHgzCmZ2PXAyMC4wLjELZmxhZ3M9MHgyNDQNbW9kZWw9VU5VNzQwMBRtYW51ZmFjdHVyZXI9U2Ftc3VuZxxzZXJpYWxOdW1iZXI9MEJQWDNTSUs5MDQ5MjBODXByb3RvdmVycz0xLjETc3JjdmVycz0zNzcuMTcuMjQuNhRwaT0yQToxQjo1NzozNjozODpENChwc2k9MDAwMDAwMDAtMDAwMC0wMDAwLTAwMDAtMkExQjU3MzYzOEQ0KGdpZD0wMDAwMDAwMC0wMDAwLTAwMDAtMDAwMC0yQTFCNTczNjM4RDQGZ2NnbD0wQ3BrPWIyYmI2YzAyOGM4MjgxOTczMDU2YzYyYzNmMzk4NmFhODVjNjhhOWJhZjgzYzBiYjViMzA1NzA4NWI2MzdiZjc=</string>
    <key>PTPInfo</key>
    <string>OpenAVNU ArtAndLogic-aPTP-changes Commit: 17f0335 on Sep 22, 2018</string>
    <key>protocolVersion</key>
    <string>1.1</string>
    <key>audioLatencies</key>
    <array>

This helps applications determine what services may need what data and so on from here. However, what is a BPLIST? BPLIST is a binary representation of a Plist file, this was also created by apple for efficiency as binary representations of the data save not only on speed but memory when parsing or loading the file into the program. Now if we were to tell curl to take this output and put it into a file then continue to output it using cat we will see the following

We see below the connection to host message the output of the file and continue to see the file. If we want to view this file in hex which is something I would typically do in most cases to see if any of file contents can be seen we can write a simple program in golang to do so.

package main

import (  
    "bufio"
    "encoding/hex"
    "fmt"
    "log"
    "os"
    "io"
)
func main() {  
    f, err := os.Open("infofile") // info file is the output of the file
    if err != nil {
        log.Fatal(err)
    }
    defer f.Close()
    reader := bufio.NewReader(f)
    buf := make([]byte, 256)
    for {
        _, err := reader.Read(buf)
        if err != nil {
            if err != io.EOF {
                fmt.Println(err)
            }
            break
        }        
        fmt.Printf("%s", hex.Dump(buf))
    }
}

or we can use a simple command to output the data hexdump -C

We can already see information such as the name of the device, its address, its settings for the application, and so on from here. Now how exactly does this help us? When you get more advanced into recon steps like this files such as BPLISTS can be decoded and once decoded and more readable can show sensitive information that can be used to discover new data.

For now, the file only gives us basic information such as the name of the device, the auto output and input formats, and even the device UUID which is seen here.

This file may also give us information that the application or service may require for maybe headers or request parameters when trying to use the service further. For context given, we got this file from port 7000 this means this file may be used in AirTune’s service given the info below.

7000/tcp  open  rtsp       AirTunes rtspd 220.68
|_rtsp-methods: ANNOUNCE, SETUP, RECORD, PAUSE, FLUSH, TEARDOWN, OPTIONS, GET_PARAMETER, SET_PARAMETER, POST, GET, PUT 

Now that we have an idea of what to look for we can move on to our secondary section.

Figuring out how the services work with wireshark!

When it comes to IoT it is 100% guaranteed if that device has a service on it that the device will either be using mDNS, Multicast Listener Discovery version 6, SSDP or some form of packet or protocol such as RTSP/RTP to transmit data for its service.

There are a lot of tools out there to help us understand how these protocols work I have even made my own for personal use but nothing truly beats Wireshark. If you are new to Wireshark or do not understand what it is Wireshark is a network sniffer, it will sniff packets, protocols, streams, and data happening within the network which can include anything from an HTTP request to an SSDP discovery conversation going on between two or multiple devices. Tools like this will help in our case because of the way Wireshark allows you to view decoded data and how well it can organize things for us.

Before we start working with Wireshark I am going to open a plain listener on any interface and start an interactive AirPlay stream using screen mirroring from my iPhone to the given target ( the AppleTV ). When we open wireshark and I start the screen mirror we will see some interesting traffic come across on the server mostly MDNS traffic.

Now what exactly are we targeting? We are looking for packets with MDNS that may be informative to us or that may have the information we can use to gain a better understanding of how AirPlay works. If we sit here for a bit and go through each packet we will eventually come across this one MDNS query which has the following.

Aha! There we go! During the enumeration process, a step I like to always check is to get information on the device we are targeting, in this case, we now found that the mDNS at Living Room Apple TV._airplay._tcp.local with Type TXT is a DNS that can retrieve system information. This domain TXT record will spit out information such as

This service is pretty interesting and we could always try and forge a packet to grab this information however that is a very rough process and would take up time however it is just good to know that this TV has multiple services running on it. Within the same packet we can see the following services.

_raop._tcp.local: type PTR, class IN, F4F951DF6F97@Living Room Apple TV._raop._tcp.local
Living Room Apple TV._device-info._tcp.local: type TXT, class IN
_airplay._tcp.local: type PTR, class IN, Living Room Apple TV._airplay._tcp.local

So we now know from this very basic search that there is three services running when trying to create a connection or airplay session.

• AirplayTCP: This is known as an AirPlay sender which inspects the TXT records we saw above as well as all of the entries from _raop._tcp .
• RAOPTCP: This service also known as Remote Audio Output Protocol is a service that is used for audio streaming when streaming audio within an airplay session as _AirPlay only supports photo and video streaming.
• Device-Info: It is a bit obvious, no? device information service

When doing some extra digging on these services I came across a website that also explained that apple uses their own implementation of the zero-configuration networking known as Bonjour . This is good to know when looking at services and trying to figure out data for future research.

Now that we know the services that appleTV runs lets see if we can find anything like universal documentation or developer notes or even source code that we can go to that might end up giving us some endpoint details and ideas, a quick google search will do! Given that we are trying to target the AirPLay protocol something we need a dork or some type of search that will give us results showing possible HTTP or API endpoints for these services specifying with AirPlay so we create the following dork → Airplay protocol specification inurl ipaddress, port, http which yields…

Hmm, there seems to be an issue here, it seems we can not according to the unofficial documentation make a request to the server-info path without an X-Apple-Session-ID. This is an issue but let’s try it without one anyway.

curl -v http://10.0.0.96:7000/server-info

Note: We are still targeting port 7000 because that is the airplay service

command yields..

Well this is interesting, despite the unofficial documentation telling us we may require a session ID we were still able to send a request as the client to the server. This is correct information as well according to the data within the settings of the device. Looking further let’s see about actually executing commands such as making the remote go up or making the remote go down in this case of an AirPlay session.

Within the current documentation, we were just looking at it does not seem to note that so let us move on to the other one. In the second documentation note titled by openairplay is a link to a command list of all keys that you can send within the AirPlay session. The commands are as follows

These commands can be sent via http by querying /ctrl-int/1/$KEY . The only issue is that unlike our other request where it did not need a session ID this entry seems to require another form of authorization known as Active-remote which again in itself acts as an authentication token before the command can be executed. AppleTV uses DMAP or DACP servers which ends up meaning Digital Media Access Protocol which is a protocol that covers most if not all the tools or software developed by apple which may be using RTSP ( Real Time Streaming Protocol ). This service is defined as a basic HTTP server that will respond to certain inputs and execute them accordingly ( not the way you think with something like a system(); but rather with an endpoint handler ) for example, the following URL http://10.0.0.96/ctrl-int/1/play will tell the DAAP/DACP server to execute that command given the proper params. However, this is where we start to get a bit wonky.

Back when I was working with Amazon-FireSticks I encountered a similar issue where in order to grab system information of the device you required the device UUID which in the end was an easier fix. All I would do is forge an SSDP packet or listen for SSDP packets for that type of information and when the program found a URL it would parse it to see if there was a UUID in there and then would use it to grab the amazon-FireStick system information which could be used later. However, this is similar but not the same concept, sure I can wait around forever until someone sync’s their phone to the TV or tries but that would take a lot of packet decoding when I could just work with different methods.

However as of now without being able to set up and locate or even identify the DACP server you are not going to be able to get that Active-Remote header value to send commands like that. This is an ongoing issue, sure there are other endpoints we can reach to extract information however this is where the step goes from enumeration to full-fledged exploitation by finding ways to bypass or break past these types of systems. In this post, I will not go over a full-fledged exploitation process because as of right now I have not found one that allows you to bypass this kind of system however I am sure with the right security research it is there and can be taken advantage of. Currently, there are a lot of URLs that you can send information to but all require individual fields. Below is a list of URL’s for apple TV’s that I have found require some form of authorization.

http://$IP:7000/pair-verify
http://$IP:7000/auth-setup
http://$IP:7000/fp-setup
http://$IP:7000/pair-setup
http://$IP:7000/command
http://$IP:7000/feedback
http://$IP:7000/audioMode
http://$IP:7000/slideshow-features
http://$IP:7000/photo
http://$IP:7000/slideshows/1
http://$IP:7000/stop
# and more

Despite there being some with authorization most of the ones that require those are with RTSP which means even if you wanted to you could not see any change without having an interactive AirPlay session connected and running on the correct apps. Below is a list of URLs which are only getting requests and require minimal forms of authorization if any at all.

While these URLs require authorization to an extent they do not require passwords or usernames but rather a session ID which is in the technical form just a “UUID” like any other form of authorization this can also be difficult within itself, unlike amazon firestick you ca not just sniff this session ID either unless there is serious streaming going on. However, this gives you a good idea of where to start and the process of how AppleTV works with its APIs.

EndPoint abuse : A future thought

The entire goal of this journey was not to exploit the APIs but rather to understand how they work to an extent where we can abuse the endpoints before we start to exploit them. This is a perfect example of why logging your data from your scans and other forms are important because in the future you may need these APIs to reach some form of exploit whether it is simple RCE or a very long and annoying LFI vulnerability. API abuse can mean a million things but needing less to say it is dangerous to keep your APIs wide open for the internet to use even if you do not expect people from the outside to go this far down the rabbit hole or perhaps further to where they can bypass the authorization. Endpoint abuse can lead to major downfalls to a company or corporation such as users losing data, data being stolen as we can see with some other IoT devices like Google Cast, or even exposing video feeds where the APIs lies hidden within the network of the camera itself.

Conclusion

This was a very exciting article to write and I enjoyed and still am enjoying the process of figuring out and learning how these devices work. Every single day I go deeper into the realm of this obscure rabbit hole I learn something new and I am excited to bring you guys with me onto it! I know this article was not the most informative but it should give you a good idea of where to start in terms of understanding APIs and really seeing where API endpoint abuse can become a major issue, especially within IoT devices.