Próximos eventos

Tras estar en más de 15 eventos tanto nacionales como internacionales durante el primer trimestre, vamos a seguir informándoos de dónde podréis encontrar a nuestros expertos en las próximas semanas.

Los próximos 13 y 14 de abril va a tener lugar en Pamplona el VII Foro Sobre Protección de Datos de Salud.

Este año tampoco nos lo hemos querido perder y Montserrat Gómez, Consultora Senior de S21sec, ofrecerá una ponencia en la sesión Nuevas Soluciones para la Seguridad de los Datos de Salud el miércoles, 14 de abril.

A finales de mes, los días 27, 28 y 29 de abril se celebrará en Madrid el evento Securmatica, XXI Congreso español de Seguridad de la Información.

Aquí Mariano Largo, Director de Estrategia y Desarrollo de Negocio de S21sec, impartirá junto con Miguel Ángel Fernandez, Director de Producción de Redes y Procesos, la ponencia “Monitorización integral de la seguridad”. Puedes verlo todo sobre el evento aquí.

Y ya en mayo, nos iremos a Brasil, ya que S21sec estará patrocinando el evento CeCOS IV, organizado por el APWG en Sao Paulo entre los días 11 y 13 de mayo. Además, David Barroso, Director de S21sec e-crime impartirá la ponencia "On iPhone eCrime Forensics". Puedes consultar la agenda aquí.

Pasad unos buenos días de vacaciones. ¡Nos vemos a la vuelta!

Marketing S21sec

Una solución para el crackme de la Rooted - Level #1

Como ya comentamos en un anterior post, simultáneamente a las conferencias de la RootedCon tuvo lugar un wargame en el que se debían resolver diversas pruebas. A continuación se muestra una posible solución para una de ellas, que se presentaba a modo de crackme.

Para pasarla, se debía generar un password correcto para el usuario admin:



Un buen punto de entrada habitual en este tipo de crackmes puede ser lanzar el programa con el depurador y poner un punto de ruptura en la API MessageBox, de modo que la ejecución se detenga al mostrar el mensaje de error producido al introducir un valor incorrecto, y suponiendo que nos encontraremos cerca de la rutina de comprobación del password.

En este caso no es tan simple, puesto que el creador del crackme ha añadido algún truco anti-debug. Al lanzar el crackme en el depurador, éste se detiene debido a instrucciones int3, como se puede ver a continuación:



Por supuesto, no se trata de un error de programación, sino que las funciones más importantes del programa han sido cifradas con un código similiar al siguiente:



Como bien sabemos, habitualmente las subrutinas comienzan con el siguiente prólogo:



Podemos comprobar que si ciframos está función con el algoritmo mencionado, dado que la clave de cifrado inicial es 0x99 y la función comienza con 0x55, con un XOR obtenemos 0xCC, que se corresponde con el int3. De esta manera, garantizamos que las funciones cifradas comenzaran con int3, y la función de descifrado será almacenada en el manejador de excepciones para que pueda ser descifrada en ejecución y ejecutada sin problema alguno.

Sabiendo cómo se cifran las funciones, podemos decodificarlas todas, y podemos tener un fichero más cómodo de estudiar. El crackme utiliza la API GetDlgItemTextA para obtener los valores introducidos en los TextBox, llegando al siguiente código:



Aquí podemos encontrar la subrutina que valida nuestro código, protegido por tres detecciones de depurador antes y después de su ejecución y, para complicar más el asunto, el código de validación, a diferencia de las demás funciones, vuelve a ser cifrado después de ejecutarse, siendo únicamente visible mientras la contraseña está siendo comprobada. El string "iddqd-idkfa!" no se trata de la contraseña, habrá que trabajárselo un poco más ;)

Dentro de la rutina de comprobación podemos diferenciar varias partes, como la comprobación del inicio del password, que debe coincidir con "r00ted-" para que la rutina siga comprobando las siguientes condiciones:



Siguiendo el análisis de la rutina, se puede comprobar que el password correcto debe contener un guión ("-") y algunos "Hi" y/o "Lo", llegando a la conclusión de que el password debe seguir el siguiente esquema:

r00ted-XXXXXX-YYY

XXXXXX consiste en una combinación de Hi y Lo, mientras que YYY se trata del valor introducido por el usuario que, como veremos más adelante, deberá cumplir ciertas condiciones.

Veamos ahora como son generados los mensajes de error. Podemos encontrar un array de punteros a diferentes mensajes de error, aunque están cifrados. Encontramos dicho array en la dirección 0x426000.



Posteriormente, son inicializados en el siguiente orden, contando desde 0 hasta 7:



El más importante es el 5º elemento, porque contiene la subrutina que muestra el mensaje que nos dice que hemos acertado el password. Lo único que nos falta es como hacer que el flujo del programa termine llegando a esta rutina.

La solución consiste en que la segunda parte de la contraseña debe apuntar a dicho valor, esto es, el quinto, para lo que, valiendo Hi 1 y Lo 0, necesitamos el valor 101

Ahora tan solo falta la última parte del password. El crackme calcula el checksum (un simple XOR) de las dos primeras partes (azul) y lo compara con el checksum de la última parte (verde):

r00ted-HiLoHi-YYY

Por lo tanto, necesitamos el valor YYY que haga coincidir los dos checksums, y una combinación de caracteres para que esto sea real es r00ted-HiLoHi-Ap8

Solo como curiosidad, otros mensajes ocultos en el programa son:

