Sony Rootkit, o cómo una Megacorporación cae en su propio juego.

Sony Rootkit o cómo una Megacorporación cae en su propio juego.
Parte I [de nadie sabe cuántas] Jodiéndote por detrás.

Voy a tratar de explicar esto.
Seguramente la masa de ignorantes no tiene idea de este fenómeno del cual dependen nuestros derechos como consumidores. Es importantísimo que se informen, así que lean pues, todo lo necesario para entender el asunto se haya en esta serie que voy a seguir publicando. Las notas son mías y son de apoyo para que entiendan mejor o para amenizar los textos.

Todo comenzó el 31 de Octubre de 2005, mientras un prominente tecnomante (Mark Russinovich) se encontró en medio de una película de Ridley Scott.

“Sony, Rootkits y los DRM (Digital Rights Management – Administración de Derechos Digitales) fueron demasiado lejos.

La semana pasada cuando estaba probando la última version de RootkitRevealer (RKR) [una herramienta que desarrollo el susodicho] hice una revisión en uno de mis sistemas y quedé estupefacto al encontrar evidencia de un rootkit. Los Rootkits son tecnologías de ocultamiento que esconden archivos, claves del registro, y otros objetos, de los sistemas de software de seguridad y diagnóstico, y son usualmente usados por malware [programas que instalan basura que te deja el PC lento o estúpido o decididamente muerto, también se les llama así a los programas que te espían para robarte el email o sólo para molestarte] tratando de mantener sus aplicaciones ocultas (ver mi artículo “Desenterrando Rootkits” de la edición de Junio de Windows IT Pro Magazine [Revista de Micro$oft donde distintos tecnomantes hacen bolsa el sistema operativo y dan ayudas para evitarlo] para más información sobre los rootkits).La ventana de resultados de RKR mostraba un directorio oculto, varios controladores de dispositivos ocultos, y una aplicación oculta:

Dado el hecho de que soy cuidadoso al navegar y sólo instalo software de distribuidores reconocidos no tenía la menor idea de dónde había agarrado un rootkit real, y de no haber sido por los nombres sospechosos de la lista de archivos hubiera sospechado que el RKR estaba equivocado. Inmediatamente eché a andar Process Explorer y Autoruns [dos programillas del mismo sitio] para buscar evidencia de código que activara el rootkit en cada partida del sistema [cuando parten sus PCs], pero me encontré sin nada con ambas herramientas. Me volví entonces sobre LiveKd, una herramienta que escribí para Inside Windows 2000 [algo así como, cómo hacer que W2000 funcione a la primera] y que permite explorar los interiores de un sistema en vivo usando el Microsoft kernel debugger [una cosa que seguramente no sirve para nada más que captar errores de Windows, por eso nadie sabe que existe], para determinar qué componente era responsable del ocultamiento.

[Aquí corté un blabla que seguramente muy pocos iban a entender, agradézcanlo]

…cualquier función que no está parchada es una función normal. Volcando la tabla en Livekd reveló varias funciones parchadas.

Listé una de las funciones interceptadas y vi que era parte del controlador de dispositivo Aries.sys, el cual era una de las imágenes que había visto oculta en el directorio $sys$filesystem.

Armado con el conocimiento de que el controlador aplicaba el ocultamiento me puse a ver si podía deshabilitar el ocultamiento y exponer el proceso escondido, los archivos, directorios, y datos del registro que también lo estaban. Aunque el RKR indicaba que el directorio \Windows\System32\$sys$filesystem estaba escondido del Windows API, es común de los rootkits exconder directorios de un listado de directorios, pero no evitar que un directorio escondido se pueda abrir directamente. Por lo tanto le di una mirada a ver si podia examinar los archivos del directorio oculto abriendo el command prompt [esto tampoco saben qué es pero van a cachar con la imagen] y meterme dentro del directorio escondido. De hecho, fui capaz de entrar y acceder a la mayoría de los archivos ocultos:

Quizás renombrando el controlador y reiniciando removería el ocultamiento, pero también quería ver si el Aries.sys estaba haciendo más que sólo esconder así que lo copié dentro de un directorio no oculto y lo cargué dentro de IDA Pro, un poderoso desensamblador que uso en mi exploración de los interiores de Windows.

[todo un hacker… aquí corté otro pedazo donde explicaba algo que nadie de uds. debe cachar, onda casi bits & Bytes]

