Empieza el combate para SHA-3

El pasado 31 de octubre se terminó el plazo de presentación de algoritmos Hash para el nuevo estándar SHA-3. En total se han presentado unos 64 trabajos de los cuales la mitad son públicos y entre los que hay que citar, por curiosidad, la propuesta de un joven de 15 años y el nuevo MD-6 presentado el pasado mes de agosto.
En la fase preliminar de criptoanálisis ya se han roto 8 de los candidatos públicos (no tengo acceso a los candidatos privados) y si el calendario se cumple la proxima semana se darán a conocer los algoritmos que cumplen todos los requisitos de la competicion.
Para finales de febrero está prevista la presentación oficial justo después de la FSE y muy pronto, en 2012, tendremos el nuevo estándar SHA-3, eso si al menos uno consigue llegar a la final.

Eduardo Morrás
S21sec labs

¿Confías en tu cuenta de correo?

Recientes rumores hablaban sobre una vulnerabilidad de seguridad en uno de los populares servicios de correo. Nada más lejos de la realidad, no se trataba de una vulnerabilidad en ese cloud computing, sino que algunos usuarios de ese servicio, habían sido víctimas de un ataque phishing y erróneamente se había propagado el rumor de vulnerabilidad de seguridad en dicho servicio. "Donde dije vulnerabilidad, digo descuido por mi parte".

Actualmente, cuando todos utilizamos cuentas de correo personales, en ocasiones incluso más que nuestra propia cuenta de correo corporativa, ya sea por todo el tipo de características y servicios dispares que nos ofrecen, o porque ya tenemos desarrollada nuestra identidad alrededor de ella, conviene pensar en la seguridad de este tipo de cuentas, no a nivel del servicio como la falsa vulnerabilidad anterior, sino a nivel de las características que nos ofrecen, y nuestro comportamiento en Internet.


Aquí, la seguridad no depende tanto del proveedor del servicio, sino de nosotros mismos, de nuestros hábitos en Internet.

A veces, el bosque no nos deja ver los árboles.
¿Seguro que sómos los únicos que leemos nuestras cuentas de correo personales?

Emilio Casbas
S21sec labs

EL PROBLEMA REAL Y UNA POSIBLE SOLUCIÓN

¿Recuerdan al señor O.?

La mayoría de los encargados de seguridad de las empresas entre medianas y grandes lo tienen muy en cuenta. Y por ese motivo invierten la mayor parte de sus recursos para protegerse de amenazas externas.

Sin embargo, existen informes de que la mayoría de las pérdidas de información se deben a agentes internos de los cuales, casi el 75% no eran malintencionados. Cada dos por tres nos encontramos con alguna noticia en prensa, ¿cierto?

Y es que no es necesario recurrir a los informes de las compañías que tienen algo que ganar vendiendo sus productos para darse cuenta de que esos peligros están ahí. Basta ver cómo se funciona para darse cuenta de que, en mayor o menor medida, casi todo el mundo:

· Utiliza memorias externas, CDs, IPods, para extraer documentación de la empresa. Incluso considerándolo, y no es del todo incorrecto, una medida "de seguridad". Seguridad frente a la pérdida o destrucción de esos datos, desde luego, pero aumentando el riesgo de que caiga en manos indebidas.

· Transmite esos archivos a direcciones de correo electrónico externas, personales, e incluso, erróneas. ¿Quién no ha dicho alguna vez "Ups" justo después de darle al "send"? Bien... pues ahora imagínate al amigo/compañero/familiar más despistado que conoces, y piensa en cómo de parda la podría liar.

· Comunica información sensible con sistemas de mensajería instantánea, a menudo no corporativos.

· Envía el documento que no debe a la impresora que no es, dejando durante días datos confidenciales en la bandeja hasta que alguien los coge y... los tira. ¡Qué suerte! ¡No ha pasado nada! (Esta vez).

Por ese motivo, varias de las principales compañías de seguridad del mundo se han posicionado (a menudo a su estilo, comprando a golpe de talonario compañías pequeñas) en el mercado del Data Loss Prevention.

Ten cuidado con tus puntos de fuga.

Estas tecnologías básicamente se dedican a controlar los modos de transferencia de la información, y son capaces de reconocer aquellos flujos que no deberían permitirse. Existen en estos sabores:

· Como tecnología de red. Introduciendo firmas de seguridad en los documentos sensibles (de manera automática o asistida) de los repositorios, para decidir si permitir o no ciertas transferencias.

· Como tecnología de usuario final. Interviniendo en las aplicaciones y dispositivos por las que se accede/transmite/copia la información: email, webmail, p2p, IM, skype, HTTP, HTTPS, FTP, Wi-Fi, USB, CD, DVD, impresoras, fax, discos extraíbles…

· Como combinación de ambas.

Las principales ventajas de los sistemas DLP es que son útiles tanto frente a comportamientos maliciosos como frente a descuidos y que son independientes del tipo de información que se quiera proteger. Sus principales problemas son que son bastante caras, muy intrusivas con el sistema y, por lo tanto, de instalación costosa.

Pese a ello, poco a poco, cada vez más clientes preguntan y se interesan por el tema. Es decir, están "creando un mercado".

Por supuesto, eso hace que las siglas DLP se pongan de moda y que cada vez se vean más productos que presentan "funcionalidad DLP". Lo cual es es engañoso. Hay que tener muy claro que, a menudo, estas compañías se dedican a meter el mismo producto que ya tenían en otra caja con nuevas siglas.

Del mismo modo que no todo lo que tiene ruedas es un coche, no se puede decir que cualquier, digamos, firewall, NAC o tecnología de cifrado haga lo que un DLP. Aunque ayude a prevenir pérdidas de datos. Por supuesto, puede que lo que se necesite no sea un coche, pero siempre es bueno saber qué es lo que te están vendiendo.


Luis Tarrafea
s21sec labs

Recolección de Información pública - IV OWASP

La cuarta conferencia realizada por OWASP en España ha sido todo un éxito, la sala estaba completa con más de 150 personas, es interesante la cantidad de participantes en España si lo comparamos con el resto de países donde OWASP realiza conferencias, aunque no podemos comparar nunca con OWASP APPSEC Asia donde han participado 1500 personas!!

Las presentaciones aún no están disponibles en el site de OWASP, pero aquí os dejamos como adelanto la presentación que hizo nuestro compañero Christian Martorella sobre recolección de información pública, "A fresh new look into Information Gathering".

En la charla surgieron ciertas dudas por parte del público de cómo una empresa puede controlar lo que se dice de ellas, o que información se filtra por comentarios de los trabajadores en foros, blogs, etc. Esta no es una tarea fácil, pero en S21sec contamos con un servicio de "Vigilancia Digital" que aporta una solución a las empresas, con esta problemática.

Explotando la MS08-067

Cada vez el lapso de tiempo entre la aparición de una vulnerabilidad (o parche que la soluciona) y la aparición del malware que la explota, es menor. Un estudio de una universidad americana decía que el récord eran 30 minutos desde la aparición de un parche y la explotación de la vulnerabilidad que solucionaba.

En cualquier caso, ya hemos detectado el primer caso de malware que explota la vulnerabilidad recientemente parcheada por Microsoft MS08-067, en este caso mediante el gusano conocido como W32-Downadup o Win32/Conficker.A.

Tras la instalación en el sistema a través de un loader, el gusano se copia a sí mismo en el directorio del sistema de Windows en forma de DLL con un nombre aleatorio. Además se crea un nuevo servicio también con un nombre aleatorio que permite la ejecución de la DLL en cada inicio del sistema, creando a su vez una entrada en el registro donde se especifica la ruta que se ejecutará al inciarse el servicio.

La DLL realiza diversas peticiones para obtener la IP externa de la máquina infectada, dejando a la escucha un servidor web en un puerto aleatorio del equipo, enviando una URL del tipo http://IP_EXTERNA:puerto_aleatorio al intentar explotar nuevos equipos, y sirviendo desde aquí una copia del malware en su intento de propagación. De esta forma, no es necesario un servidor externo para expandirse, sino que cada máquina infectada ayuda en esta tarea.

Además realiza más peticiones HTTP: una de ellas intentando descargarse una base de datos de geolocalización de IPs; en otra, el gusano intenta descargarse y ejecutar un falso Anti-Spyware que tras realizar falsos escaneos proporcionará ciertos resultados indicando que es necesaria una limpieza del equipo e invitando al usuario a comprar la versión completa del producto.



