La semana pasada Justo Zambrana, Secretario de Estado de Seguridad, alertaba de la debilidad de las infraestructuras críticas en lo que a tecnologías de la información se refiere y hablaba del riesgo de ciberataques contra éstas; unos días más tarde, este mismo fin de semana, ha saltado a los medios ([1], [2], [3]…) el supuesto ataque telemático contra una planta de tratamiento de agua en Springfield (Illinois) -no, no es el Springfield en el que estais pensando…-. Unos piratas rusos -presuntamente- han conseguido romper la seguridad de los sistemas SCADA de la planta y quemar una bomba de agua; aunque no parece haber habido problemas de abastecimiento para la población, se trata del primer ciberataque contra una infraestructura crítica estadounidense según Joe Weiss, reconocido experto en la materia, y el problema no parece ser lo que los piratas hayan hecho, sino (a) lo que han podido hacer y (b) el tiempo que los responsables de la planta han tardado en detectar y reaccionar…

Sea o no cierto que el ataque se ha producido, sea o no cierto que se ha producido desde Rusia contra los Estados Unidos -en recuerdo de épocas pasadas-, sea o no cierto que no ha habido riesgo de desabastecimiento -o de algo peor- para la población, el caso es que esta noticia, este hecho, viene a poner de nuevo en el punto de mira -y ya van muchas veces- la seguridad de nuestras infraestructuras críticas no sólo desde el punto de vista tradicional sino también desde el punto de vista “cibernético”. A los componentes de seguridad “clásicos”, como la protección mediante personas frente a ataques físicos del enemigo, se han añadido estos años componentes de seguridad menos habituales, fruto de la convergencia de la seguridad de la que tanto se ha venido a hablar durante la primera década del siglo. Dicho de otra forma, si hace dos mil años la única manera de atacar una infraestructura crítica era mediante el uso de ejércitos a pie o caballo, o si hace cincuenta años la única forma de hacerlo era mediante ejércitos con tanques, barcos y aviación, hoy en día a estas tres armas se une un punto de vista adicional: el de la ciberguerra. O el del ciberterrorismo. O simplemente, el del cibervandalismo. Acciones clásicas con el prefijo “ciber”, que viene a decir que se desarrollan a través de redes de computadores. Sin un despliegue de miles de hombres y sin un nivel de riesgo considerable para el atacante, estas acciones pueden llegar a sustituir a –o al menos, convivir con- las anteriores, constituyendo un nuevo escenario de seguridad y defensa que preocupa a todos los estados del mundo: el de la ciberseguridad y ciberdefensa, en especial en lo relativo a protección de infraestructuras críticas.

Recientemente el CSIRT-cv y el INTECO-CERT han publicado una guía denominada “Pentest: Information Gathering” (140 págs), del que son autores Borja Merino Febrero (@BorjaMerino), habitual colaborador de este blog (y magnífica persona, por lo que pude comprobar en mi visita a León) y José Miguel Holguin (@J0SM1, y que también es otra magnífica persona :), y cuya lectura es totalmente recomendable.

El objetivo principal de la misma es informar sobre algunas de las técnicas que los ciberdelincuentes utilizan para obtener información sobre empresas y organizaciones. Uno de los aspectos más significativos y destacables de esta guía es su enfoque real a la hora de detallar muchas de estas técnicas mediante ejemplos prácticos (utilizando herramientas como Metasploit, Maltego, Nmap, la Foca, etc.).

Lejos de detallar aspectos relacionados con la gestión de la seguridad de la información, el informe ofrece una visión más práctica orientada a responsables de seguridad con un perfil más técnico que administrativo. La guía puede servir de gran apoyo técnico a la hora de implementar contramedidas contra algunos ataques que posiblemente ni siquiera se habían valorado a la hora de crear políticas de seguridad. El enfoque utilizado para explicar muchos de estos ataques (utilizando ejemplos explícitos) puede ayudar a concienciar de manera más eficaz a responsables de seguridad que mediante recomendaciones puramente conceptuales, que en la práctica son difíciles de implementar.

Nmap es una archiconocida herramienta de escaneo de red. Seguramente todos los que estéis leyendo esto la habréis utilizado alguna vez. Permite de forma muy sencilla hacer una enumeración de los equipos que hay conectados a una red, o descubrir los servicios disponibles en una máquina. Cuando hacemos esto de forma ocasional, y para un escaneo de una red pequeña, o para un solo equipo, no nos paramos a pensar en afinar la configuración, y escribimos la ristra de parámetros que nos sabemos de memoria. En mi caso suelo usar:

# nmap -T4 -A ip-host

Esta configuración hace un escaneo TCP de tipo SYN scan, que es el tipo por defecto si no le especificas de otro tipo. Utiliza una plantilla de tiempo bastante agresiva (-T4), y además ejecuta detección de sistema operativo, de versión de servicios, uso de scripts, y traceroute (-A) Todo esto, como ya hemos comentado, puede ser adecuado si el escaneo se lo realizamos a una única máquina. Pero cuando estamos hablando por ejemplo de hacer un escaneo a una clase B entera, se hace imprescindible optimizar el máximo posible la configuración del escaneo, ajustar al máximo los tiempos y lanzar únicamente las sondas que sean necesarias. Veamos como ajustar los rtt con valores personalizados.

