Pues como iba diciendo, después de tanto tiempo sin lunes desmotivador y con las vacaciones de por medio, empiezo a notar cierto aire positivo, así que es necesario desempolvar algunos lunes desmotivadores que veréis en las próximas semanas para ir bajando esa ilusión pasajera de mejorar la seguridad.

He aquí, pues, el lunes desmotivador 21. Y recordad, si no es lo suficientemente desmotivador, siempre podéis echar un ojo a todos juntos en nuestra página de lunes desmotivadores.

Cuando se redactan procedimientos de seguridad (o de cualquier otra cosa, dicho sea) es posible pensar que se trata de una especie de programa que será ejecutado por personas. La verdad, como suele ocurrir en estos casos, es bastante más compleja.

El problema de los procedimientos es que hay que leerlos, que no pueden contarlo todo, que tienen que estar actualizados y ser relevantes, hay que comprobar que se han seguido, que hay que saber cómo encontrarlos y si existe uno para eso que vas a hacer, que hay que saber cuándo hay que usarlos, etc.

En definitiva, demasiado complicado para que funcione bien. Sobre todo porque es necesaria la implicación de los que mandan y la colaboración de los que hacen las cosas y, la verdad, a nadie le importa un carajo. Se trabaja mejor sin documentos de por medio que evidencien que nos estamos saltando la mitad de las cosas que queremos hacer.

En fin, os hacéis a la idea ¿no? En cualquier caso, una cosa importante es que, muchos ‘managers‘ piensan que si todo está bien definido: 1) Se puede sustituir a cualquiera por otro que lo hará igual de bien y 2) Es posible sustituir a alguien bueno (y caro) por alguien que sepa menos (y sea más barato).

Pues dejadme deciros que eso es una patraña. No sólo por los inherentes problemas para ‘documentarlo todo’ sino también porque la gestión de TI está bastante alejada de la ‘cadena industrial’, cosa que muchos no quieren ver.

Pero bueno, eso lo discutiremos en el próximo Sec&Beer, que espero que no se deje ir mucho.

Pues poco más que añadir. Nuevo tema, más limpio que el anterior y menos cluttered que esperemos que os guste. Si no os gusta, poned vuestras quejas aquí abajo o en vuestra red social favorita (siempre enlazando la noticia para que el wordpress haga su magia).

Se ofrece cerveza gratis al que nos pase un logo, banner o similar que recoja el espíritu del blog.

Aunque despacito, comienza a revivir el blog. Y mañana… ¡un nuevo lunes desmotivador! Porque me parece a mí que estáis muy positivos últimamente.

Bueno, tras un extenso parón espero poder retomar poco a poco el ritmo del blog. Animo al resto de «editores» a que publiquen algo y así no se note tanto cuando alguno entramos en un agujero negro. Y si alguno de los que estáis por Sevilla en esto de la seguridad queréis publicar algo, pues hacedmelo llegar, ¿ok?

Hoy quiero hablaros de un detalle de inseguridad de los visores de SIG (Sistemas de Información Geográfica). El visor es una aplicación web que extrae las imágenes de un mapa de alguna base de datos con localización geográfica (el SIG propiamente dicho). Sobre estas imágenes es posible añadir ‘capas’ que no es otra cosa que más información relacionada con la posición.

Muchos de estos visores te dejan, como usuario, añadir nuevas capas de otras fuentes para crear tu propio mapa. Otros ya traen sus capas fijas y puedes añadirlas o quitarlas pero sólo esas.

Ahora bien, la implementación de la funcionalidad de añadir capas suele incluir un cuadro de diálogo donde le pones un nombre, le indicas una URL para descargarla y le pones qué tipo de capa es (hay varias opciones).

Internamente, es el servidor el que se conecta al recurso, se lo descarga y lo devuelve al navegador. Lo bueno (o lo malo, según se mire) es que de este modo es posible solicitar cualquier URL que queramos y el servidor la pillará para nosotros.

el_mapa

Analicemos un poco esta situación: básicamente esta funcionalidad es un proxy que se ejecuta en un servidor en una red interna del organismo correspondiente al que le puedes solicitar cualquier URL, incluso de equipos internos. De hecho, en algunos SIG que he visto la URL se llama proxy o MapProxy o similar.