También existen evidencias de que se realizan otras peticiones a ciertos dominios con el objetivo de obtener la fecha actual, generando nuevos dominios desde los que se descarga más malware.

Además de todo esto, el gusano coloca ciertos hooks en funciones conocidas del sistema, destacando las colocadas para controlar los movimientos del ratón y las pulsaciones del teclado en el ámbito del proceso iexplore.exe, que podrían usarse para el robo de credenciales e información sensible enviadas a través de Internet.

Como ya se ha comentado brevemente en párrafos anteriores, el gusano intenta propagarse a través de la explotación de la vulnerabilidad de RPC en los equipos vecinos. Para ello intenta infectar al segmento local donde se encuentra, probando la explotación en cada IP, una a una y de forma secuencial. En caso de tener éxito, el equipo infectado se decargará desde el servidor web instalado en la máquina propagadora una copia del binario malicioso, continúando así su infección masiva.

También se ha observado capacidad de propagarse buscando unidades compartidas e interacción mediante uPnP con los routers de salida (generalmente ADSL), aunque todavía no se ha podido analizar en profundidad este comportamiento.

En conclusión, este gusano está empezando a hacer estragos especialmente en redes corporativas, gracias a la explotación de una vulnerabilidad reciente y que muy posiblemente esté sin parchear en muchos equipos. A la hora de prevenir este ataque basta con aplicar el parche que da título a este post, que se puede descargar desde:

http://www.microsoft.com/technet/security/Bulletin/MS08-067.mspx

Vicente Díaz

S21sec e-crime

Deja deja, ya pago yo con mi Visa-móvil

Echando un vistazo a las noticias recientes del mundo del RFID, y del que ya hemos hablado en varias ocasiones en el blog, me llama la atención una noticia sobre las alianzas del fabricante de móviles finlandés con Visa, de modo que se pueda habilitar, mediante la tecnología Near Field Communication, la posibilidad de hacer pagos (a débito de momento) con el teléfono.

Ya se que no es nada nuevo, tan sólo me choca que se siga adelante con la iniciativa del uso de NFC para transacciones comerciales. Desde luego, y como en otros casos, el consumidor tendrá la última palabra. Yo, por lo pronto le veo algunos problemas:

• Tu teléfono móvil sería tan atractivo para los chorizos como una cartera, con la diferencia de que esta última no te la pones en la oreja con lo que es menos visible. Además, una tarjeta de crédito/débito dura entre 2 a 3 veces más que un móvil hasta ser reemplazado. ¿Será ese reemplazo transparente para el usuario?
  
• Podría suponer una nueva fuente de SPAM telefónico a base de mensajitos *MS, qué mejor para el operador que tener correlados y listos para su venta, los datos de tu tarjeta de débito, comercios donde la has usado, y número de teléfono. Así los comercios tendrían muy fácil el mandarte avisos sobre la liquidación de la marca de ropa temporada de otoño que siempre compras. Esperemos que para entonces esté regulado el tema del SPAM telefónico
• Y cómo no, seguridad seguridad y más seguridad. Nuestras transacciones (más o menos seguras) viajando por el aire, así a priori, no resulta muy atractivo. Y hablamos de NFC, un protocolo en el que las prestaciones a nivel autenticación y cifrado parecen haberse dejado de lado, al más puro estilo RFID clásico. Bueno, podrían pensar en volver a tropezar con la misma piedra si se lo proponen, en la próxima versión de las especificaciones
  
• Un móvil no nace (se fabrica) con un criptoprocesador embebido del estilo del presente en el DNIe. Esto quiere decir que en algún momento habrá que cargarle los certificados (no están generados en el móvil). ¿Cómo será de seguro este proceso? ¿Se podrá usar la SIM como sustituto igualmente válido?
  

Aunque ahora mismo, tal y como pone en la noticia, se encuentra en fase piloto, me quedo intranquilo. Pero como dije antes, al consumidor, que de él depende la adopción de una tecnología (afortunadamente) le preocupa cada vez más su seguridad y privacidad, y antes de aceptar una tecnología de este tipo, tendrá que ver que puede confiar plenamente en ella.

Álvaro Ramón
S21sec labs

Protección del software (Parte VII)

Siguiendo con las técnicas antidebug, pensemos en qué más cosas podemos tratar de detectar.

1. Si estamos siendo depurados
2. Si se está ejecutando una aplicación no deseada
3. Si se tiene instalada una aplicación no deseada
4. Tratar de evitar el attach del proceso desde un depurador
   

Personalmente el uso de las técnicas comentadas en los puntos 2 y 3 no me parece ético en el ámbito del software comercial, ya que el ejecutar ciertas aplicaciones (y aún más el hecho de tener aplicaciones instaladas) no incumbe al creador de software, pero son técnicas muy utilizadas. Veamos algunos ejemplos:

Tratar de saber si estamos siendo depurados:

• IsDebuggerPresent, CheckRemoteDebuggerPresent.

• Consulta de ciertos valores dependientes de la presencia de un depurador, como NTGlobalFlag, valores devueltos por NtQueryInformationProcess, etc.

• Protecciones de tiempo: Esta protección, menos técnica, trata de averiguar el tiempo que se tarda en ejecutar cierto código, ya que si el tiempo es muy elevado se puede suponer que se ha detenido la ejecución y, por tanto, está siendo depurado. Existen varias maneras de obtener el tiempo transcurrido, con GetTickCount, QueryPerformanceCounter, rdtsc o GetProcessTimes.
  

• Excepciones. Si el programa levanta una excepción, el depurador por defecto detiene la ejecución y la maneja, de tal modo que la ejecución continúa en la instrucción siguiente. Por contra, si el propio programa instala un manejador de excepciones, podrá redigir el flujo a donde desee. Podemos utilizar SEH (Structured Exception Handler) o VEH (Vectored Exception Handler).
  

• Comprobar que el proceso padre no sea un depurador (o esperar que sea explorer.exe)

Buscar aplicaciones no deseadas en ejecución:

• Por ejemplo, mediante el título de las ventanas

• Mediante el nombre del proceso

• Mediante un patrón de bytes

Buscar aplicaciones no deseadas instaladas: Existen diveros métodos, como buscar ficheros conocidos en rutas concretas o entradas de registro conocidas. Cualquier característica que identifique el software nos puede servir pero, como hemos comentado al inicio, no es una actitud muy recomendable.

Tratar de evitar el attach del proceso desde un depurador:

• Apertura exclusiva: Se realiza una apertura exclusiva del fichero.
  

• Sobreescritura de API. Una manera poco elegante puede consistir en sobreescribir alguna API que sepamos que se va a ejecutar.

Existe además algún truco para intentar cazar al atacante cuando no se lo espera, como puede ser la introducción de código en callbacks TLS, tal y como se puede ver en alguno de los primeros retos publicados, de tal manera que este código se ejecuta antes que la supuesta primera instrucción del programa.

Recordad daros una vuelta por Securityfocus para ver alguno que se me haya escapado ;)

Mikel Gastesi
S21sec e-crime

McColo vuelve... durante un rato (¡aunque bien aprovechado!)

Ya hablamos del ISP McColo hace unos días y de lo que suponía como amenaza a la sociedad. Pensaba que ya teníamos que pasar página sobre este ISP pero no es así, puesto que esta semana reapareció durante unos instantes, esta vez más cerca de nosotros, en Suecia. El motivo fue que un ISP sueco (TeliaSonera AB) fue el que le pusó otra vez activo en Internet a través de un router que tiene esta empresa en San José. Rápidamente este ISP fue notificado del error que estaba haciendo y tomaron las medidas oportunas para volver a dejar a McColo fuera de Internet. Realmente reaccionaron rápido y muy bien.

Durante el tiempo en que McColo estuvo de nuevo vivo, se esforzó en actualizar todos sus C&C para redirigir todas sus botnets a otros ISPs (varios de Rusia) para poder seguir con su fraudulento negocio. Si fue capaz o no de migrar todos sus C&C el tiempo lo dirá.

Lo que sí es que está claro es que siguen esforzándose en volver a aparecer en Internet. Hay otros ISPs de Asia que están siendo utilizados para intentar volver a estar activo. Justo en el momento de escribir estas líneas, acabo de comprobarlo y hay otro ISP que está dándoles acceso, en este caso GBLX Global Crossing Ltd. (AS3549), con lo que con toda probabilidad les dará tiempo a "mover" toda su infraestructura y el SPAM volverá a los números anteriores.

