Platform in the Middle – Bypass DRM protections at Content Delivery Networks

Please find below the description of the research about Platform in the Middle attacks carried out by Tarlogic and included in RootedCON 2015 congress. These attacks refer to Internet television services impersonation and free-to-air redistribution of multimedia content.

1.1 DRM Research scope

This research gives evidence of configuration, implementation and design failures in well-known protected video delivery platforms such as Orange Tv, Nubeox, Wuaki.TV, TotalChannel and Netflix. Besides, it also identifies which measures should be implemented in order to prevent piracy.

Therefore, traffic generated by these web applications as well as all the players used have been analyzed using reverse engineering in order to provide evidence regarding internal behavior. Besides, custom-made players were also created in order to carry out tests. By the way, this article is not aimed at publishing modified video players code or promoting piracy.

It is noteworthy that during the research, legal subscriptions have been used in each of the analyzed platforms. Besides, no platform was attacked, nor any legitimate clients’ data was stolen nor any economic advantage was taken. Then, this research final aims are the following: spotting main content delivery platforms weaknesses and providing companies working in this field and offering this service with the necessary guidelines to protect their infrastructure correctly and tackle some of the threats that may affect their business.

1.2 OTT infrastructure analysis

Over-the-top (OTT) technologies enable multimedia content delivery via Internet without using conventional delivery means such as cable or satellite.

OTT infrastructures are divided in two types differentiated regarding the content delivered. On one hand, there are Video on Demand (VOD) platforms enabling users to see the content whenever they want and on the other hand, there are those platforms delivering live channels.

OTT technologies use Content Delivery Networks (CDN) in order to ensure efficient content delivery. Besides, DRM technology is used by companies in order to ensure that delivered contents could be only viewed by legitimate clients.

1.2.1. How OTT infrastructures work

Infrastructure used by companies using OTT is based on four main elements: Flash or Silverlight player, Web server, DRM server and CDN.

Flash or Silverlight player is sent to the client whenever content view is requested. It is also responsible for sending the corresponding requests to the CDN in order to download the video and to the DRM servers in order to extract the license enabling video view.

The web server hosts the company webpage from where the user can be authenticated and select content. This server is also responsible for sending the corresponding player configuration parameters to the user.

DRM server is responsible for providing the player with the corresponding DRM license in order to display the protected content. To this purpose, the client should send a parameter to be identified as a valid user.

The CND network is responsible for hosting the video and audio that is going to be used by the player. The protocol used for this content transmission is HDS, HTTP Dynamic Streaming.

Please, find below the necessary operations sequence enabling user’s content view using video platforms:

1. First of all, the user is authenticated in the web application.
2. Next, the user accesses the available content and applies access to one of the products available.
3. The web server sends the user the necessary HTML code to display the content, together with a hash identifying the client in CDN requests. The variables used by the player are sent in this server’s request.
4. The player sends a request to the Manifest file URL, sent by the server as a part of the player variables.
5. The player starts downloading video fragments.
6. Due to the fact that video fragments are protected by DRM, the player sends a request to the DRM server configured in order to obtain a valid license.
7. In case the DRM license is valid, the content is played and the download continues.

1.2.2. HTTP Dynamic Streaming

HTTP Dynamic Streaming (HDS) protocol enables multimedia content delivery using the HTTP protocol, adapting the video bitrate depending on user’s network speed.

In order to view content using this protocol, first of all the player sends a request to the Manifest file and next, this last one selects those video fragments that should be downloaded.

1.3. Platform in the Middle – DRM attack analysis

In this section, different protection measures observed during the research about Internet television platforms are detailed. Please, find below also information regarding commonly used methods in order to bypass these controls and therefore deliver content by a Platform in the Middle.

1.3.1. Devices identification

One of the protection measures found during the research was companies’ limitation regarding the number of devices that can be associated to an account. Therefore, the player used is identified with a unique hash. Then, the identifier is authenticated and before accessing multimedia content, whether devices limit number has been exceeded it is also checked.

In case of using reverse engineering over the players and due to the fact that the player is identified against the server, code parts where hash generation is carried out could be identified and later delivered to the server.

A way to bypass this protection consists on reusing the same identifier for every user, harcoding a valid hash in the modified player. Then, in case the analyzed company’s web server does not verify if this identifier is being used from different locations, the request sent by the player in order to authenticate if the content can be displayed will send back a correct answer.

1.3.2. Crossdomain.xml

Whenever a Flash application is run in any browser context, a request is sent automatically in order to obtain the crossdomain.xml file. This XML file defines domains from where content hosted in the server could be accessed. Therefore, access from non-authorized domains is restricted.

In case this crossdomain.xml file is very restrictive and does not enable access from any other domain, it is necessary to modify the URL used by the player to obtain the file. Thus, programmes such as RABCDAsm can be used. These programmes enable the application of reverse engineering processes over ActionScript 3 code to modify the URL in order to send the request to your own server which will send back a file enabling any domain access.

