Platform in the Middle – Cómo eludir las protecciones DRM en las redes de distribución de contenidos

Este artículo describe la investigación realizada por Tarlogic y que ha sido publicada en el congreso RootedCON 2015 sobre ataques Platform in the Middle, con los que suplantar la identidad de servicios de televisión por Internet y redistribuir en abierto contenido multimedia.

1.1. Scope de la investigación

La investigación realizada pretende evidenciar fallos de configuración, implementación y diseño en las plataformas de distribución de vídeo protegido más conocidas del mercado, como es el caso de Orange Tv, Nubeox, Wuaki.TV,  TotalChannel y Netflix e identificar qué medidas pueden ser llevadas a cabo para prevenir la piratería.

Para ello se ha analizado el tráfico generado por estas aplicaciones web y los reproductores utilizados, haciendo ingeniería inversa de los mismos para evidenciar el comportamiento interno y construyendo reproductores a medida para poder llevar a cabo las pruebas. No es objeto de este artículo publicar el código de los reproductores de vídeo modificados ni fomentar la piratería.

Cabe destacar de durante la investigación se han utilizado suscripciones legítimas en cada una de las plataformas analizadas, no se ha realizado ningún ataque contra las plataformas, ni robado ningún dato de clientes legítimos, ni sacado beneficio económico. El objetivo final de esta investigación es poner en conocimiento las principales debilidades de las plataformas de distribución de contenido y dar las pautas necesarias para que las empresas que proporcionan este tipo de servicios puedan proteger su infraestructura de forma adecuada y conocer algunas de las amenazas que pueden afectar a su negocio.

1.2. Análisis de infraestructuras OTT

Las tecnologías Over-the-top (OTT) son aquellas que permiten la distribución de contenido multimedia a través de Internet sin hacer uso de las infraestructuras clásicas de distribución a través de cable o satélite.

Las infraestructuras OTT están divididas en dos tipos, diferenciándose por el tipo de contenido que distribuyen. Por una lado existen las plataformas Video on Demand (VOD) que permite a los usuarios visualizar el contenido cuando lo deseen, y por otro lado existen las que distribuyen canales en directo.

Para garantizar que la distribución del contenido se hace de forma eficiente, estas infraestructuras hacen uso de redes de distribución de contenido (CDN). Para garantizar que los contenidos distribuidos pueden ser visionados únicamente por los clientes legítimos, las empresas hacen uso de la tecnología DRM.

1.2.1.  Como funcionan las infraestructuras OTT

La infraestructura desplegada por las compañías que hacen uso de la tecnología OTT, se compone de cuatro componentes fundamentales: reproductor Flash o Silverlight, servidor Web, servidor DRM y CDN.

El reproductor Flash o Silverlight es enviado al cliente cuando desea visualizar contenido y es el encargado de realizar las peticiones al CDN para la descarga del vídeo y a los servidores de DRM para obtener la licencia que permita visualizar el vídeo.

El servidor web aloja la página web de la empresa, desde la que el usuario puede autenticarse y seleccionar el contenido que desea visualizar. Este servidor es también el encargado de enviar al usuario los parámetros de configuración del reproductor.

El servidor de DRM es el encargado de entregar al reproductor la licencia DRM necesaria para reproducir el contenido protegido. Para ello el cliente debe enviar algún parámetro que lo identifique como un usuario válido.

La red CDN es la encargada de alojar el vídeo y el audio que el reproductor consumirá. El protocolo utilizado para la transmisión de este contenido es HDS, HTTP Dynamic Streaming.

La secuencia de operaciones necesarias para que el usuario pueda visualizar contenido a través de las plataformas de vídeo es la siguiente:

1. En primera instancia, el usuario se autentica en la aplicación web.
2. A continuación accede al contenido disponible y solicita el acceso a uno de los productos ofrecidos.
3. El servidor web le envía al usuario el código HTML necesario para la reproducción del contenido, junto con un hash que identifica al cliente en las peticiones al CDN. Las variables utilizadas por el reproductor son enviadas en esta respuesta del servidor.
4. El reproductor hace una petición a la URL del fichero Manifest, enviada por el servidor como parte de las variables del reproductor.
5. El reproductor comienza a descargar los fragmentos de vídeo
6. Debido a que los fragmentos de vídeo están protegidos por DRM, el reproductor hace una petición al servidor de DRM configurado para obtener una licencia válida.
7. En caso de que la licencia DRM sea válida, comienza a reproducirlo y continua descargando el contenido.

1.2.2.  HTTP Dynamic Streaming