De nuevo nos encontramos el problema que ya hemos comentado varias veces: blackholing a un ISP no es efectivo puesto que es relativamente fácil reubicarse en otro sitio. O se toman medidas legales y se persigue a la gente que está detrás de McColo, o nunca seremos capaces de acabar con sus actividades.

David Barroso

S21sec e-crime

IV Conferencia OWASP España

Después de la última conferencia con mas de 200 participantes, se celebra una nueva edición de las conferencias OWASP en España. El evento se realiza como iniciativa del capítulo español de la OWASP, el cual pretende difundir la seguridad en las aplicaciones WEB y los proyectos desarrollados por la organización.

Esta nueva conferencia se celebrará el dia 21 de Noviembre en el "IL3 - Institute for LifeLong Learning (Universitat de Barcelona)"

La asistencia es GRATUITA. Debido a la limitación del aforo, todos aquellos interesados en asistir deberán notificarlo previamente enviando un correo incluyendo la palabra "INSCRIPCIÓN" en el asunto del mensaje.

En cuanto al cartel en esta ocasión se hablara de "w3af: Un framework de test de intrusión web", "Análisis de eco en Aplicaciones Web", "Microsoft Seguridad IT al descubierto" y por último Christian Martorella de S21sec hablará sobre "A fresh look into Information Gathering", una interesante charla sobre nuevos métodos y fuentes de obtención de información pública sobre un individuo o compañía.

Nos vemos por allí

Phreaking

La telefonía podría considerarse como el primer sistema de telecomunicaciones cuyo uso se generalizó entre la población. Como no podía ser de otra manera aparecieron personas que tenían curiosidad por el funcionamiento de este sistema. A estas personas se les acabó conociendo como phreaks como mezcla de “phone” y “freak”. De ahí han salido términos como phreaking o phreaker y un movimiento que se podría considerar como el comienzo del posterior movimiento p/hacker.

En un principio las llamadas se enrutaban manualmente. Es decir, cuando se solicitaba, una persona realizaba la conexión de los 2 extremos manualmente, por lo que el único recurso que quedaba era la ingeniería social. Este sistema no era sostenible teniendo en cuenta el ritmo al que crecía la red telefónica. Cuando se automatizó el establecimiento y enrutamiento de las llamadas aumentaron las posibilidades de investigar en el funcionamiento del sistema. Este movimiento lógicamente surgió en EEUU. Los primeros descubrimientos se hicieron por azar, cuando Joe Engressia (Joybubbles) descubrió que un tono de 2600 Hz hacía que una llamada ya establecida se interrumpiera. Lo que sucedía es que había descubierto un tono de control que hacía que el enlace quedara libre, preparado para recibir más comandos en forma de más tonos de control. La señalización del sistema usaba el mismo canal de comunicación que las propias llamadas. Los descubrimientos hechos por varias personas, junto con un artículo sobre el tema publicado en “Bell Labs Technical Journal” hizo que varias personas (algunas de cierto reconocimiento en la actualidad) consiguieran hacer llamadas, cancelarlas o redireccionarlas a otro número. Todos estos descubrimientos se tradujeron en varios dispositivos como la caja azul o la caja negra, que usando la señalización de control de la red de telefonía, permiten hacer llamadas gratis, añadir crédito a una cabina pública sin introducir dinero, hacer que suene el teléfono aunque no haya ninguna llamada, falsificar la identidad de una llamada, etc...
Aparte de esto, se atacaron los sistemas de prepago, la seguridad física de las cabinas públicas, modems conectados a la red telefónica, etc, etc...
En muchas ocasiones se usaban los conocimientos para llamar sin pagar a la compañía correspondiente, por lo que muchos phreaks eran perseguidos por las compañías y por la ley. Además, la difusión de estos conocimientos no era tan sencilla ya que se realizaba por teléfono (muchas veces mediante llamadas “gratuitas”) entre un grupo reducido de gente, que muchas veces ya estaban relacionados con el tema de una manera u otra. Esto hizo que fuera un movimiento relativamente minoritario, pero sin duda importante.
Mas en concreto, en España el movimiento phreak apareció muchos más tarde, en los años 90, gracias a la (escasa) información que se distribuía por BBS. Se investigó el funcionamiento de la red telefónica del país (distinto al de EEUU), su señalización, el uso (abuso) de los números gratuitos (900), buzones de voz, así como fallos en las cabinas públicas que en algunos casos permitían llamar gratis de manera anónima.

Según la red de telefonía ha evolucionado, estas técnicas se han quedado desfasadas y el phreaking con ellas. Actualmente utilizar VoIP y redes de datos modernas para dar servicios de telefonía es cada vez más común, por lo que los riesgos de seguridad o privacidad se parecen cada vez más a los del resto de servicios como el correo o la navegación web y se tratan de igual manera. De todas formas el phreaking clásico quizás pueda enseñarnos algo a la hora de lidiar con la seguridad de las modernas centralitas de VoIP.

Patxi Astiz
S21sec labs

Acciones en el Portable Document Format

El formato PDF está al alza, o eso parecen indicar varias vulnerabilidades en productos de Adobe publicadas recientemente, y que permiten la ejecución de código arbitrario en el sistema. Por ahora no me voy a meter con ese tipo de archivos maliciosos, aunque cuando haya expuesto todo el potencial del Portable Document Format seguramente haré una referencia a ellos.

Tras la breve explicación sobre los diferentes objetos que podemos encontrar en un documento de este formato, y su estructura física y lógica, seguiré con las acciones que se pueden llevar a cabo en background. Los PDFs no son documentos estáticos, sino que es posible especificar en su interior cierta programación de instrucciones a llevar a cabo según las acciones que realice el usuario. Como ya estaréis pensando, es aquí donde se esconde el verdadero problema en cuanto a la seguridad se refiere, y que convierte a un PDF en malware potencial, con una alta probabilidad de ser ejecutado.

Una acción en un PDF es un objeto de tipo diccionario que puede contener los siguientes elementos:

• /Type: es opcional y sirve para indicar el tipo de objeto que describe el diccionario. En este caso Action.
• /S: es un elemento obligatorio y define el tipo de acción a realizar.
• /Next: también es opcional, y permite especificar la siguiente acción o acciones que se ejecutarán después.

Además, dependiendo del tipo de acción, los elementos que se pueden incluir en el diccionario aumentan, permitiendo un mayor grado de control. Los tipos de acciones que podemos encontrar se describen a continuación:

• GoTo: coloca el foco de la aplicación en otra parte del documento.
• GoToR: coloca el foco en una parte concreta de otro documento diferente del actual.
• GoToE: permite redireccionar a/desde un documento PDF incrustado.
• Launch: ejecuta una aplicación o lee o imprime un documento.
• Thread: salta a un artículo dentro de un documento.
• URI: permite acceder a páginas o recursos remotos.
• Sound: reproduce el sonido especificado.
• Movie: reproduce el vídeo especificado.
• Hide: oculta o muestra la anotación o anotaciones especificadas.
• Named: ejecuta una acción predefinida por el lector PDF.
• SubmitForm: envía los datos de un formulario existente a una URL dada.
• ResetForm: cambia el valor de los campos de un formulario a sus valores por defecto.
• ImportData: importa datos desde un fichero al documento.
• JavaScript: ejecuta un script JavaScript.
• SetOCGState: fija el estado de un grupo opcional de componentes, que son una colección de elementos gráficos distribuidos a lo largo del documento.
• Rendition: controla la reproducción de contenido multimedia.
• Trans: permite controlar la transición gráfica entre diferentes acciones.
• GoTo3DView: identifica una anotación de tipo 3D y especifica un tipo de vista a usar por ésta.

El desencadenante de estas acciones es muy variado dependiendo de dónde se encuentren especificadas. Su ubicación suele ser una anotación o cualquier objeto que forma parte del esquema del documento (outline), se introduce a través del elemento /A, y se ejecutará cuando el objeto correspondiente se active. También pueden ubicarse en una anotación, una página o un campo de un formulario interactivo a través del elemento /AA, acciones adicionales, y su ejecución variará dependiendo de las opciones elegidas. De esta forma se pueden programar acciones cuando el cursor del ratón entra o sale de una zona en una anotación, cuando se visualiza cierta página del documento, o cuando se cambia el valor de un campo de un formulario, entre otras muchas otras. Además, mediante el elemento /OpenAction, ubicado en el catálogo del documento, se puede ejecutar una acción al abrirse el documento.

