Recapitulando
Ya pasan más de dos meses desde el filtrado de información de Hacking Team, filtración que podríamos calificar claramente como masiva con sus más de 400Gb. de información. La información ha ido poco a poco extendiéndose, expandiéndose a diestro y siniestro, y generando multitud de artículos y reacciones, particularmente en aquellos países en los que alguna agencia gubernamental aparecía como cliente de la empresa en la información filtrada.
Desde los primeros volcados "en bruto" de la información, que han ido replicándose, se ha empezado a disponer de formatos de visualización más especializados en determinados tipos de información a presentar:
- Wikileaks ha publicado los correos filtrados junto con un motor para facilitar las búsquedas.
- El código fuente filtrado se ha publicado en Github.
Las empresas antivirus igualmente se han visto obligadas a "ponerse las pilas" y han comenzado a detectar las instancias de los agentes (aka, troyanos) que despliega el Remote Control System (o RCS) de Hacking Team, como por ejemplo ESET, aunque eso sí, sin dar demasiados detalles.
Otras empresas de software afectadas por los exploits utilizados por el producto de Hacking Team para propagar sus agentes, también se han visto forzadas a "reparar" el lío, como es el caso de Adobe, con el enésimo exploit que afectaba a su complemento Flash. Exploits que según la documentación filtrada Hacking Team adquiría a terceros.
Para Hacking Team, la mañana del lunes 6 de julio en el que se encontraron el lío desplegado desde su propia cuenta de Twitter, también hackeada (cosas de compartir la misma contraseña en varios servicios), sin duda fue un duro despertar.
 |
| La filtración expuesta en la cuenta Twitter de la compañía |
Esa mañana, salvo las apresuradas reacciones de un empleado al borde de un ataque de nervios, ningún comunicado salió de la empresa. De hecho la web de la compañía estuvo parte de ese día caída.
 |
| Primeras reacciones |
No fue hasta dos días después cuando el día 8 apareció un primer comunicado del accidente, que ha sido complementado posteriormente con otro comunicado del CEO de la compañía el pasado día 14 y con un nuevo comunicado el día 22.
En ese primer comunicado la compañía, en boca de su responsable de marketing y comunicaciones exponía con bastante sinceridad en mi opinión, que el código filtrado ponía en manos de cualquiera con los conocimientos adecuados la posibilidad de utilizar la tecnología que habían desarrollado y que hasta ahora solo estaba en manos de gobiernos y agencias gubernamentales. Esto podía facilitar su uso por parte de terroristas y extorsionadores, por lo que describía la situación como "extremadamente peligrosa".
 |