¿Cómo identificar esta funcionalidad? Si se trata de un visor que acepta capas, nada más fácil que añadir una URL cualquier y observar con un proxy de interceptación (Burp, por ejemplo) a ver qué URL utiliza. Si tenéis algún servidor web por ahí, ponedlo y echad un ojo a los logs.

Si no acepta capas, esta funcionalidad de proxy puede estar presente aunque no se use en la aplicación web y conviene echar un ojo al código fuente de los ficheros javascript para identificar la URL en cuestión.

Por lo tanto, si hacemos un análisis de seguridad a un organismo que tiene un SIG con esta ‘vulnerabilidad’ ya tenemos una forma de acceder a sus webs internas.

Pero ojo, ese no es el único problema, que te usen como ‘proxy’ abierto para hacer fechorías te puede traer muchos problemas (consumo de ancho de banda, inclusión en listas negras, ser origen de ‘delitos’, etc.).

Algunas limitaciones de este tipo de proxies:

  • El método HTTP está fijado, en algunos es GET y en otros, POST.
  • Normalmente no es posible generar solicitudes complejas, ya que la URL que pongamos es un parámetro de otra URL, incluir variables puede no acabar de funcionar.
  • Los enlaces de la página interna no funcionan, claro, porque no tienen en cuenta que hemos accedido de una forma subrepticia.
  • A veces el Content-Type es xml y el navegador no lo acaba llevando bien.

¿Cómo solucionar esto? Pues si no se trata de un visor SIG con capacidad para añadir capas, desactivando la funcionalidad ‘proxy’.

Por el contrario, si se trata de un visor SIG para añadir capas externas, se podrían filtrar las URLs con algún criterio o comprobar que la vuelta efectivamente corresponde al formato esperado. También se puede hacer que sea el navegador el que descargue el recurso y no el servidor, evitando este problema.

Y, como siempre, registrad logs y echad un ojo de vez en cuando no vaya ser que…

ACTUALIZACIÓN:

Ups «que sea el navegador el que descargue el recurso y no el servidor«. Acabo de comerme la Same-Origin Policy (aka SOP). Luego pensando me he dado cuenta de que igual no es tan fácil esta opción así de primeras.

Probablemente lo mejor sería comprobar que el fichero se ajusta al DTD específico del tipo de mapa que se quiere cargar, evitando servirlo si no es un fichero esperado y no enviando ciegamente lo que se descargue de la URL.

Después de llevar ya más de 10 años en el mundo empresarial debo confesar que creo fervientemente que la magia existe. Y también los magos.

La magia se manifiesta en muchas ocasiones justo después de realizar alguna afirmación sobre una situación de seguridad. Creo que se entiende mejor con un ejemplo.

Alguien de seguridad dice que en cierto sistema hay una vulnerabilidad en el FTP que además es un servicio inseguro. Entonces aparece el mago con su «hechizo» y argumenta que «pero eso está a punto de migrarse». Con eso… se acaba todo. El hechizo ha tenido su efecto y consigue que nada se haga. Por supuesto, una año después todo sigue igual, el FTP, la vulnerabilidad y sigue «a punto de migrarse».

Así es la gestión de IT que tenemos. Mientras más gente haya presente más efectivo puede ser el hechizo. Como este de Wally, el «mago» de Dilbert.

1713.strip.zoom Pero bueno, este artículo no iba precisamente de esto, aunque está relacionado. Os quería hablar de un hechizo bastante común: el de los entornos.

En todas las organizaciones siempre hay diversos tipos de entornos: producción, pruebas, preproducción, desarrollo, integración, formación, etc.

El objetivo es disponer de entornos donde desarrollar, probar, romper, integrar, etc. las aplicaciones o nuevas funcionalidades que acabarán en el entorno de producción.

La idea en la mente del personal de IT es que el entorno de producción es estable y está expuesto a los usuarios (internos, de Internet, etc.) y que el resto de entornos están restringidos y son inaccesibles. Por lo tanto, si encuentras una vulnerabilidad o configuración no adecuada en un entorno que no es producción, normalmente no importa. El hechizo en este caso es «es que está en el entorno de [citar cualquier entorno que no es producción]«.