- You are tracing me!
- ALLMOST!! Bad bad bad ....
- ALLMOST!! This one is not good : /((
- INVALID, No luck .....
- KEEP WORKING, Bad bad bad ....
- INFO, Keep the good work ...
- IN-VALID The password doesn't look OK
- Not Good, Still not there ...

Un crackme muy interesante!

Jozsef Gegeny
S21sec e-crime

Servicios y herramientas de análisis de URLs maliciosas

En el cuarto trimestre de 2009 aproximádamente 5.5 millones de páginas web contenían software diseñado para realizar instalaciones sin necesidad de la intervención del usuario (fuente). Este tipo de ataques, a.k.a drive-by downloads, hace tiempo eran comunes en sitios de dudoso contenido, pero en la actualidad, la tendencia es encontrarlos en todo tipo de sitios web legítimos, ya sea directamente o bien, a través de terceros como banners publicitarios.

Existen servicios WebMalware avanzados, orientados a empresa e instituciones, con el objetivo de detectarlos y poner solución a estas amenazas antes de que realicen una infección másiva a los visitantes de estos sitios web. Qualys recientemente ha publicado una BETA pública con limitaciones para su uso.

Por otra parte, existen herramientas gratuitas con el mismo objetivo pero destinadas al usuario final, ya que únicamente permiten realizar el análisis de una url, sin posibilidad de crawling, ni otras características. Algunos de estos servicios van desde la simple comprobación de la URL en listas negras, hasta el uso de honeypots de alta interacción para el análisis de comportamiento. Ante la heterogeneidad de este tipo de ataques, decidimos probar algunos de estos servicios gratuitos en busca de comportamientos ante diferentes tipos de URLs.

Los servicios gratuitos de análisis de URLs probados fueron:

• Web of Trust: Comprueba la reputación de un sitio web y advierte de sitios web peligrosos.
• Unmask parasites: Miles de propietarios de sitios web no son conscientes de que sus sitios han sido infectados con parásitos.
• Trend Micro web reputation: Comprueba la reputación de un sitio web.
• Norton safe web: Muestra la reputación del sitio.
• Finjan URL analisis: Analiza la URL en tiempo real en busca de amenazas.
• F-Secure browsing protection: Muestra la reputación del sitio.
• AVG linkscanner drop zone: Analiza la URL en tiempo real en busca de amenazas.
• Wepawet: Servicio para detectar y analizar malware basado en web.

El tipo de URLs que se probaron:

• URLs maliciosas activas
• URLs maliciosas activas en el pasado pero que ya no existen (inactivas)
• URLs maliciosas escondidas a través de servicios acortadores de URLs
• URLs benignas con javascript sospechoso antes de una redirección
• URLs benignas con javascript sospechoso después de una redirección
• URLs inexistentes
• URLs benignas

(Código malicioso drive-by download)

Para simplificar el análisis, mostramos cada servicio con el comportamiento ante cada tipo de URL. Mostramos únicamente un resumen representativo del resultado de dicho análisis:

WEB OF TRUST

1. URLs maliciosas activas: Contenido malintencionado, virús.
2. URLs maliciosas activas en el pasado pero que ya no existen: Contenido malintencionado, virús, infracción en navegador, spyware.
3. URLs malignas escondidas a través de servicios acortadores de URLs: Sitio de confianza
4. URLs benignas con javascript sospechoso antes de una redirección: No muestra nada
   
5. URLs benignas con javascript sospechoso después de una redirección: No muestra nada
   
6. URLs inexistentes: No muestra nada
7. URLs benignas: Sitio de confianza

UNMASK PARASITES

1. URLs maliciosas activas: URL sospechosa.
2. URLs maliciosas activas en el pasado pero que ya no existen: Error.
3. URLs malignas escondidas a través de servicios acortadores de URLs: URL sospechosa
4. URLs benignas con javascript sospechoso antes de una redirección: URL sospechosa
   
5. URLs benignas con javascript sospechoso después de una redirección: URL limpia
   
6. URLs inexistentes: Error
   
7. URLs benignas: URL limpia

TREND MICRO WEB REPUTATION

1. URLs maliciosas activas: URL maliciosa.
2. URLs maliciosas activas en el pasado pero que ya no existen: URL maliciosa.
3. URLs malignas escondidas a través de servicios acortadores de URLs: No maliciosa
4. URLs benignas con javascript sospechoso antes de una redirección: No maliciosa
   
5. URLs benignas con javascript sospechoso después de una redirección: No maliciosa
   
6. URLs inexistentes: No maliciosa
7. URLs benignas: No maliciosa

NORTON SAFE WEB

1. URLs maliciosas activas: 7 amenazas encontradas. Clasificación del tipo de amenazas.
2. URLs maliciosas activas en el pasado pero que ya no existen: Sitio seguro
3. URLs malignas escondidas a través de servicios acortadores de URLs: Sitio seguro
4. URLs benignas con javascript sospechoso antes de una redirección: No comprobado
   
5. URLs benignas con javascript sospechoso después de una redirección: No comprobado
   
6. URLs inexistentes: No comprobado
   
7. URLs benignas: Sitio seguro.

FINJAN URL ANALISIS

1. URLs maliciosas activas: URL bloqueada, virus detectado. Informa de la familia del malware.
2. URLs maliciosas activas en el pasado pero que ya no existen: URL bloqueada. Informa de la familia del malware
3. URLs malignas escondidas a través de servicios acortadores de URLs: URL bloqueada. Informa de la familia del malware
4. URLs benignas con javascript sospechoso antes de una redirección: URL bloqueada. Informa de la famila del malware.
   
5. URLs benignas con javascript sospechoso después de una redirección: URL legítima
   
6. URLs inexistentes: URL no disponible.
   
7. URLs benignas: URL legítima.

F-SECURE BROWSING PROTECTION

1. URLs maliciosas activas: Este sitio es dañino.
2. URLs maliciosas activas en el pasado pero que ya no existen: Sitio desconocido
3. URLs malignas escondidas a través de servicios acortadores de URLs: Este sitio es seguro
4. URLs benignas con javascript sospechoso antes de una redirección: Sitio desconocido
   
5. URLs benignas con javascript sospechoso después de una redirección: Sitio desconocido
   
6. URLs inexistentes: Sitio desconocido
   
7. URLs benignas: Este sitio es seguro

AVG LINK SCANNER DROP ZONE

1. URLs maliciosas activas: Reportada como dangerous. Detalla familia.
2. URLs maliciosas activas en el pasado pero que ya no existen: No se pudo escanear por algún problema
3. URLs malignas escondidas a través de servicios acortadores de URLs: No se pudo escanear por algún problema
4. URLs benignas con javascript sospechoso antes de una redirección: Reportada como dangerous.
   
5. URLs benignas con javascript sospechoso después de una redirección: No se pudo escanear por algún problema
   
6. URLs inexistentes: No se pudo escanear por algún problema
   
7. URLs benignas: No se encontró ningún exploit

WEPAWET

1. URLs maliciosas activas: Maliciosas. Análisis en profundidad.
   
2. URLs maliciosas activas en el pasado pero que ya no existen: Error de red accediendo a la URL.
3. URLs malignas escondidas a través de servicios acortadores de URLs: Benigna, aunque realiza análisis de redirección.
   
4. URLs benignas con javascript sospechoso antes de una redirección: Sospechosa
   
5. URLs benignas con javascript sospechoso después de una redirección: Sospechosa
   
6. URLs inexistentes: nombre de host no válido.
   
7. URLs benignas: La url es segura.
   

CONCLUSIONES

Unmask parasites y wepawet fueron los servicios que más se acercaron a los resultados esperados. El tipo de URLs analizadas es sólo una mínima parte de la casuística que se puede presentar en este tipo de ataques. Los cibercriminales cada vez más, intentan camuflar su malware en Internet para mantener el control -cuanto más tiempo mejor- de los servidores que han modificado. Además, los BlackHat seo poseen una gran infraestructura para poder aprovecharse de cualquier acontecimiento de interés mundial. La suma de todo ello y las posibilidades de ocultarse ante herramientas como las analizadas en este artículo, muestran que actualmente la mejor protección pasa por una mezcla de herramientas de análisis automático, manual, sentido común como siempre, y algo de suerte.

Uno de los grandes problemas de este tipo de ataques es que suelen ser descubiertos tarde, cuando los visitantes de los sitios web comprometidos ya han sido infectados. Grandes pérdidas económicas y de reputación online pueden ser algunas de las consecuencias. En este sentido, no tiene el mismo impacto un sitio web pequeño muy segmentado, como el que pudiera tener un sitio web de interés público como servicios de administración electrónica o periódicos digitales por citar algunos. S21sec, dispone del servicio webmalware como medida proactiva en la lucha contra el fraude online y amenazas web y como parte de un servicio de protección integral.

Emilio Casbas
S21sec e-crime

Análisis forense de la cache de DNS en equipos Windows

Según la metodología de SANS para la recolección de información forense en vivo (una de las más prestigiosas). El orden de volatilidad de las evidencias digitales es la siguiente:
1) CPU, cache y contenido de los registros
2) Tabla de enrutado, tabla ARP, tabla de procesos, estadísticas del kernel
3) Memoria
4) Ficheros temporales, espacio de intercambio
5) Información en discos duros
6) Información registrada remotamente
7) Datos guardados en dispositivos de almacenamiento

Cuanto más volátil es una evidencia, antes debe ser recuperada para evitar su alteración.

En entornos Windows existe un tipo de evidencia que suele ser olvidada por la literatura clásica: la cache de DNS. Que podríamos situar en el punto 2 de la anterior lista, por su alta volatilidad.

Para recuperar esta cache podemos utilizar el comando ipconfig de la siguiente forma:

ipconfig /displaydns

El formato de la salida es el siguiente:

ejemplo.net
----------------------------------------
Nombre de registro . : ejemplo.net
Tipo de registro . . : 1
Período de vida . . . : 84627
Longitud de datos . . : 4
Sección . . . . . . . : respuesta
Un registro (host). . : 10.0.0.150

A simple vista podemos ver la gran utilidad de esta información. Nos permite determinar que nombres DNS se han resuelto últimamente y cuando se han introducido en la cache. Es decir, podemos deducir con bastante precisión a que sitios se ha conectado desde el equipo en las últimas horas o minutos (dependiendo del tiempo de caducidad de cada registro).

Esta información puede ser muy interesante si no ha transcurrido mucho tiempo desde el suceso a investigar, pero recordemos que esta información es altamente volátil y desaparece rápidamente.

Para calcular el momento en el que se creó la entrada en la cache tenemos que hacer un sencillo cálculo: Obtener el tiempo de caducidad del registro y restar el tiempo de vida que queda. La diferencia será el tiempo que ha pasado desde que el registro se introdujo en la cache.

En este ejemplo:

