Después de una temporada en el infierno, vuelvo a la guerra proponiéndoos una sesión de película, cervezas y, como no, seguridad. La película en cuestión es Open Windows de Nacho Vigalondo. Aunque a los más viejos quizá os recuerde a esto.

Realmente se trata de esto. Es un thriller tecnológico contado a través de pantallas de ordenador, ventanas, webcams… Tiene una temática bastante relacionada con la seguridad, principalmente hacking y privacidad. Y, bueno, nada más el ir identificando sistemas operativos, software, comandos, etc. ya merece la pena echar el rato.

En definitiva, que da para verla y luego comentarla echandonos unas cervezas en algún sitio cercano al cine.

¿Qué os parece, alguien se apunta?

¿Que qué día será tan feliz evento?? Pues NUNCA. Porque la película no ha durado ni un mes en los cines de esta mierda de ciudad retrógrada…

Así que, si alguien ha tenido la suerte de verla, que nos cuente qué tal. Desde el punto de vista de seguridad y cosas informáticas, nada de spoilers o referencias a la anterior vida de Sasha Grey, ¿eh?

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.

Es durante una auditoría o revisión de seguridad donde te encuentras las cosas más bizarras. Todos los miedos que tienes sobre lo mal que podría estar todo se hacen realidad.

El nivel de incredulidad a veces es gracioso porque piensas “¿no se podrá hacer esto, verdad?”. Y se puede :). Bueno, no siempre, a veces no, pero sí muchas más veces de lo que debiera ser.

Contraseñas sencillas (por no decir iguales al usuario), sistemas SIN contraseñas, servicios conectados a redes inalámbricas inseguras, servicios vulnerables, scripts de administración con contraseñas, aplicaciones web en las que se piensa que el usuario no puede modificar nada, sistemas de permisos ligeritos, etc.

Hay veces que las malas decisiones de diseño deja entrever muy poco conocimiento de cómo funcionan las tecnologías y de patrones de seguridad:

  • En redes: visibilidad de servicios TCP, segmentación de red, arquitectura…
  • En sistemas: gestión de contraseñas, métodos de acceso, fortificación, etc.
  • En web: mantenimiento de sesión, ejecución de código en el navegador (javascript, flash, java…), same origin policy, etc.

En fin, para ilustrar esta situación, aquí está un nuevo lunes desmotivador, sólo en Sevilla Sec&Beer (rechace imitaciones).

Si no pasa nada más porque Dios no quiere… ¿o es que no nos damos cuenta? Bueno, eso es asunto para otro post, pronto.

Una constante en cualquier auditoría es que se repiten las excusas de “pero esto lo vamos a cambiar“, “está en proceso de migración“, “mejor esperamos a que esté operativo tal o cual nuevo sistema“. Vamos, que todo está siempre en continuo cambio.

Y el cambio, como ya sabemos, es un problema para la seguridad si no está relativamente controlado. Pero de lo que va este artículo es de usar el cambio como excusa para retrasar (normalmente indefinidamente) alguna actividad de seguridad.

Puede aparecer de dos formas. La que he comentado antes de esperar para efectuar algún tipo de revisión y la de esperar para implantar alguna medida de seguridad.

La excusa es bastante razonable y suele calar en los responsables que atienden a ella. Pero hay una mentira subyacente y es que… siempre hay cambios, con lo cual el estado al que se propone esperar para efectuar la actividad de seguridad no va a llegar nunca.

Para reflejar esto he hecho el lunes desmotivador de esta semana, esta vez inspirado en el cine español, que ha estado injustamente ausente en los anteriores.

Pues eso, está claro que, al ritmo que van las tecnologías de la información en una organización, todo cambia continuamente y eso no nos debe impedir implantar medidas de seguridad.

Por otro lado… a veces pasa que el cambio que viene y viene y la migración que migra y migra pero… pasa el tiempo y no cambia nada por esto o por aquello.

Por eso, actuemos sobre lo que hay hoy y, si cambia, pues al menos  hemos aprendido y lo haremos mejor en la siguiente versión. Y, además, sabremos que requisitos imponer incluso antes de que cambie.

Por último, relacionado con el asunto del cambio, está claro que eso supone un desafío para la gestión de la seguridad si no está controlado y documentado… ¿O conocéis algún mapa de red actualizado?

Una cosa que no acabo de entender muy bien es como puede ser que los administradores de sistemas monten cualquier software que va a dar servicio a una aplicación y lo dejen todo tal cual, por defecto o por omisión (que suena más a pecado).