Estudié la función de inicio de los controladores, confirmando que parchaba varias funciones por medio de la tabla de llamada al sistema y vi que su código de ocultamiento escondía cualquier archivo, directorio, clave de registro o proceso cuyo nombre empieza con “$sys$”. Para verificarlo hice una copia del Block de Notas (Notepad.exe) nombrado $sys$notepad.exe y despareció de la vista. Aparte de que los objetos ocultos son indiscriminados, otras partes del código de Aries muestran una falta de sofisticación de parte del programador [ojo].

[Aquí corté otro trozo donde hablaba de que el PC se cuelga cuando el controlador se descarga de memoria, error de programación]

Después que terminé de estudiar el código del controlador reinicié el sistema. El ocultamiento se había ido y podía ver todos los archivos anteriormente ocultos en el Explorador y las claves de registro en el Regedit [un programa que viene de regalo con Window$ y que seguramente tampoco sabían que existía… súper útil cuando haces parir el PC]. Dudé que los archivos tuvieran cualquier información de descripción, pero hice andar mi programa Sigcheck en ellos. Para mi sorpresa, la mayoría sí tenía información de identificación de producto, archivo e información de la compañía. Ya había reconocido Dbghelp.dll y Unicows.dll como Microsoft Windows DLLs [bibliotecas dinámicas de W] por sus nombres. Los otros archivos reclamaron ser parte del producto “Herramientas Esenciales del Sistema” de una compañía llamada “First 4 Internet”:

Ingresé el nombre de la compañía en mi navegador y fui a http://www.first4internet.com/. Busqué el nombre del producto y Aries.sys, pero no encontré nada. Sin embargo, el hecho de que la compañía vendiera una tecnología llamada XCP me hizo pensar que quizá los archivos que encontré eran parte de algún esquema de protección de contenido [no copiar, no duplicar, etc.]. Busqué en Google el nombre de la compañía y me encontré con este artículo, confirmando el hecho de que tenían varios tratos con algunas compañías de grabación, incluyendo Sony, para implementar software de Digital Rights Management (DRM) [Administración de Derechos Digitales] para CDs.

La referencia de DRM me hizo recordar que había comprado recientemente un CD que sólo podía ser reproducido usando el software reproductor que venía con el CD mismo y que te limitaba a un máximo de 3 copias. Escarbé en mis CD’s y lo encontré, Get Right with the Man de Sony BMG (el nombre es irónico por las circunstancias) por Van Zant brothers. No me percaté cuando lo compré de Amazon.com que estaba protegido por software DRM, pero si hubiera mirado más de cerca al texto de Amazon.com hubiera sabido:

La próxima fase de mi investigación fue verificar que el rootkit y sus archivos ocultos eran relacionados con la protección de copia del CD, así que metí el CD al reproductor de CDs e hice doble clic en el ícono para lanzar el software de reproducción, el cual tenía íconos para hacer hasta tres CDs de respaldo con protección de copia:

El Process Explorer mostró que el reproductor era de Macromedia, pero descubrí un incremento de uso de la CPU [el cerebro de tu PC] cuando presioné el botón de play, por $sys$DRMServer.exe, una de las imágenes anteriormente escondidas. Una mirada en la pestaña de Servicios de su diálogo de propiedades de proceso, mostró que contenía un servicio llamado “Plug and Play Device Manager” [Administrador de Dispositivos Plug and Play], lo cual es obviamente un intento de engañar al usuario casual que se encontrara con él en el MMC snapin (services.msc) [da lo mismo que no sepan lo que es, tiene que ver con los Servicios de Windows] haciéndolo creer que es una parte de Windows:

Cerré el reproductor esperando que el uso de CPU de $sys$DRMServer cayera a cero, pero casi me fui de espalda cuando me di cuenta que aún estaba consumiendo entre 1% y 2% de la CPU. Parecía que estaba pagando una multa a la CPU por solo tener el proceso activo en el sistema. Lancé Filemon y Regmon [sácate un programa] para ver qué podría estar haciendo y la búsqueda de Filemon mostró que revisaba los ejecutables correspondientes a los procesos andando en el sistema cada dos segundos, interrogando información básica acerca de los archivos, incluyendo su tamaño, 8 veces en cada revisión. Empecé a perder respeto por los desarrolladores del software rápidamente:

[Aquí de nuevo corté. Tiene la duda de la relación entre lo que hacía el $sys$DRMServer y cómo se comunicaba con el CD, si es que lo hacía. El punto es que sí, lo confirmó y descubrió cómo se comunicaba].

