Security Art Work

BotHunter es un sistema de detección de malware a través del tráfico de red creado por Computer Science Laboratory, SRI International. Si uno accede a la página web oficial del proyecto observará la siguiente descripción:

Hemos destacado dos aspectos de la descripción: por un lado que se compara el tráfico contra un modelo abstracto de patrones de comunicación de malware y por otro la afirmación de que es excepcionalmente efectivo. Uno con esta descripción tan sugerente no le queda otra que ver en qué consiste este modelo y qué lo puede hacer tan efectivo. Durante esta entrada vamos a revisar el paper de SRI, donde se comenta la arquitectura, la lógica y diversos componentes de gran interés.

[Read more…]

Hoy toca contar una historia, que por desgracia cada vez es más frecuente. Estaba yo el día uno de noviembre en mi casa, sentado en mi mesa de estudio peleándome con las particiones FAT32 con sus “directory root” y los “longs entry” (a quién se le ocurre empezar por el final), cuando a las cinco de la tarde decidí darme una vuelta por la web, y en concreto por las de noticias, a ver que había ocurrido.

Dentro de las noticias que vi me encontré con una muy interesante que indicaba que había habido un socavón en un estado de Alemania (me pareció curiosa), pero al pinchar sobre esa noticia el no-script me grito, algo bastante raro ya que lo tengo bastante bien configurado. Cuando mire a ver que ocurría me encontré con esto:

Antes de continuar se habrán dado cuenta que tanto he eliminado cualquier referencia de la página web donde ocurrió, como he eliminado el supuesto atacante que lo produzco, por razones muy distintas, un fallo lo puede cometer cualquiera, y el que esté libre de culpa que tire la primera piedra. Por otro lado, me he negado a hacer publicidad de los supuestos atacantes, que no son más que un par de irresponsables, por no emplear calificativos de otro tipo.

Bueno, ya podemos seguir. Al ver el mensaje “alert” lo vi claro, sabía donde estaba el fallo puesto que siempre que visitaba la web veía esa zona y pensaba: “esto es vulnerable sí o sí”. No hubo duda, fui directo a la zonas de comentario en busca del alert, y claramente “one more time” esto era un XSS:

<span class="fechaHora">01.11.2010 - 16.55 h - </span>Dice ser <strong><a 
href="mailto:XXX%3C"><script>alert("Hacked By: XXXXXXXX")</script>@gmail.com"
>XXXX</a></strong> - <span class="ordinal">#1</span>

Por tanto la zona vulnerable era la parte donde se mostraba el nombre del usuario registrado que había publicado el comentario. Lo peligroso de esto, es que, como todo comentario, este es permanente y por tanto el XSS se ejecutaba cada vez que un usuario visitaba la noticia. Como se podrán imaginar el atacante fue aumentado la calidad del ataque, dejando inservible la noticia.

Como ven, esto es lo que tendría que haber en un usuario registrado:

<span class="fechaHora">01.11.2010 - 14.28 h -</span><strong><a href="direccion 
web" onclick="window.open(this.href); return false; ">Nombre usuario</a></strong> - 
<span class="ordinal">#1</span>

A raíz de esto me surgieron varias dudas que quiero compartir con ustedes.

Si como técnico de seguridad detecto que una web es posiblemente vulnerable, ¿debo informar a la web? ¿Si informo me podrían acusar de asaltante? ¿Me harían caso? Antes de contestar piensen: ¿en que web hay un enlace para poder notificar posibles fallos de seguridad detectados?

Otra duda que me surgió fue, ¿porqué si cada vez más se están realizando ataques de tipo XSS que permiten, entre otras, modificar la imagen de la web, robar sesiones de los usuarios y redireccionar a servidores con malware, cuando se informa de una vulnerabilidad XSS en una auditoría no se le da el valor que corresponde?

¿Pero saben cuál fue la mayor pregunta que me hice después? Que ocurrió en Alemania con el socavón, que era lo que realmente me interesaba.

El pasado martes 19 de octubre apareció la noticia del lanzamiento de la suite de seguridad más famosa en su versión comercial, Metasploit Pro 3.5. Entre las nuevas características, destacan la habilidad de identificar, auditar y explotar aplicaciones web, lanzar campañas de ingeniería social a gran escala, evasión de antivirus e IDS, trabajo colaborativo y generar informes personalizados. Además, Metasploit Pro permite hacer VPN Pivoting en capa 2, lo cual nos crea una interfaz virtual dentro de la red remota desde la que poder lanzar cualquier herramienta de seguridad.

