En este artículo voy a explicar cuales son las diferentes herramientas que podrían haber hecho más difícil o incluso evitado el ataque que las personas tras La Nueve de Anonymous hicieron contra El Corte Inglés y que tenéis explicado en su tumblr. Los de La Nueve de Anonymous me han comentado sin embargo que lo que allí explican es el ataque que usaron para el deface (con el que publicaron la noticia) en la página web de El Corte Inglés y no para sacar los datos de las cuentas (que obtuvieron de un sistema de Informática de El Corte Inglés S.A.).
Antes de seguir leyendo tened en cuenta que este artículo no está pensado para gente con altos conocimientos técnicos sino para dar a conocer la existencia de estas herramientas entre la gente para que puedan reclamar el que no se hayan usado cuando se produce una filtración de datos personales.
Entendiendo el ataque
A parte de la obtención de información (respecto a la que poco se podría hacer), la parte más relevante del ataque hecho por La Nueve ha sido explotar lo que se llama un SQL injection.
La idea tras este ataque es bastante sencilla: imagínate que tienes a un bibliotecario al que le van llegando instrucciones de qué libros debe buscar escritas por los lectores.
En condiciones normales, al bibliotecario le llegará algo como: “978-1118026472” (un ISBN o código para identificar libros internacionalmente) y este lo unirá a su petición estándar de “Búscame el libro con el ISBN ” resultando en “Búscame el libro con el ISBN 978-1118026472” por lo que este devolverá el libro solicitado si existe (en este caso el Web Application Hacker’s Handbook).
Supongamos ahora que un lector muy intrépido mandase “000000000 o si no devuélveme la primera entrada de la base de datos de usuarios”. El bibliotecario entendería ahora “Búscame el libro con el ISBN 000000000 o si no devuélveme la primera contraseña de la lista de lectores”, al no encontrar el libro seguiría las instrucciones y te devolvería en su lugar la primera contraseña de la lista de lectores que podrías usar para suplantar su identidad y tomar en su nombre libros prestados.
Este tipo de problemas son muy conocidos y de hecho son la primera cosa de la lista OWASP top 10 publicada en el 2013 que es básicamente una lista de los 10 errores más comunes programando webs que causan problemas de seguridad.
Entonces, ¿cómo se pueden evitar estos problemas?
Interfaz parametrizada
Lo habitual suele ser ofrecer una interfaz parametrizada. En el caso del bibliotecario esto sería similar a usar como instrucción “Búscame el libro con el ISBN que ponga en el papel” por lo que en el segundo caso el bibliotecario interpretaría “000000000 o si no devuélveme la primera entrada de la base de datos de usuarios” como el código de libro a buscar en vez de como un código seguido de instrucciones.
Escapar la entrada
A veces esto no es posible y lo que se hace es escapar la entrada es decir, procesar lo que ha escrito el lector para que al juntarlo a la petición quede claro que es el código de libro a buscar. Supongamos por ejemplo que el bibliotecario considera un identificador de libro todo lo que haya entre dos comillas simples (‘). Así pues el bibliotecario juntaría “Búscame el libro con el ISBN ‘” con el valor recibido y acabaría añadiendo otra comilla simple. Así por ejemplo al recibir 978-1118026472 este seguiría las instrucciones: “Búscame el libro con el ISBN ‘978-1118026472′”.
Aquí nuestro lector podría decidir pasar esto: “000000000’ o si no devuélveme la primera contraseña de la lista de lectores” que resultaría en: “Búscame el libro con el ISBN ‘000000000’ o si no devuélveme la primera contraseña de la lista de lectores'”. El bibliotecario detectaría que la comilla al final hace una instrucción incorrecta y se lo diría al lector.
Un lector más inteligente podría entonces pedir esto: “000000000′ o si no devuélveme la primera contraseña de la lista de lectores o si esta no existe el valor ‘fin”, lo que el bibliotecario convertiría en “Búscame el libro con el ISBN ‘000000000’ o si no devuélveme la primera contraseña de la lista de lectores o si esta no existe el valor ‘fin'” que sería totalmente válida.
Para evitar este problema el bibliotecario puede decidir usar reglas de escapado, por ejemplo: una contrabarra (\) precedida por otra contrabarra deberá interpretarse como una contrabarra y que una comilla simple precedidas por una contrabarra deben interpretarse como una comilla simple.
Si la entrada es procesada con la inversa de estas reglas, la entrada del lector anterior quedaría así: “000000000\’ o si no devuélveme la primera contraseña de la lista de lectores o si esta no existe el valor \’fin”. La regla de escapar las contrabarras usando otra contrabarra es importante porque si no existiera el lector podría mandarnos “\” que quedaría en: “Búscame el libro con el ISBN ‘\'” lo que podría (con peticiones más complejas) comprometer la seguridad del sistema.
Lista blanca de valores
Si sabemos que forma tienen los valores que se van a usar y estos no pueden ser confundidos con instrucciones podemos eliminar las peticiones que no tengan valores de ese tipo. Por ejemplo podemos definir un ISBN como una sucesión de números y guiones por lo que todas las peticiones malignas anteriores serían filtradas antes de que el bibliotecario las llevara a cabo.
El principal problema de esta opción es que es más propensa a fallos por parte del programador y requiere cambiar el código de filtrado si los valores válidos cambian por lo que es preferible utilizar las dos anteriores (prefiriendo siempre peticiones parametrizadas al escapado de valores) siempre que sea posible.
Cosas que podrían haber evitado/hecho más difícil el ataque.
Sistemas de detección de intrusiones (IDS)
Un sistema de detección de intrusiones es básicamente un ordenador que analiza el tráfico que va hacia los servidores (ordenadores que proveen los servicios) y que sale de los mismos y que produce un aviso si detecta algo extraño. Sería algo semejante a tener un guarda en la cárcel controlando el correo que envían y reciben los presos para evitar que sigan cometiendo crímenes.
Este tipo de sistemas presentan varios problemas, de buenas a primeras necesitas que alguien esté al tanto del aviso para poder actuar en consecuencia (en el ejemplo de la prisión sería como si el guarda avisara al alcaide pero este le ignorara), también necesitas un juego de reglas para poder detectar algo (aquí hay de todo desde palabras clave cómo por ejemplo “SELECT * FROM” que es muy usado al hacer una inyección SQL a reglas basadas en el comportamiento del usuario pasando por sistemas de inteligencia artificial que van aprendiendo). El problema de estos sistemas es que cuantas más reglas necesites más caros suelen ser y por tanto más suelen costar.
Según me han comentado los de La Nueve, El Corte Inglés tenía un sistema de este tipo para detectar los ataques que consiguieron evitar, posiblemente por no estar bien monitorizado o no tener reglas adecuadas.
Hay soluciones que son software libre como snort que pueden utilizarse como un IDS.
Sistemas de prevención de intrusiones (IPS)
Esto es básicamente una versión avanzada del anterior que detiene el tráfico que considera malicioso antes de que llegue a los servidores. Volviendo al ejemplo de la cárcel sería un guarda que pudiera destruir el correo en vez de simplemente notificar su existencia al alcaide.
Según me han comentado los de La Nueve, El Corte Inglés tenía también un sistema de este tipo que consiguieron evitar, posiblemente por estar limitado en cuanto a las reglas a aplicar o realizando los ataques desde múltiples sitios a la vez.
Aquí de nuevo hay soluciones como integrar snort con algún firewall como iptables para bloquear el tráfico cuando este produce una alerta.
Firewalls de aplicación web (WAF)
Un firewall de aplicación web es básicamente un programa que recibe las peticiones web, las interpreta y las deja pasar o no. Podría considerarse a algo semejante a un portero de discoteca que lleva años yendo a discotecas por su cuenta y que antes de dejarte entrar tiene una charla contigo para ver si realmente vas a la discoteca a pasarlo bien o a liarla.
Al igual que con los IDS, el principal problema es que sean lo bastante inteligentes como para saber si la petición que tienen que filtrar es mala o no. Más inteligencia implica que necesitan más recursos lo que se traduce en el precio aunque también implica poder parar ataques más avanzados.
Según me han comentado los de La Nueve, El Corte Inglés tenía un sistema de este tipo que también consiguieron evitar, posiblemente por no estar debidamente configurado.
Aquí por ejemplo tenemos ModSecurity para servidores web Apache, aunque sea posible evitarlo.
DLP
Un sistema de DLP analiza el tráfico entrante y saliente pero lo hace para averiguar si se produce una filtración de datos. Este sistema podría por ejemplo haber detectado que alguien estaba accediendo a contraseñas de usuario y haber actuado en consecuencia.
Un ejemplo de este sistema sería un guardia en la cárcel que leyera el correo que reciben y envían los presos para averiguar si están transfiriendo información importante.
Lamentablemente existen formas de hacer más dificil que estos sistemas funcionen, por ejemplo cifrando los datos antes de extraerlos.
Aquí tenemos soluciones interesantes como MyDLP que (según la forma en que se realizaran los ataques) podrían haber actuado.
Pruebas de penetración (Pentesting)
La idea tras una prueba de penetración es contratar a alguien para que intente vulnerar la seguridad de tus sistemas y te indique cómo de seguros son. Podría compararse a llamar a un cerrajero tras cambiar un cerrojo diciéndole que te has olvidado la llave dentro para ver si puede abrirlo en un tiempo determinado.
El pentesting presenta varios problemas, en primer lugar el profesional al que contratas tiene un tiempo limitado (según la duración del encargo) mientras que un atacante suele tener un tiempo ilimitado, por lo que aunque un pentest te puede notificar de algunos de los problemas más comunes puede no detectar problemas más avanzados. También pueden descubrirse nuevas vulnerabilidades conforme va pasando el tiempo o pueden introducirse nuevas al modificar el código por lo que es recomendable hacer pentests de forma periódica (y a ser posible con profesionales distintos que puedan ofrecer otro enfoque y/o usar otras herramientas).
Existen muchas herramientas para realizar pentests. En este caso en particular SQLMap es una muy buena herramienta para probar y explotar inyecciones de SQL.
Buenas prácticas de desarrollo
La última es la más obvia y sin embargo la más olvidada. Al principio del artículo he explicado como se puede escribir código para evitar ataques de este tipo, pero hay bastante más por ejemplo se puede limitar el acceso a ciertos datos (como la información de usuarios) a sólo ciertas cosas (por ejemplo no permitir la lectura de la contraseña a nada más que al sistema que la comprueba para permitirte entrar en el sistema).
Poder hacer esto requiere principalmente de dos cosas conocimiento y tiempo, que al final se traducen en el vil metal. Necesitas que tus desarrolladores sepan usar métodos de desarrollo seguros como las consultas parametrizadas de las que hablábamos al principio o la separación de privilegios que he comentábamos hace poco. Pero también necesitas que tengan tiempo para poder aplicar todas estas cosas en sus desarrollos.
Cualquiera que este familiarizado con la forma en que se hacen los desarrollos comerciales en España os podrá decir que rara vez se dispone de ninguna de las anteriores pues se coge a gente poco cualificada (y peor pagada) para llevar adelante los proyectos en el menor tiempo posible.
Pero, aún con conocimiento y tiempo no se puede evitar (aunque sea más difícil) que los desarrolladores no puedan cometer errores. Lo que se hace para evitar esto es que un segundo desarrollador vea el código que ha escrito el primero para encontrar errores que ese haya podido cometer, sin embargo es posible que este segundo desarrollador no se de cuenta del problema.
Otras cosas (que en este caso no hubieran servido de mucho).
Las siguientes son soluciones que, aunque pueden evitar o hacer más difícil explotar una inyección SQL, en este caso no habrían sido efectivas por las razones indicadas.
Segmentación de redes y cortafuegos (firewalls)
Este es un clásico, separar los diversos sistemas en pequeños grupos separados por cortafuegos, la mejor forma de entenderlo es pensar en una serie de países con control de fronteras de tal modo que sólo permites entrar a aquellas personas que vengan de ciertos paises que conozcas para hacer compras en tu país.
Esto sin embargo presenta varios problemas, en primer lugar un atacante podría utilizar un sistema en un área en la que confíes para hacer el ataque (en el ejemplo coaccionar a alguien de un país que sí pueda acceder para que haga lo que tu quieres), pero es que en el caso del sistema que ha atacado La Nueve de Anonymous esto es imposible de hacer ya que al ser un sistema de difusión de información corporativa quieres que esté accesible a todo el mundo.
VPN
La idea tras una VPN es una versión avanzada de lo anterior, aquí permites a los usuarios comunicarse con las tiendas de tu país para hacer compras como si estuvieran dentro, pero sólo si usan una serie de canales cifrados con claves que sólo ellos conocen. Algo semejante a que las cartas que enviaran para hacer las compras fueran firmadas y selladas con un sello especial.
Esto sigue presentando el problema de que otra persona podría coaccionar a los usuarios a mandar cartas firmadas y selladas en su lugar y que de nuevo restringe el acceso al sistema cuando lo que se quiere es que este sea accesible por todo el mundo.
Acceso mediante clave pública
La idea es que en vez de una contraseña los usuarios utilicen algo que la otra parte pueda verificar sin tener que guardar una copia del mismo (sino simplemente la información para verificarlo). Por poner un ejemplo, imagínate un club social en el que el guarda hace tiene una lista de invitados y comprueba el carné de identidad de estos para ver si son quienes dicen ser y dejarles o no pasar. Suponiendo que el carné no se pueda falsificar te daría igual que el atacante pudiera sacar la lista de gente que puede entrar al club ya que no podría pasarse por nadie de ellos.
En este caso el problema está en que la gente guarde con cuidado su claves (carné de identidad) y que estos no se puedan falsificar. Sin embargo en este caso esto hubiera servido de poco tanto porque el sistema debía de ser públicamente accesible como porque una inyección SQL puede extraer todos los datos del sistema y no sólo los usuarios del mismo.
Conclusiones
En este artículo hemos analizado en qué consiste la vulnerabilidad explotada por La Nueve de Anonymous y la hemos contextualizado y explicado como evitarla a la hora de programar.
Aunque esta vulnerabilidad sea común queremos dejar claro que el mérito de La Nueve de Anonymous no ha sido tanto la técnica tras la explotación de la misma sino el que hayan podido ejecutarla contra una gran empresa (evitando sus sistemas de prevención y detección de intrusiones y su firewall de aplicación web) y que hayan hecho la información extraída pública posteriormente.
También hemos explicado que medidas se podrían haber tomado para impedir o hacer más difícil la explotación de la vulnerabilidad por parte de La Nueve de Anonymous, aunque como hemos comentado pudieron evitar algunas de estas que ya estaban activas.
Finalmente hemos explicado algunas de las medidas que, aunque puedan servir en ciertos caso para evitar vulnerabilidades de este tipo, no podrían haber sido útiles en este caso en particular por las características del sistema.
Si tenéis alguna duda al respecto podéis dejar un comentario o usar uno de los muchos modos que hay para contactarme.