IMS: Algunos elementos de la arquitectura

En mi anterior post, os hice una pequeña introducción sobre la arquitectura IMS. A continuación trataré de explicar algunos de los conceptos mas importantes sobre esta arquitectura.

Como anteriórmente comenté, la arquitectura IMS se puede dividir en tres capas;la de aplicación, la de control y la capa de transporte.

Capa de aplicación

En la capa de aplicacion, uno de los elementos mas importantes es el AS o "Application Server". Es aquí donde se ejecutan y/o se hospedan los servicios que los operadores de telefonia movil quieren ofrecer (bueno, mas bien vender) a través de la arquitectura IMS.
Los AS hablan SIP, es decir, usan el protocolo SIP ("Session Initiation Protocol"). Este último es un protocolo de señalización utilizado principalmente para el establecimiento de sesiones de comunicación multimedia, tales como llamadas de audio y video sobre internet.

Otro elemento de gran importancia en esta capa es el HSS o el "Home Subscriber Server". El HSS es una especie de base de datos donde se almacenan las credenciales de los usuarios subscritos a una operadora de telecomunicaciones.

Capa de control

Aquí nos encontramos con el nucleo de IMS ("IMS Core"). Las especificaiones sobre IMS del 3GPP están principalmente centradas en esta capa (mas concretamente en el "IMS Core"), y tratan principalmente de las intercacciones entre los AS y el "IMS Core". Es un poco complicado entender que es IMS a través de los documentos del 3GPP, por eso, a los que os atrevais os recomiendo tener paciencia.

En esta capa nos encontramos con los CSCF ("Call Session Controll Function"), que son servidores SIP o proxies que principalmente se encargan de enrutar el trafico SIP entre las diferentes entidades que forman la arquitectura IMS.

Existen 3 tipos de CSCFS:

• P-CSCF o Proxy-CSCF, es el primer punto de contacto entre un termianl IMS y la red. Puede estar colocado tanto en la red local como en una red de otra compañia. Sirve para enrutar la conexion hacia los I-CSCF.

• S-CSCF o Serving-CSCF, es el nodo central en el plano de señalización de IMS. Es un servidor SIP, pero también se encarga de controlar sesiones. Simplificando un poco, es elnod en la arquitectura IMS que se encarga de conectarse con el HSS, para descargarse o actualizar perfiles de usuarios. En la conexion con el HSS, se usa el protocolo DIAMETER, especificamente usado para funcionalidades de AAA ("Authentication, Authorization and Accounting").

• I-CSCF o Interrogating-CSCF, es un servidor SIP que se coloca en el "borde" del dominio administrativo. La dirección IP de este servidor se publica en el DNS ("Domain Name System") del dominio al que pertenece. De esta manera, otros servidores remotos pueden encontrarlo y usarlo como punto de reenvio de paquetes SIP hacia ese dominio.

Capa de transporte

La intencion de esta serie de posts es centrarse en la capa de aplicaciones y los servicios IMS, es por esto que voy a omitir esta capa.


Con todo lo que hemos visto hasta ahora ya podemos empezar a hacernos una idea de cómo podría funcionar todo este "asunto" del IMS. En la siguiente imagen tenemos un ejemplo de establecimiento de conexion en IMS.




El P-CSCF elimina culaquier tipo de intento de establecimento de ruta por parte del terminal y establece una ruta hasta el S-CSCF situado en la red del operador al que pertence el usuario. Esta ruta se estableció de antemano al registrarse el terminal en la red, y puede que atraviese algun I-CSCF en caso de que la red a la que pertenece el usuario quiera ocultar detalles de su topologia a la red visitante (res a través de la cual el usuario ha iniciado la conexión, como por ejemplo, cuando hacemos roaming al llamar desde el extrangero).

Una vez enrutada la conexión al S-CSCF de la red del operador correspondiente, el S-CSCF se conecta con el HSS para obtener detalles sobre el usuario conectado (a que servicios de lared tiene acceso/contratados etc.). Una vez verificado que el usuario tiene disponible ese servicio (en el caso del dibujo, una llamda de voz) el S-CSCF dirige la conexion al S-CSCF que provee servicio al usuario destinatario de la llamada.

A partir de aqui, ocurre lo mismo pero en la red del usuario destino, hasta que finalmente se establece la conexion.




Asier Marruedo
S21sec e-crime

Cuidado con la información que ponemos en las Intranets

Hace días que en diferentes listas de correo del W3C se vienen discutiendo los pros y contras sobre la estandarización de una nueva cabecera HTTP, denominada Origin, con la única intención de servir como defensa a los ataques CSRF.

Gran parte de la discusión viene dada con argumentos de que ya existe una cabecera HTTP que sirve para ese propósito si se utiliza bien, Referer. Esta cabecera a pesar de que es trivial falsearla, tiene algunas características de privacidad, motivo por el cual muchos proxys y navegadores la descartan, ya que muestra el path de la URI. -¿Y qué problema tiene?-, más adelante lo vemos.

Adam Barth, en su paper "Robust Defenses for Cross-Site Request Forgery", en el cual expone sus argumentos para la adopción de esta nueva cabecera HTTP, hace referencia a un tipo de problema derivado del uso de Referer. Me llamó la atención porque creo que este tipo de situaciones no se tienen en cuenta si se desconocen.

Para situarnos con el uso que se le da a esta cabecera, si realizamos la búsqueda "seguridad digital" en www.ask.es y vemos las peticiones que generamos:

[1]
GET / HTTP/1.1
Host: www.ask.es
(datos omitidos)

[2]
GET /web?q=seguridad+digital&qsrc=0&o=312&l=dir&dm=lang HTTP/1.1
Host: es.ask.com
(...)

El buscador nos muestra los resultados y pinchamos sobre uno de ellos,

[3]
GET / HTTP/1.1
Host: blog.s21sec.com
(...)
Referer: http://es.ask.com/web?q=seguridad+digital&qsrc=0&o=312&l=dir&dm=lang

Esta cabecera es ampliamente utilizada en software de estadísticas web como Google Analytics para determinar cómo se llego hasta un sitio web, si fue a través de un buscador como en este caso, a través de otra página, o introduciendo la URI directamente en el navegador.

Ahora viene la parte interesante, la que comentaban como problema de privacidad de esta cabecera según el entorno donde se use. Imaginad una Intranet, donde se colocan noticias de los logros del negocio, planes futuros, o el próximo lanzamiento de un nuevo producto. Si en esa intranet colocamos un enlace a una empresa competidora para mostrar los beneficios de nuestro nuevo producto frente al suyo, nos podría suceder algo como esto:

Noticia de ejemplo en nuestra intranet. Qué tendrá una URI como esta:
http://nuestra-intranet.com/noticias/2008/12/10/Lanzamiento-del-nuevo-producto-X

"El departamento de desarrollo ha finalizado el producto X, el cual pretendemos lanzar al mercado en el periodo de 2 meses. El valor añadido que ofrece este producto frente a otros similares como el de [empresa que vera nuestra noticia] o [otra empresa que verá nuestra noticia] son las características de poder [...]"