C:\> nslookup -type=A -debug ejemplo.net | findstr ttl
Respuesta no autoritativa:
ttl = 27338 (7 hours 35 mins 38 secs)
ttl = 86400 (1 day) <- Caducidad del registro

Obtenemos el siguiente cálculo:

86400 - 84627 = 1773 -> Hace unos 30 minutos que se creó la entrada en la cache.

Se puede automatizar este proceso para realizar un resumen de todas las entradas que existan en la cache y poder obtener un cronograma aproximado de la actividad DNS reciente en el equipo (y a partir de ella deducir la actividad de red). Muy útil.

Ramón Pinuaga Cascales
Dept. Auditoria S21sec

Post-Rooted CON

Hacía tiempo que se esperaba una CON pública con acento español, y ésta llegó la semana pasada. La Rooted CON tuvo lugar a partir del lunes 15 de marzo y hasta el sábado 20, dedicando los tres primeros días a los trainings, con formaciones sobre análisis de malware, ingeniería inversa o pentesting, entre otras.

Las conferencias comenzaron el jueves 18, tocando temas como la lucha contra los ataques cibernéticos dirigidos a empresas y organizaciones (Fighting Advanced Persistent Threat (APT) with Open Source Tools), anécdotas de Pedro Sánchez sobre diferentes situaciones reales ocurridas durante sus análisis forenses (Autopsia de una intrusión: A la sombra del chacal), consejos sobre cómo trabajar en el mundo de la seguridad informática (Operación Triunfo Profesional) por parte de Alejandro Ramos o la interesante charla sobre el cibercrimen. Se terminó la jornada con un panel de discusión sobre el nuevo código penal aplicado a las nuevas tecnologías.

El viernes 19 se comenzó con una charla sobre los fallos de diseño en firewalls (FuckWALL - Bypassing Firewalls), seguida de la explicación sobre el funcionamiento del CCN-CERT en el ámbito de la respuesta ante incidentes, y de la ponencia de nuestro compañero Antonio Ramos, explicando el análisis de la seguridad utilizando la llamada Teoría de las Limitaciones (La seguridad como sistema. Factores limitantes y evolución en el tiempo). Se terminó la mañana con la charla sobre WiFiSlax 4.0 y la esperada puesta en escena de Rubén Santamarta liberando un 0day en primicia. Aún quedaban otras dos más para la tarde: la presentación de Radare2 y sus diferentes usos, y el análisis del diseño y vulnerabilidades de Oracle Financials por parte de Joxean Koret (Hackproofing Oracle Financials 11i & R12). Por último, cerrando el día, el panel con dos invitados de excepción, dos miembros del mítico grupo Apostols (Jordi y Ramón) contando sus aventuras y desventuras.

El último día se intuía como el mejor por los ponentes y el contenido de sus charlas. Se dio el pistoletazo de salida con la ponencia sobre seguridad y explotación en Android, por parte de Javier Moreno y Eloi Sanfélix, seguida por la de David Reguera y su técnica de hookeo y modificación de librerías en caliente. Tras una charla sobre los hackers en el mundo del cómic entró en escena David Barroso, contando, a modo de historia, la peligrosidad de una posible botnet para iPhones. Después de comer la cosa siguió con Chema Alonso y su FOCA v2.0, una charla sobre una nueva variante de una técnica de esteganografía, y la de Fermín J. Serna sobre mitigaciones en explotación de entornos Windows, presentando la segunda versión de su EMET (Enhanced Mitigation Evaluation Toolkit). Todo el material de las charlas irá saliendo próximamente en la página de la Rooted CON.


De forma paralela a las charlas y coincidiendo con la primera del viernes comenzó también el Capture The Flag (CTF), organizado por RoMaNSoFt, dreyer y Antonio. Consistía en pruebas que se iban liberando y que podían resolverse en cualquier orden. Cada prueba tenía una puntuación fija más otra variable que dependía del número de personas que la superaban. Al final se liberaron más de quince (creo recordar) con temática muy variada como SQL y LDAP Injection, explotación de un BOF remoto, análisis de protocolos de comunicación, un crackme, análisis de shellcodes, desofuscación de Javascript, y un largo etcétera. Sin lugar a dudas un gran trabajo de los organizadores. Hubo un gran nivel durante todo el tiempo que duró la prueba, con especial mención al pique sano entre los dos primeros clasificados, whats y kachakil, que lucharon hasta el final por el primer puesto.

En el post-Rooted se puede decir que la experiencia ha sido buena, hay cosas que mejorar, por supuesto, pero sin duda es una buena línea de trabajo; esperaremos ansiosos la del año que viene :)


Jose Miguel Esparza
S21sec e-crime

Gestión de Eventos de Seguridad
Todos somos conscientes de la creciente importancia que la información y su tratamiento está adquiriendo para las organizaciones. Esta importancia deriva del aumento exponencial del volumen de datos con el que han de lidiar los Responsables de Sistemas de Información. Las necesidades de almacenamiento y procesado de datos se siguen multiplicando, al igual que las necesidades de asegurar la información en términos de Confidencialidad, Integridad y Disponibilidad.

Actualmente, nos hayamos inmersos en un cambio de paradigma en el que la seguridad está pasando a tratarse como un proceso continuo totalmente integrada con el resto de procesos de las organizaciones. Para que este cambio se pueda llevar a cabo, es imprescindible que se implementen sistemas o plataformas que permitan analizar, comprender y reaccionar ante los eventos de seguridad que se produzcan en nuestra compañía.

Sin embargo, llevar a cabo estas tareas de análisis es realmente complejo, ya que el número de fuentes que pueden generar eventos de seguridad es cada vez mayor; Firewalls, IPS/IDS, VPN, Servidores Web, Logs de aplicaciones, Sistemas centrales, Sistemas distribuidos, PC de usuarios, portátiles, dispositivos móviles, cámaras de videovigilancia, registros de entrada física a los edificios, y un largo etcétera…
Por lo tanto, las organizaciones se enfrentan en la actualidad a volúmenes ingentes de eventos que no pueden ser controlados de una forma manual. Atrás quedaron los tiempos en los que bastaba con uno o varios operadores visualizando una consola de logs para controlar lo que ocurría en los sistemas de una instalación.
Por otro lado, muchos de estos eventos no tienen sentido por sí mismos, sino que han de contextualizarse con eventos provenientes de otras fuentes. Es decir, nuestro sistema de análisis ha de ser capaz de aplicar inteligencia y correlacionar eventos entre sí. Además es imprescindible realizarlo en tiempo real, ya que en la mayoría de los casos la velocidad de detección será clave para que podamos reaccionar a tiempo ante una amenaza o incidente grave de seguridad.

¿Cuánto vale mi marca?

Hola a todos, felicidades a todos aquellos que sois o vais a ser padres.

En este post vamos a explicar un caso concreto de por qué son muy útiles las técnicas de protección de marca y qué herramientas podemos utilizar para monitorizarla.

Imaginemos que somos una compañía que además de sus fuentes de venta tradicionales también tenemos una página web para dichas ventas, un caso muy raro, ¿verdad?, pues bien, qué pasa si tenemos a "alguien" utilizando una página web parecida o no en forma, pero sí en contenido que se encarga de "captar" a posibles clientes, para o bien llevarse una comisión por la transacción o bien redirigirlos a páginas de nuestra competencia.

¿Cómo podemos valorar el coste que este tipo de páginas web nos representa?, una forma sencilla pero aproximada podría ser:

Sabemos un porcentaje de las visitas realiza compras y el valor medio de las compras, por lo tanto el coste que nos representará será la multiplicación del número de visitas que esas páginas tengan por el valor medio de las compras por el porcentaje de efectividad de la página.

Este coste puede llegar a ser realmente alarmante e incluso que las páginas fraudulentas (están haciendo un uso indebido de la marca) pueden llegar a tener en su conjunto incluso más visitas que la nuestra.

Otras posibles causas pueden ser un correcto posicionamiento en los principales buscadores, ya que la mayoría de los visitantes se dirigirán a los primeros resultados (casi siempre el primero).

¿Cómo nos protegemos?

En primer lugar debemos controlar que no existan páginas que puedan suplantar mi marca, en caso de que las haya emprender las acciones legales pertinentes.

