Como parte de nuestra obra social, buscamos adoptar a gente con problemas pero, con esto de la crisis, las plazas son limitadas. Por ello, todos aquellos interesados en asistir deben enviar una propuesta de charla a $(echo “tubggA59cjut/dpn” | perl -pe ‘s/(.)/chr(ord($1)-1)/ge’) y ser seleccionados.

Algunas de nuestras preferencias:

- hardware bugs/hacking.
- malware / reversing / eCrime o no lo é (esta es mía jiji)
- private stuff / 0days
- hacking ufos, ground vehicles,..
- payment systems: EMV, NFC
- Wireless comunications (WI-FI, bluetooth, satellite, telequinesis, … )
- DoS attacks o TreS

Además de la asistencia (con los ojos vendados), tendréis ración extra de pulpo (lo que deje Mario de la suya) y licor cafe (un chupito).

GRAZIAS DE HANTEBRAZO

UPDATE (by matalaz): Puedes ser una maravillosa persona o el/la mayor h*p* redomado/a sobre la faz de la tierra que el método para ir a LaCON es el mismo. Si quieres venir, tienes que envíar una propuesta de txarla y, si sale seleccionada, entonces y solo entonces podrás ir. Por lo demás, si te estás preguntando si puedes ir o no, la respuesta es no.

English version of this post can be found here

Durante los últimos 4 años he dedicado casi todo mi tiempo de investigación personal a estudiar la seguridad de los sistemas de comunicación y navegación aeronáuticos, tanto en tierra como en las propias aeronaves. Tras todo este tiempo creo que he llegado a interesantes conclusiones y he hecho bastantes descubrimientos que podría ser interesante publicar.

Así pues, con este primer post pretendo iniciar una serie de artículos en los que ir exponiendo poco a poco el proceso que he seguido, los problemas y soluciones que me he encontrado así como los resultados y conclusiones a los que he llegado.

¿Aviones? ¿Estas de broma?

Sí, sí, has leído bien, todo esto va de AVIONES; realmente va de aeronaves pero tampoco nos vamos a poner técnicos tan pronto. La pregunta más habitual llegado este punto es: ¿a qué clase de mente perturbada se le puede ocurrir algo así?. Es cierto que no es algo habitual pero tiene una explicación… o no; veamos un poco de historia.

Todo esto comenzó un día que estaba buscando nuevos sistemas en los que encontrar vulnerabilidades. Por aquel entonces me dedicaba a los sistemas SCADA y, como aparte de ser investigador de seguridad  uno es piloto comercial, de repente me surgió una pregunta: ¿habrá algún sistema abordo de un avión lo suficientemente complejo como para poder tener vulnerabilidades? Y así empezó todo…

A una respuesta afirmativa para esa primera pregunta, surgieron nuevas preguntas y… aquí estamos años después

Hoja de ruta

Ahora que ha pasado tanto tiempo, y he avanzado mucho en esta investigación, no voy a seguir los mismos pasos en estos artículos que los que seguí durante mi investigación; voy a intentar seguir un camino más ordenado, más teniendo en cuenta que habrá que introducir bastantes conceptos aeronáuticos que yo ya poseía de entrada.

A estas alturas puedo enfocar el estudio usando una metodología más clásica, algo que no creía que fuese posible cuando empecé yo, así que intentaremos seguir los mismos pasos (aproximadamente) que seguiríamos a la hora de atacar cualquier otro sistema de los que estamos acostumbrados:

A grandes rasgos intentaré seguir el diagrama anterior, intercalando todas las explicaciones de conceptos nuevos que sean necesarias, y teniendo en cuenta que se trata de un trabajo de investigación de un sistema nuevo y no de un ataque convencional, por lo que habrá mucho de investigación y desarrollo. Veamos cada una de las fases un poco más en más detalle:

Descubrimiento

Tras unas primeras entradas introductorias dedicadas a presentar los conceptos necesarios, se estudiarán aquellos sistemas de navegación y comunicación que nos permitirán listar e identificar aeronaves específicas así como realizar su posterior seguimiento.

¿Y tú que creías saber de redes Wifi, eh?

Enumeración

Una vez visto como listar y localizar objetivos concretos se verán diferentes opciones para extraer toda la información posible de los objetivos seleccionados. La finalidad de esta fase es la misma que en los ataques convencionales: conseguir toda la información posible para usar en la fase de explotación.