La instalación es muy sencilla, tanto para Windows como para Linux. En caso de tener alguna duda, recomiendo seguir las guías de instalación y de usuario que se pueden encontrar en la web. Para probar la herramienta, Rapid7 pone a nuestra disposición una imagen de VmWare con servicios vulnerables.

Vamos a ver de forma rápida la interfaz web y algunas de las nuevas opciones que hemos probado:

La interfaz es prácticamente igual que la de Metasploit Express. Tenemos un resumen del estado del proyecto donde se aprecian las estadísticas sobre estado de los hosts, sistemas operativos, actividad y servicios de red encontrados.

Esta es la pantalla de auditoría web automática. Las opciones se explican por sí solas: WebScan, Autit Web Apps y Exploit Web Apps.

Otra de las características que nos ha gustado es el apartado de Campaigns, desde donde podemos montar un servidor web que genere ataques de phishing, o explotar vulnerabilidades del navegador con solo visitar la página.

En la captura se ven las diferentes opciones para lanzar la campaña. Por ejemplo podemos configurar un envío masivo de correos electrónicos que redirijan a nuestra página especialmente creada. En una página posterior nos permite personalizar la página que se mostrará; aquí entra la habilidad o imaginación de cada uno para realizar un site creíble. También dispone de la opción de lanzar una campaña USB que nos creará los archivos necesarios para “dejar olvidado” un usb en lugares estratégicos. Aquí un ejemplo de campaña exitosa:

Como se ve en la imagen, se han obtenido 2 sesiones con el host después de explotar una vulnerabilidad de java.

Después de esto, en el apartado Sessions, podemos obtener evidencias de la intrusión, acceder al sistema de ficheros, realizar pivoting y obtener una shell en el navegador. Todo esto centralizado y accesible para todos los miembros del proyecto.

Por último, comentar el apartado Reports, que nos permite de forma fácil y rápida, generar informes sobre la auditoría. Entre los reportes que genera están el resumen ejecutivo, vulnerabilidades explotadas. Incluso hay un informe (Detailed Audit Report) donde se informa de todos los pasos que se han ejecutado en la auditoría.

Para terminar, comentar el precio de la herramienta, 15000$ por la licencia anual. Un precio prohibitivo para muchas empresas pero que sin duda, vale la pena probar, para lo que existe una versión trial totalmente funcional durante unos días, que hará las delicias de los pentesters. Happy hacking!

Para esta tarde de martes tenemos una entrada de Marcos García, que ya ha colaborado con nosotros anteriormente.

Periodista digitalizado y Director estratégico de écran Comunicación Interactiva, donde trabaja planificando estrategias de comunicación y escribiendo al respecto en el blog EstrategicaMENTE. Tuitea, de vez en cuando, como @elplumilla.

Se supone que en el Templo de Apolo de Delfos (y bajo la puerta del Oráculo en Matrix) había una inscripción que decía ‘Conócete a ti mismo’. Atribuida tradicionalmente a la poetisa Femonoé, para el poeta Juvenal es el primer paso hacia la auténtica sabiduría. Curiosamente en comunicación, conocerse a uno mismo es uno de los aspectos a los que menos atención se suele dedicar. Sin embargo en ese autoconocimiento se encuentra la clave para desarrollar una reputación a prueba de crisis.

Crisis es una palabra que, pese a llevar un par de años de moda, tiene un amplio recorrido tanto en gestión empresarial como en comunicación corporativa. La gestión de crisis es una disciplina y un arte que, pese a lo que muchos pudieran pensar, tiene más de prevención que de reacción. Y precisamente en esa actitud preventiva es donde juega un papel esencial la necesidad de conocerse a uno mismo (y a su marca, por supuesto).

[Read more…]

Como todos sabéis, la seguridad de la información ha pasado en los últimos años de ser un terreno reservado a unos pocos a estar en boca de todos, gozando de gran repercusión en los medios tradicionales, que hasta hace poco parecían dejar de lado muchas veces el mundo virtual. Con nuestros datos repartidos en cientos de aplicaciones, tanto de escritorio como web, y la facilidad actual para conectarse a Internet, las intromisiones en la seguridad de las aplicaciones y el robo de información personal están a la orden del día.