Como veis, las acciones pueden dar mucho juego. Este post ha querido ser una introducción a la ejecución de acciones en un documento PDF, en próximas entradas se desgranarán algunas de las más importantes desde un enfoque más práctico.


Jose Miguel Esparza
S21sec e-crime

Factor humano y contraseñas

¿Cómo de segura es la contraseña que usas para proteger tu información privada?

Elegir la contraseña adecuada es fundamental para conseguir proteger nuestros datos. Para explicar qué se entiende por "contraseña adecuada" tal vez tenemos que mirar la otra cara de la moneda: los métodos que se utilizan para poder romper las contraseñas.

Destacan dos, el ataque por fuerza bruta y el ataque por diccionario.

El ataque por fuerza bruta consiste en probar todas las combinaciones de password posibles hasta encontrar aquella que permite el acceso. Los ataques por fuerza bruta, dado que utilizan el método de prueba y error, son muy costosos en tiempo computacional.

Los ataques de diccionario consisten en intentar averiguar una contraseña probando todas las palabras del diccionario (palabras con sentido, o también combinaciones de letras/números que se usan como contraseña habitualmente: 123abc, etc.). Este tipo de ataque suele ser más eficiente que un ataque de fuerza bruta ya que muchos usuarios suelen utilizar una palabra existente en su lengua como contraseña para que la clave sea fácil de recordar, lo cual no es una práctica recomendable.

Así pues, visto lo visto, en un principio nos quedamos con la idea de que nuestra contraseña debe tener, por un lado una longitud considerable (contraseñas de menos de 8 caracteres se pueden considerar débiles), y por otro, a ser posible, no deben de estar basadas en palabras de diccionario. ¿Es esto suficiente?. Pues no, también hay que tener en cuenta el "factor humano".

Y digo esto, debido a una reciente discusión que hemos mantenido entre los compañeros de trabajo aquí en S21sec. Pongamos, que yo, elijo una canción en euskera (para complicarlo un poco, je,je) al azar, y decido utilizar una estrofa de esta canción como clave. En un principio, podría parecer que mi clave puede ser vulnerable frente a ataques por diccionario. Además, el "factor humano" interviene: he apuntado mi contraseña en un papel que está en mi escritorio, de esta manera, cualquiera puede leer mi clave. ¿Sería la gente capaz de entreveer que la contraseña está escrita en ese papel? Y, lo que finalmente motivó el debate entre nosotros, ¿usar estrofas de canciones en euskera es una buena elección como clave?.

Por un lado son claves lo suficientemente largas como para que ataques por fuerza bruta sean inviables. Por otro, si tenemos en cuenta que dentro del euskera hay 5 dialectos (sin contar el euskera unificado, mas conocido como euskera batua), que cada una de las canciones puede transcribirse en uno de esos 5 dialectos y que no todas las canciones que existen en euskera están transcritas, a primera vista parece que un ataque por diccionario tampoco es factible. Además, al ser una canción, es fácilmente memorizable. ¿Es entonces una contraseña de este tipo adecuada? (el caso del euskera, dadas las particularidades de ese idioma da mucho juego, aunque la pregunta puede ser extensible para cualquier idioma).

No os podéis ni imaginar el debate que ha surgido a partir de esta cuestión. A partir de aquí, espero vuestras opiniones, y ya de paso, os dejo una pequeña guía de buenas prácticas para la gestión de contraseñas seguras (gracias Montse ;-)), que por supuesto no es una lista cerrada:

• Contraseñas alfanuméricas de 10 a 12 caracteres. Que tengan parámetros de no coincidencia con el ID, y el histórico de contraseñas utilizadas, y limitación de utilización de palabras preseleccionadas Ej. Nº DNI usuario, nombre empresa, meses, años, equipos de fútbol, grupos musicales, etc.

• Cambio periódico cada 90 días por ejemplo (aunque el empleo de una contraseña robusta con todos estos requerimientos podría hacer posible que la contraseña se cambiase con una periodicidad incluso mayor).

• Bloqueo de la cuenta con necesidad de que intervenga el administrador (no bloqueo temporal de la cuenta) al 3 ó 5 intento.

• Histórico de 8 a 14 contraseñas.

• Bloqueo de la cuenta por inactividad durante por ejemplo 1 mes (15 días o menos para sistemas muy críticos Ej. Cuentas de administración de sistemas).

• Cambio obligatorio de la contraseña en la primera autenticación del usuario.

• Exclusión del uso de ID genéricos o compartidos.

• Y por supuesto, tratar de minimizar el "factor humano"; si apuntáis vuestra contraseña en algún papel, guardarlo en un sitio seguro (ah! y nunca le digáis la contraseña a nadie).

Nota: Si tenéis curiosidad de saber cuanto tiempo costaría sacar por fuerza bruta vuestra contraseña, no dudéis en visitar esta página.

Asier Marruedo
S21sec e-crime

McColo: bullet-proof hosting in the USA

Desde primeras horas del día de ayer un ISP norteamericano dejó de existir en Internet: McColo (AS 26780). La razón no fue la quiebra de la empresa, sino que sus homólogos norteamericanos dejaron de enrutar sus paquetes (situación parecida hace unos meses a Atrivo/Intercage). En los servidores de este ISP estaban paneles de control (C&C) que manejaban muchas de las botnets responsables del SPAM actual: Rustock, Srizbi, Pushdo, Mega-D, ... botnets dedicadas casi enteramente al SPAM y que son el motivo principal de todo el SPAM existente en el mundo.

De hecho si echamos un vistazo a las estadísticas que tiene SpamCop, justo en el momento en que McColo dejó de existir, nos llevamos una pequeña sorpresa:

Phishing, pharming, pornografía infantil, código malicioso, falsos antivirus, y sobre todo SPAM, mucho SPAM, es lo que se podía encontrar en las direcciones IP de este ISP, del que se puede apreciar que era responsable casi del 50% de la mayoría del SPAM actual.

La eterna pregunta es si es mejor 'sacar' este tipo de ISP fuera de Internet, o si por el cambio es más beneficioso seguir monitorizando sus actividades. El problema de 'sacar' de Internet a un ISP es que su negocio no cesa, sino que cambia de localización, con lo que muchas veces se ramifica y divide en otros ISPs ya sea en el mismo país (EEUU) u otros. El modelo de negocio detrás de estos ISP supone tantos beneficios que simplemente se van con sus bártulos a otra parte. Por otro lado, si no lo cerramos, es verdad que se puede monitorizar y seguir más o menos sus pasos de cerca, pero la que pierde es la Sociedad, puesto que sigue habiendo todos los delitos originados en esas IPs.

Al ser Internet una entidad tan extraña (desde el punto de vista organizativo y legal)  a la hora de tomar decisiones tan unilaterales como quitar a un ISP de Internet (a partir de una iniciativa de NANOG) es complicado dilucidar quién es el organismo que tendría que tomar dichas decisiones. Otro ejemplo claro es el reciente de ESTDomains (todavía en revisión, pero que todo parece que estarán hasta el 24 de Noviembre), donde es ICANN la que aprueba/deniega las operaciones de los registrars. Es un caso parecido relacionado con el fraude.

Acciones como la de Atrivio/Intercage, ESTDomains o la más reciente de McColo, obligarán a repensar en un futuro no muy lejano realmente quién tiene el poder de Internet, quién lo controla, o simplemente quién puede determinar qué se puede hacer o no. Internet ha pasado ya su adolescencia, y dentro de poco se convirtirá en un animal político, donde las luchas por el control de Internet nos salpicarán a los usuarios.

En fin, indudablemente es una gran noticia que más del 50% del SPAM existente desaparezca (por ahora), pero el cierre de este ISP no será el último. Y vosotros, ¿habéis recibido menos SPAM?

PD: existe un informe más detallado de las actividades de McColo en el informe siguiente:

David Barroso

S21sec e-crime

SCAP - Automatización en seguridad

La rueda de SCAP (Security Content Automation Protocol) sigue avanzando. A los que desconozcan las siglas, basta con resumir que se trata de una iniciativa del gobierno americano acogida en Mitre que pretende poner fin a los problemas de automatización en la gestión de seguridad en cualquier entorno (donde habré oído yo esto antes...).

Atrás quedan ya los esfuerzos del NIST con sus checklist, los becnhmarks de CIS, los Plugins de Nessus e incluso la herramienta MBSA, ya que no se ha contemplado la posibilidad de reutilizar la información, sino que se empieza desde cero (en ocasiones es mejor para evitar arrastrar los errores del pasado).