1.3.3. Content Access Hashes

During the research, evidence of access restrictions by some CDN networks is provided. Content access is restricted using a hash generated by the web server whenever multimedia content view is requested by the user. In order to avoid a user reusing this hash from many locations, the hash generation algorithm uses client’s IP as one of the entry parameters.

It was also pointed out that some web frontends accept proxy HTTP headers. These HTTP headers are usually used in internal networks to identify client’s real IP in case intermediary proxies exist in the organization.

Due to the fact that frontends accept this type of headers and that the hash identifying the client is generated based on the IP, it is possible to generate access tokens for any IP sending this header whenever configuration parameters enabling content view are obtained.

1.3.4. DRM license request Token

Smooth Streaming service provided by Microsoft Internet Information Services (IIS) Media Services enables multimedia content consumption from Silverlight using streaming adaptive protocols such as HDS (HTTP Dynamic Streaming).

Silverlight API provides the possibility of consuming this type of services and also the necessary methods to obtain the DRM license. Therefore, it is necessary using an access token generated by the web server which is sent to the client whenever the player configuration parameters are requested.

In this scenario there are two options: first, the DRM server is included in the company hosting the service or second, a third company carries out rights management service. In the first scenario the token needed to obtain a valid DRM license shall be generated based on the client’s IP. Then, it is necessary to verify if a proxy HTTP header can be used in order to specify the web server IP used for token generation. In the second scenario, maybe the token is not generated based on the client’s IP due to integrations between suppliers. Therefore, this will provide the possibility to reuse the token sent by the web server from any location.

1.3.5. Self-created protocols

During the research it was shown that some suppliers use their own protocols in order to exchange messages between the client and the server, as well as for DRM licensing services.

Due to the fact that those protocols are implemented in the server and in the player, it shall be necessary to use reverse engineering processes in the player in order to obtain information about how these messages are generated. HTTP traffic analyzers are useful in this scenario since they help to find out about parameters provided by the server and also those sent by the client.

1.3.6. Encoding messages

Some of the analyzed suppliers encode the messages exchanged between the client and the server, preventing to know the original values although HTTP traffic is captured. Since this traffic is encoded in the client, the application of reverse engineering processes over the players may help to find out the encoding methods used and also the necessary parameters in each message.

1.3.7. Code obfuscation

In order to complicate reverse engineering tasks, some suppliers obfuscate players source code, preventing the researcher from obtaining a comprehensible code. Then, in this scenario it is recommendable to use programming applications or IDEs enabling the load of source code obtained and also the name change or label of classes and methods analyzed.

1.4. Video store

The analysis integration done during this research was fulfilled by a video store implementation where analyzed suppliers services can be consumed. This platform, internally developed as a concept test, is responsible for content redistribution using legal credentials in television services.

1.4.1. Platform in the Middle – Remove DRM protections

In order to explain the technique, a similar concept to the well-known Man-in-the-Middle was used. However, instead of placing an attacker between both parts, a developed video store is located forming the Platform in the Middle.

By using this method, whenever a video store user wants to view the content of one of the analyzed companies, the server hosting the Platform in the Middle attack concept test will send the necessary requests and therefore give access to the user.

Please, find below a sequence chart containing the operations flow from a video store and from the client, using Platform in the Middle.

1. First of all, content view is requested by the client in the Video Store created as a Platform in the Middle attack concept test.
2. The video store is authenticated in the supplier’s web application selected by the user.
3. Next, a request is done in order to obtain the player configuration parameters specifying the real client’s IP in the X-Forwarded-For and True-Client-IP headers, if necessary.
4. The web application sends the Video Store the generated configuration parameters using the real client’s IP.
5. The video store resends the client’s configuration parameters and the modified player.
6. The modified player sends a request to the Manifest file URL, and it is sent by the server as part of player variables.
7. The player starts downloading video fragments.
8. Due to the fact that video fragments are protected by DRM, the player sends a request to the DRM server configured to obtain a valid license.
9. In case the DRM license is valid, the video display starts and content download continues.

1.5. Conclusions of the protections

The conclusions drawn after this research are the following:

• Implemented players should be revised since it has been proofed that some of the analyzed players implement business logic which should be implemented at the same time in the server.
• Players code should be obfuscated since this complicates reverse engineering tasks. These techniques are necessary in order to understand functioning.
• It is necessary to analyze proxy HTTP headers use in web applications frontends, since this enables generating access tokens for any client only requiring the IP.
• Protection measures should be implemented in order to confirm if any user’s account has been requesting content many times in a short period of time. Therefore, this can be a clear evidence of fraud.

Attacking these infrastructures is a complex task due to the high number of elements involved. Nevertheless, internet television platforms should consider Platform in the middle attacks as a real risk which should be mitigated with fraud investigation services.
Discover our work and cybersecurity services at www.tarlogic.com