Es por ello necesario realizar campañas de concienciación para que el usuario medio, normalmente poco consciente de las implicaciones que tiene usar cierta aplicación o servicio y despreocupado a la hora de introducir sus datos personales, contraseñas y/o tarjetas de crédito en cualquier aplicación que se proponga usar, tenga más cuidado en lo que a seguridad de la información y revelación de datos de carácter personal se refiere.

En esta línea, octubre es el mes de la concienciación por la ciber seguridad para la NCSA (National Cyber Security Alliance), que durante todo el mes de octubre está haciendo campaña a través de diferentes canales y a través de las empresas que lo forman. Se han realizado todo tipo de eventos, creado multitud de campañas y cientos de recursos en esta línea.

Pero entre todos ellos destaca por su simplicidad y, a mi juicio, efectividad, la lista de comprobaciones de seguridad que Google ha lanzado para sus cuentas. En ella se cubre la seguridad, únicamente web en este caso, en todos sus aspectos y de una forma sencilla y concisa.

Tenemos 18 recomendaciones repartidas en cinco grupos de elementos: el ordenador, el navegador, configuración de cuenta, configuración de correo electrónico y un muy genérico recomendaciones finales, que engloba otras consideraciones que no caben en las categorías anteriores. Si bien están pensados para las cuentas de Google, son recomendaciones simples que se pueden extrapolar a cualquier otro servicio web, y su uso constituye un ejemplo de buenas prácticas que nunca está de más seguir.

Como contrapartida, decir que esta “checklist” está disponible únicamente en inglés, pero al estar enfocado a un público general el nivel de inglés requerido no es muy técnico, por lo que seguir las directrices que nos recomiendan no debería ser excesivamente complejo. Espero que les sirva de utilidad a ustedes, o si ya las aplican, a otras personas menos puestas en este tema.

(N.d.E. Para que no se aburran durante este largo fin de semana, aquí va una entrada de Roberto calentita calentita.)

Hace escasos días surgía la noticia de la posibilidad de saltar el código de bloqueo de los dispositivos iPhone con IOS 4.1 a través de las llamadas de emergencia, permitiendo realizar llamadas a cualquier número. El escándalo saltaba nuevamente, y los “antimaqueros” tenían una nueva excusa para demonizar al gigante de Jobs y los usuarios amantes de “la Manzana”, entre los que se encuentra un servidor, sonreíamos resignadamente ante las burlas de estos.

Pues bien, para quitar hierro al asunto y aunque como profesional de la seguridad me parece una gran pifia por parte de los desarrolladores de Apple, os voy a presentar una segunda manera de poder realizar llamadas a cualquier número con el bloqueo de código activado. Este método hace uso del control por voz de nuestros terminales, de esta manera y con el dispositivo bloqueado tan solo tenemos que dejar presionado el botón de Home durante un par de segundos y activar el reconocimiento de audio. Acto seguido tan solo tenemos que pronunciar el comando “llamar” y el número de teléfono que queramos, por ejemplo “llamar 555 34 43 34”.

Como aspectos negativos de esta funcionalidad nativa del terminal cabe destacar que gran parte de los usuarios no la utilizan o ni siquiera saben que existe, a ello hay que añadir su principal problema y es que viene activada por defecto cuando se adquiere el dispositivo. ¿Debería Apple desactivar esta funcionalidad, al menos por defecto, dejando la posibilidad de activarla al usuario? La respuesta a esto se la dejamos a los lectores.

Por último y como buena noticia comentar que es posible deshabilitar su uso cuando el terminal está bloqueado en Ajustes-> General -> Bloqueo con código -> Marcación por voz.

Después de una semana para dejar pensar a nuestros lectores, seguimos con el artículo sobre la implantación de un sistema IDS en un entorno con una tasa de tráfico muy elevada.

Nos habíamos quedado en un momento donde la tasa de tráfico era tan elevada que, aunque la tarjeta no estaba perdiendo tráfico, Snort no era capaz de procesar todos los paquetes. Teniendo en cuenta la carga de CPU en el sistema, y revisando la documentación de Snort donde se indica que esta aplicación no es multi-hilo, no quedaba otra opción que montar la granja; es decir, levantar varias instancias de Snort y repartir el tráfico para que cada una de ellas analizara una tasa menor. Suponíamos que íbamos a conseguir un buen resultado ya que sólo se estaba utilizando un único core al 100% mientras que el resto no se utilizaba.