El protocolo HTTP Dynamic Streaming o HDS permite la distribución de contenido multimedia a través del protocolo HTTP, pudiendo adaptar el bitrate del vídeo en función de la velocidad de la  red del usuario.

Para la visualización del contenido haciendo uso de este protocolo, el reproductor debe realizar en primera instancia una petición al fichero de Manifest, el cual declara los fragmentos de vídeo que deben descargarse.

1.3. Análisis del ataque Platform in the Middle

En este apartado se detallarán las protecciones observadas durante la investigación realizada a las plataformas de televisión a través de Internet. Se presentará también los métodos comúnmente utilizados para evadir estos controles y poder distribuir el contenido a través de una infraestructura Platform in the Middle.

1.3.1.  Identificación de dispositivos

Una de las medidas de protección observadas durante la investigación ha sido la limitación por parte de las compañías en el número de dispositivos que pueden estar asociados a una cuenta. Para ello se identifica el reproductor utilizado con un hash único, y antes acceder al contenido multimedia se verifica si el identificador es válido y si no se ha superado el límite de dispositivos.

Debido a que es el reproductor quien se identifica contra el servidor, si se realizan ingeniería inversa sobre los reproductores se podrá identificar las partes de código donde se lleva a cabo la generación del hash y el posterior envío al servidor.

Una forma de evadir estas protecciones es reutilizar el mismo identificador para todos los usuarios, hardcodeando un hash válido en el reproductor modificado. En caso de que el servidor web de la compañía analizada no verifique si se está utilizando este identificador desde múltiples localizaciones, la petición realizada por el reproductor para  verificar si puede reproducir contenido, devolverá una respuesta correcta.

1.3.2.  Crossdomain.xml

Cuando una aplicación Flash se ejecuta en el contexto del navegador, realiza de forma automática una petición para obtener el fichero crossdomain.xml. Este fichero XML define los dominios desde los cuales se puede acceder al contenido alojado en el servidor, restringiendo de esta forma el acceso desde dominios no autorizados.

En caso de que el fichero crossdomain.xml sea muy restrictivo, y no permita acceder desde cualquier dominio, será necesario modificar la URL utilizada por el reproductor para obtener el fichero. Para ello se puede hacer uso de programas como RABCDAsm, que permiten aplicar procesos de ingeniería inversa sobre código ActionScript 3, para modificar la URL con el fin de conseguir que la petición se realice a un servidor propio, el cual devuelva un fichero que permita el acceso desde cualquier dominio.

1.3.3.  Hashes de acceso al contenido

Durante la investigación se ha evidenciado que algunas redes CDN restringen el acceso al contenido mediante un hash generado por el servidor web en el momento en el que usuario solicita el visionado del contenido multimedia. Con el fin de evitar que un usuario reutilice este hash desde múltiples localizaciones, el algoritmo de generación del hash utiliza la IP del cliente como uno de los parámetros de entrada.

Se ha evidenciado que algunos frontales web aceptan cabeceras HTTP de proxy. Estas cabeceras HTTP son utilizadas comúnmente en redes internas para identificar la IP real de un cliente si se dispone de proxies intermedios dentro de la organización.

Debido a que los frontales aceptan este tipo de cabeceras y que el hash que identifica al cliente se genera en base a la IP, es posible generar tokens de acceso para cualquier IP, enviando esta cabecera cuando se obtienen los parámetros de configuración para ver el contenido.

1.3.4.  Token para la petición de licencia DRM

El servicio Smooth Streaming proporcionado por Microsoft como parte los Media Services de Internet Information Services (IIS), permite consumir desde Silverlight contenido multimedia haciendo uso de protocolos adaptativos de streaming como HDS (HTTP Dynamic Streaming).

La API de Silverlight que permite consumir este tipo de servicios, proporciona también los métodos necesarios para la obtención de la licencia DRM. Para ello es necesario utilizar un token de acceso que genera el servidor web y que es enviado al cliente cuando este solicita los parámetros de configuración del reproductor.

En este escenario existen dos alternativas, que el servidor de DRM forme parte de la empresa prestadora del servicio o que este servicio de gestión de derechos sea realizado por una tercera empresa. En el primero de los escenarios el token necesario para obtener una licencia DRM válida será generado en base a la IP del cliente, por lo que es necesario verificar si se puede utilizar alguna cabecera HTTP de proxy que permita especificar la IP que usa el servidor web para generar este token. En el segundo de los escenarios probablemente el token no se genere en base a la IP del cliente, debido a las integraciones entre proveedores, lo que permitirá la reutilización del token enviado por el servidor web desde cualquier localización.

1.3.5.  Protocolos propios