Posteriormente seguir monitorizando para que no aparezcan nuevas falsificaciones.

Para ello se pueden utilizar técnicas manuales o servicios o herramientas que nos permitan y faciliten el trabajo realizado.

¿Qué ganamos con todo esto?, cuanto más complicado lo tenga un posible atacante menos probable es que seas su objetivo.

José María Arce Guillén

S21sec e-crime

Smart Grid, ¿una red demasiado “lista”? (II)

Continuando el post anterior, voy a aprovechar para revisar las implicaciones desde el punto de vista de la privacidad que supondrá la Smart Grid para los futuros clientes de esta nueva red eléctrica. El uso de dispositivos y contadores inteligentes pondrá a disposición de las compañías eléctricas (y quizás también en manos más desaprensivas) información relacionada con el servicio eléctrico que podría clasificarse como de carácter personal.

En la actualidad el consumo eléctrico se contabiliza al finalizar el período de facturación. Con la Smart Grid, la monitorización del mismo se realizará en intervalos de tiempo muchos más cortos, que podrán ir desde una contabilización diaria, hasta otra que podía ser casi en tiempo real. Esto dependerá de las capacidades de los contadores inteligentes y de las necesidades y requisitos de la propia compañía eléctrica. Debido a esta monitorización de consumo, así como por la sustitución de los actuales electrodomésticos y aparatos electrónicos por otros más inteligentes, se podrá llegar a deducir información como:

• Número aproximado de personas en la vivienda en cada momento
  
• Cuándo una vivienda está desocupada
  
• Si los inquilinos se encuentran despiertos o durmiendo
  
• Qué electrodomésticos/aparatos electrónicos se están utilizando y cuándo suelen utilizarse
  
• Si los clientes tienden a cocinar más con el microondas o por el contrario prefieren la cocina más tradicional
  
• Si los inquilinos desayunan
  
• Si la casa cuenta con un sistema de alarma, y cada cuánto es activado
  
• Cuál es el momento elegido habitualmente para la ducha
  
• Si los electrodomésticos están en buenas condiciones o están estropeados (falta de uso, consumo excesivo, etc.)
  
• El número de aparatos electrónicos en la casa
  
• Si la vivienda cuenta con lavadora y secadora y cada cuánto se usan
  
• Si las luces se encienden o los aparatos electrónicos (ordenador, TV, etc.) se utilizan a horas poco comunes (de madrugada, etc.)
  
• Si se dispone de una cinta de correr para hacer deporte y cuánto se usa
  

Si además relacionamos esta información con otra asequible por otras vías, como por ejemplo el lugar de trabajo de los inquilinos o si éstos tienen hijos o no, se puede llegar a hacer predicciones como:

• Llega tarde al trabajo porque sale tarde de casa cada mañana
  
• El marido llega a casa siempre poco después de cerrarse los bares
  
• Alguno de los inquilinos padece insomnio
  
• El propietario deja conectados los electrodomésticos cuando se va al trabajo
  
• La persona apenas lava la ropa
  
• El propietario deja a sus hijos en casa solos
  
• Los inquilinos apenas hacen deporte
  

Con este tipo de información más elaborada sería posible calcular estadísticas de uso energético, de utilización de dispositivos por marca todo ello a nivel individual o agregado a nivel de vecindario, ciudad, provincia o país. Así mismo, este tipo de deducciones permitiría realizar campañas de marketing mucho más específicas, con anuncios de productos concretos, ofertas específicas para un tipo de cliente, etc. También las compañías de seguros podrían llegar a calcular las pólizas en base al riesgo personalizado derivado de los hábitos de vida. Finalmente, esta información también puede resultar muy valiosa para potenciales atracadores que podrían aprovechar los momentos en los que la casa está vacía.

La pregunta que cabe ahora es: ¿llegará la Smart Grid realmente a este nivel de detalle o se quedará en meras experiencias piloto, que podemos ver cada día? Aquí en la oficina hemos tenido una interesante discusión al respecto. ¿Vosotros qué pensáis?

Elyoenai Egozcue,

S21sec labs

Bancos contra carders

Acordaos de la última vez que usasteis el comercio online. Muy probablemente en el formulario para autorizar la compra, además del CVV, vuestro nombre y la caducidad de la tarjeta, os pedían ese número de 3 cifras impreso en el reverso de la misma. En el argot bancario a este numerito se le denomina de distintas formas: para VISA es el CVV2 (Card Verification Value 2), Master Card lo llama CVC2 (Card Validation code 2) y American Express CID2 (Card Identifier 2).

Independientemente de la nomenclatura el CVV2, o como queráis llamarlo, es una de las medidas que implementaron en su día las entidades emisoras de tarjetas para evitar el fraude en Transacciones No Presenciales, es decir compras realizadas por Internet, teléfono o fax. Como os podéis imaginar estas operaciones son las más propensas al fraude, debido a que resulta imposible identificar al cliente de forma fiable.


El sistema se basa en que tanto el CVV como el nombre del titular y la caducidad están grabadas en la banda magnética, sin embargo el CVV2 no. Y además la normativa de VISA, M.C y AMEX prohíbe expresamente que se almacene en las bases de datos de los comercios online. Eso quiere decir que aunque tu tarjeta haya sido copiada en un restaurante, gasolinera o similar mediante un bonito skimmer o bien los delincuentes hayan comprometido la base de datos de tu tienda online preferida, les seguirá faltando el CVV2 y no podrán realizar compras online ilegítimas (a.k.a online carding).
La idea en su momento fue útil, pero hace años los carders la superaron, haciendo unos ajustes en los clásicos ataques:

Phishing
No me refiero a los enfocados contra la banca online, sino los destinados a capturar tarjetas. Generalmente vienen en forma de webs para recargar el móvil, aunque algunos años también nos sorprenden con sugerentes devoluciones fiscales. En ambos casos se intenta que la víctima introduzca el CVV2. Una variante original son falsos sites de comercio online o de contenido adulto situados altos en Google mediante Black Hat SEO

Vishing
Otra posibilidad muy comentada en foros underground, si se posee el CVV y los datos personales (generalmente mediante la explotación de una base de datos), consiste en llamar al cliente y conseguir el CVV2 con un poco de ingeniería social empleando los datos que conocemos para dar sensación de seguridad a la víctima.

Código malicioso
Los métodos anteriores no están mal, pero actualmente la principal fuente de datos del mundo del carding, con mucha diferencia, son las botnets.

El método de captura más sencillo es mediante el formgrabbing implementado por la mayoría de los troyanos bancarios. En este ejemplo pueden verse los datos de un usuario capturados, por Sereki mientras realiza una compra. El malware se activa al detectar la URL de la pasarela de pago (tapada en rojo) obteniendo CVV, CVV2 y fecha de caducidad.

Otra posibilidad más sofisticada es la inyección HTML que tantas veces hemos comentado en este blog. La siguiente imagen muestra la página del Bank of América modificada por nuestro amigo ZeuS.


En este caso, la pantalla insertada aparte del CVV2 también pide el PIN; la razón es la siguiente: conociendo las claves de acceso a la banca electrónica obtendremos el nombre del cliente. Con CVV + fecha de caducidad + nombre montamos una banda magnética válida , la grabamos en una tarjeta falsa y junto con el obtenido por ZeuS se pueden hacer compras en comercios (instore carding) o directamente sacar dinero en cajeros (real carding).

Para terminar podéis ver que ZeuS también solicita el ZIP del usuario ¿alguien sabe por qué lo está haciendo? Al que pueda aportar una respuesta válida le invito a un copa en la fiesta de la Rooted CON de este sábado :D

Javier Barrios Martos
S21sec ecrime

fun!SharedMalwareData

El rootkit TDL3 contiene una peculiaridad en su código que se aprecia rápidamente al ser visualizado en un desensamblador: el uso masivo de direcciones de memoria absoluta, sin relocalización, que referencian diferentes offsets de una misma página. La dirección de memoria absoluta es una dirección de memoria virtual válida de kernel, 0xFFDF0000, y el offset al que más veces se hace referencia es +0x308, 0xFFDF0308.