Para conseguir esto se deben tener en cuenta varios aspectos para que no entren en conflicto diferentes instancias en un mismo sistema. En resumen, se deben crear filtros BPF para especificar el tráfico que procesará cada instancia, puede haber uno o varios archivos de configuración, debe especificarse un sufijo diferente para el pidfile de cada instancia, debe especificarse un identificador (id) en cada instancia a la hora de escribir en la base de datos y un directorio diferente para almacenar los logs.

[Read more…]

Mientras Toni asistía a los talleres relacionados con la protección de las ICs, yo me encargué en esta primera jornada de asistir a los relacionados con el Esquema Nacional de Seguridad, ENS.

Déjenme hacer antes de continuar una sugerencia a INTECO de cara a próximas ediciones. Si los talleres que han suscitado más interés durante las tres jornadas han sido claramente los relacionados con el ENS, el ENI y las ICs, ¿por qué ha juntado los tres temas el primer día? Si hubiese dedicado un día a cada tema, complementándolos con el resto de talleres que se han desarrollado, además de permitir que los interesados pudiesen asistir a los tres temas, se habría garantizado un nivel de asistencia homogéneo durante los tres días (cosa que no ha ocurrido). Tómese como una crítica constructiva.

Dicho esto, sobre lo que se trató en los talleres relacionados con el ENS me gustaría destacar algunas conclusiones que saqué:

1. Es un secreto a voces que ninguna administración pública va a estar cumpliendo el ENS a fecha 29 de Enero de 2011. El planteamiento general es: vamos a definir el plan de adecuación que exige la disposición transitoria de ENS, y a partir de ahí y hasta el horizonte de 2014 iremos poco a poco. A mi juicio este planteamiento se deriva de dos factores. Por un lado, de una actitud bastante generalizada de “yo me espero a ver por dónde van los demás” (salvo honrosas excepciones como la Junta de Andalucía o el MITYC), y por otro, de un problema evidente: no hay dinero.

2. La definición de un esquema de referencia basado en el ENS y la norma ISO27001 está muy extendida. Aunque algunos ponentes hicieron malabarismos para establecer equivalencias y correlaciones entre ambas figuras, y en relaciones porcentuales como que cumplir uno implica que cumples el otro en no sé qué tanto por cien y viceversa, en mi modesta opinión es importante no olvidar sus diferencias:

• El ENS es de obligado cumplimiento; ISO 27001 no.
• El ENS está orientado a las Administraciones Públicas (AAPP), ISO 27001 al negocio.
• El ENS categoriza los sistemas de información, y por tanto las medidas de protección con las que deberán contar en función de la misma. ISO 27001 no.

En cualquier caso el ENS habla del “proceso de seguridad” y de la necesidad de implantar un sistema de gestión de la seguridad, y a nadie se le puede escapar que a partir de 2015 habrá que gestionar los niveles de seguridad ENS alcanzados, con independencia de que se le ponga la etiqueta ISO o no.

3. La referencia a seguir por todos van a ser las guías que el CCN está preparando para implantar el ENS: la serie CCN-STIC 800.

4. Se está evidenciando un dilema: las AAPP no son expertas en seguridad, para eso están las consultoras. Pero las consultoras no conocemos “el negocio público” en profundidad. Es fundamental la colaboración y una integración total de ambos equipos de trabajo para conocer cuál es el problema de partida y poder alcanzar unos resultados satisfactorios. El objetivo no debe ser cubrir el expediente y aparentar que se está cumpliendo el ENS, ni dejar que las consultoras hagan y deshagan a su antojo con el objetivo puesto en el negocio. No hay que perder de vista que el objetivo fundamental del ENS es generar confianza en el ciudadano. Si ya de por sí es difícil ganar esa confianza, mucho más difícil es volver a ganarla después de haberla perdido. Y ese es el peligro que acecha si no se hacen las cosas bien.

Unas preguntas que quedaron en el aire:

• Parece claro que el CCN es la “figura de autoridad” en relación con el ENS. ¿Va a jugar un papel similar al que desempeña la AEPD en relación con la LOPD y su Reglamento?
• El artículo 35 del ENS viene a decir que las AAPP van a tener que informar “en tiempo real” de su grado de cumplimiento del ENS al Comité Sectorial de Administración Electrónica. ¿Cómo se come eso?

Por último, una noticia: es de inminente publicación una nueva versión simplificada de PILAR, denominada μPILAR (microPILAR), dirigida a facilitar el análisis de riesgos en el ámbito del ENS. ¡¡Aleluya!!