Lo que se verá al otro lado de nuestra intranet, es decir, en las estadísticas web de las empresas que hemos enlazado como competidoras de nuestro producto sera:

X.X.X.X - - [29/Jan/2009:09:34:22 -0500] “GET /noticias/ HTTP/1.1″ 200 34659 “http://nuestra-intranet.com/noticias/2008/12/10/Lanzamiento-del-nuevo-producto-X” “Mozilla/5.0 [información eliminada]″

Este puede ser un tipo de fuga de información, muy específico, pero que puede dar detalles a los competidores sobre nuestros planes.

Otra variante de este tipo de fuga de información puede darse a través del correo. Las intranets suelen tener la opción activada para enviar correos de las noticias publicadas, con el fin de que aquellas personas que por motivos diversos no tengan acceso, puedan conocer esas noticias a través del correo. Si estas personas acceden al correo a través de un webmail y pinchan sobre los enlaces de la noticia, lo que verán estas empresas será un log del referer del tipo.

http://webmail.tudominio.com/search;_tlt=V0oG43BZHn1JFEoAVcar4Qt.

No muestra tanta información como desde la intranet, pero se ve, que algo se está preparando en la empresa competidora ya que nos están haciendo referencia por algún motivo.

¿Se os ocurren más variantes de problemas relacionados con esta cabecera?

Emilio Casbas
S21sec labs

Digital Bond’s SCADA Security Scientific Symposium (S4)

La semana pasada tuvo lugar el simposio científico de seguridad SCADA, organizado por Digital Bond en Miami Beach desde hace tres años.

S4 es un evento donde se presentan trabajos de investigación altamente técnicos relacionados con la seguridad en sistemas de control y en SCADA.

Este año, a la cita acudieron un grupo de 46 asistentes físicos y 24 asistentes virtuales, formado por investigadores, ingenieros y líderes en seguridad SCADA entre los que se encontraba como no, S21sec.

A lo largo de los dos días que duró el simposio, se presentaron una serie de ideas y estudios interesantes, voy a intentar resumir las ponencias que bajo mi punto de vista, tienen una mayor repercusión:


Leveraging Ethernet Card Vulnerabilities in Field Devices

La ponencia que nos presentan Frank Marcus, Daniel Peck y Dale Peterson (Digital Bond) se centra en la particularidad que tienen muchos dispositivos de campo (PLC’s, RTU’s, PAC’s,...) de permitir la carga de firmware sin necesidad de autenticación.

Como se puede intuir, esta característica puede ser explotada por un atacante para leer información del dispositivo, e incluso ejecutar código arbitrario en él. Imaginaros por un momento que el atacante consigue introducir un gusano en uno de los dispositivos de campo perteneciente a una infraestructura crítica y éste es capaz de propagarse a todos los dispositivos del sistema de control, las consecuencias serían nefastas.


Customizing Control System Intrusion Detection at the Application Layer

Mai Kiuchi, Eiji Ohba y Yoshizumi Serizawa (CRIEPI) nos hablan de la posibilidad de configurar productos de seguridad como firewalls, cifrado o IDS’s para proteger la comunicación interna de los dispositivos de control añadiendo capas de seguridad al sistema y detectar posibles ataques.

En mi opinión la idea más interesante de esta ponencia es la forma utilizada para detectar ataques, estudiando el protocolo implementado por la aplicación SCADA y analizando ciertos patrones del tráfico de red que no deberían ocurrir durante una operación normal.

Aquí es donde surgen las reglas específicas SCADA para un IDS, en concreto se habla del sistema de detención de intrusiones opensource SNORT.

Si os interesa este punto, no debéis perder de vista el gran trabajo que está llevando a cabo el equipo de Digital Bond, desarrollando firmas específicas para tres de los protocolos más utilizados en infraestructuras críticas (DNP3, ICCP y MODBUS/TCP).

También aparece el problema de la latencia. En los sistemas SCADA, como hemos visto en otros post, las aplicaciones deben de funcionar en tiempo real por lo que la tolerancia al aumento del retardo en la transmisión de paquetes es mínima. Entonces, ¿cómo podemos integrar firewalls y cifrado en el modelo sin que el sistema se resienta?, se necesita una evaluación exhaustiva para determinar si es viable en un sistema SCADA real.

An Analysis of Two New Directions in Control System Perimeter Security

Ludovic Piètre-Cambacédès y Pascal Sitbon (Electricité de France) nos comentan que en la actualidad son los firewalls tradicionales IT los que proporcionan seguridad a los sistemas de control, ofreciendo una protección importante. No obstante, ya están disponibles dos nuevas direcciones en lo que se refiere a la seguridad perimetral de los sistemas de control que pretenden ofrecer un mayor nivel de seguridad:

1. Diodo físico de datos, básicamente se puede decir que es un cable de red modificado para permitir a los datos viajar en único sentido (strict one-way policy), siendo utilizado para garantizar la seguridad y la integridad de la información además de la confidencialidad.


2. Seguridad en la “capa 8”, protección dinámica basada en la lógica del proceso industrial, controlando acciones fuera de la lógica de proceso y aplicando heurística para determinar si una acción es peligrosa.

Como ya he dicho antes, estas son las ponencias que más me gustaron personalmente, si os interesara saber más sobre todos los temas tratados con un nivel de detalle mayor no dudéis en visitar la página web de Digital Bond, donde podéis encontrar la agenda completa del simposio así como varios resúmenes de lo acontecido.

Daniel Herreras Rodríguez
S21sec labs

Ejecución de aplicaciones en un PDF

Como ya comenté hace un tiempo, existen multitud de acciones que se pueden realizar dentro de un PDF. Una de ellas es la ejecución de aplicaciones, que además tiene la característica de poder realizarse en diferentes plataformas: Windows, Unix y Mac.

Para probar la capacidad de este elemento me voy a basar en un PDF básico, modificándolo según mis preferencias. Primero se debe incluir un evento disparador de la acción, por ejemplo, al abrir el documento. Para ello se tiene que incluir un elemento /OpenAction en el catálogo del documento, apuntando a un objeto que será la acción /Launch, que lanzará la aplicación deseada. Dicho objeto puede contener los siguientes elementos:

• /S: es un parámetro obligatorio de tipo nombre que detalla el tipo de acción que se describe en el objeto. En este caso su valor deber ser /Launch.

• /F: si no se especifican las entradas /Win, /Unix o /Mac éste es un parámetro obligatorio y en él se puede encontrar la ruta de la aplicación que queremos lanzar o imprimir. Esto es algo que no había comentado, pero a través de este tipo de acción también se pueden imprimir documentos, aunque por el momento sólo en sistemas Windows.

• /Win: es un diccionario opcional que contiene entradas específicas de este sistema operativo. Dentro de estas entradas encontramos de nuevo el elemento /F, con el mismo fin que el anterior, /D, una cadena de texto representando el directorio por defecto, /O, con valores 'open' o 'print' y siendo la primera la que se usará en caso de ausencia de este elemento, y, por último, el elemento /P, para indicar los argumentos de la aplicación a lanzar.