Tras un breve análisis se puede determinar que estas direcciones de memoria son utilizadas como una única variable global en la que el rootkit almacena unos cuantos datos y a los que accede constantemente durante su ejecución.

Ejemplos de uso en el código:

Usando windbg se puede obtener la siguiente información:

En el mapa de direcciones virtuales de Windows x86 32bits esta "misteriosa" dirección virtual pertenece al espacio asignado para uso de HAL:

Aunque en principio es posible continuar el análisis del rootkit sin saber lo que significa esta dirección de memoria y el contenido de la página que referencia, al final, es necesario tener toda la información posible para no perder ningún detalle.

Una búsqueda en Google de la dirección virtual 0xFFDF0000 nos muestra varios documentos y rápidamente damos con la pista definitiva. De todos los resultados destaca un artículo muy interesante publicado hace unos pocos años, de sobra conocido, "Remote Windows Kernel Exploitation Step into the Ring0" de Barnaby Jack. En este documento se muestra detalladamente como construir una shellcode que debe funcionar en kernel y los trucos que podemos utilizar para localizar APIs, zonas de memoria, etc. En una de las secciones del artículo se comenta lo siguiente:

"
... we can store our code within kernel-user-shared memory, officially known as SharedUserData. At 0xFFDF0000 is a writable memory area where we may store our shell code. This memory address is mapped from user land at 0x7FFE0000 and marked read only; these mapped locations are the same on all platforms, so it is a good choice for keeping everything generic. As the data at this memory location is readable from all processes, we are not required to switch into the address space of our target process.
...
"

Con esta aclaración todas las dudas quedan despejadas, la "misteriosa" dirección virtual dentro del espacio de kernel se corresponde con la famosa estructura de datos global SharedUserData:
nt!_KUSER_SHARED_DATA.

Esta página tan peculiar es mapeada en ring0 y ring3 durante la inicialización del sistema (ntoskrnl) en la rutina nt!MiInitSystem():

Utilizando windbg de nuevo se puede comprobar que el doble mapeo es válido y se accede al mismo contenido a través de las dos direcciones de memoria virtual, una de kernel y otra de un proceso de usuario:

Hay que tener en cuenta que SharedUserData es una estructura bastante grande y al ser usada por el sistema y por los procesos de usuario no se puede cambiar el valor de cualquier campo. Los autores del rootkit han tenido esto muy en cuenta y los datos almacenados son "camuflados" en determinados campos o en el espacio restante de la página, evitando así cualquier mal funcionamiento del sistema.

El tipo de datos que guarda el rootkit y para que los usa es otra historia :)

Rubén Jiménez
S21sec e-crime

INFORMES DE AUDITORÍA: ¿SON TODOS IGUALES?

A la hora de evaluar un informe de una auditoría técnica de seguridad podemos entrar a valorar diferentes aspectos, pero en este post vamos a considerar para dicho análisis dos conceptos, por un lado, el contenido y, por otro, el formato.

En cuanto al contenido, obvia decir que, como punto de partida, cualquier informe de auditoría tendrá que dar cumplida respuesta a la expectativa del cliente. Si en algún caso el destinatario no tiene claro cual será el tipo de entregables, la información contenida en el mismo y la utilidad que podrá dar al trabajo, estas cuestiones deberán aclararse antes de comenzar, apoyándose en el archiconocido principio “más vale prevenir que curar”.

Como elementos esenciales se tendrá presente que cualquier hallazgo que se incluya en un informe técnico tendrá que regirse bajo los siguientes principios:

• Las pruebas se realizarán con la profundidad requerida para los objetivos propuestos.
• La auditoría se realizará teniendo en cuenta la legislación vigente.
• Los resultados que se obtengan podrán ser medidos, consistentes, y si se repiten las pruebas se obtendrán resultados similares (repetibles).
• Las conclusiones que se obtengan estarán derivadas únicamente de las pruebas realizadas y serán pertinentes, es decir, estarán en línea con los objetivos de la auditoría.
• El lenguaje empleado será acorde a la audiencia que lo reciba.
  

EVALUACIÓN DEL CONTENIDO

Existen aspectos imprescindibles en cuanto al contenido y que podrán ser clave a la hora de decidir escoger a un proveedor de seguridad u otro. Estos aspectos podrían ser:

• En cuanto a cada uno de los riesgos identificados:
  
  
  
  • Grado de abstracción deseado para la tipificación del riesgo, se podría denominar “vulnerabilidad tipo” o “problema tipo de seguridad”.
  • Riesgo asociado a la vulnerabilidad identificada en un lugar concreto. (*1)
  • Nivel de detalle de la ocurrencia identificada sobre el riesgo tipo. La descripción deberá de facilitar la posibilidad de repetir el proceso de detección para evaluar si la corrección aplicada es correcta. Para evaluar adecuadamente este punto se podría plantear la siguiente reflexión ¿Es suficiente una herramienta automática para realizar esta tarea?, seguramente NO.
  • Posibilidad de identificar de forma unívoca e inequívoca la ubicación del riesgo hallado, dirección IP, IP y puerto, URL, URL y parámetro afectado, etc.
  • Simplicidad y claridad de la descripción para que alguien “no técnico” pueda interpretarla.
  • La inclusión de enlaces o referencias externas que añaden información clarificadora sobre el riesgo hallado.
  • Recomendaciones y propuestas de solución para cada riesgo identificado matizando las propuestas para que se puedan adaptar a los riesgos concretos hallados en cada trabajo.
    
    

Monitorización de internet

Como algunos de vosotros ya sabréis, uno de los temas habituales de este blog es la privacidad en las redes sociales. Otro de los temas que ya hemos tratado anteriormente es el de la reputación online. Ambos dos conceptos nos llevan a plantear un tercero, el concepto de la monitorización de internet.

En unos tiempos en los que la divulgación de información de toda índole está a la orden del día, vía redes sociales, blogs, y páginas web en general, cada vez más, las empresas y personajes públicos/relevantes en general se están dando cuenta de que es interesante estar al día de lo que se habla de ellos en internet.

No solo se trata de vigilar la reputación online de personas/empresas, también, la divulgación de información privada puede ayudar a crear ataques del tipo “spear phising”.

Recientemente se ha dado un caso muy curioso en Inglaterra, relacionado con los conceptos hasta ahora vistos. La protagonista de esta historia es la mujer del director de los servicios secretos de Gran Bretaña, el famoso MI6.

Técnicamente, los datos referentes al director, su esposa etc. son datos de carácter secreto. Y digo técnicamente, porque en la practica dejaron de serlo, a raíz de que la mujer los público en su perfil de facebook, haciéndolos públicos delante de 200 millones de usuarios. Un pequeño fallo puede tenerlo cualquiera, y en este caso, a la señora en cuestión se le pasó por alto proteger esos datos haciéndolos privados dentro de facebook.

Detalles, como por ejemplo, la ubicación de su piso en Londres, lista de amigos (entre ellos, estrellas de la televisión, familiares etc.) fueron revelados, y lo mejor de todo es, que el MI6 no se enteró de la jugada hasta que un periódico les avisó.

¿Donde están los servicios de monitorización del MI6? ¿No sabían lo que estaba haciendo, sin querer, esta señora?

He aquí un ejemplo de porque se tiene que tener en cuenta la monitorización de internet.

 

Asier Marruedo

S21sec e-crime

SCADA, más estándares, más documentos..

Hoy apenas tengo tiempo de escribir un post más de los míos (de esos de 20 páginas), así que dejaré algo más sintetizado y comprimido de lo habitual, acerca de lo que me hubiera gustado haber escrito y que no he podido.

Durante estos días hemos podido apreciar una evolución en el interés de la seguridad en infraestructuras críticas, incluyendo los sistemas SCADA. Que dicho interés sea reciente (en los últimos dos años) en este país, no significa que no se haya hablado largo y tendido e incluso realizado acciones concretas en otros. Una de las apreciaciones más comunes en los diferentes eventos a los que asistimos es precisamente la de que la situación actual de las infraestructuras en España (en cuanto a seguridad se refiere) está años atrasada, y que no debemos reinventar la rueda.