Da la impresión de que suceden varias cosas:

  • El administrador no tiene ni puta idea del software y lo instala con todo lo que traiga
  • El administrador no tiene ni puta idea de los requisitos de desarrollo (si se trata de un sistema para ejecutar una aplicación a medida)
  • El administrador no se ha molestado en mirar ninguna instrucción sobre qué hacer después de la instalación del software ni ha buscado guías de configuración segura

Vamos, menos mal que, cada vez más, las opciones por defecto suelen ir viniendo mucho más seguras que antes, que si no…

Y lo de las contraseñas por defecto o muy, muy sencillas es otra historia similar.

En fin, para ilustrar esta no muy alegre situación, os dejo un nuevo lunes desmotivador para vuestro deleite esta semana, como si el calor no fuera ya suficiente.

Aprovechando que entra la primavera vuelve el afamado lunes desmotivador para hundiros en la más profunda depresión de la que saldréis mucho más concienciados que de cualquier charla motivadora positivista.

Hoy toca desmotivar sobre la consultoría de seguridad, ese arcano arte de interpretar una situación compleja desde el punto de vista de seguridad y convertirla en algo que entienda el cliente y que le motive a tomar acción.

Cuando digo cliente me refiero al destinatario de la consultoría de seguridad que debe tomar decisiones, independientemente de si es tu jefe, el responsable de otra unidad o tu cliente en una relación profesional.

La complejidad está en escapar del “¿y qué?” sin llegar a caer en el sensacionalismo y el meter miedo excesivo ni tampoco acabar dando la impresión de que todo es una puta mierda pero no decir que están bien porque entonces igual no hace nada… En fin, los que hayáis hecho esto alguna vez sabréis de qué hablo.

Recordad siempre sustituir palabras negativas por positivas (programación neurolinguista, como diría alguno que yo me sé). Por ejemplo: problema -> desafío, carencia -> aspecto de mejora y cosas así.

En definitiva, disfrutad del lunes desmotivador de esta semana.

Una puntualización sobre la cita anterior. Siempre trato de ser absolutamente fiel a las palabras empleadas en la versión española de la película. Incluso he llegado a descargarme la película para capturar la pantalla y ver exactamente qué dice en español.

En este caso, sin embargo, he hecho una excepción porque la traducción de la película en español es francamente chorra “Este trabajo lo fastidian los malditos clientes“. Cuando en inglés es “This job would be great if it weren’t for the fucking customers“. Así que he puesto una traducción propia que creo que ejemplifica mejor la intención original.

La seguridad en el desarrollo de aplicaciones es un oscuro arte que difícilmente puede hacerse bien. Si ya es difícil que la aplicación haga lo que se supone que tiene que hacer… que además lo haga de forma segura es un imposible.

Si además consideramos la situación actual de la tecnología web con sus múltiples posibilidades y sutilezas (pronto hablaré algo más de esto cuando termine The tangled web) la tarea se convierte en algo improbable.

Y si encima consideramos la situación de la mayor parte de los equipos de desarrollo (personal externo, rotación, becarios e inexpertos, variabilidad de requisitos, etc.) pues os podéis imaginar dónde acaba la seguridad.

Por eso, os dejo el primer lunes desmotivador de este año, para empezar con buen pié esta nueva vuelta alrededor del astro rey.

Tened en cuenta que desarrollar una aplicación que tiene que ejecutarse en un entorno de producción e interaccionar con un conjunto de servicios no tiene nada que ver con simplemente ‘programar’ en un lenguaje de programación.

Asombroso es también la diferencia entre lo que se gasta en hacer un sistema de información (podéis tirar de los números públicos) y lo que se gasta en analizar y corregir defectos de seguridad.

Por muchas medidas que pongamos en los sistemas de información la realidad es que el administrador del sistema puede hacer lo que quiera. Esta verdad puede ser chocante (y normalmente lo es) para la gente de negocio, que piensa que las medidas de control de acceso protegen la información del mismo.

“¿Cómo?? ¿Que pueden leer mi correo? ¿Acceder a mis directorios compartidos del servidor? ¿Acceder a los datos de la base de datos directamente??”

Pues sí. Y no es que no se pueda hacer nada para evitarlo… es que tampoco se quiere hacer. Porque en casos de crisis siempre está bien tener un acceso absolutamente privilegiado… ¿o no?

El problema es que el poder absoluto corrompe absolutamente. Y tal y como está la cosa, además, es bastante común que sus sueldos no sean muy altos, por lo que el riesgo aumenta.

Os dejo el lunes desmotivador de hoy para ilustrar esta terrorífica situación.

