Archives for junio 2011

Todos odiamos el spam: es desagradable, molesto, inútil e incluso peligroso (algún incrédulo habrá que compre viagra por Internet pero allá el…). A ninguno nos gusta tener que dedicarle ni dos segundos a marcarlo como spam, o simplemente borrarlo, pero parece que hay que resignarse.

Sin embargo hay ocasiones en que la vida te sonríe y la semana pasada fue una de ellas. Estábamos recibiendo spam de una empresa española en distintas cuentas de correo de un mismo proyecto, y a cada correo que llegaba respondíamos pidiendo la baja de la lista de suscripción (a la cual no nos hemos suscrito); ya sabemos que no hay que hacerlo, pero al ser una empresa española y al estar algo aburridos, nos animamos ;) Tras recibir el enésimo correo y alentado por el día de furia que llevaba a cuestas, cogimos el el teléfono y llamamos al número de contacto para explicarles algunas cosas.

Un gustazo. Debe ser lo que sentía Michael Douglas en Un día de Furia mientras luchaba contra las injusticias cotidianas. Como cambian las cosas cuando el spammer que se siente protegido detrás de su pantalla tiene que dar la cara y tratar con personas… ahí desaparece el sentimiento de anonimato y la tranquilidad de hacer algo que está mal amparado en la distancia. Esto no es aplicable a todos los casos ya que hubiese sido tan fácil como colgar el teléfono, pero la persona al otro lado no lo hizo y nos pudimos despachar a gusto.

No se pude evitar pensar en lo bonito que sería tener a mano la dirección del autor de ese virus que te ha costado horas de trabajo, o de ese desalmado que limpia cuentas bancarias ajenas… Curiosamente, al rato de colgar nos dedicó un correo indignado por acusaciones varias (ojo, en ningún momento se faltó al respeto). Casi entramos en su juego, pero ya sabéis: “don’t feed the troll”, así que cordialmente se zanjó el tema. El caso es que evidentemente ni nos registramos en dicha web, ni solicitamos publicidad suya en ningún momento. Tras analizarlo hemos observado que únicamente hemos recibido publicidad en las cuentas de correo que están publicadas en la web, por lo que parece obvio que las han obtenido tirando mano de buscadores, por lo que queremos aprovechar la situación para recordar conceptos importantes sobre LOPD, LSSI y spam.

LSSI, artículo 21.1

“Se prohíbe el envío de comunicaciones publicitarias o promocionales por correo electrónico u otro medio de comunicación electrónica equivalente que previamente no hubieran sido solicitadas o expresamente autorizadas por los destinatarios de las mismas.”

Creo que poco que añadir. Más claro, agua.

RDLOPD, artículo 45:

“Quienes se dediquen a la recopilación de direcciones, reparto de documentos, publicidad,[…] sólo podrán utilizar nombres y direcciones u otros datos de carácter personal cuando los mismos se encuentren en uno de los siguientes casos:

b) Hayan sido facilitados por los propios interesados[…]”.

Las fuentes accesibles al publico mencionadas son las siguientes:

“Tienen la consideración de fuentes de acceso público, exclusivamente, el censo promocional, los repertorios telefónicos en los términos previstos por su normativa específica y las listas de personas pertenecientes a grupos de profesionales que contengan únicamente los datos de nombre, título, profesión, actividad, grado académico, dirección e indicación de su pertenencia al grupo. Asimismo, tienen el carácter de fuentes de acceso público los diarios y boletines oficiales y los medios de comunicación.”

En este caso es común interpretar que Internet es un “medio de comunicación”, pero no es así, al menos en materia de LOPD. Se trata de un tema ampliamente tratado en diversos foros, y corroborado después por resoluciones de la Agencia Española de Protección de Datos; Internet es un canal de comunicación pero no un medio.

Disponéis de dos interesantes artículos al respecto en las siguientes direcciones:

http://www.carlosucelay.com/index.php?option=com_content&view=article&id=39

http://www.ayudaleyprotecciondatos.es/2010/05/18/fuentes-accesibles-al-publico-en-la-lopd/

Esperamos que os gusten :)

En estos días que corren está sonando mucho para lo bueno y para lo malo el servicio “pastebin.com”. Este servicio se utiliza para pegar texto, un servicio sencillo como la vida misma :).

