El deber de prácticamente todo fabricante es acabar sellando sus creaciones con un injerto que estipula/marca el último día de uso o funcionamiento. Al igual que se le exige y obliga a un producto comprado en un supermercado establecer una fecha de caducidad, los dispositivos electrónicos tienen también su cuenta regresiva final -“final countdown”-. 

Puede que acabe llegando algún día la hora de la temida obsolescencia programada, que determina cuando es el mejor momento para emprender ruta hacia el último destino -la basura- antes de despedirse de su dueño/a, dejando pocas opciones cara al cliente; 

1. Adquirir uno de igual o similares características.
2. Vivir prescindiendo del mismo (vamos, como el hecho de dejar de fumar, evitando así la compra de más cigarrillos y oye ¡ahorrando dinero!).

Pero... ¿y sí todavía no llega el día de despedirse? Se dice que la vida son dos días, pues ¿a que esperas a vivirla intensamente? Siempre y cuando se disfrute con cabeza, por supuesto ;).

Gozando de un momento de paz en el sofá de casa frente a mi Smart TV consumiendo/viendo contenido bajo demanda, de pronto la televisión se apagó y… se encendió. Sí, se reinició, como cuando se actualiza un equipo o éste tiene un fallo y decide reiniciarse a modo aleatorio. Me pareció un comportamiento un tanto raruno en una TV “inteligente”. Pensé que tal vez estaba llegando su hora, bien por una programación obsoleta o por un fallo real en hardware. La TV estaba al día de firmware pero ya hacía tiempo que no se disponía de actualizaciones por caer en el olvido/abandono. 

Lo primero que se me ocurrió es mirar el perímetro de su software y ver si existían algunos fallos y/o vulnerabilidades reportadas por los usuarios, y de eso va a ir este artículo, donde vamos a ver un ataque de DoS a través de un servicio de conexión WiFi en la SmartTV llamado SWL [Samsung Wireless Link]. Es decir, vamos a tener un poco de Hacking WiFi en SmartTV.

SWL [Samsung Wireless Link] - El HotSpot de la TV

Esta tele en concreto, con el servicio SWL,  permite generar un punto de acceso WiFi como tal. Por defecto sale desactivado (al menos, en la última versión disponible de firmware). Monta una subred distinta a la de tu red local -10.123.12.0/24- pero da conexión a Internet a los dispositivos que allí conectes.

Según la figura anterior, el dispositivo P1 puede comunicarse con los que se encuentran en la red local del hogar -192.168.1.0/24- conducido por el NAT generado por TV, por lo que P2 verá la IP asignada a la interfaz Ethernet de la tele. Sí P2 quiere hablar con P1, debe existir una ruta en el router (para que no sea necesario configurarse en el host) o bien crear la ruta manualmente en el propio P2 (más engorroso para el usuario).

El proceso de activación de SWL se muestra en el siguiente vídeo. También se aprecia en el vídeo cómo lograr que un dispositivo Android posterior a la versión 9 (sin soporte para WPS - WiFi Protected Setup), se conecte a la red WiFi que es accesible solamente por mecanismo WPS (ya que no se conoce la contraseña WPA2, no aparece en ningún manual, ni detrás de la SmartTV, ni nada...).

Figura 4: Extract/Obtain/Get WPA/2 Password from a WPS WiFi for Android - 
Por desgracia/suerte, todavía existen sistemas que apuestan por WPS, como las ediciones actuales de Windows. Es tan simple como conectarse y extraer el password con el siguiente mandato:

Donde SEC_LinkShare_* es el nombre de la red WiFi creada por  la SmartTV, el asterisco funciona para el resto del texto, que en este caso, contiene parte de la MAC Ethernet de la tele.

Probando a explotar la vulnerabilidad VDB-12842

La vulnerabilidad recae en la explotación del código PIN de 8 dígitos por tener expuesto WPS. La clave era 8 ceros, y fue descubierto por un tal John, quien dejó plasmada su hazaña en el comentario nº 229 de la web de Stefan Viehböck (uno de los principales descubridores de la deficiencia en WPS). No existe CVE asignado pero sí fue recogido por VulDB (Vulnerability Database) con código VDB-12842.