• /Unix y /Mac: en teoría serán elementos del mismo tipo que /Win, pero a día de hoy no están definidos oficialmente. Para lanzar una aplicación en estas plataformas habría que indicar el path de la aplicación en el parámetro /F global, por lo menos en el caso de Linux (no funciona en evince ni en KPDF, pero sí en xpdf). Además, la ejecución mediante el parámetro OpenAction no funciona correctamente en este sistema operativo, pero sí se lanza cuando se hace click sobre una anotación. A continuación se muestra un ejemplo de cómo se podría hacer:

Tanto en Windows como en Linux, al ejecutarse la acción aparece una ventana avisando de que la aplicación se va a lanzar, preguntando al usuario si lo permite. Podéis descargar un ejemplo aquí.

En el caso de xpdf siempre se debe responder la pregunta, mientras que en el Acrobat Reader 8.1.2 de Windows se da la opción de no volver a preguntar, una muestra clara de cómo la comodidad del usuario está por encima de la seguridad en este caso. Se me ocurre un escenario bastante real, en el que el usuario marque esta casilla, y permita la ejecución de la aplicación en un momento dado, por evitar verla otra vez.

Alguien suplanta la identidad de un amigo de Pepe, y manda un correo a Pepe con un PDF muy bonito, que en una de sus páginas lanza el PowerPoint para mostrar una presentación. Seguramente la primera vez no marque la casilla del demonio, pero después de recibir varios PDFs de su amigo del alma, y en vistas a recibir alguno más, lo hará. En ese momento, podrá ejecutar todo lo que quiera sin que la ventanita se chive de lo que quiere hacer realmente. ¿Qué tal descargar un troyano y ejecutarlo de forma casi transparente? Ésta es una prueba de concepto lanzando calc.exe.


En la versión de Acrobat Reader que he usado esto se puede subsanar desmarcando una casilla, activada por defecto, y que permite la ejecución de aplicaciones externas para abrir archivos que no sean PDFs.


Como podéis ver, los PDFs no son tan inofensivos como parece, en siguientes publicaciones os iré contando un poco más sobre su lado oscuro;)

Jose Miguel Esparza
S21sec e-crime

Switches: los grandes olvidados (II) – Spanning Tree Protocol

En esta parte voy a explicar las vulnerabilidades del Spanning Tree Protocol, estas pueden ser explotadas por una herramienta programada por Alfredo Berrueta y David Barroso, dos grandes de S21sec.

 

En un gran entorno de red, donde existen varios switches gestionando diferentes segmentos de red, el protocolo Spanning Tree Protocol (a partir de ahora STP), es usado para evitar la creación de bucles de red a nivel 2 del modelo OSI.

Existen diferentes estándares de STP, el primero es el IEEE 802.1d, además tenemos 802.1q, 802.1w, 802.1s:

 

802.1d   es el estándar que define el STP inicialmente, define el método usado para evitar los caminos redundantes en una red de switches, además de asegurar la recuperación de la red si alguno de los mismos falla.

 

802.1q es una extensión del 802.1d pero añadiendo el término de redes locales virtuales (VLAN), este protocolo ya lo explicaremos en otro capítulo.

 

802.1w o (Rapid STP) RSTP es una revisión del 802.1d la cual aplica algunos cambios en el algoritmo para agilizarlo, así la recuperación tras un fallo es más rápida. En general mejora su rendimiento mientras se es compatible con los dispositivos que solo soportan el STP original.

 

802.1s o Múltiple STP (MSTP), mejora el 802.1q permitiendo a los bridges a gestionar múltiples spanning tres cada uno por grupo de VLAN, incrementado la escalabilidad.

 

Funcionamiento de STP

El objetivo es evitar bucles y recuperación ante fallos. Para cumplirlo el algoritmo crea un árbol de switches, la raíz es aquel switch con un ID más bajo, para identificarlo, todos los switches mandan a multicast las Bridge Protocol Data Units (BPDU), es un frame de nivel 2 en el cual va incluido el ID del switch (prioridad + MAC del dispositivo), cuando un switch recibe un BPDU con un ID menos que el suyo deja de enviar su BPDU, así solo el switch con el ID más bajo se mantendrá generando BPDUs y se convierte en el switch raíz. 

 

STP utiliza un sistema de costes para evitar los bucles, cada puerto es configurado con un coste, la mayoría de los switches configuran sus el coste de sus puertos en relación con la velocidad de los mismos.

 

Cada vez que un puerto recibe una BPDU el coste de ese puerto se incrementa con el coste que contiene la BPDU, el switch raíz envía BPDUs de coste cero. Evidentemente si se reciben más de una BPDU, las BPDUs de mayor coste se ponen en modo bloqueado.

 

Cada cierto tiempo, el switch raíz manda un BPDU. Cuando un switch recibe un BPDU con un ID mayor que el suyo propio, intenta convertirse en raíz mandando su BPDU. Cuando un bridge recibe una BPDU en el que el coste hasta la raíz es mayor que el coste que él mismo puede ofrecer por uno de sus puertos, intenta convertirse en puente designado para ese camino. Si el coste es el mismo, se compararían identificadores.

 

Existen también los denominados TCN BPDUs, son BPDUs que anuncian cambios en la topología, cuando son recibidos (después de un proceso de confirmaciones) los switches reducen el tiempo para actualizar sus tablas de forwarding.

 

Por cierto, y ya que no lo he dicho antes, este protocolo no implementa ningún sistema de autenticación ni protección, es además en claro…

 

Ataques al STP

Convertirse en bridge raíz

Este ataque es tan fácil como inyectar tramas BPDUs donde nos ponemos un ID más bajo que el del switch raíz, ósea la misma prioridad (por defecto el del raíz es 32768) y una MAC más baja, o directamente ID=0… Así nos convertiríamos en bridge raíz.

 

¿Hace falta que os diga más?, desde aquí podemos convertir nuestro sistema en un switch si tiene dos tarjetas de red (Yersinia te facilita la tarea), y desde esta posición podríamos realizar ataques MiTM sobre el tráfico que pasara por nuestro sistema.

 

DOS por inundación de configuration BPDUs y TCN BPDUs

Mandar múltiples (miles) configuration BPDUs por segundo hace que algunos dispositivos fallen al procesarlas e incrementen el uso de su CPU hasta un 99%. Además, cada vez que se manda un TCN BPDU, el bridge raíz debe contestar con un TC-ACK , y cada vez que esta confirmación es recibida, los switches deben reducir el tiempo para actualizar sus tablas de forwarding.

 

 

Soluciones

Root Guard

Cuando configuramos root guard, configuramos en que puertos puede estar el switch raíz y en cuales no, así si se recibe una BPDU con ID más bajo en uno de los puertos con root guard el mismo se pone en modo STP inestable y deja de transmitir paquetes.

 

BPDU-Guard

Este sistema permite a los administradores forzar la topología de arboles y mantenerla predecible, aquellos dispositivos que estén fuera de la topología configurada con BPDU-guard no podrán influir en la topología STP. La recepción de BPDUs fuera de este ámbito hace que BPDU guard deshabilite el puerto.

 

Hasta el próximo capitulo…

 