¿Qué es SCAP?

El programa ISAP (Information Security Automation Program) es una iniciativa entre varias agencias del gobierno americano (NIST - National Institute of Standards and Technology, OSD - Operational Services Division, DHS - Department of Homeland Security, NSA - National Security Agency, y DISA - Defense Information Systems Agency) madurada en 2007, que pretende definir los modelos de automatización y los estándares de las operaciones de seguridad en la información (me pregunto que es lo que se había estado haciendo hasta ahora..). Desde el punto de vista operativo, SCAP es el método para utilizar estos estándares de forma que sea posible la medida, gestión de vulnerabilidades y su cumplimiento de forma automática.

Pero que que nadie se emocione. Desde el punto de vista técnico, se trata de una cantidad ingente de información en XML en múltiples archivos diferentes, cada uno soportando múltiples esquemas, que pueden provenir además de múltiples fuentes, y que requiere de interpretes específicos para su utilización y gestión.

Componentes de SCAP

SCAP se compone de diferentes elementos a partir de los cuales "debería ser posible" garantizar el cumplimiento de su naturaleza, que es la automatización en la medida, gestión de vulnerabilidades y su cumplimiento de estándares y políticas:

• Sistemas de enumeración: CPE (Common Platform Enumeration), CVE (Common Vulnerabilities and Exposures), CCE (Common Configuration Enumeration) permiten identificar Plataformas (software: sistema operativo y aplicación, hardware, etc...), Vulnerabilidades y Consideraciones en la configuración respectivamente.
  
  
  
• Lenguajes propios: OVAL (Open Vulnerability and Assessment Language) para realizar las tareas de inventariado así como las comprobaciones acerca de vulnerabilidades y XCCDF (Extensible Configuration Checklist Description format) para comprobar los criterios de seguridad en las configuraciones.
  
  
  
• Sistema de valoración: CVSS (Common Vulnerability Scoring System) utilizado para medir el impacto de las vulnerabilidades encontradas.
  

A primera vista, sin conocer mucho más acerca de las todas entrañas de este engendro uno puede hacer a la idea de que es posible determinar que esta tecnología permite relacionar los activos (plataformas software y hardware) con todos los identificadores de seguridad asociados (CVE, CCE, CWE); ejecutar la comprobación de controles de seguridad (XCCDF y OVAL) y disponer de una serie de resultados gestionables organizados por su impacto (CVSS). La siguiente figura muestra una primera relación entre estos componentes y su ámbito dentro de la gestión.

En realidad, conforme se van descubriendo los secretos internos de cada una de las tecnologías, las herramientas (OVAL y XCCDF) permiten hacer muchas más cosas, como por ejemplo identificar de forma automática activos del equipo, determinar que parches faltan por instalar (relacionados con las vulnerabilidades que solucionan), o incluso monitorizar el cumplimiento de normativas. (Extracto de teletienda: "¿Es o no es un chollo, jerry? pues espera, porque si llamas ahora mismo..")

En un futuro es posible que se añadan más indicadores que ahora mismo están en proceso de incubación, aunque con una orientación clara hacia su inclusión en el concepto de SCAP:

• CWE: identifica debilidades inherentes al uso de los servicios
• CAPEC: árbol que determina los diferentes patrones de ataques.
• CEE: requerimientos de seguridad en el registro de eventos, AKA, el log.
• CRF: consideraciones de seguridad en el Reporting de la información.
  

A medida que una herramienta va incorporando estas tecnologías (todas basadas en XML) será posible realizar una verificación automática de su funcionamiento (validación SCAP) en cualquiera de los laboratorios autorizados, y completar un proceso de certificación de cumplimiento que permite optar al negocio de la seguridad en el gobierno americano. (Extracto de teletienda: "No lo puedo creer, Tom!").

Proceso de maduración de SCAP

El propósito de SCAP consiste en explotar las posibilidades de la distribución de información en XML. Aunque la base de SCAP nació en el seno de Mitre a partir de sus dos elementos más maduros: CVE y CPE, la inclusión de otras entidades como el FiRST en la gestión del CVSS, o el NIST en la definición de los requerimientos, ha permitido la exportación del conocimiento a otras entidades, y la idea final ha evolucionado hasta el punto de que se va a permitir que cada proveedor de IT defina sus propios controles. Aunque Mitre gestiona el repositorio central y da soporte a aquellos proveedores que quieran incluir su propia información, plantea como alternativa que cada uno pueda en cierto modo gestionar sus datos (bien mediante la firma de los controles en el propio XML o bien mediante el uso de otro repositorio de oval propio).

A modo de ejemplo, los fabricantes de software/hardware podrán crear entradas en el CPE por cada nuevo producto (ya se hace a través de la lista de correo CPE), e incluso publicar sus propios controles de OVAL acerca de sus parches de actualización (REDHAT ya lo está haciendo: Redhat - oval). Por el tipo de licencia (todo es propiedad de Mitre, o de Nist, o de la NSA, de todos a la vez) , es posible que algunas de las fuentes de SCAP que aparezcan en un futuro sean de pago, o que sea necesario realizar algún tipo de subscripción para obtener acceso a los datos.

Así pues, en un futuro próximo, iremos viendo florecer ya subdominios (actualizad vuestras herramientas para detectar hosts) del tipo oval.dominio.com o directorios /oval/ en los servidores Web de diferentes proveedores.

Conclusión

La teoría dice que con todo esto funcionando podría ser incluso posible, partiendo de una implantación cualquiera que nunca ha sido auditada y haciendo Click en un botón, llegar a automatizar el parcheado de seguridad de forma desatendida para disponer al final del proceso de una plataforma totalmente segura (tanto en actualización de software como en configuración).

Desafortunadamente a día de hoy son más los contras que los pros. No existen editores orientados (a pesar de la supuesta sencillez del XML, las opciones son enormes) y existen muchos modelos de esquema en cada una de las diferentes partes implicadas. Además es necesario cumplir con la definición mediante la validación del XML, y por otro lado la mezcla de los distintos repositorios (con sus diferentes esquemas que habrá que validar y consolidar) se convertirá en un proceso lento y no exento de errores, ya que será posible encontrar proveedores que suministren su información en un esquemas XML sin actualizar, para los que no existen herramientas de gestión que permiten controlar toda la información disponible; y cuando digo no existen, me refiero a gratuitas.

La lista de productos validados (en solo ocho meses) que actualmente cumplen alguno de los criterios de SCAP es muy corta. La primera herramienta que consiga integrar todas estas tecnologías y realizar la totalidad de sus funciones se llevará el gato al agua en el paranoico mundo de la seguridad estadounidense, muy diferente del mundo de la seguridad en España. Por suerte o por desgracia, en España llevamos más de un año de atraso, e incluso ya quedan atrás las extrañas maniobras de adquisición de empresas que habían empezado a desarrollar en estas tecnologías.

Iñaki López
S21sec Labs

Asegur@IT IV y Jornadas Facultad de Informática de A Coruña

Hace unas pocas semanas estuvimos muy a gusto en dos eventos distantes geográficamente el uno del otro: Asegur@IT IV en Getafe, Madrid, y las Jornadas de la Facultad de Informática de A Coruña. Ambos eventos fueron un éxito, no sólo por la fantástica organización (¡gracias Chema y Diego!) sino también por las impresiones que pudimos cambiar con otros ponentes y sobre todo con gente que asistió a los eventos (muchos de ellos lectores de este blog). Desde estas líneas un sincero agradecimiento a los patrocinadores de Asegur@IT IV, y a la Facultad de Informática de A Coruña.

Lo más importante de este tipo de eventos es la gente que se conoce, y sobre todo las ideas, comentarios o proyectos en los que está cada uno, puesto que muchas veces podemos comprobar que hay cosas que no se te habían ocurrido pensar de esa manera, o que otros temas en los que quieres empezar a investigar ya han sido analizados al milímetro por otras personas.

Las charlas fueron de todo tipo: esteganografía, botnets, el famoso bug de OpenSSL en Debian, descargas de ficheros usando Blind SQL Injection, qué está haciendo Microsoft referente a la Seguridad, programación segura, pen-testing en web, control parental, detección y eliminación de código malicioso, ... un cóctel explosivo de temas muy interesantes, pero que seguro que muchos disfrutaron de tener toda esta ingente cantidad de información procesada en sus cerebros.