(N.d.E. Esta tarde tenemos una entrada de Andrés Núñez, que trata la seguridad desde un punto de vista inusual en este blog, pero estarán de acuerdo conmigo en que es igualmente importante que cualquier otra vertiente que puedan pensar. Al fin y al cabo, la (in)disponibilidad de los alimentos ha sido uno de los mayores problemas del ser humano desde sus inicios.)

En las últimas semanas a raíz de la noticia del posible dopaje del ciclista Alberto Contador, hemos podido ver en distintos medios de comunicación noticias y debates relacionados con la seguridad alimentaria, puesto que el citado ciclista achaca el positivo a haber ingerido un filete que contenía la sustancia prohibida clembuterol.

Esta noticia ha vuelto a poner en tela de juicio al sector alimentario hasta el punto de que como publicaba la agencia EFE el pasado 15 de Octubre:

Puesto que vuelve a ser tema de actualidad, repasemos brevemente por medio de este post qué es esto de la seguridad alimentaria y cuáles son las normativas y códigos de buenas prácticas que están utilizando las empresas del sector para gestionarla.

[Read more…]

(Toni nos remite esta entrada desde el congreso ENISE, con el aliciente añadido de que la ha escrito con la Blackberry, lo que no deja de tener su mérito)

Como algunos ya sabíais y otros imaginábais, un año más estamos en el congreso ENISE, en León, organizado por INTECO. Este año nos hemos acercado Fernando y yo, para poder repartirnos por los talleres más interesantes de cada sesión, y a mí me ha tocado el correspondiente a la protección de infraestructuras críticas. Más allá del programa, ponentes, etc. que tenéis disponibles en la web del evento, comentamos en este post algunas opiniones y reflexiones acerca de lo que escuchamos en la jornada de ayer.

Comenzó el día con una sesión plenaria sobre los esquemas nacionales de seguridad en Europa, sesión en la que lo más repetido fue el término COLABORACIÓN para poder proteger las infraestructuras críticas de los países miembros y de Europa en su conjunto de forma adecuada. ¿Recordáis el congreso del CNPIC al que acudimos en febrero y que ya contamos en este blog? Ponentes diferentes pero la misma idea una vez más; si tan necesaria es la colaboración… Por qué nos cuesta tanto potenciarla?

Tras la plenaria, un par de talleres (mañana y tarde) sobre protección de infraestructuras críticas, ahora con dos términos que destacaron por encima de los demás: SCADA y resiliencia (esta última aún no incluida en el DRAE, pero estamos en ello). Parece que el problema de la PIC se centra en la (in)seguridad en los entornos SCADA, algo que parece obvio pero que me hace plantearme algunas preguntas: ¿qué pasa con los ataques a las personas? ¿Qué pasa con los accidentes y los desastres naturales? Qué pasa con el terrorismo “clásico”? La protección frente a actos delictivos, ciberterrorismo y demás esta muy bien (por supuesto), pero no debemos descuidar ningún otro aspecto o acabaremos mal. Hablar de SCADA “mola”, pero garantizando la seguridad de estos sistemas no garantizamos la “invulnerabilidad” de una infraestructura crítica.

En cuanto a resiliencia, palabra que también está de moda, una pregunta que nos lanzó el ponente: ¿sirven los paradigmas clásicos de seguridad para proteger las infraestructuras críticas o debemos ampliar nuestra visión? ¿Seguimos hablando de confidencialidad, integridad y disponibilidad o ahora hay algo más? Casi nada :) Como decía Darwin, no sobreviven los más fuertes ni los más inteligentes, sino los que mejor se adaptan al cambio…

Para acabar, una reflexión adicional. Se habló mucho (sobre todo en la plenaria) de CERTs. El concepto clásico de CERT está a punto de cumplir 22 añitos (ahí queda eso) y, bajo mi punto de vista, la visión clásica de estos centros es necesaria pero no suficiente. Por supuesto que debemos estar preparados para responder adecuadamente a incidentes, pero en la actualidad creo que los centros de seguridad (SOC o como los queramos llamar, pero no CERT) deben ser más preventivos que reactivos y además potenciar no una respuesta focalizada en la parte técnica sino una respuesta integral, por supuesto junto a otro tipo de servicios que sobrepasan el ámbito de un CERT tradicional… ¿Por qué seguimos hablando de CERTs? Esto será un tema para otro post, del que ya tenemos el título: del gusano de Morris a Stuxnet (gracias Xavi :).

Seguiremos informando.