Como no podía ser de otra manera el servicio está siendo utilizado para subir todo tipo de contenido: dumps de base datos de terceros tomadas sin pedir permiso, usuarios, contraseñas, código fuente de aplicaciones, listados de proxys, configuraciones de botnets, etcétera. Otra de las cosas destacables, es el hecho de que el servicio lo usan determinados keyloggers para almacenar lo que van capturando, como os mostramos a continuación:

Esto no es algo novedoso como se puede leer en en thetechherald y hackhispano. Pero nos gustaría volver a resaltarlo dado que se sigue registrando contenido actualmente por keyloggers.

Aconsejamos por tanto en la medida de lo posible monitorizar este tipo de servicios, dado que la información pública en ellos es de lo más variopinta. Para esta monitorización os aconsejamos herramientas como Pastenum.

Generalmente, cuando administramos switches Cisco, es fácil encontrarnos con configuraciones idénticas en distintas interfaces de red. La forma habitual de configurar las interfaces, aunque sencilla, puede resultar tediosa, puesto que se trata de copiar la misma configuracion en distintas interfaces individuales o rangos de interfaces. No obstante, una forma más cómoda de hacerlo es mediante el uso de macros smartport.

Los macros Smartport son scripts de configuraciones creados previamente, que es posible aplicarlos a las distintas interfaces de red, de forma que ganamos consistencia y velocidad a la hora de configurar dispositivos.

Los Switches Cisco tienen varias macros creadas por defecto, que nos permiten configurar interfaces para soportar entre otros, equipos de usuario, telefonos, u otra electronica de red; mediante el comando show parser macro brief es posible ver las macros definidas en nuestro switch:

Switch#show  parser macro  brief                                                
    default global   : cisco-global                                             
    default interface: cisco-desktop                                            
    default interface: cisco-phone                                              
    default interface: cisco-switch                                             
    default interface: cisco-router                                             
    default interface: cisco-wireless

[Read more…]

Al hablar de seguridad siempre la consideramos como un proceso en lugar de como un producto, puesto que cada día aparecen nuevas vulnerabilidades y amenazas. Debido a éste proceso continuo, un aspecto crítico es la formación del personal que gestiona cualquier ambito de la seguridad.

Habitualmente, la formación en materia de seguridad (sin entrar en la autoformación), se lleva a cabo mediante cursos o certificaciones, ya sean técnicas o no. Una de las certificaciones mas valoradas (o al menos más solicitadas) es la certificacion CISSP (Certified Information Systems Security Professional) ofrecida por ISC(2) (International Information Systems Security Certification Consortium).

La certificación CISSP la podemos encontrar a medio camino entre una certificación puramente técnica y una dedicada más a aspectos de gestión. El proceso de certificación consta de 250 preguntas tipo test simples basadas en el Common Body of Knowledge (CBK), el cual está compuesto por los siguientes 10 dominios de seguridad:

1. Seguridad de la Información y Gestión de Riesgos (Information Security and Risk Management)
2. Sistemas y Metodología de Control de Acceso (Access Control Systems and Methodology)
3. Criptografía (Cryptography)
4. Seguridad Física (Physical Security)
5. Arquitectura y Diseño de Seguridad (Security Architecture and Design)
6. Legislación, Regulaciones, Cumplimiento de las mismas e Investigación (Legal, Regulations, Compliance, and Investigation)
7. Seguridad de red y Telecomunicaciones (Telecommunications and Network Security)
8. Planes de continuidad del negocio y de Recuperación Frente a Desastres (Business Continuity and Disaster Recovery Planning)
9. Seguridad de Aplicaciones (Applications Security)
10. Seguridad de Operaciones (Operations Security)

En España hay dos convocatorias, una en Barcelona (abril-mayo) y otra en Madrid (octubre-noviembre), pudiendo elegir el examen en inglés con la ayuda de un diccionario o en doble traducción inglés-español.

Dentro de los problemas que podemos encontrarnos a la hora de preparar esta certificacion destacaría:

• La duración del examen. El examen dura 6 horas, más el tiempo de registro previo, que suele ser entre 30 minutos y 1 hora.
• La multitud de documentación existente en el mercado. Existe gran cantidad de libros sobre la certificación, algunos de lectura más comoda que otros, y que, por muchos que leas, siempre te dejarás algo. Cuando piensas que ya te lo sabes, aparece una nueva referencia a un nuevo libro que debes revisar (y así sucesivamente).
• No todas las preguntas tienen el mismo valor, ni todas puntuan, por lo que vas un poco a ciegas a la hora de hacer cálculos sobre la nota (en este caso, al menos las incorrectas no restan).