Lamentablemente, la realidad no siempre es como uno se la imagina. Y lo que te encuentras en muchos casos es la siguiente situación:

  • Varios entornos comparten redes y, en algunos casos, incluso sistemas.
  • Es posible acceder a muchos entornos de prueba, pre-producción, etc.
  • Los entornos de formación tienen usuarios/contraseñas predecibles.
  • En muchos entornos hay datos reales (a veces antiguos pero reales).
  • Las contraseñas, claves, scripts, etc. en el entorno de producción se replican en los otros entornos.

En definitiva, hay una tenue diferencia entre los entornos que, en muchos casos, desde el punto de vista de la seguridad equivale exclusivamente al nombre. Una intrusión en alguno de los entornos (aunque no sean producción) tendrá consecuencias similares. Es más, una vulnerabilidad en un entorno puede servir para afectar al entorno de producción.

A lo que quiero llegar con esto es que hay que evitar ser confundidos por la magia y analizar, realmente, hasta qué punto los entornos que no son producción se encuentran aislados y cuentan con medidas adecuadas de seguridad. Y que tan importante es aplicar dichas medidas a unos como a otros entornos. Tened mucho cuidado con ser hechizados.

¿Y vosotros? ¿Creéis en la magia? ¿Qué otros hechizos conocéis? ¿Cómo se gestionan los entornos en vuestra organización?

Después de casi dos años, o algo así, inauguraremos nueva etapa pronto.

Everything changes, yet nothing is truly lost

A continuación, os ofrecemos algunas de las novedades previstas que podréis disfrutar muy pronto.

Nuevas secciones

El primer cambio, y más significativo, es la creación de nuevas secciones en el blog. Visto el éxito del Lunes desmotivador, vamos a crear algunas nuevas ‘secciones’ también vinculadas a ciertos días de la semana.

  • Lunes desmotivador: esta no necesita presentación. Continuaremos con la sección con nuevas escenas de nuestras películas favoritas.
  • Miércoles técnico: los miércoles ofreceremos un artículo sobre algún detalle técnico de implantación de la seguridad. 
  • Viernes casual hacking: los viernes toca un poco de relax. Os contaremos los últimos avances en ‘casual hacking’ que vayamos realizando en nuestros ratos libres.

Por supuesto, no todas las semanas habrá todas las secciones (o incluso alguna de ellas :)). Pero siendo esto guerrilla blogging, tendréis que estar atentos.

Nuevo tema

Estoy probando nuevos temas de WordPress para cambiar el aspecto del blog. Por ahora me va gustando este. Por favor, si veis alguno que os guste, opinad ahora que todavía hay tiempo.

Más reuniones

Este año intentaremos mantener más reuniones ‘en vivo’ en nuevos lugares de la geografía sevillana. Estamos abiertos a recomendaciones de cervecerías para la celebración.

Nuevo sistema de comentarios

Después de la tralla que nos están dando los spammers en el blog y de haber usado DISQUS en otros blogs. Voy a ver si soy capaz de sustituir el sistema de comentarios. Y esperemos que esto solucione el problema del spam y os permita tener una mejor experiencia al comentar.

Nuevas colaboraciones

Por otro lado, ya que estamos, esperemos que haya nuevas colaboraciones en el blog tanto de los que ya tienen cuenta para editar como de los nuevos que nos lo solicitéis.

 

En fin, estos son algunos de los cambios que veréis pronto. Si tenéis alguna idea para mejorar el blog, hacednoslo saber.

Bueno, después de un largo letargo, este es el primer post de 2013, ¿qué te parece?

Intentaré ser breve. El otro día un organismo con el que colaboro sufrió un ataque de phishing. El típico correo que simula muy burdamente provenir de Informática instando a los usuarios a pinchar en un enlace. En ese enlace se solicitan sus datos de acceso al correo que serán utilizados para otras fechorías más tarde.

En este escenario, una vez detectado el ataque, algunas de las acciones tomadas fueron la de bloquear al remitente de correo en el servidor de correo (que era siempre el mismo) y bloquear la página del enlace para que, si el usuario pinchaba, no llegase ‘a ningún sitio’.

Y, digo yo, ¿y si aprovecháramos para concienciar y obtener algunas métricas?

En vez de enviar la página a ‘a la nada’ ¿se les podría enviar a una página concienciatoria y aprovecharla para recopilar métricas?

Veamos cómo podría ser la cosa.

2013-02-11-225604_573x533_scrot