Esto… que alguien le pregunte a Chemita si su FOCA tiene algo que decirnos al respecto, o se le ha comido la lengua una ORCA

Explotación

En esta fase se estudiarán varios sistemas, tanto embarcados como de tierra, en busca de vuelnerabilidades que se puedan explotar (ambas locales y remotas) para tomar el control de los sistemas vulnerables. Si bien el objetivo no es el de explotar protocolos inseguros con ataques tipo MitM, spoofing, etc, ese tipo de ataques también se incluirán en el estudio.

En resumen: fuzzing, ingeniería inversa, arquitecturas raras y toneladas de ensambladores varios!

Post-explotación

Por último se estudiarán tanto los conceptos habituales para comprometer otros sistemas a partir del sistema explotado como las peculiaridades de explotar un entorno tan novedoso como puede ser una aeronave. Todos sabemos qué hacer con un servidor web comprometido pero… ¿y con un avión? ¿será el botón rojo?

¡Sr Moore, Sr Moore! ¿Y el meterpreter me sirve para esto?

Al igual que ocurre durante un ataque clásico, estas fases forman parte de un proceso cíclico por lo que tras una fase de explotación o post-explotación puede repetirse el ciclo completo varias veces.

Notas finales

Como podréis comprender se trata de un estudio bastante delicado, por lo que ya adelanto que no se liberarán exploits o vulnerabilidades que puedan ser usados de forma irresponsable contra aeronaves (cri cri! cri cri! el auditorio se queda vacío…), ese no es el objetivo de esta serie de artículos. Se pretende ilustrar el proceso de estudiar un sistema poco habitual, exponer el estado de la seguridad del mismo y aprender todo lo posible en el proceso.

Nota: Esta es una historia real basada en hechos ficticios

Estaba un día trabajando en casa de mi primo y necesitaba acceso a la internet, por lo que obviamente le pedí la clave de la WiFi y de muy buena gana me la proporcionó, a lo cuál le agradecí su tan generoso gesto.

Para proseguir con mi actividad productiva necesitaba redirigir un puerto hacia mi máquina así que, dado que las cualidades técnicas de mi primo no van mas allá del facebook, decidí hacerlo sin preguntar y aquí comienza realmente la historia.

Me conecté al Router y comencé a probar las N combinaciones de cuentas de administrador que me conocía y alguna más que busqué por la web:

Sin resultado satisfactorio, me dirigí a mi primo con la oreja gacha herido en el orgullo hacker para preguntarle el usuario y contraseña, a lo cual me respondió con un “no se de que me hablas”. Perfecto, estaba apunto de arruinar un día entero de trabajo…

El siguiente paso fue intentar escalar privilegios desde una cuenta de usuario para consultar, por suerte éste router tenía la contraseña por defecto user/user habilitada, pero obviamente no permitía cambiar ningún parámetro, primero los pasos básicos para obtener shell de alguna manera:

Vaya por dios, parece que se han tomado en serio la seguridad los que han hecho esta versión de firmware! Pensemos durante unos segundos qué más podríamos probar:

Bingo! Parece que tenemos una manera de ejecutar comandos, sigamos jugando un poco más:

Perfecto, ya tenemos la clave de admin que era lo que necesitábamos; después de preguntar a nuestro amigo John pude redirigir el puerto que necesitaba. Pero ya quee no parece tener la shell disponible facilmente seguí un vistazo a ver qué podemos sacar desde la cuenta de admin.
Como se puede ver a continuación, tiene mucho más comandos, en concreto me llama la atención el comando echo:

Con el comando echo podemos ver la salida completa de los comandos ejecutados! Exploremos a ver que tiene este dispositivo:

Wow, hay un nc por ahí! Podremos usarlo para copiar ficheros dentro y fuera del mismo? Además tenemos un md5sum que nos viene perfecto para ver si la copia ha sido satisfactoria. Probemos con el binario /bin/httpd:

Comprobando en mi PC:

Funciona perfectamente! Probemos a enviar un fichero…

Y en el router:

Ya que tenemos el nc y que andar ejecutando comando a golpe de echo es un poco coñazo, una reverse shell nos vendría de lujo! Let’s try it, primero ponemos a escuchar el nc en el router:

Y después nos conectamos desde el PC:

Yeah! Pues nada, ahí tenemos control total de manera remota y ya podemos seguir jugando más comodamente, aunque eso será para otra entrada en el blog!