Existen varias iniciativas nacionales que pretenden 'crear' desde cero estándares de seguridad para estos entornos, lo que para nosotros es un error dado que ese esfuerzo ya se ha realizado anteriormente, esfuerzos probados y comprobados. Ya hay un camino recorrido, y dado que la seguridad de las infraestructuras críticas es algo que beneficia a todos, es mejor subirse a un tren en marcha que no pretender arrancar uno nuevo. Con el tiempo, durante estos años, se ha ido creando un tren por cada tipo de 'entorno' en las IC; los criterios de estos entornos van en función de si existe legislación que cumplir, o del porcentaje de PIB que dicho entorno o sector genera. Pongamos una lista de ejemplo:

• Transporte (ferrocarril, metro, control aéreo, …)
• Aguas (depuradoras, sistemas de regadío, …)
• Distribución (gas, electricidad, petróleo, …)
• Generación (eólica, térmica, nuclear, ...)
• Alimentación y bebidas (lácteas, cerveceras, …)
• Procesos industriales clásicos (químicas, maderera, siderurgia, …)

Aún en esta categorización, es necesario particularizar mucho más la definición de "medidas de seguridad" aplicables/interesantes/obligatorias/lo que sea. Pongamos por ejemplo los casos de distribución y generación de energía, casos que en España existen en forma de varias empresas competidoras, y que dispone desde hace tiempo de normativas y recomendaciones:

• IEC 61850: Sistemas y redes de comunicación para la automatización del suministro de energía
• IEC 62351: Seguridad y comunicación en datos NERC- CIP
• IEC 61968: Interfaz de aplicación para sistemas de administración de la energía
• IEC 61400-25: Comunicaciones para la supervisión y control de plantas eólicas generadoras de energía
• IEC 60850-5: Perfiles 101/104 y DNP3
• IEEE 1686: Capacidades de Seguridad de dispositivos electrónicos inteligentes (IED’s) en subestaciones

El cruce de estos estándares con las normativas vigentes de nuestro pais pasa por el acercamiento de las infraestructuras críticas hacía la ISO 17799, algo en lo que nosotros llevamos trabajando más de un año ya. Como camino para llegar a este resultado hemos tenido que ir resolviendo diferentes preguntas a lo largo del camino, os dejo algunas como muestra:

• ¿Con qué frecuenta se van a modificar las normas, y que margen de tiempo la legislación va a permitir la adecuación a los estándares?
• ¿Qué nivel de implantación existe y que nivel de implantación se exige, o se exigirá a las diferentes empresas?
• ¿Cómo afecta el tamaño de la infraestructura crítica al nivel de exigencia?
• ¿Cómo diferencian estos estándares los sistemas hechos a medida de los productos comprados?
• ¿Qué herramientas existen para completar la adecuación a estos estándares? ¿qué herramientas existen para comprobar la adecuación de estos estándares?

Al que le interese, antes o después llegará a encontrar respuesta a estas preguntas, claro que para hacerlo divertido tampoco vamos a poner las soluciones ahora, ¿no?

Iñaki López

S21Sec Labs

Redes sociales: Números rojos en privacidad

Hace ya algún tiempo leí en un blog la falta de privacidad en las redes sociales. Estas redes, como ya se ha dicho multitud de veces en este blog, pero que es bueno reiterar, usan una gran cantidad de datos personales. Estos datos, son transferidos dento de la red sin ningún tipo de codificación ni acreditación, es decir, suelen estar en claro dentro de nuestro perfil a la vista de cualquier persona que tenga un nexo de "amistad" con nosotros.

También es consabido que dentro de este tipo de redes existe alto número de perfiles de dudosa credibilidad, es decir, perfiles cuyo único objetivo es agrupar el mayor número de gente para obtener un beneficio sobre ellas. A este tipo de perfiles se les suele denominar perfiles hub. Basándonos en los perfiles hub, la universidad de Rutgers elaboró un articulo sobre el impacto que produce una ataque sobre las redes sociales. El articulo se centra en explotar los perfiles hub uniendo a sus perfiles agregados a una botnet y controlando a las víctimas de dicha botnet vía la red social. El estudio concluye una serie de soluciones entre las que se encuentra la restricción de perfiles hub, la realización y control de una jerarquía de amigos, la creación de un sistema de reputación basado en el comportamiento del perfil y la protección de los datos del usuario.

Como conclusión, decir que los ataques sobre redes sociales están a la orden del día y malware como Zeus hacen que los datos que se almacenan en las redes sociales puedan ser usados con otro fin de dudosa ética. Por esta razón, tanto las redes sociales como los mismos usuarios deben concienciarse en el valor de estos datos personales y de los mecanismos de acceso necesarios para difundirlos.

Aitor Corchero Rodríguez

S21sec labs

Aprendiendo del enemigo. Spammers

Desde hace algunos años poseo una cuenta en gmail, principalmente debido a que me permitían tener un nombre mucho mas profesional al de hotmail, tenia mas capacidad de almacenamiento y no recibía prácticamente ningún correo spam.

Desde hace algunas semanas estoy empezando a recibir algunos correos un tanto sospechosos:

Al principio no lo tome demasiado en cuenta pero debido a varios casos que he vuelto a detectar, empecé a cuestionar me una serie de preguntas :

¿de donde han obtenido mi dirección?
¿cómo he llegado yo a esta lista?
¿por que me envían SPAM?


Inicialmente, se enviaban correos utilizando direcciones IP de origen conocidas o enviaban los correos a servidores de correo de internet.
La primera solución que se decidió tomar fue asignar las direcciones IP de las cuales provenían estos correos a las famosas DNS BLACKLIST (Listas Negras), las cuales siguen siendo utilizadas por firewalls, antispam y antivirus.


Estas listas se alimentan mediante robots encargados de buscar sistemas Open Relay's Http://en.wikipedia.org/wiki/Open_mail_relay(Esta técnica aun no está optimizada del todo ya que, una vez detectado , se deberá intentar contactar con el administrador del servidor de correo afectado y en el caso de que no muestren cambios en la configuración, el servidor sera incluido en la lista).

Los sistemas de correos abiertos, han sido durante muchos años unos de los métodos preferidos por los spammers para el envío de correo masivo, una vez que se detecta un servidor con estas características, los responsables del servidor relay son afectados por un consumo de recursos y ancho de banda elevado y, por la parte contraria, la de sus clientes, reciben una cantidad ingente de correo basura o “spam”

En los últimos años, el uso de esta técnica se ha visto reducida, debido posiblemente a los problemas que podrían acarrear, por ejemplo, el no atender bien a estas listas antes descritas.

Telefónica, 2004.
Http://www.hostinglmi.es/bitacoras/index.php/archives/2004/05/12/telefonica-en-blacklist/


Algunas de estas técnicas son conocidas como:

E-Mail Address Harvesting
Proceso de obtención de listas de correo de formas tan dispares como las siguientes:
*Compra de listas a otros spammers
*Búsquedas de direcciones a través de búsquedas realizadas en páginas web (USENET)
*Uso de Aplicaciones software (Spam bots, harvesters)


Directory Harvest Attack
Consiste en ataques de diccionario sobre los servidores de correo, donde aquellas direcciones de correo que sean válidas en dominios, son obtenidas por fuerza bruta, mediante el uso de nombres comunes en direcciones de correo y a través de la respuesta dada por el servidor.

Ejemplo: intentar mediante scripts, encontrar correos como: pepe@eldominio.com, paco@eldominio.com, etc...

Los spammers para conocer si estos correos son válidos o no, saben que los servidores de correo usan una utilidad para diferenciar a los usuarios legítimos: el comando VRFY, por el que un servidor de correo chequea el usuario antes de enviarle un correo, y el comando EXPN, por el cual podríamos obtener una lista con todos los usuarios en el servidor.

Ejemplo:

$ telnet localhost 25 Trying 127.0.0.1 ... Connected to localhost. Escape character is '^]'. 220 localhost sendmail ---- ready at Fri, 12 Feb 2010 09:13:12 -0800 debug 500 Command unrecognized vrfy jose 250 Pepito el de los palotes expn all 250-Juan Cisneros 250-Pepito el de los palotes 250-Alfredo Perez Rubalcaba [/code]