Una vez detectado el ataque de phishing, tomamos la URL a la que envía al usuario y la redirigimos (vía DNS o en el cortafuegos) a una página de concienciación en la que se le indique al usuario que ha estado a punto de liarla y se le recuerda que no debe pinchar en los enlaces de correos, en general.

En el servidor de esta página se mantiene una estadística para detectar cuántos han pinchado en el enlace del correo. Si esta información se correla con todos los que han recibido el mensaje (a partir de los logs del servidor de correo) sería interesante extraer una métrica de cuántos usuarios han pinchado.

Por supuesto, hay que considerar que «puede que no todos hayan abierto el correo» o «puede que algunos hayan accedido desde informática para análisis», etc. Pero desde luego es un ejercicio interesante a la vez que consigues concienciar a los usuarios que sí hayan pinchado porque no se trata de un simulacro, sino de un ataque real.

Y, visto que hay gente que pica independientemente de lo chungo del mensaje, todo lo que se gane con estas acciones, ahí queda.

A la gente del Sevilla Sec&Beer nos pasa una cosa curiosa. La gente nos asalta por la calle preguntando cuál es el secreto para ser tan versados en las artes de la (in-)seguridad. Cómo puede ser que encontremos tantas vulnerabilidades, adivinemos tantas contraseñas y sepamos tantos acrónimos.

Pues bien, hoy, aquí, en primicia, os contamos nuestro secreto mejor guardado: la fragancia hacker.

El efecto hacker

Unas gotitas antes de cada auditoría y no hay vulnerabilidad que se esconda ni no conformidad que no se encuentre. XSS, SQLi, XSRF y RFI serán tan evidentes que no te hará falta ninguna cara herramienta de detección automática.

¿Contraseñas? Con la fragancia hacker adivinarás la contraseña de cualquier usuario en menos de cinco intentos, independientemente de la complejidad que haya querido darle.

Te conectarás a redes inalámbricas sin darte ni cuenta. Los terminales públicos te dejarán acceder al sistema operativo con solo pulsar una combinación aleatoria de teclas.

La fragancia hacker no sólo funciona con personas, perfuma tu base de datos de carácter personal periódicamente y nunca tendrás problemas con la LOPD.

Con su aroma, la normativa de seguridad será leída con entusiasmo por los usuarios, que no sólo la cumplirán sino que tomarán parte activa en la gestión de la seguridad.

Eso sí, debemos advertir que la fragancia hacker no está indicada para acometer la implantación del ENS. Al fin y al cabo es sólo una colonia, no hace milagros.

¿A qué esperas? Consigue hoy tu fragancia hacker y llévate de regalo este juego de ganzúas, dos 0days y el after-shave cracker.

Ya a la venta en las reuniones de Sevilla Sec&Beer.

Para estas vacaciones os recomiendo que os pidáis un «juego de seguridad». La verdad es que yo no he jugado a ninguno, pero me parecen interesantes por su valor educativo y lúdico.

Tras una conversación en twitter, Adam Shostack y Jeremiah Grossman, el primero ha preparado esta lista con los ‘juegos de mesa’ con enfoque en seguridad informática.

Os pongo aquí la lista por aquello de que no quede muy descafeinado el post, aunque tendréis que ir a la fuente para ver más detalles:

  • Control-Alt-Hack
  • Elevation of privilege: the threat modeling game
  • Hacker
  • [D0x3d!]
  • NetRunner

Particularmente interesante es [D0x3d!] ya que es open source y es posible descargarse las cartas para imprimirlas, mezclarlas y personalizarlas.

Si alguno los tiene, los compra o se los regalan, que nos cuente qué tal. Por otro lado, si necesitáis jugadores no dudéis en avisarnos y montamos un secandbeer con tablero.

Como se acerca la Navidad, desde Sevilla Sec&Beer aprovechamos para felicitaros y de paso contaros una bonita historia navideña.

Imaginaos que vais a un centro comercial (nada raro en estas fechas). Imaginaos que os pasáis por la sección de informática. Allí hay muchos equipos para que los prueben los clientes que tienen conexión a Internet.

Imaginaos que sacáis un terminal, veis la dirección IP (192.168.1.algo, como no) y se os ocurre probar con la 192.168.1.1. Imaginaos que el router tiene la contraseña por defecto del operador…

Ya es Navidad en el...

En fin, me pregunto qué tendrán conectado a la red inalámbrica… Espero que nada crítico.