Una vez que finalizas el examen, se tarda entre 4 y 6 semanas en obtener el resultado. Si has tenido la suerte de aprobar (tienes que sacar un mínimo de 700 puntos sobre 1000), empieza el proceso de certificación, donde tienes que demostrar detalladamente tu formación y experiencia en seguridad (mínimo 5 años en al menos dos dominios del CBK). También debes adherirte al codigo ético de (ISC)2. Los resultados de este proceso tambien tardan varias semanas en comunicarlos. Si finalizas de forma correcta todo el proceso, deberás acreditar una cierta cantidad minima de CPE (120 cada 3 años) para mantener la certificación, como ya sucede en muchas de las certificaciones existentes en el mercado.

Si están preparando la certificación y tienen alguna duda en la que podamos ayudarles, tienen los comentarios a su disposición.

Voy a proponerles un sencillo ejercicio. Levántense de su silla (aprovechen para estirar las piernas) y diríjanse a la máquina expendedora de refrescos y snacks de su empresa. Busquen el display que muestra la selección de producto etc. (suele estar a la derecha). Lean la temperatura a la que, supuestamente, se almacenan los productos allí expuestos. ¿Qué valor encuentran? ¿Diez, quince grados? Ahora busquen los dos o tres sándwiches que, seguramente, están a la venta. Si fuerzan un poco la vista, verán que en el frontal de cada envase hay un letrero (en el caso que me ocupa, sobre fondo amarillo o rojo, para hacerlo más ilegible) que dice lo siguiente: “Conservar entre 0 y 5 grados”.

[Read more…]

Recientemente en el blog de Lenny Zeltser, se ha publicado una entrada donde hace referencia a un documento realizado por “CompuCom”, donde se explicaba una prueba de concepto de una técnica para identificar la distribución de un malware mediante la cabecera HTTP ETags.

En estos momentos dos de las principales fuentes para poder filtrar y prevenir la distribución a los usuarios finales es mediante listas de IPs o listados de dominios maliciosos (ver MDL por ejemplo). Pero todos sabemos que tanto las IPs como los dominios van variando de una manera muy rápida, lo que hace muy difícil la tarea de filtrar y prevenir la distribución en base a estos listados.

Los investigadores de “CompuCom” proponen utilizar la cabecera http ETags a modo de “fingerprint”. La cabecera HTTP ETag es opcional y enviada por el servidor Web, que sirve para que el cliente pueda realizar una validación condicional de la caché, de manera que en el caso de que se haya servido ese objeto no volverlo a solicitar con lo que se produce un ahorro de ancho de banda entre cliente y servidor.

A continuación os mostramos nuestras impresiones del documento. Lo primero que debemos tener claro es que:

1. La cabecera ETag es opcional.
2. Por lo que hemos podido ver cada uno de los servidores Web, posee un formato diferente para la cabecera ETag. A continuación podemos ver un listado de ETags de servidores Web diferentes (en el artículo ponen como ejemplo un ETag como el cuarto del listado)

3. El cálculo depende de determinadas variables temporales, variables asociadas al sistema, etcétera. Por poner un ejemplo, en el caso de Apache tras visitar la URL “hxxp://192.168.1.40/file.exe”, que se trata de un fichero infectado, el servidor Web nos devuelve (véase http://httpd.apache.org/docs/current/mod/core.html):

El Etag que nos envía el servidor se divide en:

• 33b309: Inode, inodo en el sistema que tiene asociado.
• 5400: Size, tamaño de fichero
• 4a49c1fd8d4c0: Mtime, tiempo de la última modificación.

Este mismo binario en otro sistema sería servido con un ETag diferente (inodo y mtime cambiarán con una alta probabilidad). Podemos plantearlo como si tuviéramos tres variables:

• V1=IP
• V2=dominio
• V3=sistema (englobamos sistema operativo, servidor web y binario)

En el caso de que V3 sea constante, podemos detectar el malware, dando igual el valor que tenga V1 y V2, dado que no se contemplan en su cálculo.

Estaremos atentos a la evolución de la investigación de “CompuCom”, pero por el momento pensamos que tienen un largo camino por recorrer, para ver su efectividad.