Las charlas de A Coruña ya están publicadas, y podéis echarle un ojo en su página web.

¡¡Nos vemos en la próxima!!

David Barroso

S21sec e-crime

Abriéndose camino por WPA (TKIP)

A finales de la semana pasada dos investigadores alemanes hicieron público que se puede descifrar cierta parte del protocolo WPA, más concretamente WPA+TKIP, algo que presentarán esta semana con una demostración en público.

La importancia de este ataque se debe a que es el primero sobre este protocolo (aparte de ataques de diccionario) que se realiza con cierto éxito, ya que el ataque no permite recuperar completamente la clave, pero permite descifrar algunos paquetes de datos, con lo que no se puede conseguir más que una pequeña parte de la clave. Además, permite enviar paquetes de datos falsos al cliente conectado al router.

Erik Tews, coautor del descubrimiento, ha comentado que el ataque se ha basado en una modificación del ataque a WEP. Dicho ataque no se ha basado en la recuperación de la clave sino en el esnifado de paquetes para poder descifrarlo sin afectar al checksum.




Este es el momento de pensar en un cambio, para aquellos que tengan WPA+TKIP, ya que la solución AES empieza a consolidarse como el cifrado más seguro para evitar accesos no autorizados a nuestra red.

En el documento elaborado por Erik Tews y Martin Beck se tratan además ataques previos realizados sobre el estándar IEEE 802.11, como los realizados sobre WEP. Unas muy buenas explicaciones sobre las vulnerabilidades de WEP las tenéis en estos dos enlaces:

Cómo (no) funciona WEP I
Cómo (no) funciona WEP II.

Acerca del cifrado WEP, se pueden encontar unas nuevas herramientas muy útiles del paquete aircrack: easside-ng, wesside-ng y airdecloak-ng.

Esperaremos a ver qué cuenta Tews esta semana en la PacSec de Tokio.


Miguel López-Negrete
S21sec labs

Protección del software (Parte VI)

Los trucos anti-debug consisten generalmente en diversas comprobaciones que tratan de detectar ciertos comportamientos que indiquen la presencia de un depurador para poder actuar en consecuencia.

Acostumbro a llamarlos trucos y no técnicas porque la mayoría son unas comprobaciones muy simples que pueden evitar que un novel pueda analizar la aplicación, pero que una vez conocidas por el mismo no suponen una barrera muy importante. De hecho, existen muchos automatismos para evitar las detecciones, como pueden ser diversos plug-ins para OllyDbg.

Existe mucha información sobre los anti-debug, ya que llevan mucho tiempo utilizándose, por lo que solamente comentaremos algunos de ellos. Podemos ver una lista extensa de anti-debug en SecurityFocus, página que referenciaremos cuando nos sirva de ejemplo.

El día de hoy trataremos de detectar la interacción de alguien con nuestro programa mediante un depurador, detectando las tres maneras más comunes de detener una ejecución:

Detección de puntos de ruptura:

Si se establece un punto de ruptura sobre cierta instrucción, lo que realmente realiza el depuradore es reemplazar un byte por "CC" (int3), de tal manera que si se ejecuta saltará una excepción que manejará el depurador. En este momento buscará en una lista de puntos de ruptura si la dirección actual se encuentra en ella y repondrá el byte que había reemplazado.

De este modo, si se comprueba que, por ejemplo, en la primera instrucción de una API nos encontramos con un "CC" significará que se ha establecido un punto de ruptura en la misma.
En Securityfocus se habla de esto en el punto "- Uncategorized anti-debug --> (2) CC scanning"

Para completar la definición, veamos a continuación una implementación de la detección de un punto de ruptura en la API MessageBox:

Detección de puntos de ruptura en memoria.

Para establecer un punto de ruptura en memoria sobre alguna acción (lectura, escritura o ejecución), el depurador quita el permiso para ello. Si establecemos un punto de ruptura en escritura, el depurador quitará este permiso, de manera que cuando el programa intente escribir en dicho punto saltará una excepción que manejará el depurador, comprobará que en dicha dirección de memoria se ha establecido un punto de ruptura, restaurará los permisos y mostrará la ejecución detenida.

En estos casos, existe la posibilidad de modificar los permisos, de tal manera que los puntos de rupturan no surjan efecto.

En el siguiente código vemos cómo si establecemos un punto de ruptura en la zona reservada en el momento en que la ejecución llega a la interrupción, el depurador no se detendrá, puesto que la propia aplicación habilita el permiso de escritura antes de escribir en ella.

Detección de puntos de ruptura hardware

Los registros de depuración (Debug Registers) permiten establacer hasta cuatro puntos de ruptura, pero también pueden ser detectados y/o borrados, ya que se puede consultar los valores de dichos registros, alojados en la estructura Context (ESP+C). Se puede encontrar código que implemente el borrado de estos puntos de ruptura en el punto 7 del apartado CPU antidebug del enlace anterior: "Debug registers manipulation".

Mikel Gastesi
S21sec e-crime

S21sec en la 30ª Conferencia Internacional de Privacidad y Protección de Datos

Entre el 15 y el 17 de octubre de 2008 tuvo lugar en Estrasburgo la trigésima conferencia internacional de Privacidad y Protección de Datos, dos de las sesiones del Programa tenían como título:

1. “La vida privada: ¿una especie en desaparición?”
2. “Privacidad y juventud”

En dichas sesiones participaron representantes de redes sociales como Facebook y Myspace, ambas compañías hicieron una exposición de las medidas de seguridad que emplean hasta la fecha para la protección de la privacidad de sus usuarios, especialmente de los menores.

Así el representante de Facebook señalo que la privacidad es vista en su organización como:

• Privacidad vertical, en vez de una privacidad horizontal en toda la plataforma, aplicada a grupos de interés y de usuarios.


• Gestión individual del los riesgos de privacidad, dejando al usuario final la aplicación de las medidas de seguridad.


• Visión de la Plataforma como un instrumento de gestión de la vida propia.

Por otra parte el representante en la conferencia de Myspace expuso que sus iniciativas pasan por:

1. La colaboración con las Administraciones Públicas.
2. Formación de padres y usuarios de las redes sociales
3. Empleo de medidas de seguridad para la protección de la información, entre ellas destacaron:

• La limitación para el acceso de Myspace , en función del límite de edad, en el que se emplea un dispositivo técnico que detecta el primer intento de suscripción como valido. La categoría de edad no puede modificarse en ningún momento.


• Empleo de motores de búsquedas mediante keywords para prevenir un mal uso y para la identificación de menores.


• Empleo de medidas de seguridad especiales para categorías entre los 13 y los 18 años.


• Discriminación de perfiles, por ejemplo los menores entre 13 y 16 años no pueden recibir ninguna comunicación de un mayor que no éste en su lista de contactos.


• Moderación de comentarios en los blog’s privados y públicos.

Curiosamente después de la participación de los representantes de las empresas de redes sociales, en la sesión cerrada entre reguladores adoptaron una resolución en la que 37 países alertan de la indiscreción de las redes sociales.

Si bien parece claro que las medidas de seguridad empleadas por redes sociales como Tuenti , Facebook o Myspace no garantizan la privacidad personal de sus usuarios y sus posturas son bien diferenciadas entre la “gestión individual” y el empleo de “medidas de seguridad”; tampoco parece de recibo que los reguladores internacionales de privacidad y protección de datos demonicen las redes sociales alegando posturas como “la doble identidad digital” de los usuarios, estableciendo diferentes recomendaciones. Facilitaría mucho más en estos casos que se propusiesen soluciones como: la identidad Digital de los usuarios, como el empleo de medidas de filtrado así como la colaboración con las fuerzas del orden para prevenir todos los abusos en contra de la privacidad, promoción e impulso de los código tipo etc.

En todo caso se trata de un debate abierto en el que los reguladores deberán de tasar cómo implantar las recomendaciones de su resolución, mientras que los prestadores de servicios tendrán que establecer unas medidas de seguridad efectivas para la protección de la privacidad de los usuarios.

David Imizcoz Etxeberria
Manager de Vigilancia Digital

IDS: SISTEMAS DE DETECCIÓN DE INTRUSIONES (INTRUSION DETECTION SYSTEM)

Hoy en día y cada vez más a menudo oímos noticias sobre ataques informáticos a ciertas empresas, gracias a que en la actualidad y cada vez más, se pueden realizar ataques informáticos de una forma muy sencilla.