En ese punto ya sabía concluyentemente que el rootkit y sus archivos asociados estaban relacionados con el software de DRM de First 4 Internet que Sony vendía en sus CDs. No feliz con haberle doblado la mano a un software escrito pésimamente en mi sistema busqué por una manera de desinstalarlo. Sin embargo, no encontré ninguna referencia de él en el Panel de Control o en el Agregar y Quitar Programas, ni tampoco encontré ningún utilitario para desinstalarlo o instrucciones en el CD o en el sitio de First 4 Internet. Revisé la EULA y no leí mención del hecho de que estaba de acuerdo en tener que poner software en mi sistema que no podía desinstalar. Ahora estaba indignado.Borré los archivos del controlador y sus claves del registro, detuve el servicio del $sys$DRMServer y borré su imagen, y reinicié. Mientras estaba borrando las claves del registro del controlador bajo HKLM\System\CurrentControlSet\Services me di cuenta que estaban confirmadas como controladores al momento de inicio-partida o miembros de grupos listados por nombre en las subclaves HKLM\System\CurrentControlSet\Control\SafeBoot, lo que significa que cargan incluso en Modo Seguro [Safe Mode, ese modo que se usa cuando Windows muere], haciendo la recuperación del sistema extremadamente difícil si cualquiera de ellos tuviera un error que previniera al sistema de iniciar.Cuando reinicié y me metí de nuevos a Windows descubrí que el CD no estaba en el Explorador. Borrar los controladores había hecho desaparecer el CD. Ahora sí que estaba apestado. Windows soporta “filtrado” de dispositivos, lo que permite a un controlador insertarse a sí mismo por sobre o bajo otro así puede mirar y modificar las peticiones de I/O [entrada/salida] dirigidas al que quiero filtrar. Sé desde mi trabajo anterior con controladores de filtros de controladores de dispositivos [parece trabalenguas] que si tu borras la imagen de un controlador de filtro, Windows falla al echar a andar el controlador al que estoy filtrando. Abrí el Device Manager [Administrador de Dispositivos], desplegué las propiedades de mi CD-ROM, y vi uno de los controladores ocultos, Crater.sys (otro nombre irónico, pues ‘hizo un cráter’ de mi CD) [jo jo jo, humor gringo] registrado como un filtro inferior:

Desafortunadamente, aunque puedas ver los nombre de los controladores de filtros registrados en la pestaña de detalles del dispositivo en los “Filtros Superiores” y en los “Filtros Inferiores” en el Administrador de Dispositivos, no hay una interfaz para borrar los filtros. Los registros de los filtros son almacenados en el Registro bajo HKLM\System\CurrentControlSet\Enum así que abrí Regedit [¿Ven que era útil?] y busqué $sys$ en esa clave. Encontré la entrada que configuraba el filtro inferior del CD:

Borré la entrada, pero obtuve un error de acceso-denegado. Aquellas claves tienen permisos de seguridad que solo permiten a la cuenta del Sistema Local modificarlas, así que relancé Regedit en la cuenta de Sistema Local usando PsExec: psexec –s –i –d regedit.exe. Volví a tratar de borrar, tuve éxito, y busqué por $sys$ de nuevo. Encontré una entrada configurando otro de los controladores, Cor.sys (internamente llamada Corvus), como un filtro superior para el dispositivo del canal IDE [el canal de comunicación donde se conecta el CD-ROM y los Discos Duros IDE] y también lo borré. Reinicié y mi CD había vuelto.La experiencia completa fue frustrante e irritante. SONY no sólo había puesto software que usaba técnicas comúnmente usadas por malware para enmascarar su presencia en mi sistema, el software estaba pobremente escrito y no entregaba formas para desinstalarlo. Peor aún, la mayoría de los usuarios que se atravesaran con los archivos escondidos con una revisión de RKR mutilarían su sistema si intentaran los pasos obvios para borrar los archivos escondidos.

Mientras creo en los derechos de la industria de medios para usar mecanismos de protección de copia para prevenir copias ilegales, no creo que hayamos encontrado el balance correcto entre uso justo y protección de copia, aún. Este es un caso claro de SONY llevando los DRM demasiado lejos.

[Aquí termina el artículo que escribió Mark Russinovich. El original está en http://www.sysinternals.com/blog/2005/10/sony-rootkits-and-digital-rights.html en inglés, no he pedido permiso ni nada pues está transcrito tal cual y sólo es informativo, todos los créditos son de él.

Comenten y pregunten. Aún falta más en esta teleserie, pero lo haremos de a poco pues es mucha información y además es compleja para el no interiorizado en su propio computador y en sus derechos como consumidor de medios. A medida que desarrolle esta noticia irán comprendiendo las implicancias de la situación y se darán cuenta que si no hacemos algo hoy, mañana será demasiado tarde.]

---

Este artículo está traducido y comentado del artículo original de Mark Russinovich por Neurotoxine.