Como ya adelantamos en la entrada anterior, el proceso de aprendizaje y demostración de Spring Security lo llevaremos a cabo construyendo una aplicación web. Para ser más precisos, se trata de una aplicación web colaborativa que permitirá a los usuarios organizar, crear y compartir sus colecciones musicales (álbumes, discos, artistas). Además, podrán planificar y tener noticias actualizadas de los últimos eventos musicales, crear anuncios de trabajo relacionados con la música, listas de reproducción, etc. Actualmente, solo una pequeña parte de la funcionalidad anteriormente dicha está implementada, pero que iremos completando en las próximas entradas. En la siguiente imagen se aprecia la página principal de nuestra aplicación.

Se pueden diferenciar claramente tres zonas:

…o como las mafias roban dinero de los móviles y lavan ese dinero en Rusia.

El otro día escuché un podcast del investigador Denis Maslennikov hablando sobre este tema y me gustaría compartir con vosotros los aspectos mas importantes de su podcast.

Comencemos diciendo que la gran mayoría de tarjetas SIM en Rusia son de tipo prepago, y que uno de los mayores operadores de Rusia, Beeline, ofrece un servicio totalmente legal que permite a cualquiera que use una de sus tarjetas SIM transferir saldo a una tarjeta de crédito, cuenta corriente, a una cuenta Unistrem (parecido a Western Union) o a otro número de teléfono enviando un SMS a un número gratuito. Por ejemplo, para enviar dinero a la tarjeta SIM del atacante habría que teclear: *145*nº_de_tlf*cantidad# y enviarlo al 145.

En entradas previas hemos visto qué era UMO y una pequeña guía de cómo instalarlo, por lo que ha llegado el momento de ver algunos ejemplos de cómo usarlo y donde puede ayudarnos.

Antes de empezar me gustaría comentaros que se han eliminado los ficheros de la sección de descargas donde estaba la versión empaquetada en tar.gz y es necesario por el momento descargarlo vía un cliente de subversión, tal que así, “svn checkout http://umo.googlecode.com/svn/ umo-read-only”. Añadir también que si os encontráis problemas en el uso de la librería MySQLDb con la librería para Safebrowsing en python, deciros que he propuesto un pequeño cambio en el issue 11 del proyecto para que no dé problemas.

No es que sea un fan de Jimmy Jump, pero en esta entrada quiero comentar algunas experiencias personales relacionadas con saltarse controles de acceso. Para evitar dañar la marca/imagen de algunos de los actores que aparecen en el post, voy a evitar incluir nombres de las compañías involucradas en estas historias.

Buenos días, tengo una reunión con nombre_del_jefe

El contexto de esta historia es el siguiente: en el desarrollo de un proyecto comprobamos que los controles de acceso del cliente no eran todo lo estrictos que debían ser, lo comunicamos al personal responsable del control de acceso y ésto dio pie a que pudiéramos hacer pruebas para ver si conseguíamos evitar las medidas de seguridad. Las distintas pruebas se realizaron durante un periodo que duró aproximadamente tres meses.

Siempre se han escuchado rumores y comentarios de la gente sobre si el gobierno nos espía, si saben todo lo que hacemos, etc. pero, ¿hasta que punto esto es cierto? ¿Es posible que alguien pueda escanear todo lo que hacemos a través de nuestro PC o nuestro teléfono? La respuesta es sí.

Como sabemos no todas las comunicaciones se transmiten de la misma manera ni por el mismo medio, y por este motivo no las podemos tratar a todas de la misma forma. Así que haremos una pequeña clasificación según el medio por el que sean transmitidas estas comunicaciones y veremos como pueden ser interceptadas.

Para hoy miércoles tenemos una entrada de Sergio Galán, alias @NaxoneZ, que ya ha colaborado con Security Art Work en el pasado.

Pueden encontrarle en su blog naxonez.wordpress.com o seguirle en Twitter.

phpLdapAdmin es un front PHP que nos sirve para gestionar nuestro LDAP de una manera más cómoda y fácil. Realmente es una aplicación que nos puede facilitar mucho la vida, pero que como todos software, es vulnerable a diferentes fallos que un usuario remoto puede utilizar para hacerse con nuestro sistema. En concreto, el fallo que vamos a ver en esta entrada es del tipo denominado como “PHP Code Injection Vulnerabilities”; para más información sobre este tipo de ataques, pueden visitar la página correspondiente de OWASP.

La entomología es la ciencia que estudia los insectos. En este artículo vamos a tomar el rol de un entomólogo y pasaremos a analizar los “insectos” que haya capturado nuestra planta dionaea, para ver si descubrimos algún espécimen nuevo. Y hasta aquí, cualquier similitud con esta ciencia.

En realidad, voy a contar el uso de wireshark para analizar un ataque recibido por nuestra sonda que está ejecutando dionaea y explicar cómo ver las pruebas, así como también algunas cosas más del funcionamiento de este interesante honeypot del que ya hemos hablado en alguna que otra ocasión. Adelanto que la captura del tráfico se hizo con tcpdump porque, aunque sabemos que dionaea se guarda el ejecutable que descarga, queríamos capturar todo el ataque, no sólo el ejecutable en cuestión.