No me sigas por la calle! Sígueme por el twitter http://www.twitter.com/gabrielgonzalez

En este post os voy a hablar un poco de como he escrito un motor de análisis de código para x86 y x86_64, de los problemas que me he encontrado y de como he intentado solucionarlos (los que he arreglado, vamos…).

Hace ya algún tiempo que comencé con un proyecto llamado Pyew (similar al todo poderoso radare) el cual está pensado, principalmente, para análisis de baterías de malware. Se podría utilizar el IDA para ello pero, en ocasiones, esta herramienta es un poco pesada y, además, requiere una licencia (no muy barata, por cierto) que no todo el mundo tiene.

Comienzo

Al lío. Para hacer un reemplazo ligero del IDA para analizar malware se necesitan como mínimo 3 cosas:

1. Un cargador de formatos de ficheros: Para PE, ELF, Mach-O o lo que sea que te interese. En mi caso he utilizado Python PEFile para PEs y VTrace para ELFs.
2. Un desensamblador para el procesador: En mi caso, elegí Distorm64 (la versión 2) ya que tiene buen soporte para Python y soporta código x86 de 16, 32 y 64 bits.
3. Un motor de análisis de código: Esta es la pieza clave que no pude ‘coger de por ahí’ fácilmente, sino que me la tendría que escribir desde “0″ (bueno, la verdad es que se podría utilizar radare, pero preferí escribirlo por mi cuenta y aprender algo de paso).

Análisis de código

En este caso, la función que estamos analizando, comienza en la instrucción TEST, en 0xa950 y el bloque básico acaba en el primer salto condicional, en la instrucción JZ (en 0xa957). Ahora tenemos 2 posibles caminos que tomar: en caso de que la condición se cumpla (saltando a 0xa9c3) y el caso contrario, en el cual continuaría con la siguiente instrucción. ¿Cuándo terminaríamos de analizar esta función? Cuando llegamos a la instrucción RET, en 0xa9c4, que es donde acaba el último basic block y ya la función (porque no hay más caminos posibles que seguir).

Grafo de la sencilla función comentada

Mientras vamos siguiendo el flujo del programa descubriendo nuevas rutas de código, guardamos las llamadas a función, las ponemos en una lista y, al acabar con la función actual, se continúa con las funciones (direcciones) que se hayan encontrado. Hasta aquí todo muy bien y muy fácil. ¿Y con esto se descubren todas las funciones y todos los bloques básicos de una función? Ni mucho menos.

Bloques básicos

Antes había dicho que un bloque básico de una función es un conjunto de instrucciones seguidas hasta un salto condicional, no? Bueno, pues no exactamente. Pongamos un ejemplo fácil:

En este caso, en el primer bloque básico llegamos a un salto incondicional (JMP) y, siguiendo ese salto, encontramos después un salto condicional (JLE) a la dirección 0x3d3.  Las instrucciones desde 0x3c5 hasta 0x3d1 y 0x3ef a 0x3f3 no forman un único bloque básico, por una razón: un bloque básico solo puede tener un único punto de entrada. Así pues, lo que inicialmente creíamos que es un bloque básico hay que separarlo en piezas más pequeñas, de modo que cada bloque tenga solo un único punto de entrada (no así de salida). El grafo de flujo para esta función quedaría como sigue:

Grafo de la función con bloques básicos que no cumplen la lóǵica explicada inicialmente.

Ahora ya sabemos como tiene que ser un bloque básico correctamente y, teniendo en cuenta esto, ¿Tendríamos ya un motor de análisis de código funcional? Ni mucho menos.

Punteros a función

Los punteros a función son un quebradero de cabeza a la hora de analizar código estáticamente para encontrar funciones. ¿Porqué? Pongamos un ejemplo con el siguiente código en C:

Si compilamos este código (con GCC en mi caso) se generará el siguiente código ensamblador:

Realmente, no tenemos ninguna ruta de código a esa función así que, siguiendo la lógica actual de nuestro motor, no encontraremos la función “func”. ¿Soluciones? Varias, una de ellas, la más compleja, es trackear los argumentos y sus valores (haciendo una especie de mini-emulación). Si una dirección es pasada como argumento a una función y después se ejecuta esa dirección, pues sabemos que es un puntero a función, así que esa dirección la metemos en la cola de direcciones a analizar y listo.