Durante la investigación se ha evidenciado que algunos proveedores utilizan protocolos propios para el intercambio de mensajes entre el cliente y el servidor, así como para los servicios de licenciamiento DRM.

Debido a que estos protocolos están implementados tanto en el servidor como el reproductor, será necesario aplicar procesos de ingeniería inversa al reproductor con el fin de obtener trazas de como se generan estos mensajes. El uso de analizadores de tráfico HTTP, que permitan conocer los parámetros proporcionados por el servidor y los enviados por el cliente, también son útiles en este escenario.

1.3.6.  Cifrado de mensajes

Algunos de los proveedores analizados cifran los mensajes intercambiados entre el cliente y el servidor, impidiendo conocer lo valores originales aunque se intercepte el tráfico HTTP. Ya que este tráfico está cifrado en el cliente, los procesos de ingeniería inversa sobre los reproductores ayudará a conocer los métodos de cifrado utilizados y los parámetros necesarios en cada uno de los mensajes.

1.3.7.  Ofuscación de código

Con el fin de complicar las tareas de ingeniería inversa, algunos proveedores ofuscan el código fuente de los reproductores, impidiendo obtener un código comprensible para el investigador. Ante este escenario, es recomendable utilizar aplicaciones o IDEs de programación que nos permitan cargar el código fuente obtenido y renombrar o etiquetar las clases y los métodos analizados.

1.4. Videoclub

La integración del análisis realizado durante esta investigación se ha realizado mediante la implementación de un videoclub desde el que se pueden consumir los servicios de los proveedores analizados. Esta plataforma, desarrollada internamente como prueba de concepto, es la encargada de redistribuir el contenido haciendo uso de credenciales legítimas en los servicios de televisión.

1.4.1.  Platform in the Middle

Para ilustrar la técnica utilizada se ha definido un concepto similar al conocido Man-in-the-Middle, pero en vez de colocar un atacante entre las dos partes, se sitúa el videoclub desarrollado, constituyendo así la infraestructura Platform in the Middle.

Con esta infraestructura, cuando un usuario del videoclub desea ver el contenido de una de las compañías analizadas, el servidor que aloja la prueba de concepto del ataque Platform in the Middle realiza las peticiones necesarias para que el usuario pueda acceder al mismo.

A continuación se presenta un diagrama de secuencia en el que se aprecia el flujo de operaciones realizadas desde el videoclub y desde el cliente, haciendo uso de la infraestructura Platform in the Middle.

1. En primera instancia, el cliente solicita visionar contenido en el Videoclub creado como prueba de concepto del ataque Platform in the Middle.
2. El videoclub se autentica en la aplicación web del proveedor escogido por el usuario
3. A continuación hace una petición para obtener los parámetros de configuración del reproductor, especificando en las cabeceras X-Forwarded-For y True-Client-IP la IP real del cliente, en caso de que sean necesarias.
4. La aplicación web envía al videoclub los parámetros de configuración generados haciendo uso de la IP real del cliente.
5. El videoclub reenvía los parámetros de configuración al cliente y el reproductor modificado.
6. El reproductor modificado hace una petición a la URL del fichero Manifest, enviada por el servidor como parte de las variables del reproductor.
7. El reproductor comienza a descargar los fragmentos de vídeo
8. Debido a que los fragmentos de vídeo están protegidos por DRM, el reproductor hace una petición al servidor de DRM configurado para obtener una licencia válida.
9. En caso de que la licencia DRM sea válida, comienza a reproducirlo y continua descargando el contenido.

1.5. Conclusiones

Las conclusiones extraídas de esta investigación son las siguientes:

• Se deben revisar los reproductores implementados, ya que se ha evidenciado que algunos de los que se han analizado implementan lógica de negocio que debería estar implementada en el servidor.
• Se debe ofuscar el código de los reproductores, ya que esto complicaría las tareas de ingeniería inversa necesarias para comprender el funcionamiento del mismo.
• Es necesario analizar el uso de cabeceras HTTP de proxy en los frontales de las aplicaciones web, ya que esto permite generar tokens de acceso para cualquier cliente, conociendo únicamente su IP.
• Se deben implementar medidas de protección que verifiquen si una cuenta de usuario solicita múltiples veces en poco tiempo contenido, ya que esto puede ser un indicio de fraude.

La realización de ataques en estas infraestructuras es una tarea compleja debido al alto número de elementos involucrados. Aún así, las plataformas de televisión por internet deben considerar los ataques de Platform in the middle como un riesgo real que debe ser mitigado y acompañado de servicios de investigación y prevención de fraude.

Descubre nuestro trabajo y nuestros servicios de ciberseguridad en www.tarlogic.com