Es entonces cuando nos hacemos la pregunta de cuán protegidos estamos o cuán protegida esta nuestra empresa hacia estos ataques.

Dentro de las empresas y ante todo, una vez definida la política de seguridad a seguir, es cuando muchas empresas deciden implantar los llamados IDS.

Los IDS tal y como su nombre nos indica, son sistemas software y hardware capaces de detectar intrusiones o intentos de intrusión. Estos sistemas automatizan el proceso de monitorizar los eventos en un sistema o en una red analizándolos en busca de problemas de seguridad.

Los IDS nacieron en 1980 de la mano de James P. Anderson (docAnderson) gracias a un estudio promovido por las Fuerzas Aéreas de EEUU con el fin de detectar intrusiones. A partir de aquí empezaron a surgir los primeros IDS físicos alcanzando su auge en 1995 con la crisis del Firewall, naciendo así IDS como “Computer Watch”, “ISOA”…

Los IDS están formados por las siguientes características:

• Fuentes de Información: Orígenes de datos que se usan para determinar si una intrusión se ha llevado a cabo. Las fuentes de información pueden ser de tres tipos:
• Host: Recogiendo datos de una máquina (procesos, recursos…).
• Red: Monitorizando una red en concreto, es decir, una cierta interfaz.
• Aplicación: Recaban datos de una aplicación activa en el sistema (por ejemplo logs) y buscan evidencias en esos datos.
  
  
• Análisis de Eventos: Define el método de detección utilizado. Los métodos de detección se centran en dos grandes tendencias:
• Basados en firmas o estado del mal uso: Suelen usar BBDD con el fin de detectar las anomalías. Generan un bajo porcentaje de falsas alarmas. Suelen funcionar en base a ciertas reglas.
• Detección de Anomalías: Suelen centrarse en el trafico que genera el origen de datos a observar. Están más centrados en el análisis en tiempo real. (Data Mining, Redes Neuronales, Series Temporales…).

• Respuesta: Cuando el IDS detecta una intrusión, los IDSs pueden responder bien de forma activa (realizando una acción) o de forma pasiva (mostrando una alerta).
• Componentes funcionales: Esta centrada en si el IDS corre dentro del mismo sistema que analiza o no.
• Estrategias de Control: Método de toma de decisiones del IDS y de la generación de Informes.
  
  

En la actualidad, los IDS han ido evolucionando hacia mejoras en la gestión y hacia los sistemas distribuidos, es decir, sistemas que están alejados o separados del sistema a analizar con el fin de que no sean detectados y anulados por los intrusos.

Aitor Corchero Rodríguez
S21sec labs

Solución al reto 6

Ha pasado ya un tiempo considerable desde la publicación del reto 6, por lo que vamos a publicar las dos soluciones recibidas, de mano de Dani Kachakil y Oriol Carreras junto con Jose Carlos Luna.

El reto consta de 3 fases (absténgase de continuar quien todavía quiera intentarlo):

• La primera consiste en interpretar un pequeño programa escrito en BrainFuck y oculto en un comentario HTML dentro del post. En primer lugar se debe arreglar el código, ya que se encuentra desordenado, pero se dispone de una pista dentro del mismó comentario HTML.
• La segunda fase consiste en descifrar el código obtenido en la primera fase, que se encuentra cifrado con Vigenére. El texto resultante indicaba de donde descargarse el fichero para la tercera y última parte de la prueba.
  
• Enla última fase se debe reconocer el formato de un fichero del que no se tiene información. Resulta ser un fichero de audio en raw,que se puede reproducir, por ejemplo, con sox.

Las dos excelentes soluciones:

• Oriol Carreras y Jose Carlos Luna
• Daniel Kachakil

Como tan solo puede haber un ganador, en este caso el libro se lo llevan Oriol y Jose Carlos por su detallado análisis de cada fase.

Ahora nos toca pensar como enviamos la páginas pares a Oriol y las impares a Jose Carlos xD

Muchas gracias a todos,

Mikel Gastesi
S21sec e-crime

Virtual Worlds, Real Money

Ayer ENISA publicó un nuevo estudio de Seguridad (como hizo hace ya un año sobre las botnets), en este caso sobre la seguridad en los mundos virtuales, estudio en el que participamos dando nuestra visión y conocimientos del tema. El estudio tiene por título: 'Security and privacy in massively-multiplayer online games and social and corporate virtual worlds'.

Para la realización del estudio, se hizo también una encuesta a 1.500 usuarios de mundos virtuales, siendo los riesgos identificados los siguientes:

1. Robo de identidad (el más común de todos ellos)
2. Riesgos de privacidad (muy relacionado con las redes sociales, al fin y al cabo los mundos virtuales son una especie de red social)
3. Automatización (una forma de saltarse las reglas del juego)
4. Cheating (siempre ha existido, desde huevos de Pascua hasta formas más complejas y no contempladas en el diseño original)
5. Intimidación online (y muy relacionada, en la vida real)
6. Fraude (siempre está presente el motivo económico)
7. Riesgos a la propiedad intelectual: cada vez más frecuentes
8. Menores de edad: violencia, pornografía, ...
9. Resolución de disputas online: de alguna forma necesitamos leyes y jueces
10. Spam dentro del mundo virtual: los spammers buscan nuevas formas de contacto continuamente
11. Denegaciones de servicio (DoS): debido muchas veces al caracter cliente-servidor y (a veces) pobres medidas de seguridad.
12. Servidores de juego maliciosos: una especie de man-in-the-middle cuando no existe autenticación cliente-servidor (y servidor-cliente), o simplemente, servidores de juegos 'no oficiales'
13. Ataques en el cliente: muy común hoy en día (client side exploits)
14. Ataques en el servidor de autenticación: para utilizar en beneficio propio y bloquear a otros usuarios
15. Dificultad de establecer políticas corporativas: ¿qué hacemos con la información confidencial que a veces aparece?

Al igual que todos los nuevos conceptos que van apareciendo hoy en día (redes sociales, virtualización, juegos online, ...) necesitan un análisis para conocer los riesgos existentes, es necesario también conocer las contramedidas que existen para intentar eliminarlos, o al menos, mitigarlos; para ello el documento de ENISA ofrece diferentes recomendaciones que merecen la pena analizar.

David Barroso

S21sec e-crime

OWASP EU Summit 2008

Bajo la consigna “Setting the AppSec agenda for 2009” el congreso europeo de OWASP (Open Web Applicacion Security Project) se celebrará esta semana en Portugal. Será un encuentro donde participarán los líderes de los distintos proyectos de OWASP y los participantes clave de la industria para presentar y discutir sobre las últimas herramientas, documentación y proyectos de OWASP y las tendencias en la seguridad de las aplicaciones Web.

Christian Martorella del Departamento de Auditoría participará en el evento representado a S21sec en distintas sesiones de trabajo.

Seguridad MPLS (I)

Explicar la tecnología MPLS podría llevarnos varias entradas. Por ello simplemente voy a realizar un breve resumen de algunos de los aspectos más importantes para refrescar la memoria a quienes ya la conocen. Para el resto os recomiendo que os leáis alguna de las siguientes referencias:

• MPLS Fundamentals: A comprehensive Introduction to MPLS Theory and Practice. Luc De Ghein. Cisco Press.
• Advanced MPLS Design and Implementation. Vivek Alwayn. Cisco Press.

La tecnología MPLS (RFC 3031) es un estándar abierto del IETF que básicamente adapta la tecnología “tag switching”, sistema propietario de Cisco y que destacó frente al IP Switching, tecnología similar propuesta por Ipsilon Networks pero restringida a la arquitectura ATM.

Se trata de una tecnología para el transporte de datos a nivel de red MAN y WAN perteneciente a la familia de tecnologías basadas en la conmutación de paquetes. Además proporciona un servicio de transporte de datos orientado a conexión a través de la creación de circuitos virtuales, previa al transporte de la información. A nivel del modelo OSI de comunicaciones se localiza entre el nivel de enlace y el nivel de red, por lo que podemos hablar de un nivel ficticio 2.5. El aspecto fundamental de esta tecnología es que el reenvío de paquetes se hace en base a unas etiquetas que se incluyen en la cabecera del protocolo. Estas etiquetas van cambiando de salto a salto y definen un camino (LSP) que ha sido calculado con carácter previo por los nodos de la red y en base a algún criterio predefinido llamado FEC (Ej. tráfico destinado a un cierto rango de red con unos requisitos de calidad de servicio elevados). Nótese la diferencia con el transporte tradicional IP, en el que el plano de control y el plano de datos se encuentran entrelazados. Las etiquetas definen el camino y se distribuyen en base a algún protocolo de intercambio de etiquetas (LDP, RSVP-TE, MP-BGP, etc.).