| Primer comunicado oficial |
El último párrafo, el que indica que han solicitado a sus clientes que suspendan cualquier operación en curso que utilice la herramienta, es una obviedad. Lo solicite o no la empresa, cualquier agencia gubernamental de inteligencia medianamente responsable ante tamaña filtración abortará inmediatamente cualquier tipo de investigación que utilice la herramienta filtrada. De hecho, cuando Citizen Labs publicó nuevas investigaciones sobre el RCS de Hacking Team allá por febrero de 2014, agencias como el CNI español desinstalaron los agentes desplegados y "apagaron" el sistema, dejando su uso suspendido preventivamente durante varios meses. Y eso que los únicos datos relevantes que pudo publicar Citizen Labs fueron las direcciones IP de los anonimizadores que utilizaban los agentes interceptados, y quizás la dirección del recolector afectado. Desde luego, nada que ver con la filtración masiva que nos ocupa ahora.
El segundo comunicado es del propio CEO de la empresa, restándole importancia al asunto. Desdice en parte al comunicado anterior indicando que no cree que el código fuente filtrado pueda permitir utilizar la tecnología para realizar ataques a objetivos, código fuente que considera como "obsoleto". Anuncia además, una nueva versión del RCS para permitir a las agencias cliente retomar lo antes posible las investigaciones que estaban realizando con la ayuda del RCS, ahora mismo paralizadas.
También indica que aunque han mantenido relaciones comerciales con países "delicados" como Rusia, Sudán o Etiopía, y que en el momento en el que las circunstancias legales han cambiado, han cortado las relaciones comerciales con los países afectados.
El tercer comunicado, de nuevo por parte del responsable de marketing, se reitera en el comunicado anterior de su CEO, y además muestra su lamento acerca de que la actividad de la compañía es legal, que la única ilegalidad ha sido la intrusión en sus equipos y la comunicación pública de datos confidenciales de la empresa y de sus clientes, y que por contra en los medios son ellos los que aparecen como los supuestos malhechores.
La plataforma Kayako se alimenta con una base de datos MySQL. En dicha base de datos, además de las incidencias, se almacenan los usuarios así como sus credenciales de acceso. Una de las primeras cuestiones sobre las que se puede sacar partido son estas contraseñas. De todos es conocido la inclinación natural de cualquier ser humano a reutilizar las mismas credenciales de acceso en distintos servicios. Es una cosa lógica teniendo en cuenta la gran cantidad de credenciales de acceso que una misma persona puede llegar a atesorar. Y nadie se salva de este pequeño "pecado" en cuanto a la seguridad informática se refiere, ni yo, ni expertos en seguridad informática como los empleados de Hacking Team a tenor de lo ocurrido en su cuenta de Twitter el pasado 6 de julio.
El segundo comunicado es del propio CEO de la empresa, restándole importancia al asunto. Desdice en parte al comunicado anterior indicando que no cree que el código fuente filtrado pueda permitir utilizar la tecnología para realizar ataques a objetivos, código fuente que considera como "obsoleto". Anuncia además, una nueva versión del RCS para permitir a las agencias cliente retomar lo antes posible las investigaciones que estaban realizando con la ayuda del RCS, ahora mismo paralizadas.
También indica que aunque han mantenido relaciones comerciales con países "delicados" como Rusia, Sudán o Etiopía, y que en el momento en el que las circunstancias legales han cambiado, han cortado las relaciones comerciales con los países afectados.
El tercer comunicado, de nuevo por parte del responsable de marketing, se reitera en el comunicado anterior de su CEO, y además muestra su lamento acerca de que la actividad de la compañía es legal, que la única ilegalidad ha sido la intrusión en sus equipos y la comunicación pública de datos confidenciales de la empresa y de sus clientes, y que por contra en los medios son ellos los que aparecen como los supuestos malhechores.
Desnudo integral de Hacking Team frente a sus clientes
No dudo que desde HT podrán retocar su RCS actual, y cambiar las huellas digitales de los agentes para evitar la detección de los antivirus, y volver adquirir nuevos exploits zero-day para sustituir a los filtrados (cosa que, por otro lado, tarde o temprano tenía que ocurrir). Pero el problema principal es recobrar la confianza.
La información filtrada ha comprometido no solo operaciones actuales de agencias gubernamentales, sino también operaciones pasadas. El listado de las direcciones IP de los anonimizadores asignados a cada cliente es un ejemplo. Con ese listado, un mero cruce de esas direcciones IP con los registros de equipos y servidores puede descubrir que un determinado equipo ha sido infectado en el pasado con un agente del RCS, pero es que además la lista permite saber qué agencia es la que operaba dicho agente. El uso que los clientes de Hacking Team hayan hecho de su producto en las operaciones que puedan descubrirse, podrían producir reacciones interesantes, e incluso problemas diplomáticos si a alguna agencia se le ha ido la mano convirtiendo en objetivos a ciudadanos extranjeros o incluso a empleados de embajadas. Imagino que a estas alturas en más de una embajada el administrador de sistemas habrá cruzado los registros del proxy corporativo con la lista de IP's de los anonimizadores filtrada, a ver si el país anfitrión los vigila, aunque si saliera algún positivo de esos cruces de datos puede que nunca se hagan públicos, pero interna y diplomáticamente hablando se puede montar un pollo...
Y la lista de direcciones IP de los anonimizadores es solo un pequeño ejemplo. La cantidad ingente de correos electrónicos no solo revelan cuestiones que a los clientes no les gustaría que se hubieran divulgado, si no en ocasiones opiniones sobre clientes o futuros clientes que los empleados de la empresa compartían vía correo electrónico, opiniones que pueden dificultar relaciones comerciales actuales y futuras. Y pongo dos ejemplos relativos a España, respecto al Grupo de Apoyo Operativo (GAO) de la Guardia Civil y de los Mossos d'Esquadra.
Además de eso, los correos también reflejan las "jugarretas" que los empleados de HT realizaban a sus clientes a la hora de ocultarles errores o problemas en la herramienta de cara a cerrar una venta, o incluso después, como por ejemplo este correo titulado "VIKIS DAP report" en el que uno de los "ingenieros de campo" (Field Application Engineer o FAE en la terminología de la empresa, ingenieros dedicados a tareas de pre-venta y post-venta) relata como él y su compañero (Lorenzo y Serge) ocultaron al cliente, en este caso una agencia gubernamental de Vietnam, los fallos en los test de invisibilidad ante productos antivirus durante las pruebas de aceptación del producto ("Delivery At Place" o DAP). En las pruebas de entrega de producto, el vendedor muestra al cliente que el producto que le suministra ofrece todas las funcionalidades y características contratadas. En caso de que se produzca alguna no conformidad del producto adquirido, el cliente puede negarse a aceptar la entrega, y por tanto no pagar mientras no se solucione la no conformidad. Es por tanto un acto crucial para el vendedor. No digo que HT sea la única empresa en la que sus empleados realizan "trucos de prestidigitación" durante demostraciones a clientes, pero el que se realicen durante las pruebas de aceptación y que además aparezcan evidencias irrefutables de las mismas, y encima con este nivel de difusión, no es algo que suela ocurrir. Traduzco unos párrafos del citado correo:
* Nota de traducción: el "explorador" es el agente más básico del Remote Control System o RCS. Este agente es desplegado inicialmente durante la infección, en este caso usando una vulnerabilidad de la aplicación Office Word de Microsoft. Este agente "explorador" se limita a estudiar el entorno de ejecución para decidir si se actualiza a alguno de los otros dos tipos de agente con verdaderas capacidades operativas, "soldado" o "élite", o si aborta la infección en caso de detectar la presencia de determinadas aplicaciones de seguridad, antivirus o de análisis de malware que pudieran comprometer la operación.
Por si fuera poco, al final del correo su autor concluye:
Estos "juegos de manos" no solo se producían para lograr la aceptación del producto por parte del cliente, sino incluso también en explotación como prueba este otro correo en el que se la juegan al cliente SEPYF (Secretaría de Planeación y Finanzas del Estado de Baja California, México).
Con estos antecedentes, se antoja difícil de cara al futuro la recuperación de la imagen y confianza de HT ante sus clientes, y mucho menos si hablamos del "tipo" de clientes de la empresa, un sector donde el menor atisbo de duda desemboca inexorablemente en el corte de relaciones.
Al igual que los correos electrónicos filtrados en forma de ficheros .pst requieren de una plataforma para visualizar la información correctamente, estas otras bases de datos corresponden a plataformas de gestión documental que requieren de su instalación y configuración para poder visualizar los contenidos de manera adecuada.
Para cada uno de los clientes, la wiki tiene una plantilla preconfigurada para rellenar los datos. En gran parte de los casos la plantilla está sin rellenar, o bien tan solo han rellenado las direcciones IP de los anonimizadores. Pero en otros casos encontramos la plantilla completamente cumplimentada, con datos que incluyen el nombre del cliente, persona o personas de contacto con teléfono y email, dirección postal del cliente, datos del nodo RCS (IP, credenciales del administrador del sistema operativo, credenciales del administrador de RCS, credenciales de acceso remoto por TeamViewer), datos similares del recolector o recolectores, y de otros equipos como NAS, firewalls, switches, y anonimizadores. Igualmente nombres y datos de los usuarios RCS del sistema, e incluso del partner comercial local si lo hubiera.
Hay que tener en cuenta que el sistema parece que se comercializa de dos maneras. Como servicio administrado y mantenido por Hacking Team, donde el cliente es un usuario de explotación del sistema, o bien como sistema completo en el que es el cliente el que administra y mantiene el sistema además de explotarlo.
En aquellos casos en los que RCS se ha comercializado como un servicio para el cliente, parece lógico que la compañía dispusiera de alguna plataforma centralizada y de acceso rápido donde albergar todos los datos necesarios para resolver cualquier incidencia relacionada con el funcionamiento del producto durante su uso por parte del cliente, y es posible que esta wiki, de uso interno para la compañía, jugara ese papel.
En cualquier modo de comercialización, Hacking Team mantiene el control sobre los anonimizadores, y posiblemente los recolectores, que aunque son utilizados por el cliente la contratación y la cuenta "root" de los mismos cae bajo la responsabilidad de Hacking Team. Esto es lógico teniendo en cuenta que si surge alguna emergencia (por ejemplo, un anonimizador comprometido porque unos investigadores de Citizen Labs se ponen a husmear en un equipo troyanizado por el RCS) desde HT pueden ser los primeros en enterarse (entre otras cosas, tienen monitorizadas las muestras que se envían a VirusTotal) y les permite actuar rápidamente para limitar el alcance del problema. Pero por otro lado, por los anonimizadores que HT controla pasan todas las evidencias que los distintos agentes distribuidos en los equipos objetivo capturan, y aunque desde HT permitan a los clientes revisar el código fuente, ya sabemos las mil y una maneras que hay de engañar al cliente...
Además de eso, los correos también reflejan las "jugarretas" que los empleados de HT realizaban a sus clientes a la hora de ocultarles errores o problemas en la herramienta de cara a cerrar una venta, o incluso después, como por ejemplo este correo titulado "VIKIS DAP report" en el que uno de los "ingenieros de campo" (Field Application Engineer o FAE en la terminología de la empresa, ingenieros dedicados a tareas de pre-venta y post-venta) relata como él y su compañero (Lorenzo y Serge) ocultaron al cliente, en este caso una agencia gubernamental de Vietnam, los fallos en los test de invisibilidad ante productos antivirus durante las pruebas de aceptación del producto ("Delivery At Place" o DAP). En las pruebas de entrega de producto, el vendedor muestra al cliente que el producto que le suministra ofrece todas las funcionalidades y características contratadas. En caso de que se produzca alguna no conformidad del producto adquirido, el cliente puede negarse a aceptar la entrega, y por tanto no pagar mientras no se solucione la no conformidad. Es por tanto un acto crucial para el vendedor. No digo que HT sea la única empresa en la que sus empleados realizan "trucos de prestidigitación" durante demostraciones a clientes, pero el que se realicen durante las pruebas de aceptación y que además aparezcan evidencias irrefutables de las mismas, y encima con este nivel de difusión, no es algo que suela ocurrir. Traduzco unos párrafos del citado correo:
- Test de invisibilidad - MacOS (Yosemite) + AVG (instalador desasisitido): durante la infección todo marchó bien; un problema ocurrió justo después de que configuramos el cliente de correo del para permitir al agente interceptar los correos; tan solo unos segundos después de esa configuración, una ventana emergente de AVG alertó sobre la detección de un troyano. Cerré la ventana emergente a tiempo mientras que el cliente estaba atendiendo a las explicaciones de Serge sobre las evidencias recibidas, por lo que el cliente no lo vio. Los correos fueron recuperados correctamente por el agente, pero no tuvimos oportunidad para verificar cuál fue el causante de la detección (nuestro troyano o algún otro);
- Test de invisibilidad - Win7 32bit + Norton Security (Word Exploit): El exploit funcionó correctamente, pero después de la infección el explorador* era detectado en cada inicio de sesión y en cada sincronización. Serge distrajo al cliente, mientras yo añadía el explorador* a la lista de excepciones de Norton, para permitirle actualizarse a élite. Después de eso, todo ha transcurrido correctamente;
* Nota de traducción: el "explorador" es el agente más básico del Remote Control System o RCS. Este agente es desplegado inicialmente durante la infección, en este caso usando una vulnerabilidad de la aplicación Office Word de Microsoft. Este agente "explorador" se limita a estudiar el entorno de ejecución para decidir si se actualiza a alguno de los otros dos tipos de agente con verdaderas capacidades operativas, "soldado" o "élite", o si aborta la infección en caso de detectar la presencia de determinadas aplicaciones de seguridad, antivirus o de análisis de malware que pudieran comprometer la operación.
Por si fuera poco, al final del correo su autor concluye:
Añado una consideración personal: 2 FAEs fueron fundamentales para esta actividad, ya que - y está claro a la vista de lo anterior - uno solo de nosotros se hubiera quedado bloqueado en el primer problema que tuvimos que encarar y el DAP no hubiera sido aceptado.
Estos "juegos de manos" no solo se producían para lograr la aceptación del producto por parte del cliente, sino incluso también en explotación como prueba este otro correo en el que se la juegan al cliente SEPYF (Secretaría de Planeación y Finanzas del Estado de Baja California, México).
Con estos antecedentes, se antoja difícil de cara al futuro la recuperación de la imagen y confianza de HT ante sus clientes, y mucho menos si hablamos del "tipo" de clientes de la empresa, un sector donde el menor atisbo de duda desemboca inexorablemente en el corte de relaciones.
Bases de datos filtradas
También se han filtrado bases de datos que requiere montarlas en el entorno adecuado para poder visualizar los datos adecuadamente. Si los correos exponían información comercial e incidencias técnicas de los clientes, estas bases de datos exponen en el caso de algunas agencias gubernamentales, nombres, direcciones de correo, direcciones postales, hashes de contraseñas usadas por los clientes, logs del RCS funcionando en clientes, etc... Información suficiente para poner en cuarentena las afirmaciones oficiales de la compañía en las que niega que se hayan divulgado datos sobre las investigaciones llevadas a cabo por los clientes usando el RCS.Al igual que los correos electrónicos filtrados en forma de ficheros .pst requieren de una plataforma para visualizar la información correctamente, estas otras bases de datos corresponden a plataformas de gestión documental que requieren de su instalación y configuración para poder visualizar los contenidos de manera adecuada.
Wiki de clientes
La primera de ellas es una wiki de clientes funcionando sobre la plataforma gratuita MediaWiki. Una vez montada la base de datos filtrada, instalado MediaWiki y todo debidamente configurado, podremos acceder al listado de clientes de Hacking Team, ordenado por orden alfabético, o por continentes y países. Esta wiki la han colgado públicamente en abierto en esta dirección.
Para cada uno de los clientes, la wiki tiene una plantilla preconfigurada para rellenar los datos. En gran parte de los casos la plantilla está sin rellenar, o bien tan solo han rellenado las direcciones IP de los anonimizadores. Pero en otros casos encontramos la plantilla completamente cumplimentada, con datos que incluyen el nombre del cliente, persona o personas de contacto con teléfono y email, dirección postal del cliente, datos del nodo RCS (IP, credenciales del administrador del sistema operativo, credenciales del administrador de RCS, credenciales de acceso remoto por TeamViewer), datos similares del recolector o recolectores, y de otros equipos como NAS, firewalls, switches, y anonimizadores. Igualmente nombres y datos de los usuarios RCS del sistema, e incluso del partner comercial local si lo hubiera.
Hay que tener en cuenta que el sistema parece que se comercializa de dos maneras. Como servicio administrado y mantenido por Hacking Team, donde el cliente es un usuario de explotación del sistema, o bien como sistema completo en el que es el cliente el que administra y mantiene el sistema además de explotarlo.
En aquellos casos en los que RCS se ha comercializado como un servicio para el cliente, parece lógico que la compañía dispusiera de alguna plataforma centralizada y de acceso rápido donde albergar todos los datos necesarios para resolver cualquier incidencia relacionada con el funcionamiento del producto durante su uso por parte del cliente, y es posible que esta wiki, de uso interno para la compañía, jugara ese papel.
En cualquier modo de comercialización, Hacking Team mantiene el control sobre los anonimizadores, y posiblemente los recolectores, que aunque son utilizados por el cliente la contratación y la cuenta "root" de los mismos cae bajo la responsabilidad de Hacking Team. Esto es lógico teniendo en cuenta que si surge alguna emergencia (por ejemplo, un anonimizador comprometido porque unos investigadores de Citizen Labs se ponen a husmear en un equipo troyanizado por el RCS) desde HT pueden ser los primeros en enterarse (entre otras cosas, tienen monitorizadas las muestras que se envían a VirusTotal) y les permite actuar rápidamente para limitar el alcance del problema. Pero por otro lado, por los anonimizadores que HT controla pasan todas las evidencias que los distintos agentes distribuidos en los equipos objetivo capturan, y aunque desde HT permitan a los clientes revisar el código fuente, ya sabemos las mil y una maneras que hay de engañar al cliente...
Plataforma de incidencias
Otra base de datos que encontramos entre la información filtrada, y que alberga información mucho más delicada, es la propia plataforma de incidencias mediante la que los clientes de Hacking Team se comunicaban con la compañía con dudas propias del uso del sistema surgidas durante su uso, tanto en operaciones reales como en operaciones simuladas para pruebas y entrenamiento.
En este caso lo que se ha filtrado ha sido el contenido completo del servidor Linux que hospedaba dicha plataforma de incidencias, y que era accesible en la dirección support.hackingteam.com. Buceando por los distintos directorios de dicho servidor, es posible extraer los datos necesarios para volver a montar la plataforma y visualizar lo que contenía en el momento en el que se efectuó la copia.
Para la plataforma de incidencias, Hacking Team utilizaba un producto comercial con licencia de pago anual denominado Kayako. La plataforma, construida sobre PHP, dispone de tres modos de acceso (usuarios, empleados y administradores), cada uno con distintas finalidades y funcionalidades. Las credenciales de acceso son el típico correo electrónico con una contraseña asociada a elección del usuario.
Credenciales de acceso
La plataforma Kayako se alimenta con una base de datos MySQL. En dicha base de datos, además de las incidencias, se almacenan los usuarios así como sus credenciales de acceso. Una de las primeras cuestiones sobre las que se puede sacar partido son estas contraseñas. De todos es conocido la inclinación natural de cualquier ser humano a reutilizar las mismas credenciales de acceso en distintos servicios. Es una cosa lógica teniendo en cuenta la gran cantidad de credenciales de acceso que una misma persona puede llegar a atesorar. Y nadie se salva de este pequeño "pecado" en cuanto a la seguridad informática se refiere, ni yo, ni expertos en seguridad informática como los empleados de Hacking Team a tenor de lo ocurrido en su cuenta de Twitter el pasado 6 de julio.
Es de suponer que si a los propios expertos les ocurre esto, a algunos de sus clientes, a pesar de ser empleados de agencias de inteligencia y cuerpos de seguridad gubernamentales para los que los temas de seguridad informática constituyen su día a día, lo de la reutilización de credenciales en distintos servicios también puede ocurrir... por lo que las credenciales almacenadas en el servidor de soporte filtrado son susceptibles de estar siendo utilizadas por el mismo usuario en otros servicios distintos.
Analizando este caso en particular, Kayako, como era de esperar, no almacena las contraseñas de los usuarios usando texto en claro. En nuestro caso, la plataforma almacena el hash SHA1 de la contraseña, pero sin "salpimentar" de ninguna manera. Aunque SHA1 no es un algoritmo reversible, se puede empezar probando con un ataque basado en un buen diccionario, y enseguida nos daremos cuenta de que a pesar de estar tratando con contraseñas definidas por usuarios con una supuesta formación en seguridad informática, el ataque basado en diccionario nos escupe una tasa de éxitos del entorno al 20%, menor que la de una colección de credenciales de usuarios estándar que se puede situar en un 35% o más, pero más alta de lo que cabía esperar de usuarios con este perfil. Entre el listado de positivos podemos encontrar contraseñas tan imaginativas como "ticket"... aunque por otro lado hay que reconocer que esta contraseña difícilmente habrá sido reutilizada por el mismo usuario en otros servicios...
El 80% restante de contraseñas, que no saltan con un mero ataque de diccionario, quedan a las ganas, a la capacidad de proceso disponible, o de los servicios que cada uno desee contratar (que los hay), el tratar de obtenerlas por fuerza bruta pura. Además, el que la plataforma no añada "sales" a la contraseña antes de calcular el hash que almacena en base de datos facilita el uso de tablas precalculadas, como las tablas rainbow.
El botín puede tener su utilidad si alguna de estas credenciales se reutiliza en otros servicios. Desde el punto de vista de la plataforma de incidencias filtradas, el obtener las contraseñas no tiene sentido ya que si queremos acceder impersonando a cualquiera de los usuarios existentes, tan solo tenemos que acceder a la base de datos MySQL y cambiar el SHA1 de la contraseña del usuario deseado por el SHA1 de una contraseña conocida. Es de suponer que desde Hacking Team habrán advertido ya a sus clientes acerca de la vulneración de sus correos y contraseñas registrados en la plataforma de incidencias.
El botín puede tener su utilidad si alguna de estas credenciales se reutiliza en otros servicios. Desde el punto de vista de la plataforma de incidencias filtradas, el obtener las contraseñas no tiene sentido ya que si queremos acceder impersonando a cualquiera de los usuarios existentes, tan solo tenemos que acceder a la base de datos MySQL y cambiar el SHA1 de la contraseña del usuario deseado por el SHA1 de una contraseña conocida. Es de suponer que desde Hacking Team habrán advertido ya a sus clientes acerca de la vulneración de sus correos y contraseñas registrados en la plataforma de incidencias.
Accediendo a la información de la plataforma de soporte
Volviendo a la plataforma Kayako y sus modos de acceso, el modo de acceso más básico es el utilizado por los clientes de la empresa, al acceder a la URL https://support.hackingteam.com. Estos usuarios se encuentran englobados dentro de una determinada organización (como puede ser en el caso español "CNI"), y por tanto las incidencias introducidas por un usuario, así como las respuestas a las mismas, son visibles para ese usuario y para el resto de usuarios de la misma organización.
Los otros dos modos de acceso están reservados para empleados de la empresa. Por un lado los empleados con privilegios solo para atender a las solicitudes de los clientes, con acceso mediante la URL https://support.hackingteam.com/staff, y por otro los empleados que además gozan de privilegios de administración sobre la propia plataforma de incidencias, que acceden por https://support.hackingteam.com/admin.
Al entrar en la plataforma como usuario "admin" pero desde el enlace para empleados podremos acceder a todos los tickets creados en el sistema, independientemente del empleado en cuestión al que fuera asignada cada incidencia.
Lo primero que encontramos son noticias publicadas por HT para información de todos sus clientes. En la captura anterior se puede apreciar una referente a la herramienta DETEKT, creada por Claudio Guarnieri, investigador de Citizen Labs y coautor de Cuckoo Sandbox y Malwr, intentando tranquilizar a los clientes con respecto a la efectividad de dicha herramienta. Otras noticias referencian también a otros informes de Citizen Labs, como el publicado el 17 de febrero de 2014 recordando la necesidad de configurar los recolectores de manera que el puerto HTTP solo sea alcanzable desde las IP's de los anonimizadores asignados.
El administrador de la plataforma de soporte de HT ha organizado los tickets en seis grupos:
La información que se puede extraer de los tickets presentes en la base de datos (1.182 incidencias desde inicios del año 2.015 hasta el 26 de junio) es enorme. Por ejemplo, sin quebrarnos mucho la cabeza podemos sacar estadísticas que muestren qué organizaciones cliente de HT son las más activas en la plataforma de soporte, lo que puede dar una idea de qué clientes son los que utilizaban más activamente la herramienta RCS. En la gráfica, por simplificar, solo se han incluido los clientes que tienen creados más de 10 tickets.
De los seis grupos de incidencias, los más jugosos son los de peticiones de exploits y por otro lado los de seguridad.
Los primeros son solo para clientes que han contratado el servicio de vectores de infección remotos, o bien que tengan una licencia de demostración de dicho servicio. Mediante este servicio, los clientes generan con su RCS un instalable silencioso del agente "explorador"(cada agente generado lleva embebido identificadores que permiten a HT determinar qué cliente lo ha generado), que lo envían adjunto a un ticket de petición de exploit, junto con otros archivos o información adicionales dependiendo del tipo de vector de infección a generar (para móviles Android 4.3.* o inferiores, o para equipos de escritorio mediante archivo de Office o por URL usando un bug del "apreciado" Adobe Flash). Todo aparece claramente explicado en este ticket dirigido precisamente al CNI español apenas cuatro días antes de la filtración.
La filtración de la información enviada por los clientes en estas peticiones de exploits pueden dejar al descubierto actividades realizadas por los mismos, y con todas las consecuencias que pueden acarrear. Por ejemplo, en caso de que la infección se realice mediante un archivo de Office, el contenido del archivo utilizado para la infección puede determinar el perfil del objetivo a infectar. En gran parte de los casos el contenido es muy neutro, pero en otros casos se puede determinar que el objetivo tiene tintes claramente políticos. También las URL utilizadas para realizar infecciones pueden permitir identificar qué agencia estaba operando, al cruzar esos datos con los datos expuestos en informes de ataques como los relatados por Citizen Labs en los que hasta ahora la identidad del atacante ha permanecido en el anonimato.
Como aperitivo para una posible entrada futura sobre el tema de peticiones de exploits (hay mucho que contar) una gráfica similar a la anterior pero incluyendo solo los tickets de petición de exploits por cliente, y listando solo aquellos que han hecho más de una petición.
Hay que destacar que la gráfica solo muestra número de tickets. Cada ticket puede incluir una petición para uno o más vectores de infección. Cada vector de infección solo se puede usar una única vez. Una vez que un objetivo usa el vector, éste se desactiva, evitando en gran medida el filtrado de vectores de infección que pudieran caer en manos de investigadores de la comunidad antivirus. Salvo los primeros, que quizás estén haciendo pruebas, algunos clientes destacan por una clara vocación vírica.
Por otro lado, en los tickets de seguridad se exponen problemas de confidencialidad de las actividades realizadas por los clientes de HT, ya sean dudas iniciadas por los propios clientes, o bien alertas de exposición pública de direcciones IP de la infraestructura RCS de alguno de sus clientes.
Al igual que las peticiones de exploits, las direcciones IP que aparezcan como comprometidas en algún ticket de seguridad, también pueden permitir identificar al atacante al cruzar dichos datos con informes de ataques ocurridos previamente.
Además de los tickets incluídos en la base de datos de Kayako en el momento de la copia (tickets desde inicio de 2015 hasta el 26 de junio) se encuentran además copias de seguridad de la base de datos con tickets de años anteriores. Mucha información sensible para examinar.
 |