Leonardo Nve

S21sec Auditoría

Switches: los grandes olvidados I

Siempre ocurre, cada vez que hago una auditoría interna, donde el alcance de la misma es toda la red del cliente en cuestión o al menos un amplio abanico de sistemas y dispositivos de red, la mayor fuente de vulnerabilidades son estos últimos.

No estoy seguro de si existe un desconocimiento sobre las vulnerabilidades existentes a este nivel o una despreocupación por las mismas. En una serie de posts voy a intentar reflejar los peligros existentes, especialmente orientados a los administradores de estos dispositivos y a aquellas personas que toman las decisiones de utilizar tal o cual protocolo.

Quiero hacer notar que la gran mayoría de estas vulnerabilidades son a nivel 2 del modelo OSI y son problemas en el propio diseño del protocolo, no obstante, también existen vulnerabilidades a nivel de aplicación.

En este POST voy a empezar con dos de los fallos que más estoy encontrando, a pesar de ser muy antiguos:

Usuarios y claves por defecto

Si, esta vulnerabilidad, ya usada por el Chaos Computer Club cuando hackeaba ordenadores VAX para el Komitet Gosudárstvennoy Bezopásnosti (KGB) a principio de los 80, aun sigue afectando a nuestras empresas, da igual el tamaño.

La forma de explotar esta vulnerabilidad es fácil, o bien buscas listas de contraseñas por defecto (hay algunas muy buenas por internet) o, la forma más segura, vas a la web del fabricante y te bajas el manual del dispositivo. En el mismo, al documentar la instalación del dispositivo en cuestión seguro que te viene la contraseña que hay que usar para conectarse por primera vez y configurarlo.

Protocolo SNMP versión 1

Este protocolo (SNMP, Simple Network Management Protocol) es evidentemente conocido por todos los administradores de red, nos simplifica la configuración del dispositivo (permiso de escritura), y nos proporciona datos sobre el mismo así como su estado en un momento actual (permiso de lectura). Existen numerosos programas de administración de redes que implementan SNMP para ayudarnos en estas tareas.

Sin entrar en detalle en la descripción del protocolo, diré que se basa consultar (leer) unas OIDs (Object IDentifier) para obtener información sobre el dispositivo (depende del OID te proporciona un dato u otro) o modificar (escribir) el valor de estos OIDs para cambiar la configuración. Para controlar si se tiene o no permiso para leer o leer/escribir, se utilizan las llamadas comunidades, estas comunidades hacen las funciones de contraseñas aunque técnicamente hablando no es la realidad. Otro dato fundamental es que este protocolo funciona sobre UDP.

En sí, usar este protocolo ya lo incluimos como vulnerabilidad en nuestros informes:

• El protocolo funciona en texto claro, por lo que, es susceptible de ser capturado. Con la información que contiene (la comunidad, e IP de origen de un paquete) ya tenemos datos suficientes como para acceder a información del dispositivo (si la comunidad es solo de lectura) e incluso para modificar su configuración (si la comunidad es de lectura/escritura).

• Muchas configuraciones filtran la IP desde la cual se pueden hacer consultas SNMP como medida de seguridad. Bueno, al ser UDP y cada comando es solo una línea, hacer IP spoofing del mismo para saltarse esta protección es algo trivial para cualquier auditor
  

• El acceso a la configuración de un sistema por este método suele ser más o menos reducido, pero algunos dispositivos, como los Cisco, permiten además acceder (y modificar) profundamente la misma, llegando a poder leer o modificar las contraseñas y listas de acceso, permitiendo así la intrusión. Otros sistemas, como algunas Solaris permiten ya directamente la ejecución de comandos, MS Windows lista usuarios, etc etc etc…
  

Estos fallos son a nivel aplicación, en POSTs posteriores bajaremos al nivel 2. Nos vemos!

Leonardo Nve

S21sec Auditoría

Obama

Aunque parezca que volvamos a comentar el uso de un acto público, como es el día que Barack H. Obama entró a la Presidencia de los Estados Unidos, con el objetivo de ser infectados (una prueba exitosa, aunque poco imaginativa, del uso de ingeniería social), realmente la entrada del nuevo 44º Presidente puede conllevar un cambio bastante radical en la estrategia de EEUU en Internet.

Hace aproximadamente un mes, el Centro de Estudios Estratégicos e Internacionales (CSIS), publicó un documento elaborado por numerosos profesionales de la Seguridad Nacional y la Seguridad Informática, con el objetivo de recomendar al nuevo Presidente las acciones a tomar respecto al ciberespacio. Básicamente, el resumen es el siguiente:

1. Uno de los mayores problemas de EEUU es la seguridad en el ciberespacio. Realmente reconocen que han fallado hasta ahora
2. Las decisiones que se tomen tienen que respetar los valores NorteAmericanos relacionados con la privacidad y derechos civiles
3. Sólo una estrategia de seguridad que aglutine los aspectos nacionales e internacionales podrá mejorar la situación.

El documento realmente ofrece una visión bastante objetiva del problema, comentando incluso que ya en 1998 una comisión presidencial dijo que el ciberespacio sería crucial para la seguridad nacional. Esta recomendación no fue ignorada, sino principalmente malinterpretada, puesto que se esperaban los típicos ataques de las películas (contra refinerías, depósitos de agua, aviones, ...) y no se contemplaba los ataques reales que realmente son los más comunes, atentando contra la infraestructura económica de la nación, principalmente representados por el robo de información sensible o confidencial, ya sea gubernamental, militar, o empresarial.

El documento además ofrece una serie de buenas recomendaciones (algunas más acertadas que otras) y representa un base adecuada para construir la estrategia de seguridad nacional. Algunas de estas recomendaciones son:

• Crear una estrategia de seguridad en el ciberespacio que dependa directamente del Presidente, y sea impulsada por él mismo, de esta forma evitando que quede difuminada por la gran cantidad de agencias que existen. Además, se crearán ciertos órganos de actuación (dependientes directamente del Presidente) que coordinaran las acciones (por ejemplo el US CERT seguirá dependiendo del DHS). También es importante la relación con otras naciones (como por ejemplo la Convención Europa sobre Cibercrimen)
• Revisión de la relación entre el sector público y el privado. Básicamente coordinar las actividades tanto de prevención como de reacción. No olvidemos que la mayor parte de la tecnología de seguridad proviene de empresas privadas, y es esa dependencia tan grande algo que se quiere cambiar.
• Normativa: creación de leyes que regulen la seguridad de las infraestructuras críticas
• Asegurar SCADA: hemos hablado mucho de ello en este blog. Identificando las estructuras críticas y sus vulnerabilidades
• Hacer uso de las certificaciones a la hora de adquirir tecnología, de tal manera que se garanticen productos desarrollados de una forma segura (como por ejemplo, Common Criteria)
• Gestión de identidades (seguras) a nivel nacional, tanto para el gobierno como para los ciudadanos
• Formación sobre la seguridad en el ciberespacio
• Fuerte empuje a la I+D sobre seguridad en el ciberespacio