Como vimos hace tiempo en el post sobre Checkpoint SYN Defender, cada vez es mas habitual encontrar fabricantes que añaden funcionalidad para mitigar algunos ataques de denegación de servicio en sus dispositivos de seguridad. En la ocasión anterior nos centramos en la solución SynDefender de Checkpoint y en esta ocasión, será en la característica TCP Intercept de los dispositivos routers de Cisco.

Como su nombre bien indica, Cisco TCP Intercept Feature es una característica de seguridad capaz de proteger y mitigar posibles ataques DoS basados en inundaciones TCP SYN contra nuestros servidores, monitorizando para ello el numero de intentos de conexión y en caso de ser necesario, reducir el número de conexiones TCP incompletas.

Cisco TCP Intercept se puede configurar en dos modos de funcionamiento, el modo intercept y el modo watch.

El modo intercept es un modo de funcionamiento proactivo, donde el dispositivo almacena en sus buffers internos los intentos de establecimiento de conexión de modo que hasta que la conexión no está totalmente establecida (3-way handshake), el dispositivo no establece la conexión contra el servidor final. Puesto que el dispositivo realiza el seguimiento y mantiene todas las conexiones, éste requiere de una gran cantidad de memoria y CPU. Este comportamiento es similar al modo relay de SynDefender de Checkpoint.

Por el contrario, El modo watch es un modo reactivo, donde se monitorizan pasivamente las solicitudes de conexión de forma que, si una conexión no se establece en un intervalo concreto de tiempo (30 segundos por defecto), el dispositivo envía un paquete TCP Reset al origen finalizando el intento de conexión y elimina la conexión half-open. La configuración de esta característica es sencilla, solo debemos seguir los siguientes pasos:

1. Definir una lista de acceso extendida
2. Habilitar la funcionalidad TCP intercept sobre dicha lista de acceso
3. Parametrizar, si es necesario, las posibles opciones de la funcionalidad (modo de funcionamiento, intervalos de tiempo, umbrales, etc.)

Una vez habilitada, podemos monitorizar su uso con los habituales comandos show y debug de Cisco. Como hemos visto y vimos en el post anterior, cada vez mas los dispositivos implementan mayores y mejores medidas para proteger nuestros sistemas de los posibles ataques.

Los días 11 al 15 del pasado mes de abril se celebró en París el IEEE Symposium Series on Computational Intelligence, SSCI 2011. Se trata de un evento bienal que comprende más de treinta simposios que contemplan aspectos teóricos y aplicaciones de la inteligencia computacional.

¿Qué es la inteligencia computacional? Una definición de andar por casa podría ser ésta: la IC consiste en hacer que un sistema (generalmente informático) se comporte de forma tal que, si se tratara de un ser vivo, diríamos que es inteligente. Si nos quisiéramos poner un poco más técnicos, diríamos que la Inteligencia Computacional (también denominada Soft Computing) es una rama de la Inteligencia Artificial que consiste en el estudio de mecanismos adaptativos para permitir o facilitar el comportamiento inteligente en sistemas complejos y cambiantes.

Algún escéptico pensará “ya me vendieron la moto de la inteligencia artificial y aún no tengo un robot haciéndome la faena de la casa, ¿qué pretenderán ahora con esto?” Bien, no se trata de vender ninguna panacea, sino de utilizar diversas heurísticas y computación para resolver problemas; en nuestro caso, problemas de seguridad.

¿En qué mejora la IC a la IA? Tomemos como ejemplo los sistemas expertos, que son una de las áreas clave en IA. Éstos se basan en la existencia de una serie de expertos humanos que deducen reglas de comportamiento para un sistema; esas reglas las implementamos en un lenguaje específico y voilà, a correr. Esto es lo que se denomina un enfoque “de arriba a abajo” (top down para los anglófilos), en el que la estructura de las soluciones está impuesta desde arriba.

El problema viene cuando no hay expertos a quienes preguntar, bien porque el sistema es nuevo o porque el experto está de baja o se ha jubilado; también puede ser que el experto se equivoque o incluso mienta ¿Y qué pasa si hay expertos, pero no se ponen de acuerdo?