| Pantalla de acceso a la plataforma de soporte para clientes |
 |
| Interfaz de soporte para empleados |
 |
| Interfaz de administración para administradores |
Lo primero que encontramos son noticias publicadas por HT para información de todos sus clientes. En la captura anterior se puede apreciar una referente a la herramienta DETEKT, creada por Claudio Guarnieri, investigador de Citizen Labs y coautor de Cuckoo Sandbox y Malwr, intentando tranquilizar a los clientes con respecto a la efectividad de dicha herramienta. Otras noticias referencian también a otros informes de Citizen Labs, como el publicado el 17 de febrero de 2014 recordando la necesidad de configurar los recolectores de manera que el puerto HTTP solo sea alcanzable desde las IP's de los anonimizadores asignados.
 |
| Noticia en el portal de soporte referente al informe de Citizen Labs del 17/02/2014 |
El administrador de la plataforma de soporte de HT ha organizado los tickets en seis grupos:
- General
- Peticiones de exploits
- Incidencias de anonimizadores
- Licencias
- Seguridad
- Actualizaciones
La información que se puede extraer de los tickets presentes en la base de datos (1.182 incidencias desde inicios del año 2.015 hasta el 26 de junio) es enorme. Por ejemplo, sin quebrarnos mucho la cabeza podemos sacar estadísticas que muestren qué organizaciones cliente de HT son las más activas en la plataforma de soporte, lo que puede dar una idea de qué clientes son los que utilizaban más activamente la herramienta RCS. En la gráfica, por simplificar, solo se han incluido los clientes que tienen creados más de 10 tickets.
Los primeros son solo para clientes que han contratado el servicio de vectores de infección remotos, o bien que tengan una licencia de demostración de dicho servicio. Mediante este servicio, los clientes generan con su RCS un instalable silencioso del agente "explorador"(cada agente generado lleva embebido identificadores que permiten a HT determinar qué cliente lo ha generado), que lo envían adjunto a un ticket de petición de exploit, junto con otros archivos o información adicionales dependiendo del tipo de vector de infección a generar (para móviles Android 4.3.* o inferiores, o para equipos de escritorio mediante archivo de Office o por URL usando un bug del "apreciado" Adobe Flash). Todo aparece claramente explicado en este ticket dirigido precisamente al CNI español apenas cuatro días antes de la filtración.
La filtración de la información enviada por los clientes en estas peticiones de exploits pueden dejar al descubierto actividades realizadas por los mismos, y con todas las consecuencias que pueden acarrear. Por ejemplo, en caso de que la infección se realice mediante un archivo de Office, el contenido del archivo utilizado para la infección puede determinar el perfil del objetivo a infectar. En gran parte de los casos el contenido es muy neutro, pero en otros casos se puede determinar que el objetivo tiene tintes claramente políticos. También las URL utilizadas para realizar infecciones pueden permitir identificar qué agencia estaba operando, al cruzar esos datos con los datos expuestos en informes de ataques como los relatados por Citizen Labs en los que hasta ahora la identidad del atacante ha permanecido en el anonimato.
Como aperitivo para una posible entrada futura sobre el tema de peticiones de exploits (hay mucho que contar) una gráfica similar a la anterior pero incluyendo solo los tickets de petición de exploits por cliente, y listando solo aquellos que han hecho más de una petición.
Hay que destacar que la gráfica solo muestra número de tickets. Cada ticket puede incluir una petición para uno o más vectores de infección. Cada vector de infección solo se puede usar una única vez. Una vez que un objetivo usa el vector, éste se desactiva, evitando en gran medida el filtrado de vectores de infección que pudieran caer en manos de investigadores de la comunidad antivirus. Salvo los primeros, que quizás estén haciendo pruebas, algunos clientes destacan por una clara vocación vírica.
Por otro lado, en los tickets de seguridad se exponen problemas de confidencialidad de las actividades realizadas por los clientes de HT, ya sean dudas iniciadas por los propios clientes, o bien alertas de exposición pública de direcciones IP de la infraestructura RCS de alguno de sus clientes.
Al igual que las peticiones de exploits, las direcciones IP que aparezcan como comprometidas en algún ticket de seguridad, también pueden permitir identificar al atacante al cruzar dichos datos con informes de ataques ocurridos previamente.
Además de los tickets incluídos en la base de datos de Kayako en el momento de la copia (tickets desde inicio de 2015 hasta el 26 de junio) se encuentran además copias de seguridad de la base de datos con tickets de años anteriores. Mucha información sensible para examinar.
No hay comentarios:
Publicar un comentario