Como se puede apreciar, las recomendaciones son bastante razonables, y realmente equiparan el problema de la seguridad en el ciberespacio al problema de la yihad o de las armas de destrucción masiva. Es un problema equiparable, aunque en el documento apuntan a unos enemigos que no son todos los que son. El punto de mira del documento apunta a los servicios de Inteligencia y cuerpos militares de otras naciones como los principales responsables de los ataques que está sufriendo EEUU, lo cual probablemente es cierto en un pequeño porcentaje, pero no es nada si lo comparamos con la actividad de las bandas organizadas que campan en Internet y se venden al mejor postor.

Estados Unidos a menudo es una referencia en lo que a seguridad en el ciberespacio se refiere (aunque no todo lo que haga lo haga bien), y si realmente empiezan a organizarse realmente veremos muchos cambios en Internet. No olvidemos que EEUU aún domina muchos de los órganos críticos en Internet, y es ahora una cuestión de diplomacia no perder ese control y ganar aún más de lo que tiene.

David Barroso

S21sec e-crime

CAPEC

Continuando con la misma línea de publicaciones y sin salirme de los estándares definidos por y para SCAP, hoy le toca el turno a CAPEC: Common Attack Pattern Enumeration and Classification. Los patrones de ataque (que completan la definición de una amenaza) conforman la descripción de los métodos utilizados para la explotación del software/hardware, con la desviación particular (desde el punto de vista de diseño) que los orienta a un objetivo relativamente “destructivo” y que son un elemento clave para identificar y comprender las diferentes perspectivas en las que una amenaza se puede convertir en una vulnerabilidad.

¿Qué es un patrón de ataque?

Para comprender mejor la diferencia entre un “patrón de ataque” y una vulnerabilidad, analicemos el siguiente ejemplo: “Explotar la confianza del software en el cliente”, es decir, confiar parte de la seguridad (o sin ser estrictamente seguridad, cualquier control de validación) de la aplicación en el hecho de que el cliente que se conecta es realmente el cliente, en lugar de suponer que puede ser cualquier otro software (automático o manual). En otras palabras, que a lo mejor el navegador no es el navegador sino alguien con un proxy, o un script o… Mediante este patrón es posible manipular la información transmitida al servidor, realizar una suplantación de identidad, y explotar otra serie de vulnerabilidades.

¿Qué nos aporta el patrón de ataque?

Básicamente nos ayuda a determinar que vulnerabilidades pueden afectar a nuestro elemento. En este caso concreto, no debemos preocuparnos si nuestra aplicación no se compone de una estructura cliente servidor.

CAPEC tiene como objetivo ofrecer una lista de patrones de ataque, así como toda la información relacionada que permite comprender así como ordenar una taxonomía de este tipo. La versión disponible actualmente es la 1.1, que pude ser visualizada online en forma de árbol aquí o descargada desde aquí aunque la sección de descargas sea esta: http://capec.mitre.org/about/documents.html

La siguiente imagen muestra un pequeño detalle de la lista expandida de CAPEC 1.1 donde pueden apreciarse diferentes patrones de ataque.

Como post para el blog ya tengo el 5, ahora a intentar subir nota..

Estructura de CAPEC

En primer lugar, no como estructura de datos sino como visualización de la publicación, CAPEC ofrece diferentes tipos de vistas para su taxonomía (ver “Pattern abstraction Slides”). De hecho, en un principio CAPEC era mucho más grande de lo que es ahora, pero han conseguido separar los patrones de las amenazas, vulnerabilidades y debilidades (cosa complicada) por lo que el diccionario se ha reducido considerablemente.

Aunque a primera vista puede parecer que un patrón de ataque es un campo más en la lista de atributos de una vulnerabilidad y que no aporta nada más que una descripción, en realidad desde un punto de vista menos técnico ofrece información que permite determinar factores de riesgo, evaluaciones de impacto, detección proactiva de ataques, apoyo en las decisiones de seguridad, etc…

Vamos a centrarnos en un ejemplo para comprender la importancia y validez de la información que ofrece esta taxonomía (Nota: la traducción utilizada en esta explicación no es literal): “Accessing Functionality Not Properly Constrained by ACLs”

Título: “Acceso no restringido correctamente por Listas de Control de Acceso”
ID patrón de ataque: 1
Severidad Típica: Alta

Comentario: Hasta aquí, información para la impresora y el respositorio, nada útil ni práctico.

Descripción:

En aplicaciones principalmente Web, el acceso a funcionalidades es permitido por el framework de autorización, cuyo trabajo es relacionar ACLs con elementos de la funcionalidad de la aplicación, principalmente URLS de la aplicación web. En caso de que alguna de estas ACLS no sea especificada para un elemento cualquiera, un atacante podría acceder a éste sin impedimento. Un atacante que pueda acceder a funcionalidad no controlada por la ACL podría obtener información sensible, y posiblemente comprometer la aplicación en caso de que pudiese acceder a recursos que solo debieran estar disponibles para usuarios privilegiados, como secciones de gestión, etc...

Comentario: Leyendo este sumario ahora es posible determinar que las amenazas a las que se refiere este patrón de ataque pueden generarse y deberían mitigarse durante la fase de desarrollo.

A continuación se analizan los pasos utilizados habitualmente para completar este patrón de ataque.

Flujo de ejecución del ataque: describe el flujo de ejecución del atacante según este patrón.

Mediante Exploración

Estudio: El atacante trata de identificar elementos de la aplicación mediante su estudio, posiblemente como usuario válido autenticado.

Técnicas utilizadas

1. Spidering del sitios web y enlaces disponibles (entornos web principalmente)
2. Averiguar recursos (directorios, archivos, accesos) mediante fuerza bruta
3. Averiguar nombres de usuario/credenciales mediante fuerza bruta
4. Averiguar acciones o nombres de función mediante fuerza bruta.

comentario: Bien, si observamos cualquiera de estas irregularidades en el uso de la aplicación es posible que no estén intentando atacar, y ahora podemos determinar que quizá estén intentando acceder a recursos privilegiados de la aplicación.

Indicadores de susceptibilidad

1. Se han observado ACL o mecanismos de control en la aplicación
2. Existen identificadores de usuario o credenciales en la aplicación
3. Se han observado diferentes modos de operación según privilegios

Comentario: egún esta lista de susceptibilidad, si en nuestra aplicación mostramos estos “indicadores” es probable que antes o después recibamos un patrón de ataque de este tipo, ya que son claras pistas de que existe un mecanismo de control de acceso.

Identificación de funcionalidad: en cada paso el atacante es sujeto a un control de funcionalidad utilizado en algunas de las acciones

1. Uso del inventariado Web de todos los formularios y aplicación de ataques a todas sus entradas.
2. Registro y análisis de tráfico de red de la comunicación
3. Ejecución de aplicación en entorno controlado que permite visualizar la información utilizada en las API de sistema.

Comentario: AKA: Prueba y error, consiste en ir probando diferentes aspectos de la aplicación para ver si aparece algún error. Al menos desde el punto de vista del desarrollador es posible aplicar algún tipo de control que evite la repetición de acciones, o que la limite en el tiempo.

Experimentación