Decidí probar si a mí me sucedía lo mismo con la herramienta Reaver -primera hack tool pública para explotar WPS y… mi sorpresa fue “reavelar” un incidente distinto, y provocar un ataque DoS hacia mi SmartTV... Ésta se reinició a los 20 segundos aproximadamente. Y lo mejor de todo es que si dejas la herramienta corriendo, el DoS sigue y sigue produciéndose hasta que SWL es deshabilitado en SmartTV. 

La herramienta Bully también daba el mismo resultado, pero tardaba algo menos en hacerla caer del “ring”. Así que “una de cal y otra de arena”, Samsung arregló la fuga de la password WPS pero en su contra, creó un grande problema.

Reaver vs Bully: Analizando el Comportamiento

Me asombró tanto lo que sucedía que quise ver lo que se estaba lanzando “al aire”, por lo que me hice con un par de .cap’s bajo las herramientas Reaver y Bully. La herramienta Bully es muy similar en manejo a Reaver. Coloqué las peticiones por orden de aparición, creando así un diagrama de interacción.


Las peticiones fueron grabadas con airodump-ng. El ataque DoS empieza cuando se emplazan los primeros paquetes EAPOL. Se muestran en color rojo y exceptuando el primero después de -D o S START-, se emplea una serie de 6 paquetes (Deauthentication, Authentication x 2, Association Request-Respond y EAPOL - Start) que se repiten en bucle 3 veces más hasta que se reinicia la SmartTV. Esto seria como introducir papel de aluminio en una botella de salfuman y esperar a que eclosione.

La información WSC_NACK del primer paquete rojo, parece un paquete trampa para obtener la configuración del AP, según lo interpretado en Wireshark y contrastándolo con la especificación WPS. Al disponer del archivo de captura, Wireshark proporciona una funcionalidad para hacer gráficas de paquetes según el paso del tiempo. Es algo útil para ver si existen patrones similares, distancias entre ciertos protocolos, cúmulo de paquetes máximo-mínimo, etcétera.


A simple vista ya se puede ver un claro patrón. Expliquemos un poco la dinámica de este tipo de gráficas; El eje Y muestra el conteo de paquetes comprendidos en una mitad de segundo (o 500 milisegundos). El eje X es el tiempo expresado en segundos. Acerca de los colores, las líneas y los puntos:

• Línea negra: Son todos los paquetes aparecidos en el ataque.
• Línea verde: Los beacon frames que provienen de TV.
• Puntos azules: Es un pack, un conjunto de paquetes de deauthentication, authentication y association (request & response).
• Puntos granates: Paquetes EAPOL (incluyendo los de EAP).

Dicho esto, se observa que en el arranque, paquetes granates y azules cogen bastante energía, pero sobretodo granates porque luego podemos ver como se estabilizan a nivel de cantidad de paquetes por cada 1/2 fracción de segundo. Hay una tregua hasta el segundo 10. Este paquete granate es visto en la figura del diagrama de interacción, EAP - Response, Expanded Type, WPS, WSC_NACK. Luego puede verse cómo los granates van de la mano de los azules. Start + deauthentication,… En las dos primeras series, la distancia es mas corta que la segunda contrastada con la tercera serie (1 segundo de más aprox.). A los 15 segundos se produce el reinicio.

En la segunda parte del vídeo, el ataque es reflejado para la herramienta Bully. El atacante se aprovecha de que se dejara en activo el debilitado SWL - HotSpot de la SmartTV, y lo tumba en más de una ocasión… 

Me suele ir muy bien insertar un cronómetro para tomar mis mediciones y sincronizar todos los clips de vídeo implicados en el ataque. Sin un editor de vídeo me es imposible poder ver el comportamiento de cada objeto en cada instante. No tiene mayor misterio, utilizo trucos como el de dar “una palmada al aire” para sincronizarlos por sonido o bien, grabando sobre la pantalla de otro elemento para casar la inserción de una letra (p. ej.).