La tecnología MPLS está siendo adoptada por la mayoría de los proveedores de servicios de Internet (ISP) ya que les permite reducir costes en la operación de la red y ofrecer a sus clientes SLAs con compromisos reales de QoS, lo cual se está convirtiendo en una auténtica necesidad con la introducción en las empresas de la VoIP. La reducción en los costes de operación se explica porque MPLS permite ofrecer múltiples servicios de transporte de manera virtual (Ethernet, ATM, FR, HDLC, PPP, etc.) con una única red, por lo que ya no es necesario mantener equipamiento y configurar distintas redes, con la correspondiente reducción en personal especialista que esto implica. A esta funcionalidad de MPLS se le conoce por AToM (Any Transport Over MPLS). No obstante, en la actualidad su mayor auge viene de la mano de otro servicio, el de redes privadas virtuales (VPN), y será en la seguridad de este servicio en la que centraremos esta entrada.

Algunos términos que resultan fundamentales para poder comprender lo que se contará se listan a continuación. Cada uno de ellos contiene un hiperenlace a la definición del mismo.

• Router PE (Provider Edge Router) o E-LSR (Edge Label Switching Router)
• Router P (Provider Router) o LSR (Label Switching Router)
• Label Switched Path (LSP)
• Forwarding Equivalent Class (FEC)
• Virtual Routing and Forwarding Instance (VRF)
• Route Distinguiser (RD)

Antes de tratar la seguridad de las redes privadas virtuales basadas en la tecnología MPLS resulta fundamental tener una visión de alto nivel de cómo se ofrece este servicio.

Cada router PE puede estar comunicado con varios routers CE pertenecientes al mismo, o a diferentes clientes. Los routers CE son aquéllos que interactúan directamente a nivel tres con los routers PE del ISP, los cuales dan acceso a la red MPLS. Por lo tanto son ajenos a la existencia de una red MPLS y no entienden de etiquetas, LSP, LDP, VRF, etc. Cada router PE mantiene una tabla de rutas independiente por cada VPN además de una global. Es decir, si un PE da soporte a las delegaciones de dos empresas distintas mantendrá dos tablas de rutas independientes, una por cada empresa, y la tabla de rutas global, en la que se mantienen las rutas internas del propio core MPLS. La interfaz del router PE que conecta con un CE debe tener una dirección IP dentro del rango de direccionamiento de la VPN a la que pertenece dicho CE, de tal manera que el ISP participa en el direccionamiento de la empresa a la que da servicio. Esta falta de transparencia es probablemente la única desventaja del servicio de VPNs de MPLS. Siguiendo con la explicación, cada CE propaga las rutas (información de alcanzabilidad) de su tabla de rutas hacia el PE (bien mediante un IGP o mediante eBGP) y éste a su vez propaga hacia el CE las rutas que le llegan desde otros PE, comunicados a su vez por sus CE vecinos. La comunicación de rutas PE-PE requiere una explicación más detallada. Ésta se realiza mediante iBGP puesto que las rutas intercambiadas son las de todas las VPNs a las que el ISP da servicio. Puesto que dos VPN pertenecientes a empresas distintas pueden optar por un mismo espacio de direcciones privadas, es necesario buscar un mecanismo que permita distinguirlas. Este es el objetivo del RD, que no es más que una extensión de BGP, que se emplea cuando éste propaga las rutas entre routers PE. Es importante notar que los routers P, que conforman el núcleo de la red MPLS, no participan en el intercambio de las rutas de las VPN. Éstos únicamente ejecutan un protocolo de enrutamiento IGP entre sí y con los PE para intercambiar la información de alcanzabilidad del core MPLS; información que se empleará para distribuir las etiquetas que permiten el reenvío de paquetes dentro del core (ver más adelante).



Ahora que ya sabemos cómo se construyen las tablas de rutas, falta saber cómo se propagan los paquetes de distintas VPN por la red. Cuando un paquete llega a un PE desde un CE con destino un host que se encuentra en una delegación remota, se encapsula con la correspondiente cabecera MPLS. Esta cabecera incluye además dos etiquetas MPLS anidadas, la más profunda identifica la VPN a la que pertenece el paquete y la más externa permite a la red MPLS realizar el reenvío del paquete hasta el PE de destino. Una vez el paquete llega al PE correcto, éste elimina la etiqueta exterior y se fija en la etiqueta más profunda, la cual le dice a qué VPN pertenece el paquete, y por ende a través de qué interfaz (y por consiguiente hacia qué CE) debe reenviar el paquete. Finalmente, el CE asociado se encargará de hacer llegar el paquete hasta el host de destino.

Finalizada ya esta “breve” introducción a la tecnología MPLS nos encontramos en condiciones de analizar los aspectos fundamentales de la seguridad del servicio de VPN. Suponiendo que no tenemos acceso al equipamiento del core de la red MPLS (routers PE y P), y desde el punto de vista de un atacante, lo que más nos puede interesar es ver cómo desde una VPN a la qué sí tenemos acceso (Ej. somos trabajadores de una empresa que tiene contratado un servicio de VPN basado en MPLS) podemos o bien interceptar el tráfico y acceder a equipos pertenecientes a otra VPN, o bien generar una denegación de servicio en las otras VPN.

Como se puede deducir de las explicaciones anteriores, si el atacante si sitúa en una delegación dentro de una VPN concreta, cuando quiera acceder a otra delegación simplemente verá que su tráfico sigue una ruta que a nivel IP pasa como mínimo por cuatro saltos distintos (CE-PE-PE-CE), siendo el primer salto su GW por defecto. Este GW por defecto es en realidad el CE de su delegación que se comunica con un router virtual, conocido por VRF en la terminología MPLS, y que no es más que la tabla de rutas asociada a la VPN y la instancia de reenvío de paquetes asociada. Como ya sabemos, ambas se incluyen en el router PE.

Así, una primera opción que se nos puede ocurrir para intentar acceder a una VPN distinta sería enviar paquetes encapsulados con una cabecera MPLS que incorporare a su vez las etiquetas adecuadas. Estas etiquetas, debido a que no son conocidas a priori, podrían determinarse a base de prueba y error. De este modo, si no estuviéramos interesados en un objetivo concreto sino en alcanzar de manera indiscriminada una VPN de otro cliente del ISP, podría servirnos perfectamente. Sin embargo, la RFC estipula que cuando llegue un paquete MPLS por una interfaz asociada a un CE, éste se descarte automáticamente. Enno Rey, en una presentación que realizó en la Blackhat hace un par de años, afirmó que lo habían comprobado con routers CISCO y que en todos los casos se había verificado la conformidad con la RFC.

Otro posible ataque consistiría en aprovechar una incorrecta implementación de las conexiones a nivel CE-PE. Imaginemos por un instante que dos CE pertenecientes a VPNs diferentes se conectan a sendas interfaces virtuales que en realidad son una misma interfaz física. Supongamos además que los enlaces procedentes de los PE se concentran en un switch antes de conectarse contra el PE utilizando tecnología de VLAN. ¿Acaso no podríamos realizar un ataque a las VLANs (por ejemplo con Yersinia) si comprometemos el router CE para así terminar accediendo a la VPN de otro cliente del ISP? En estos casos lo mejor es implementar enlaces físicos independientes PE-CE.

Igualmente sería deseable que en las interfaces del PE que se conectan contra routers CE se incorporaran ACLs que únicamente permitieran tráfico de enrutamiento. Todo servicio adicional podría ser aprovechado por un atacante para ganar acceso al router PE (login remoto, tft para la carga de configuraciones, etc.)

Respecto a las denegaciones de servicio, qué mejor manera para dejar aislada una delegación que dejar fuera de combate al PE que le permite comunicarse con el resto de delegaciones. Cómo hacerlo, pues aprovechando el único servicio que debería ser accesible, el de algún protocolo de enrutamiento dinámico que corra entre el nuestro CE y el PE. Imaginemos que inundamos al PE con infinidad de rutas inventadas y que van cambiando cada poco tiempo. Si el router no está correctamente configurado, lograremos saturar su memoria y llevar la CPU al 100% dejándolo inutilizado para el resto de VPNs a las que dé servicio.


Continuará …


Elyoenai Egozcue,
S21sec labs