Evaluación de las capacidades de acceso: Probablemente como usuario válido, el atacante intentará realizar todas las acciones posibles en la aplicación para comprobar la extensión de la gestión de acceso.

1. Fuzzy de parámetros de API o solicitudes (parámetros URL, parámetros API de sistema, parámetros de protocolo, etc…)

Indicadores de susceptibilidad

1. Intento de crear un listado de mecanismos de acceso y resultados de su control, para determinar aquellos en los que no se realiza de forma correcta.

Comentario: Si encontramos un usuario que intenta determinar todos los controles de acceso aplicados, obviamente no puede ser nada bueno.


Prerequisitos del ataque

La aplicación debe ser accesible en un modo en que se asocien sus elementos (secciones, acciones, etc..) con ACLs. Algunos recursos, como URLs de acceso deben estar accesibles para usuarios para que se cumpla su descubrimiento. Deben existir recursos no asociados a ACLs, o bien durante el desarrollo o durante el despliegue de la aplicación.

Comentario: Sin estos requisitos, ya sabemos que aunque observemos este patrón de ataque, su finalización no será exitosa... ehem...


Propensión a ser explotable: Muy alta
Métodos de ataque: análisis y fuerza bruta.

Comentario: Con estos criterios, ya podemos determinar que si desde un origen se detecta mucho tráfico es posible que estén analizando la aplicación o realizando un ataque de fuerza bruta.

Hasta aquí podríamos resumir como análisis básico. Existen bastantes criterios que pueden ser considerados además de los expuestos, y de todos ellos es posible extraer un poquito más de información acerca del tipo de ataque podríamos recibir. Claro que también es posible realizar la consulta inversa, es decir, como responsable de seguridad mi misión es mantener un entorno de trabajo seguro. Puedo evaluar el hecho de que limitando en el tiempo el número de conexiones posibles desde un único origen reduce la posibilidad de éxito de patrones de ataque como éste (y otros), o por ejemplo, demostrar empíricamente a la dirección que un firewall no va a proteger la aplicación de este tipo de ataques. Cuando además el escenario se conoce al 100%, es posible determinar cuáles de las vulnerabilidades (relación CVE – CAPEC) a las que estoy expuesto según el último informe de la auditoría son explotables de forma remota o mediante que tipos de ataque, por lo que puedo excluir aquellas que sé no son accesibles desde el exterior.

Finalmente, otra de las aportaciones de CAPEC es el hecho de que como repositorio (catálogo) cada una de las vulnerabilidades puede ir asociada con uno o varios patrones, lo que permite la automatización de varias de las acciones/ideas/conclusiones que hemos obtenido en este mini-análisis. Teniendo en cuenta que hasta ahora no se está haciendo, disponer de tecnología que lo permite supone cuanto menos un avance.

Como factores en contra, es información que puede aclarar o terminar de liar al 'inexperto', aunque, sin apelar a la demagogia, seguramente hablar de inexpertos en seguridad en el año 2009 sea un disparate :)


Otros recursos

En el año 2007 se hicieron los primeros (y curiosamente únicos) esfuerzos por dar a conocer esta inciativa: un workshop y una conferencia en la BlackHat, que podeis descargar desde aquí (Outreach and Enhancement). En este caso es un copy-paste de los utilizados en la propia web de CAPEC, que incluyo no como referencia para otras lecturas, sino para terminar de completar los orígenes de este engendro.

Además de las taxonomías utilizadas como base para este trabajo US-CERT, Rocky y AttackPattern, se ha tenido en cuenta el conocimiento “aprobado” por la comunidad en general tras el nivel de aceptación de libros como “Building Security” o “Exploiting Software: How to Break Code”, así como trabajos bastante adelantados a su época, como la iniciativa de realizar esta taxonomía por parte del Carnegie Mellon University: “Attack Modeling for Information Security and Survivability”, del 2001. Así que como conclusión, quizá se utilice en un futuro, quizá no, pero no hay duda de que al menos su contenido merece un vistazo.

Iñaki López
S21sec Labs

Pendrive USB: Peligros conocidos y uno más

El uso del pendrive USB esta totalmente integrado en nuestras vidas, el hecho de no tener uno a mano en todo momento nos puede hacer perder el podernos copiar ese documento, o esa película, o esa colección de fotos del último fin de semana.

Los peligros de estos dispositivos están muy documentados, brevemente os describo aquellos que ya he encontrado documentados.

Auto ejecución de programas.

 Un pendrive USB no es tratado por Windows como si de un CD fuera, no es autoejecutable a no ser que nosotros configuremos nuestro sistema operativo como tal. No obstante, todos conocemos el famoso menú que se Windows muestra cuando se introduce uno de estos dispositivos en nuestro sistema. Este menú es customizable desde un fichero de configuración que se sitúa en el propio pendrive, con esto existen algunos trucos para engañar al usuario y poder ejecutar programas, aparte de que existen métodos que permiten  hacerlo, nada más alguien explore nuestro dispositivo.

Actualmente los pendrive son una gran fuente de infecciones víricas.

Soporte de robo de información

Hoy en día todos los sistemas informáticos tienen soporte activado para el uso de pendrive, esto permite que usuarios malintencionados como empleados desleales dispongan de un soporte donde grabar información sensible para nuestra empresa y la puedan llevársela fácilmente, todo esto sin necesidad de instalarse programas de grabación o no pasar ningún filtro de correo electrónico.

Además existe un método por el cual a ciertos pendrive USB se les puede cambiar el firmware y hacer que el Windows crean que son unidades de CD-ROM (por USB) con lo que estaría la auto ejecución activada por defecto.

Pérdida de datos

Como ya dije al principio es muy normal llevar nuestro USB con datos, pueden ser de nuestra empresa o personales. Estos dispositivos son susceptibles al extravío, y cualquier otra persona puede encontrarlo teniendo acceso a esos datos si no están debidamente encriptados. En esas circunstancias solo nos queda rezar. A recordar el caso de la pérdida por parte de la policía Inglesa de un USB con datos de posibles células terroristas en el Reino Unido: http://www.dailymail.co.uk/news/article-1055996/Police-lose-memory-stick-secret-terrorist-information.html

Copia oculta de nuestro USB

Otro peligro existente menos conocido es la existencia de programas que copian ocultamente el  contenido de un pendrive USB a un directorio del ordenador nada más es conectado, así si alguien conecta el suyo en un ordenador que no es de confianza puede que le roben sus archivos .

Hice un programita que hacia esto mismo, incluso podía ponerle filtros para poder elegir que extensiones de ficheros copiar y de que tamaño máximo. De hecho lo ideal es que detectara cuando se está leyendo o escribiendo en el mismo para realizar esta función y ser así más stealth (las lucecitas de algunos dispositivos pueden alertar al propietario).

 

Para todas estas vulnerabilidades existen diferentes medidas de protección, desde la más efectiva como desactivar los puertos USB de un sistema, a otras de limitada efectividad como las de USB que piden contraseñas tanto como para descifrar los archivos, como para permitir el acceso, sin entrar en el análisis de los algoritmos de cifrado usados, este sistema solo es útil para proteger la pérdida del dispositivo, al ejecutarlo en un sistema ajeno al nuestro corremos el riesgo de que en ese sistema exista un keylogger y esta protección queda evitada, o incluso que un programita se espere a que la contraseña este introducida para acceder a los ficheros internos.