Eso si en la actualidad, han sido deshabilitadas.

Otras de las técnicas de los spammers de burlar la seguridad es usando formatos de archivos desconocidos, son las siguientes (detectadas por Symantec):

-eFax: Tipo de archivo asociado al popular servicio del mismo nombre, y funciona asociando al correo electrónico un número de Fax real como si de un aparato se tratase, esto con el fin de facilitar el envió y recepción de faxes entre personas, recibiendo estos en la bandeja de entrada en forma de adjuntos.

-MHT: Un formato de archivo web creado originalmente por Microsoft para intercambiar contenido por la internet, cuya función es guardar páginas web que emulan un email HTML. Actualmente dicho tipo de fichero es soportado por varios navegadores entre los que es popular el de Opera.

Solo cabe por destacar los correos mas típicos recibidos como SPAM

1.Ofertas de trabajo en casa o aquellas que te ofrecen un empleo fácil y beneficios muy jugosos a cambio de nada o casi nada.
2.Relojes Rolex, Mido o de marcas reconocidas, eso si, casi siempre con su correspondiente descuento.
3.Cadenas de apoyo solidario, FW y demás del tipo de reenvío.
4.Mails con asuntos bancarios (nuevas tarjetas, comprobación de solicitudes inexistentes, promociones).
5.Ofertas de negocios, publicidad empresarial y todo lo que tenga que ver con “apoyo” a negocios y microemprendimientos.
6.Usando los eventos deportivos del momento, dígase juegos olímpicos o copas mundiales de fútbol.
7.Informando la muerte de algún personaje famoso o un incidente insólito acerca de alguno, mentiras por supuesto.
8.Escudándose en instituciones gubernamentales o privadas con cierta reputación.
9.Publicidad de productos en general.
10.Viagra, el asunto favorito de estos trash mails, por temporadas sube.


Propongo ahora algunas de las técnicas para ocultar direcciones de correos.

Mediante el empleo de técnicas conocidas como "Address Munging", se intenta ocultar la dirección de correo en las páginas WEB o post en listas de correo. Por ejemplo, la cuenta de correo pepe@example.domain, puede ser escrita utilizando esta técnica como "pepe at example dot domain", "pepe-at-example-dot-domain", "pepe AT example DOT domain" ...
Lamentablemente casi todo el mundo utiliza las mismas técnicas de ocultación, con lo que los programas cosechadores de direcciones de correo ya conocen el léxico empleado en la mayoría de ocasiones. Solo hace falta hacer una búsqueda del tipo +"-AT-" +"-DOT-com" y en google aparecen más de 36.000.000 de resultados con direcciones de correo ocultas con este tipo de mecanismos. La mejor forma de ocultar nuestra dirección de correo de los famosos Harvesting Bots, es incluir una imagen con nuestra dirección de correo. Aunque esto no nos libra de los ojos de los spammers.
(imagen sacada de intenet).

Si se me permite la sugerencia, a modo personal, propongo evitar todo tipo de correo que pida directamente el reenvio a "todos tus contactos"....(el 99,9% es SPAM...)

como ya sabreis este no es el único método de extraer informacion personal:

- Envio de sms con el fin de extraer informacion
http://blog.s21sec.com/2010/02/smishing.html
-Usos fraudulentos de las redes sociales
http://blog.s21sec.com/2010/01/10-usos-fraudulentos-de-twitter.html

Raúl Pérez Rojo. S21sec.

Video not killed the radio star

Toda empresa de seguridad de las telecomunicaciones que se precie invierte parte de su trabajo en el I+D en el campo de la seguridad. Se buscan vulnerabilidades en general o estudios más específicos, como auditar Oracle a fondo, por ejemplo en S21sec contamos con un laboratorio específico de sistemas SCADA justamente para analizar la seguridad de los mismos.

Una forma de financiación de los mismos poco reconocida es la de que se ofrece dinero a cambio de vulnerabilidades en muchos paquetes de software, sobre todo últimamente con recompensas por vulnerabilidades en los principales navegadores. Este esfuerzo de investigación no solo lo realizan los buenos sino también los malos que buscan vulnerabilidades con los que instalar sus troyanos, y suponemos que para prepararse para las tan cacareadas ciberguerras.

En un mundo donde tendemos a migrar nuestras comunicaciones a tecnologías como GSM, 3G, UMTS, HDSPA, WIMAX, WIFI, RDS, Bluetooth, WiMedia, ZigBee,TDT, etc. Si como vemos la información tiende a ir por el aire ¿no sería lógico invertir un poco más en la investigación de las comunicaciones de radio?

Existe ya mucha información sobre la mayoría de los protocolos de radio que he dicho antes, muchas vulnerabilidades ya publicadas, muchas solo teóricas, otras fácilmente explotables con el hardware disponible, otras no se explotan porque no existe hardware fácilmente accesible o es muy caro.

Siempre que ha existido un framework para estudiar un protocolo de radio, éste siempre ha acabado vulnerado, por ejemplo, WIFI o DECT. De GSM también se han publicado fallos, pero al ser bastante caro (que no difícil) su interceptación parece la razón para que no preocupe a la comunidad de seguridad.

¿Y si el creciente crimen organizado “electrónico” se hiciera con un sistema barato de capturar 3G, GSM, GPRS? Correos mandados desde tu blackberry capturados, si alguien va a argumentar que las comunicaciones de radio van cifradas, le tendré que recordar las comunicaciones vía satélite, el GSM, el Wifi, el DECT...

Aparte existe un gran número de tecnologías inalámbricas propietarias usadas para control de sistemas (SCADA o no), por ejemplo, en mi ciudad se que numerosas estaciones de control de agua (por ejemplo, compuertas) se hacen de forma inalámbrica. Igualmente muchos de los transformadores de electricidad aquí situados.

Además, últimamente han ido apareciendo extrañas antenas que no se a que están conectadas. Existen paneles informativos sobre el sistemas de transporte público que también van por radio ¿Nadie audita eso? ¿En qué consistiría una auditoría en este campo?

Unas pocas antenas de las que se encuentran en un simple paseo con el perro.

El proceso de auditoría consistiría primero detectar la frecuencia de la señal (existen escáneres que simplemente estando al lado del emisor de señal te dicen la frecuencia). Después se pasa a analizar la señal, un proceso complicado y que tardaría mucho en explicar aquí, después pasar a 1’s y 0’s si es que es digital, interpretar el protocolo, hacer un disector, etc. Vamos que no es algo simple, y todo esto si el sistema no utiliza salto de frecuencias, cifrado, etc.

Resumiendo, cada vez usamos más las comunicaciones de radio para acceder a nuestros sistemas, muchos de estos protocolos no están lo suficientemente analizados y, desde mi punto de vista, poco a poco habrá personas que se den cuenta que de estos sistemas pueden obtener mucha información o controlar infraestructuras críticas. Por este motivo se debería fomentar más proyectos como GNU Radio, OpenBTS, la auditoría de las femtocell o en general el análisis de protocolos de radio a bajo nivel.

A fin de que las compañías de seguridad tengan más acceso a ese tipo de comunicaciones, a la auditoría de las mismas, haciendo entender a cada empresa y/o gobierno a que peligros están expuestos realmente y así se puedan solucionar de forma eficaz, desarrollando sistemas de comunicación de radio seguros y después, ya nos preocuparíamos sobre la seguridad en los servidores.

Leonardo Nve

S21sec Auditoría

Disfruta la red con seguridad

Desde hace más de una década en la sociedad ha surgido un nuevo debate ¿es Internet peligroso? ¿es un arma?¿es solo un medio?...
Parece que el Gobierno de Navarra tiene una opinión al respecto, Internet puede ser nocivo para los menores si no se usa correctamente. Por ello ha creado un plan para el uso seguro y responsable de las Tecnologías de la Información y la Comunicación (TIC) para los menores navarros.