Por el contrario, en IC el enfoque es “de abajo a arriba” (o bottom up, que también es la expresión utilizada en el pub para instar a los compañeros a que terminen su cerveza, aunque cualquier relación es pura casualidad), donde las soluciones emergen desde un estado inicial sin estructurar. Dicho de otra forma, no le decimos a la solución cómo tiene que ser, sino que surge ella sola (bonito ¿no?). Los cinco principales paradigmas en IC son las redes neuronales artificiales, la computación evolutiva, la inteligencia de enjambres (swarm intelligence), los sistemas difusos (fuzzy) y los sistemas inmunitarios artificiales. La mayoría de estas técnicas están inspiradas en procesos que se dan en la naturaleza: la evolución y la genética, el comportamiento del cerebro humano o de los animales sociales etc., lo cual no es sorprendente, ya que la Naturaleza (con mayúscula) es una “experta” en encontrar soluciones ingeniosas a problemas de todo tipo.

Dicho todo esto, volvamos a París y al SSCI. ¿Cuál era nuestro interés en este evento? Éste venía dado por dos simposios en concreto: el simposio sobre IC en ciberseguridad (CICS) y el simposio sobre IC en aplicaciones en seguridad y defensa (CISDA). Nuestros lectores asiduos ya son conscientes de que los malos cada vez son más numerosos y más malos, mientras que los que deberían protegernos a los buenos en muchas ocasiones se están dedicando a pulir sistemas de dudosa efectividad (no lo digo yo, lo dice el informe Gartner sobre Endpoint Protection) porque esto es más sencillo que coger el toro por los cuernos. Son necesarios sistemas de ciberdefensa flexibles, adaptables y robustos, que puedan tomar decisiones casi en tiempo real y capaces de detectar una gran variedad de amenazas y ataques, tanto activos como pasivos, conocidos y desconocidos, ataques externos y mal uso interno, virus y spam etc. Y es aquí donde la IC ha revelado su capacidad de respuesta: ya que no tengo suficientes expertos para predecir por dónde van a venir los tiros, voy a intentar conseguir que mis defensas surjan solas.

En Paris hemos visto ponencias sobre análisis de tráfico de red, detección de anomalías, protección de infraestructuras, prevención de ataques DDoS… o sea, los temas de siempre y algunos nuevos, pero abordados desde el enfoque de la IC. Hemos escuchado también reflexiones interesantes, como la que hacía el director del MIT Geospatial Datacenter, John R. Williams, de que el dinero que financia a los cibercriminales proviene en gran parte de las falsificaciones. No sólo de los Rolex a tres euros, sino otras mucho más serias, como las que afectan a productos farmacéuticos y ponen en peligro nuestra salud.

Una reflexión personal, quizás no tan interesante, es ésta: los investigadores en inteligencia computacional en ciberseguridad y defensa provienen en su inmensa mayoría de EEUU y Canadá. Dicho de otra forma ¿de qué tendrán miedo los canadienses?

A diferencia de la versión Pro de Metasploit, una de las limitaciones a la hora de “pivotear” conexiones desde Meterpreter por medio de route es el tipo de herramientas que podemos usar a través del pívot. Esto es debido a que cualquier herramienta que use raw sockets no funcionará a través del túnel, estando limitados a conexiones TCP y UDP que realicen una “conexión completa” (connected sockets). En el caso de Nmap, por ejemplo, implica que únicamente podemos realizar escaneos de tipo TCP connect (-sT) por medio de socks4 y proxychains, pero será inútil utilizar switches como -sS (syn scan), -O (OS detection) o similares. Aunque otra opción es utilizar portforwarding (portfwd) mediante el cual mapear puertos locales con los de la víctima, estamos limitados a conexiones TCP, por lo que esto también reduce opciones a la hora de elegir herramientas que empleen UDP. En nuestro caso lo que haremos será preparar un entorno que nos ayude a “forwardear” peticiones DNS desde herramientas que hagan uso de UDP (nmap, dnsenum, etc) a través de Meterpreter.

Para ello configuraremos un Proxy DNS que intercepte peticiones DNS UDP y las redirija, en su “versión TCP”, al puerto configurado con portfwd. Ya que la mayoría de servidores DNS soportan TCP, no solamente para realizar transferencias de zona, sino para aceptar también queries en el puerto 53 (así lo especifica el protocolo DNS), podremos realizar consultas DNS con prácticamente cualquier herramienta. Lógicamente clientes DNS que empleen o soporten TCP (ej: dig +tcp) no requerirán de dicho Proxy y podrán lanzarse directamente a través de Meterpreter Lo mismo ocurre con clientes DNS que usen UDP y que utilizen la API adecuada, en cuyo caso podrá redirigir paquetes a través de Meterpreter utilizando route.

[Read more…]