Sin embargo, esta solución tampoco es 100% correcta. ¿Porqué? Imaginemos que la función que se encarga de ejecutar el puntero que le pasamos está en una librería, no en el binario que estamos ejecutando: como no tenemos el código de la librería (no se encuentra en el binario que estamos analizando) no sabemos que hará con esa dirección que se le pasa. Mi solución para esto es la siguiente: cada  vez que se referencia una dirección a un segmento ejecutable, esta dirección la pongo en la cola para posterior análisis. De este modo, muchas funciones de este tipo se podrían descubrir.

Aún así, tenemos otro problema más: ¿Y si el puntero se calcula en ejecución? Pues estamos jodidos, básicamente. Podemos intentar otras soluciones, como la siguiente.

Prólogos de función

El modo más típico de búsqueda de funciones es la búsqueda de prólogos de función. Por ejemplo, para x86 (32 bits) el siguiente es un prólogo típico:

Podríamos, simplemente, buscar los opcodes de este prólogo de función en los segmentos con permisos de ejecución (no necesariamente, ya que para malware, puede ser que se encuentre código en segmentos que no tienen permisos de ejecución y que luego se copien a una zona de memoria donde sí se tengan privilegios)  y, si esa dirección no corresponde con ninguna función ya analizada, poner dichas direcciones en la cola de análisis. Así se pueden encontrar muchas funciones que de otro modo, probablemente, no encontraríamos.

Pero, como siempre con el análisis de código, esta técnica tiene la oxtia de problemas: ¿Y si los opcodes que he encontrado corresponden a ese prólogo pero realmente no es una función? Este problema no es tan fácil de solucionar, la verdad. Mi solución es seguir desensamblando, buscando si el código tiene sentido (encuentro rutas de código que no se van a casa krixto, encuentro bloques básicos bien formados, etc…). Aún así, esta solución es solo parcial: ¿Qué ocurre si, por casualidad, resulta que encuentro una zona que parece código correcto y no lo es? La posible solución (que en Pyew no la he puesto aún) es asegurarse que el epílogo de función coincida. Esto es, si el prólogo de función típico de x86 es PUSH EBP & MOV EBP, ESP; habrá que buscar su epílogo correspondiente en los bloques básicos de salida, que es LEAVE & RET. Aún así, esto tampoco sería correcto, un ejemplo:

Esto podría ser un código perfectamente válido. La función recibe un argumento y salta inconicionalmente (que no llama) a la dirección pasada más un offset (una VTable, por ejemplo). La función a la que salta es la que, realmente, se encarga de arreglar la pila antes de retornar, es decir, es en esa zona de memoria donde se encuentra el epílogo de función.

De todos modos, vamos a suponer que ‘mágicamente’ tenemos solucionado también este problema. ¿Se podría decir que el motor está finalizado? Ni mucho menos: la búsqueda de prólogos de función es un coñazo porque hay múltiples prólogos de función. Por ejemplo, si desensamblamos ejecutables de Microsoft (librerías de Windows, el notepad, lo que sea) nos encontraremos que los prólogos a función no son como había puesto antes, sino así:

Así que nuestro motor de análisis de código no estaría encontrando el principio de la función, si no que estaríamos saltándonos una instrucción. La solución es buscar más prólogos: en vez de buscar solo PUSH EBP & MOV EBP, ESP, buscamos también con MOV EDI, EDI antes. Pero aún así, no vamos a encontrar todas las funciones del binario. ¿Porqué? Por la convención de llamadas de cada función, entre otras n-mil cosas.

Convenciones de llamada

Cada compilador, arquitectura, etc… tiene una serie de convenciones de llamadas, siendo las más típicas (x86) CDECL y STDCALL. La diferencia principal entre estas 2 convenciones de llamadas es la siguiente: en CDECL es el que llama a la función el que se encarga de restaurar la pila, mientras que en STDCALL es la función llamada la que tiene que restaurar la pila. En ambos casos, el prólogo de función cambiará, así que estamos jodidos.

Por si esto fuera poco, estas 2 no son las únicas convenciones de llamadas existentes. Tenemos otras más, como por ejemplo FASTCALL (la cual, por cierto, es implementada por cada fabricante como se le pone de los huevos), PASCAL, THISCALL o incluso podemos tener convenciones de llamada no estándar que el compilador ha decidido meter “así” porque resultaban más eficientes o usaban menos espacio.

Pero este no es el final de los problemas, aún tenemos otros todavía más gordos…