Los objetivos del Plan, cuyo lema es “Disfruta la red con seguridad”, son los siguientes: capacitar a los menores para el uso responsable, seguro y saludable de la red; aumentar la información y los conocimientos entre el personal docente y los padres; crear una base sólida de profesionales especializados en todo el territorio foral; conocer cuáles son los usos y necesidades del público destinatario, y extraer conclusiones que puedan servir de base al Departamento de Educación para su extensión al resto de centros.
El plan piloto se pondrá en marcha con los alumnos de Secundaria y de 5º - 6º de Primaria. Se llevará a cabo en varios centros Navarros. Además de a los alumnos, está dirigido a madres y padres de los centros escolares implicados, así como a su profesorado.

Entre las iniciativas previstas se contemplan una serie de actividades, dos sesiones de formación de 50 minutos cada una por aula, una sesión informativa para padres, talleres prácticos modulares optativos para padres y una sesión de formación específica con el profesorado.

Algunos de los temas que se tratarán en las sesiones son: privacidad y datos personales; precauciones con el uso de la Webcams; las redes sociales, ventajas y riesgos, y contactos con desconocidos; privacidad, manejo de la imagen y de los datos personales; ciberbullying, grooming, sexting y medidas preventivas, o responsabilidades legales de las acciones cometidas en Internet.


Amaia Urtasun
S21sec e-crime

Red Storm amplía sus usos

La semana pasada, el superordenador Red Storm de Laboratorio Nacional Sandia (Albuquerque, Nuevo Méjico) fue designado como "DOE user facility" (DOE, Department of Energy). En la actualidad, Red Storm cuenta con 12.960 AMD Opteron™ nodos (en 2008 se aumentó la capacidad de computación hasta 280 teraflops para asegurar su uso por otros cuatro o cinco años), es el décimo ordenador más rápido del mundo y el ordenador principal del NSCC (National Security Computing Center).

+ datos sobre Red Storm y fotos

¿Qué implica su nuevo status? Al pasar a formar parte de la red de instalaciones de alta tecnología del DOE, se abre a nuevos usuarios y aplicaciones.

El DOE gestiona el acceso a las instalaciones, para fomentar y garantizar la colaboración, por medio de diferentes tipos de acuerdos según el usuario y el fin:

• Non-proprietary User Agreement: para investigadores con fines no comerciales. Los investigadores pueden acceder a los laboratorios especializados y colaborar con sus científicos, manteniendo cada uno la propiedad de sus descubrimientos y los datos de investigación obtenidos por los investigadores externos se hacen públicos.
• Proprietary User Agreement: para investigaciones comerciales, reteniendo los datos técnicos generados (con limitadas excepciones).
• Cooperative Research and Development Agreements (CRADAs) y Non-Federal Work for Others agreements (WFOs): para usos comerciales de usuarios industriales.

Hasta ahora Red Storm se ha utilizado en el ámbito nuclear: diseño y simulación de componentes y estudios armamentísticos. En el año 2008, ya se utilizó para la planificación de misión en la Operacion Burn Frost, para destruir con un misil un satélite espía y prevenir que su tanque de combustible tóxico cayese a la tierra; ahora se empleará en temas de seguridad nacional como: ciberdefensa, evaluación de vulnerabilidades, informática y amenazas en sistemas espaciales.

Diego López
S21sec Labs

Un nuevo ataque a WPA/TKIP

Desde que a primeros de noviembre de 2008, Erik Tews y Martin Beck abrieran la caja de Pandora demostrando la viabilidad de capturar información enviada desde un router protegido con WPA/TKIP, se han ido sucediendo pequeños avances en las técnicas utilizadas en dichos ataques yendo desde la inyección de un mayor número de paquetes maliciosos (tal y como se demostró en un paper publicado por unos estudiantes de la universidad de ciencia y tecnología de Noruega en la NorSec Conference celebrada a mediados de octubre de 2009) hasta el último ataque conocido en el que, Matin Beck, vuelve a la carga con un nuevo ataque (PDF) que, gracias a un refinamiento de la técnica utilizada, permite inyectar no solamente un mayor número de paquetes, sino que estos, pueden contener más información.

Haciendo memoria

Recordemos que, TKIP (Temporary Key Integrity Protocol), es una variante de WEP. El hecho de que inicialmente WPA utilizara este sistema -frente al más seguro AES- se debe, simplemente, a una cuestión económica.

En la mayoría de los casos, un router que soportase el protocolo WEP podría ser actualizado por software para soportar el protocolo WPA/TKIP pero, probablemente no a WPA/AES pues, este último, es computacionalmente más exigente que el primero y, por tanto, sería necesario una actualización del hardware -normalmente mediante un cambio de router- con el coste que ello implicaría.

De todas formas, TKIP si que supone un pequeño avance frente a WEP pues, aparte del vector de inicialización del paquete presente en el protocolo WEP (los conocidos como IVs), se utiliza una clave de sesión que, convenientemente "mezclada" con el vector mencionado anteriormente, impide utilizar los ataques conocidos en la actualidad para WEP ya que cada uno de los bytes de un paquete, depende tanto del vector de inicialización como de la clave de sesión. Además de esto -y para evitar ataques basados en la fragilidad de la protección por CRC32 utilizado en WEP-, TKIP implementa dos medidas adicionales: un Message Integrity Check (MIC) de 64 bits incluido en cada paquete a transmitir conocido como "MICHAEL", y un contador de secuencia (TSC) diseñado para asegurar el orden de recepción de los paquetes.

Microsoft (1) - Waledac (0)

A finales de febrero y después de una investigación de varios meses, Microsoft ganó el juicio contra el imaginario John Doe (nombre utilizado de manera simbólica para representar a los responsables de la botnet Waledac) para forzar el cierre de la infraestructura formada por un total de 277 dominios (objetivo de la denuncia) y 90000 ordenadores infectados que formaban parte de esta red.

La iniciativa llevada a cabo con la colaboración de organizaciones como Shadowserver, la universidad de Washington y Symantec entre otros, tenía como objetivo involucrar a terceras partes responsables de la gestión de diversos dominios (VeriSign, China Springboard, Wild West Domains, etc.) para forzar su actuación en el cierre de los dominios implicados.

La denuncia (pdf) presentada detalla el funcionamiento de la botnet así como los objetivos del entramado criminal detrás de ella (envío de spam, malware, recolección de datos, ataques de denegación de servicios, alquiler a terceras partes, etc.).

Fuente: http://blogs.technet.com/microsoft_blog/archive/2010/02/25/cracking-down-on-botnets.aspx

La estructura multi-capa de Waledac está formada por:

- Nodos Spam: Máquinas infectadas a las que se les envía la orden de envío de spam. Los correos enviados pueden ser spam puro y duro o incluir otro tipo de códigos maliciosos.

- Nodos Repetidor: A nivel genérico, se trata de máquinas infectadas que funcionan como redirectores de tráfico. Serían los encargados de redirigir las comunicaciones entre diferentes bots o enrutar nuevas máquinas aún no infectadas hacia servidores de malware después de una campaña de spam. También pueden funcionar como servidores de nombres de dominio (DNS).

- Nodos Control: Estas máquinas NO son nodos infectados, siendo su tarea principal la de actuar como proxy inverso. Básicamente reciben datos de los "Nodos repetidor" y lo transfieren a otros servidores "detrás" de los nodos TLS. La función de esta capa de servidores es la de ocultar los servidores que hay en la última línea de la botnet, lo que dificulta en gran medida la recolección de información de las zonas detrás de estos nodos. Estos nodos están controlados por los responsables de la botnet.

-Nodos Principales: Los paneles de control de la botnet. Estos servidores son controlados directamente por los admins de la botnet. Realizan funciones de organización y coordinación de los distintos nodos que forman la red mediante el envío de instrucciones.

Evidentemente, la sentencia actúa contra estas dos últimas capas que forman el entramado de gestión de Waledac ya que seguramente sería todo un caos legislativo/técnico/social intentar tomar medidas judiciales contra las máquinas infectadas o sus proveedores. En este sentido, Microsoft ha tenido el acierto de realizar la denuncia incluyendo todas aquellas entidades legítimas que necesitan en muchos casos un apoyo legal en el que basarse para tomar este tipo de decisiones.

Esperemos que iniciativas como esta sigan prosperando y aunque por el momento no se juzgue ni conozca a sus responsables directos, se empiece a mermar de forma continuada los recursos de los que disponen.

Daniel López
S21sec e-crime