Luego, el día que el administrador se va, o peor aún, lo echan, surgen dudas como esta.

Por aquello de contrastar situaciones, ¿qué medidas tomáis o conocéis que toman para controlar a los administradores? Y no sólo estoy hablando de root, Administrator o el DBA, sino también de los usuarios administradores de aplicaciones.

La mejor escena de Instinto básico para mí siempre fue esa en la que el Douglas sube las escaleras diciendo “porque yo soy…” y la Sharon Stone (sharito para los colegas) le completa la frase diciendo “impredecible”.

Dicho esto, emplear secuencias predecibles en el ámbito tecnológico puede desembocar en problemas que el diseñador no ha previsto.

Veamos algunos ejemplos de la vida real.

El otro día me encontré un servidor de streaming servido desde una aplicación web. Resulta que los enlaces a los contenidos tienen un formato numérico del tipo 0091.flv, 0067.flv, etc. Así que, con un pequeño script es posible hacer un barrido por las 10000 posibilidades, a ver qué encontramos.

Otro día distinto me dieron una cuenta de usuario para hacer unas pruebas y tenía una nomenclartura tal como esta: thx1138. Hmmm. Total que probando, todos los usuarios del sistema eran del tipo thxNNNN. Así que es trivial encontrar nuevos usuarios para otras felonías.

Hay cierta organización que tiene un conjunto de servidores cuyos nombres son del tipo wsNNN. Por lo que, para descubrir servidores sólo hay que iterar entre las 1000 posibilidades.

En otro sitio vi que había una aplicación web que hacía de portal de entrada para otras aplicaciones. Cada usuario veía las aplicaciones que le correspondían en base a su perfil… pero claro, se trataba de un número secuencial, por lo que era fácil descubrir otras aplicaciones a las que, en principio, no tenías acceso.

Uno clásico es el directorio lleno de ficheros generados por una aplicación al que te dan acceso directo. Y resulta que es un tmpNNNNNNNN.pdf o similar. Pues nada, a probar ahí a ver si encontramos otros PDFs.

Otro clásico es la publicación de aplicaciones web de desarrollo o páginas borrador en el entorno de producción, disponibles a quién sepa la URL. Cuando es predecible, siempre aparece al que se le ocurre probar. Por ejemplo, si la aplicación es /aplicacion2011, ¿existira /aplicacion2012? Si la noticia es news20111110… ¿existirá news20111111?

El mayor de los peligros de este tipo de pensamiento (aparte de la enumeración) es que, a veces, hay recursos que el diseñador piensa que están protegidos porque no son ‘enlazados’ desde ningún sitio. Pero claro, si simplemente iterando eres capaz de encontrarlos…

Para los que no la conozcáis una herramienta muy útil para estos casos es seq. Por ejemplo, si queremos generar una secuencia del 1 al 10:

$ seq 1 10
1
2
3
4
5
6
7
8
9
10

O si queréis algo más elaborado: por ejemplo, empezar en 0000 hasta 1138 de dos en dos, añadiendo el thx y con cuatro digitos rellenando con ceros si hace falta.

$ seq -f 'thx%04g' 0000 2 1138
thx0000
thx0002
thx0004
thx0006
thx0008
thx0010
thx0012
thx0014
thx0016
thx0018
...

Para usar esto, por ejemplo, en una secuencia de comandos, podemos hacer lo siguiente:

$ for i in `seq -f 'thx%04g' 0000 2 1138`
> do
> curl -siLk https://lucas.film/user=$i
> done

¿Qué hacemos para no ser predecibles? Pues pensar un poco cada vez que vayamos a nombrar muchos elementos. En ciertos casos es imposible o inconveniente, pero en otros… es fácil.

En el caso del streaming o de las aplicaciones, o nombres de ficheros en general, es posible emplear identificadores universalmente únicos (UUID) que son difíciles de predecir, adivinar o probar por fuerza bruta.

Todos los lenguajes disponen de librerías UUID para generar vuestros nombres aleatorios irrepetibles. De hecho, existe un comando uuid que podéis instalar en vuestra distro favorita o descargar de OSSP.

Los problemas de secuencias predecibles han causado muchísimos problemas en redes. Tanto es así que en OpenBSD fueron los primeros en generar números aleatorios para todo, desde PIDs a números de secuencia TCP. Eso les ha salvado de algunos problemas que han tenido otros sistemas operativos.

Recordad diseñar siempre cualquier tipo de conjunto de elementos nominales para evitar secuencias evidentes que nos hagan tan predecibles como Michael Douglas en Instinto básico.