Otra vulnerabilidad que existe y que no he visto documentada es la siguiente:

Acceso al espacio libre del dispositivo

Esta vulnerabilidad es similar a la de copia oculta de ficheros de nuestro USB, de hecho es complementaria, la idea inicial era copiar el espacio libre para una posterior recuperación de archivos sobre el mismo, así el incauto que conecta su pendrive a un ordenador no confiable, habiendo borrado sus archivos sensibles como medida de seguridad es totalmente vulnerable a la misma. Pensad si alguna vez habeis usado el vuestro para pasar ficheros de un ordenador a otro.

No obstante, según va incrementado la capacidad de almacenamiento este método se va haciendo más difícil en un tiempo breve. En este caso, el ataque evoluciona a la recuperación de archivos stealth, así  tenemos de nuevo la capacidad de filtrar que queremos recuperar y que no y copiar los ficheros a un directorio oculto en nuestro sistema.

Leonardo Nve

S21sec Auditoría

SPAMBOTS

En este artículo, vamos a tratar el uso de la Inteligencia Artificial (IA) en el mundo de la seguridad informática. Ya comenzamos la saga con los chatbots, continuando con los pokerbots y con la acentuación de la crisis en los días actuales, ha habido una serie de bots que cada vez van a ir tomando más protagonismo como es el caso de los spambots como medio de transmision de informacion basura o spam.

Un Spambot es un programa o software encargado de la generación de correos basura o spam que, posteriormente, serán enviados a través de correos, chats...a una lista masiva de clientes de dichos servicios. La motivación principal de los spammers para el envío de dicho correo basura se centra en los siguientes puntos:

• Envío de publicidad para la venta de sustancias de dudosa reputación.

• Realización de un ataque phising para obtener contraseñas de cuentas bancarias, contraseñas de correos...

• Envío de cadenas de mail para reivindicar algún tema político-social...

El funcionamiento de los robots generadores de spam se centran en tres fases principalmente:

• Obtención de listas de mail: Una lista de mail se puede crear a traves de la generación automática de direcciones de correo electrónico o buscando éstas en páginas web. Lo podemos hacer mediante la creación de un programa capaz de identificar direcciones de correo en las páginas y con la capacidad de encontrar enlaces a otras páginas como medio de propagación para la recolección de dichas direcciones.
• Generación del spam: La creación del mensaje podemos realizarla en base a un patrón de mensaje, a la creación personalizada de mensajes, basado en imágenes... Todas estas técnicas las trataremos un poco más detalladamente en la fase de evolución.
• Distribución del spam: Esta fase es la centrada en el envío de los mensajes a los destinatarios de la lista desde un ordenador o una red de ordenadores (botnet).

La evolución de los robots generadores de spam esta muy ligado a la evolución del spam. En los comienzos de este ataque, el spam se enviaba de forma directa, es decir, se generaba una lista de direcciones e-mail y se comenzaba desde un mismo ordenador a enviar e-mails a un gran número de direcciones de correo. Pronto, los spammers evolucionaron hacia la creación de mensajes más personalizados para captar la antención de las víctimas, como, por ejemplo, introduciendo dentro del saludo la dirección de correo destino. Esto se combatió mediante el uso filtros basados en técnicas Fuzzy, es decir, en técnicas basadas en condiciones mediante las llamadas reglas de Zadeh. Esto permitía que un mensaje de e-mail quedará bloqueado (bandeja de correo no deseado) si el contenido del mensaje no pasaba unas ciertas reglas.

Con el boom de Internet en los años 90, el spam también evolucionó junto con la tecnología. Con el nacimiento del ADSL, los spammers podían llevar su ataque de una forma más rápida, es decir, podían enviar más mensajes en menos tiempo. Actualmente, los spammers se centran en el uso de Botnets con el fin de enviar, desde numerosos ordenadores, un número astronómico de mensajes basura. Las botnets están formadas por un conjunto de ordenadores zombies (infectados mediante algún tipo de malware y controlados por un Bot Master) con el fin de realizar alguna acción, en nuestro caso el envío de correo basura, aunque existen otros ataques como DDoS.

Con el fin de sobrepasar los filtros de correo no deseado, los spammers optaron por el envío del mensaje modificado de tal forma que sea legible para una persona humana, pero no para una máquina. Es decir, imaginemos que queremos mandar el mensaje: “NUMERO”, pudiéndolo modificar de la siguiente forma: “NUM3R0”. De esta forma el detector de spam dejaba pasar este mensaje. Otra modificación posible es la utilización de juegos de letras y colores en el mensaje, de tal forma que quede legible para el ser humano.

En la actualidad, los spammers han aumentado su mercado mediante el envío de mensajes vía blogs, redes sociales... Ante esto, cada vez más, aparecen captchas para la aprobación de un mensaje dentro del blog. Esta técnica, en un principio, se combatió mediante el uso de IA, más concretamente, mediante el uso de los llamados OCR (sistemas diseñados para identificar texto escrito de una imagen). Es por esto que hoy en día los captchas están formados por texto dentro de una imagen retocada o mediante el uso de “juegos de lógica simple” con el fin de que un ordenador no lo reconozca automáticamente (Touring test).

Tampoco debemos olvidar que hoy en día, y cada vez con más frecuencia, podemos ver mensajes de spam en nuestro móvil (vía SMS, MMS...) de spammers mediante el mensaje: “Tengo una foto tuya, si la quieres manda SMS al numero XXXX”. La obtención del número de estos dispositivos puede realizarse no solo desde formularios web sino también, generarlo aleatoriamente.

Algunas formas de detección de los robots generadores de spam son:

• Mediante el uso de direcciones e-mail: Esta técnica se basa en la creación de e-mails falsos o e-mails dedicados exclusivamente a la recepción de spam, con el fin de estudiar la procedencia de los mismos y crear filtros contra estas direcciones.
• Detección mediante Logs de la página: Esta técnica se basa en ver quién ha entrado en la página web y con qué frecuencia han realizado clicks (normalmente los robots realizan un alto numero de cliks en un tiempo relativamente corto). Por otro lado, también se suele mirar los clicks en imágenes pequeñas en las que un usuario humano clickaría con el fin de verlas o mediante el orden de clicks de los links siguiendo el orden del contenido (los robots no lo hacen de esta forma).

Hoy en día, ya que los spambots forman parte de redes de ordenadores zombie o botnets, los expertos se centran también en la identificación de este tipo de malware, muy de moda en los tiempos que corren. Para la detección de una botnet, los expertos usan honeynets, es decir, redes señuelo para la detección de ataques o la investigación de los mismas con el fin de obtener patrones de comportamiento basados en flujos de tráfico, logs...