El coño de la Bernarda (también llamado contrucciones “switch”)

Un switch es una sentencia condicional que en función del valor comprobado tomará una ruta u otra o, incluso, varias. ¿Cómo se imlementa un switch en ensamblador? Cada compilador lo hace como se le pone de ahí. El modo más típico es el siguiente: tener una tabla de offsets a función y llamar a un registro (donde está la dirección de esa tabla) “+” un offset, que sería el índice dentro de la tabla. Este es el modo más típico para un switch medio/grande. Veamos un ejemplo con el siguiente grafo visto en IDA:

Ejemplo de switch sencillo (GCC, 32bits)

Si miramos el bloque básico que tiene varias salidas nos encontraremos con el siguiente código ensamblador:

IDA ha encontrado que la dirección 0×8048670 es una tabla de offsets (direcciones) a los bloques básicos que ha unido después. Es decir, ha encontrado un switch. ¿Cómo lo ha hecho IDA? Analizando el código que se encuentra en ese offset que ha encontrado que luego se accede al mismo por índice (0x0804842E) y que después hay un salto incondicional al valor que haya obtenido. Así que, si nosotros hacemos lo mismo en nuestro motor ¿Ya tendríamos soporte para sentencias switch? Ni de lejos… Cada compilador y cada arquitectura tiene varios tipos diferentes de dialecto de switch. Unos crean tablas como la que aquí se muestra. Otros, lo hacen accediendo a zonas de memoria relativa obteniendo la posición en ejecución. Un ejemplo (escrito a mano, que ahora mismo no encuentro ningún binario):

En este ejemplo, el compilador ha decidido que era mejor (por algún motivo) coger la dirección relativa de la tabla de funciones obteniendo la dirección de la función actual (de ahí el CALL +5 & POP EAX, para saber la dirección de la instrucción que se está ejecutando en ese momento).

Otra cosa que estoy obviando: estoy suponiendo que la tabla donde se apunta a las direcciones de los bloques básicos son contiguas y que son completas, osea, que estará del modo siguiente:

Sin embargo, esto no tiene porque ser así. En muchos casos me he encontrado que lo que realmente hay son direcciones relativas. Es decir, en vez de la dirección virtual completa nos encontramos simplemente el último WORD de la dirección. Por ejemplo, en vez de encontrarte una dirección como 0×08048436, te encontrarías con la dirección 0×8436, a la cual luego se le sumaría la base 0×08040000. O, aún peor, que lo que hay son las diferencias entre direcciones, es decir, el resultado de restar la dirección anterior de la actual. Y así podría seguir hasta aburriros y no acabaría en la puta vida.

Bueno, creo que el post ya es bastante largo así que lo dejo aquí. Espero que os haya gustado!

Hoy, a menos que La Noria lleve a Ortega Cano para que explique cómo matar a alguien y estar en la calle, la pandereta estará sobrevolando “el debate” en breves minutos.

Hace unos meses surgió una nueva polémica política respecto al control de RTVE, si bien ésta era un poco más curiosa. En todas las noticias al respecto veíamos que se mencionaba explícitamente un sistema de generación de noticias para medios de comunicación, que es el estandar de facto de la industria, el iNews.

Me voy a morder la lengua por no hacer lo propio con la yugular de alguno, así que vamos a lo que vamos.

Primero establezcamos el contexto con estos artículos

http://www.rtve.es/television/20110923/comunicacion-sobre-decision-del-consejo-administracion-crtve-programa-inews/463593.shtml
http://www.vayatele.com/profesionales/que-es-inews-y-que-tiene-que-ver-con-el-consejo-de-rtve

Parece que todo el mundo confía en la integridad del acceso al iNews. Asi que me puse a investigar un poco cómo funcionan las “teles” por dentro, en este caso TVE.

Lo primero que hice fue llamar a RTVE e intentar sobornar con donetes a algunos empleados para que me pasaran información. La cosa, incomprensiblemente, no funcionó así que hubo que pasar al plan B: Open Source Intelligence. Es decir, lo de siempre: Webs,comunicados, notas de prensa, pliegos, videos, foros, ir a tomar cafe al mismo bar que suelen ir los trabajadores a poner la oreja o a dejar un pendrive con el logo de TVE olvidado en la barra, etc etc…

He hecho una selección de las fuentes que proporcionan más información:

En esta web http://www.cobdc.net/12JCD/actes/ nos encontramos con 3 documentos interesantes, las presentaciones y papers de “El Gestor de archivo, nuevo perfil profesional en la redacción única de TVE” y “El uso de imágenes procedentes de Internet en los informativos de TVE”

Encontramos informaciones técnicas y operativas interesantes, que nos permiten ir formándonos una imagen del escenario.

http://www.cobdc.org/jornades/12JCD/materials/comunicacions/pres/MEANA_gestor_archivo_nuevo_perfil_tve.pdf

http://www.cobdc.org/jornades/12JCD/materials/comunicacions/MEANA_gestor_archivo_nuevo_perfil_tve.pdf

http://www.cobdc.org/jornades/12JCD/materials/comunicacions/AGUILAR_uso_imagenes_internet_tve.pdf

Los dos últimos ficheros son fundamentales para entender el artículo, así que recomiendo su lectura. Explican la manera de funcionar de las redacciones de TVE, desde el punto de vista técnico y funcional.

Ejemplos de la información extraida

MEANA_gestor_archivo_nuevo_perfil_tve.pdf
“En los SSII de TVE todos los periodistas tienen la posibilidad de trabajar con texto, audio y vídeo en alta resolución. Todos trabajan sobre estas plataformas y elaboran su noticia desde su puesto de trabajo, es decir, escriben texto y después sobre el mismo equipo abren su software de edición que apunta a servidores de vídeo o unidades de almacenamiento compartido donde pueden encontrar las imágenes que necesitan.”

“Sin embargo, en la actual redacción digital de TVE, todo el material que
llega en cualquier formato, se digitaliza, y se introduce en el
almacenamiento compartido junto con los metadatos que lo identifican. Este
proceso de digitalización se llama “ingesta”.”

“El sistema se compone de un gran almacenamiento compartido llamado
ISIS/Interplay (Avid) que contiene todos los materiales con los que se puede
trabajar en un día. Este gran almacén tiene una capacidad cercana a 4.000
horas de vídeo y audio. Desde cualquier puesto de trabajo se puede tener
acceso a este almacén, añadiendo nuevos materiales, ingestando o
descargando contenidos que servirán para elaborar nuevos productos
informativos”

“La Ingesta Central es donde se llevan a cabo las grabaciones de líneas. En
la redacción digital de TVE existe un departamento que graba las señales
externas en ISIS. Utiliza 24 equipos llamados Airspeed (Avid), que se
pueden programar si se trata de envíos periódicos”

“Una vez que el material ha pasado desde los Airspeed a ISIS, el redactor o
el realizador dispone del mismo y pueden editar su noticia o pieza con
cualquier sistema de edición no lineal.
Para el montaje de una noticia, el redactor trabaja con dos aplicaciones
principales:
Instinct e Inews (ambos de Avid) que trabajan en paralelo”

AGUILAR_uso_imagenes_internet_tve.pdf
En el caso de los Informativos de TVE, las tareas estrictamente de ingesta
están a cargo de dos secciones distintas:
- Ingesta Central, encargada de la recepción de señales. Cuenta
para ello con 25 AirSpeed (servidor de ingesta directa de la
empresa Avid).
- Ingesta Local, responsable del resto de formatos que se capturan:
ENG, cintas del Archivo histórico, DVD, CD, Web y memorias tipo
flash. Cuenta con 6 NewsCutter Adrenalin

Esquema 1
Atendiendo a este esquema donde aparece Odetics para el archivo antiguo, deberían tener algo parecido a esto, mola.
http://www.youtube.com/watch?v=9fTJkVgRvpw

Esquema 2

Las imágenes y el texto recopiladas nos llevan a realizar otras búsquedas y averiguar que software, hardware y qué empresas están detrás.

Esta web de la revista de temática audiovisual nos ofrece un artículo con bastante información
http://www.tmbroadcast.es/index.php/tve-hasta-el-infinito-y-mas-alla/
Separándola convenientemente entre Producción, Emisión y Archivo.

Producción
“En la redacción se han instalado un total de 300 clientes concurrentes. La herramienta básica de trabajo para el redactor es Avid iNews Instinct”

Bien, esto cuadra con todo el revuelo organizado en base al control de iNews. Veamos un poco más del iNews en este video (3:05) de La 2 Noticias; Mara Torres invita a David Trueba a dirigir el informativo y donde hablan brevemente sobre este software.

El Famoso iNews