¿Que sucede ahora con Reaver? Por las pruebas realizadas, podemos decir que no parece estar tan pulido a nivel de código, hay un desgaste mayor de paquetes y se toma algo mas de tiempo hasta que TV es reiniciada. Sí queréis profundizar al detalle en mi investigación, podéis leer el Whitepaper que subí en Slideshare. 

Bonus Track

La vulnerabilidad que descubrí no es reciente, data de finales de marzo del pasado año 2022. A mediados de abril, generé un reporte que envié cifrado a Samsung por la plataforma de programa Bugbounty. Me dieron las gracias -por nada- la televisión era del 2011 y que por lo tanto ya no la barajan. Pero es la forma de trabaja de un "Cazarecompensas"

Entonces me decidí contactar con INCIBE, las conversaciones han durado desde finales de Junio de 2022 hasta mediados de Octubre de este año 2023 (bastante tiempo, pero para estas cosas nunca debéis tener prisa). Me dijeron que la asignación del CVE es posible gracias al uso de un “tag” en el propio CVE que indique que se trata de un producto “legacy”.

También me comentaron que nunca habían asignado un CVE con dicho “tag” pero para todo hay una primera vez. Pasó el tiempo y lancé un “par de pings” (de manera muy respetuosa, como siempre :) ) y finalmente obtuve contestación final. Mejor lo dejo en una imagen, la verdad que son gente maja y se nota que hay mucha empatía detrás. Pero las cosas son así a veces en esta vida, que le vamos a hacer…

Sobre el ranking que mencionan, yo figuro en él por la vulnerabilidad sobre el dispositivo del fabricante Meross que sí fue con su cooperación. Eso no es problema, la competición nunca ha sido de mi agrado, me prima participar y aportar mi granito como cualquier otro/a, y ante todo ser persona honesta, jugar limpio y reconocer mis errores.

P.D.: El CVE se está moviendo con MITRE ¡A ver que se cuece!

Reflexiones finales

Esta mal tocar cosas que no son tuyas (incluso puede ser de mala educación). Activar funciones de una cosa que es tuya sin tener ni idea, está igual de mal porque no sabes la repercusión que puede llegar a tener. Con suerte se borrará la configuración.

Creo que no os lo he contado, pero yo dejé un portátil “frito”, sirviendo sólo de pisapapeles (pasó a un rol muy precario pero al menos, servía para algo :P ). Lo que pasó es que actualicé la BIOS por una no compatible (con un disquete de 3 ½ pulgadas, en mis inicios de la informática) y mira que me avisó de que no era la correspondida… pero quería ser valiente, y me sirvió, y tanto..., para aprender de una muy buena lección de la vida.

Como de costumbre, los vídeos que hago pretenden reflejar situaciones reales. La mamá que aparece en el segundo vídeo del artículo, seguro que tirará la SmartTV “por la ventana”, y ya no querrá saber más nada de Samsung… El pobre bebé, que estaba tan a gusto viendo sus dibujos, se irrita porque... ¡Alguien se los quita!

También se ha observado que el canal del punto de acceso de la tele, a veces usa el 1 y otras el 11. ¿Alguna herramienta válida para no enfangarse con un script? ¡Claro! ¿Para que reinventar la rueda si Bully ya lo hace? Seria tal que así;

Para acabar, la tele la uso (es de las pocas que tienen la modalidad 3D, aunque no lo use) es decir funciona y de maravilla. Creo que este tipo de dispositivos merecen una segunda vida y, si no prosperará en innovar su software (eso sí tiene más sentido) ¿que menos que subsanar vulnerabilidades de este tipo? Y la solución es simple, para protegerse, basta con desactivar el SWL, pero se ganarían su respeto y reputación como fabricante sí lo corrigen (aunque sea capando la función/botón de activación... aunque a lo mejor hay gente que aún usa esa función y entonces es peor... ¿quién sabe?). ¿Quien en su sano juicio, abandona a sus abuelos? ¿Cuando o a que edad se le considera a una persona como “obsoleta”?