Para finalizar, mencionar que en los comienzos de este año, según lo informado por McAfee y Symantec , el spam se ha visto reducido notablemente con la eliminación de dos hostings de grandes redes de spambots/botnet como es el caso de McColo y Bobax/Kraken respectivamente. Con la eliminación de estas amenazas, el impacto en internet ha sido una reducción notoria del spam que llega a nuestros correos. Pero a lo largo de 2009 y con el impacto económico de la crisis mundial, las grandes empresas de antivirus no dudan que los spammers buscarán nuevos servidores de hosting donde implantar las botnets. Del mismo modo, los usuarios de ordenadores están cayendo cada vez más en ataques phising o infección de otro tipo de malware por medio de páginas de ganar dinero fácil, préstamos bancarios... Es por esto por lo que la gente se tiene que mentalizar en que nadie regala dinero, y que antes de dar información privilegiada conviene estar seguro de que estos datos llegan a buenas manos.

Aitor Corchero Rodríguez
S21sec labs

Protección del software (Parte VIII)

Tras ver diversos trucos para detectar la presencia de un depurador o la de cualquier programa no deseado, en esta ocasión vamos a ver otro tipo de técnicas básicas, enfocadas a tratar de evitar que un volcado del proceso resulte en un ejecutable funcional. Estas técnicas, de las que hablaremos a continuación, son conocidas como anti-dump.

La idea principal es conseguir que el programa no contenga toda la información necesaria en memoria, aunque se tiene la limitación de que la funcionalidad del mismo no puede variar.

Veamos varias formas de evitar un volcado correcto:

• Ejecución de código fuera del proceso: Si reservamos memoria y ejecutamos código desde una región externa al proceso, un volcado normal no tendrá este código y no podrá funcionar correctamente.

• Destrucción de la cabecera PE: Una vez que no haga falta, se pueden modificar datos de la cabecera, de tal manera que un volcado no nos proporcionará un fichero PE válido y no pordrá ser arrancado.

• Destrucción de la IAT: Si, por ejemplo, se añade una redirección intermedia en la tabla de importaciones, el fichero volcado no podrá cargar las APIs llamadas y no se podrá ejecutar.

• Robado de bytes: Durante el desempacado y puesta en memoria del proceso, se puede modificar el estado del programa para simular haber ejecutado ciertas instrucciones, de modo que un volcado del proceso resultará en un programa en el que faltan instrucciones y no funcionará.

Estas técnicas han sido y son utilizadas por diversos packers y, una vez más, tras comprender su funcionamiento, han sido rotas, puesto que son protecciones "reversibles". Veamos, de una manera un tanto abstracta, los pasos que se pueden dar ante estas protecciones.

• Para el primer caso, se puede volcar dicha sección a disco, añadirla dentro del ejecutable, y corregir las referencias al mismo.

• Para el segundo, se puede utilizar la cabecera del fichero empaquetado como base. Existen herramientas que vuelcan el proceso a disco y reconstruyen la cabecera en base al disco original.

• En el tercer caso se debe reparar la tabla de importaciones, para lo cual se deberá de localizar el momento en que ésta es destrozada. La automatización mediante alguna herramienta como ImportReconstructor puede ser muy útil.

• Por último, el robado de bytes de podrá analizar de diversas maneras:
  - Descubriendo qué instrucciones se han podido ejecutar en base al estado de la pila, registros, etc,
  - Se puede tratar de localizar las instrucciones (o emulaciones) ejecutadas durante el desempacado.
  - Se puede tratar de identificar el lenguaje de programación utlizado y estudiar cómo son las primeras instrucciones de los programas compilados en dicho lenguaje.

Mikel Gastesi
S21sec e-crime

Satélite: La señal del cielo que estabas esperando (II)

En este capítulo sobre trasmisiones de datos vía satélite voy a explicar algunas consideraciones que hay que tener en cuenta a la hora de manejar este tipo de conexiones desde el punto de vista de la seguridad. Como ya se expuso en la primera parte, los datos enviados por un satélite son susceptibles de ser capturados.

Existe la creencia de que solo los datos de bajada son capturables, Ésta es una verdad a medias, ya que en una conexión bidireccional, aquélla donde el canal de subida también va a través del satélite, los datos pueden ser capturados cuando el transpondedor del satélite los reenvía a través de un canal de bajada ala estación terrestre correspondiente.“Todo lo que sube tiene que bajar, pensó Newton cuando estaba debajo de un manzano”

No obstante, por temas que se verán más adelante, vamos a considerar que solo se puede capturar el canal de bajada.

Otra cosa que hay que tener en cuenta es que la señal es la misma para todos dentro de la cobertura del satélite. Es decir,  si una empresa usuaria utiliza un satélite que da cobertura a toda Europa, y la misma está en Berlín, un usuario malicioso podría capturar su canal de bajada en Sicilia, y otro a la vez en Asturias.

En este escenario, sería lógico pensar que las empresas proveedoras utilizan sistemas de cifrado fuertes para hacer inútiles estas capturas, o que el protocolo lleva cifrado incorporado. Pues como todos estáis pensando, esto no es así, la comunicación en muchos casos va en plano.

Evidentemente, los proveedores recomiendan a sus clientes que usen redes privadas virtuales en las que encapsular su tráfico de red, recomiendan asimismo cifrar o usar protocolos seguros como SSL, SSH, FTPS. Pero como se ha comentado, la mayor parte de las implantaciones no siguen estas recomendaciones.

Supongo que todo esto es porque se cree que “esnifar satélite” es muy difícil y solo esta accesible a unos mortales. 

Veamos qué hardware es necesario a priori:

•  Parabólica + LNB ≈25€
  
•  Soporte y cable ≈12€
  
•   Tarjeta DVB-S pci ≈ 60€
  
•  Satfinder≈15€
  

112€ es un precio muy accesible

Si además tenemos en cuenta que, hace un año o así, este es un hardware que usaban aquellos que pirateaban las televisiones digitales y que ahora ya no pueden, podemos encontrar este material en ebay mucho más barato, incluso podemos conocer a alguien que lo tiene y ya no lo usa.

El software necesario es todo software libre y para Linux:

-          LinuxTV (www.linuxtv.org)

•  Soporte en el kernel tarjetas DVB-S/C/T
  
• Utilidades (linuxtv-apps): sintonizador, test, soporte DVB/IP, etc.
  

-           DVBsnoop (dvbsnoop.sourceforge.net)

• Analizador de protocolo DVB para consola
  

-          Wireshark para captura de datos

Con este arsenal se puede empezar a capturar. En las pruebas realizadas de las comunicaciones de un cliente en solo 10 segundos se llegaron a capturar 7967 paquetes de datos. No hay que ser un experto para saber qué información pude llevar esta captura, desde contraseñas  a emails.

Desde mi punto de vista de investigador ya tengo claro que la captura de datos es posible, ¿Qué más posibilidades da esta tecnología a un usuario desaprensivo? Pues tenemos suficiente información como para usar estas redes sin que haga falta un proveedor, podemos hacer ataques de  DNS spoofing, TCP hijacking, etc…, todo virtualmente no rastreable. Como en la mayoría de estos casos, todo es cuestión de ser ingeniosos.

Leonardo Nve

S21sec Auditoría