Podemos deducir un poco más de como tienen estructurada la arquitectura, se ve que usan switchs KVM

Emisión
“Como sistema de emisión se ha instalado el sistema ADC-100 de Harris con cliente, Production Client”

Fijaos en la pantalla resaltada, bastante parecida a ésta, perteneciente al BroadcastSupervisor del ADC-100, lo que también cuadra.

La arquitectura vendría a ser así

Podemos observar varios de los elementos que vemos en la foto de La 2.

A más alto nivel

Recapitulando, tenemos que están usando básicamente:

Avid NewsCutter XP
Avid NewsCutter Adrenaline
Avid iNews/Instinct
Avid Media Composer
Avid Interplay
Servers Avid MediaStream
Server Avid Unity ISIS
25 servers AirSpeed
Sistema Harris ADC-100 con el hardware/software asociado

Echemos un ojo al uso de puertos, y por lo tanto funcionalidades, por parte del Software/hardware de Avid http://cdn.pinnaclesys.com/SupportFiles/FAQ_Avid/243397/Port_Usage_Guide_UPDATED_24SEP2009.xls

Es un CTF en toda regla. Cuanto más lejos llegues, más pollas ascii podrás poner en el mapa del tiempo durante el telediario.

¿Cómo de seguro es el iNews?

Con tanto revuelo, que si se puede acceder o no al iNews y ver qué está escribiendo cada periodista, quise echar un ojo a la autentificación al menos.

En principio debido a las características del Software de Avid y los tipos de clientes, es bastante restringido. Aunque haciendo un poco el retard-ninja he conseguido algunos, entre ellos el famoso iNews.

Como hemos visto iNews es un software cliente, y desgraciadamente no tenemos acceso al servidor. Sin embargo, sólo para escarbar la superficie de lo que puede ser, quise comprobar si al menos cifraba las credenciales antes de enviarlas al servidor. Efectivamente no.

Si no tenemos un servidor pues no los inventamos, mejor dicho lo moldeamos. La técnica es útil en estos casos: crear un server dummy, dejar que el cliente iNews -ANWS.exe- hable con nosotros y ver qué peticiones espera. Vamos analizando el parser de paquetes y construimos el servidor según esto, finalmente podemos completar la secuencia y llegar a la autentificación

Básicamente el cliente se comunica con el server, le envía un ‘ping’ y este le dice que acción realizar, sí está disponible o no, seguidamente se comprueban que las versiones de ambos son compatibles y se realiza la petición de autentificación.

Mediante ingeniería inversa vamos analizando las peticiones que espera recibir el cliente y cómo parsea los datos, moldeandonos el server según lo que vemos, que quedaría así.

Fake iNews Server – Testing plain authentication
Britney spears is connected
Receiving PING
‘\x17\n’
OK- Sending LOGIN Request
Receiving CLIENT version
‘#(@) 3.2.5.9 DOS\x00′
Sending SERVER Version
Initiating AUTH request
‘\xfc\x03\x00\x00\xfc\x03\x00\x00′
Completing AUTH request
receiving plaintext user/password…
‘\x05\x81\x81\x00\xfe\x01\x02\x00′
‘\x00\x04\x81\x81\x00\x01\x02\t\x00\xbd\x04\x81\x00\x04\x14\x02a\x00a\x00a\x00a\x00a\x00a\x00a\x00a\x00a\x00a\x00….

Curiosamente tras 3 intentos fallidos de autentificación, el programa muestra un Message Box diciéndote que has agotado los intentos, que te pires y se cierra. Pero teniendo en cuenta que nosotros somos el server y no le hemos dicho nada, la cuenta de los logins fallidos está en el lado cliente.

Lo que no puedo asegurar es si sólo está en ese lado, ya que no tengo un server. Si sólo se mantiene en el client-side además podríamos construir un programa para bruteforcear logins facilmente. La forma de interceptar las credenciales ya dependería de la arquitectura de red.

Los periodistas pueden estar “tranquilos”, a nivel de la aplicación sus credenciales están viajando en texto claro. Vamos que si no oficialmente, ‘extraoficialmente’ en principio no parece muy complicado monitorizarlo.

Bueno, pues ya sabemos algo más de cómo funciona TVE por dentro. Ahora a ‘disfrutar’ del debate, a ver si pasa algo raro…

Si alguno tiene más información o correcciones, escribid un comentario!

Hasta la próxima gorrillas del ciberespacio.