Solución: Mayor integración a nivel corporativo de equipos de seguridad y de desarrollo.

En la experiencia adquiridas en el marco de la seguridad de aplicaciones web para empresas como bancos, administradoras y otros tipos de instituciones financieras, me he encontrado con cierta disociación entre los departamentos de desarrollo de aplicaciones (esos locos que no prueban bien lo que hacen) y de seguridad de datos y sistemas (esos gruñones que nunca aprueban lo que desarrollamos a la primera).

Como si fuera ya una tradición, no es nuevo escuchar que los primeros (desarrolladores) se quejan de la cantidad de protocolos de verificación, metodologías de testeo y lentitud o redundancia de los procesos de validación de los sistemas, mientras los segundos (técnicos en seguridad de datos y aplicaciones) lo hacen acerca de la falta de controles en código, rutinas insuficientemente testeadas en desarrollo, "agujeros" de seguridad heredados en código reutilizado, entre muchas otras cosas.

El cambio actual del tipo de plataforma de aplicaciones convencionales o de entorno manejable a una plataforma aún más abierta y peligrosa como el entorno de aplicaciones web cuyos límites y procesos no son fácilmente controlable, no solo ha afianzado la brecha entre estos dos departamentos, sino pareciera crear en algunos casos conflictos infranqueables.

Mi punto de vista es que en la actualidad ambos tipos de departamentos se encuentran en esta encrucijada debido al mantenimiento de políticas de desarrollo y seguridad en ambos lados que poco o nada tienen que ver con la forma en que las aplicaciones web pueden ser y son atacadas actualmente.

He constatado como empresas de cierta magnitud, no tienen políticas adecuadas para solventar los ya no tan nuevos tipos de ataques a aplicaciones web y a sus usuarios, y he visto personalmente como intentan aplicar en ambos bandos procesos ineficientes y absurdos a la hora de minimizar o anular un ataque (de phishing o pharming por ejemplo). Y por último he visto también como ambos bandos culpan al otro cada vez que se encuentran en este tipo de conflictos.

Desde una mirada exterior experimentada, puedo asegurar que el problema no pertenece a ninguno y a los dos bandos simultáneamente. Las razones son las siguientes:

• Los protocolos de seguridad actuales no permiten responder con la celeridad necesaria ante ataques al entorno de aplicaciones web. Este tipo de ataques son en su gran mayoría del tipo masivo (phishing, pharming, DDoS, XSS). Son ataques que por sus características, una vez implantados y procesados atacan a un amplio espectro de los usuarios y no a uno o dos. Minutos perdidos son cantidades de dinero que no vuelven, y los protocolos de seguridad convencionales pueden llegar a estorbar más que a ayudar en estos casos.
• Los desarrolladores y expertos en seguridad, en tiempos anteriores jamás tuvieron que preocuparse por la seguridad de un usuario que se encuentra ante su computador en su propia casa. Este es un concepto radicalmente nuevo para ellos, al punto que por ejemplo los ataques de phishing hasta hace poco eran considerados problema del usuario y no de la empresa.
• Ambos equipos jamás tuvieron que validar aplicaciones y las interfaces de estas que funcionan simultáneamente en todos los sistemas operativos, bajo al menos una decena de navegadores web diferentes y una miríada de configuraciones diferentes.
• Ambos equipos jamás pensaron o se imaginaron que sus aplicaciones podrían ser atacadas desde zonas que hasta el momento eran completamente irrelevantes. A nadie le importaba lo que pudiera hacer un hacker en países como Rusia, China y otros que quizás nunca habían escuchado nombrar.
  

En fin, lo que trato de exponer es que definitivamente la seguridad nunca y mucho menos ahora ha sido un problema interdepartamental. Las empresas necesitan técnicos que manejen ambas áreas de forma actualizada y eficiente y reconduzcan al personal existente a una nueva forma de observar los procesos de desarrollo así como los procesos de validación y testeo.

El enemigo además de ser un enemigo oculto, no es enemigo de un solo departamento. Es un enemigo común que posee tecnología sofisticada que puede obtenerse de forma cada vez más simple, por lo cual su capacidad de ataque se multiplica exponencialmente con el tiempo. 

El trabajo de seguridad (y no hablo solo de aplicaciones web) actualmente debe ser definitivamente compartido. Se necesitan desarrolladores en capacidad de entender los nuevos modelos de seguridad y tipos de vulnerabilidades para ser capaces de prevenirlas en código, así como expertos de seguridad en capacidad de comprobar la existencia de este tipo de vulnerabilidades y de crear procesos dinámicos de validación pero jamás sacerdotes que promulguen tablas de leyes bíblicas inamovibles.

Por otra parte las empresas deben canalizar sus presupuestos de seguridad e invertir más en actualizar su personal en seguridad de aplicaciones web, y proveerlos de mejores herramientas de control y desarrollo para tal fin. Así como pretenden que una gran cantidad de usuarios utilice las nuevas y más económicas tecnologías, deben entender que dicha pretensión conlleva un riesgo mayor y por ende un presupuesto mayor en respaldo de las mismas.

El enemigo actual solo puede ser combatido desde una perspectiva que no es nueva ni mucho menos innovadora, pero que tiende a ser olvidada en el día a día y enterrada por los procesos. Esa perspectiva no es más que la de un verdadero trabajo de equipo por un fin común.

Hasta la próxima...

¿Qué es el Google Hacking Database (GHDB)?

Google es entre muchas otras cosas el buscador con la mayor cantidad de páginas indexadas en el mundo y la mayor cantidad de búsquedas diarias, y precisamente por eso es una fuente inagotable de recursos y de información sobre cualquier tópico relacionado con la web. Es de suponer que una fuente de información de este tipo también puede ser usada para fines no muy éticos.

No hablamos de obtener información específica con fines no necesariamente legales. Tampoco se trata de utilizar las búsquedas para recoger información específica para hacer minería de datos. Esta vez hablamos (aunque pudiéramos relacionar algunos casos con las anteriores) de utilizar el mejor buscador del mundo para buscar aplicaciones web vulnerables a ciertos tipos de ataque o utilizar la información obtenida para mejorar la eficiencia de ataques pre-configurados.

¿Cómo puede ser esto? ¿Es verdad que a través de Google se pueden descubrir vulnerabilidades específicas? Pues es cierto, con el conocimiento necesario se pueden manejar las consultas para que nos provean de una lista de sitios que tienen una vulnerabilidad en común.

Es fácil, todo el tiempo oímos acerca de nuevas versiones de software (manejadores de contenido, servidores web, aplicaciones web pre-elaboradas) en las que se corrigen determinado tipo de vulnerabilidad. A veces esta información es colocada en línea para informar a los usuarios y desarrolladores lo cual es lógico, sin embargo de forma inocente al mismo tiempo se le informa a los atacantes acerca de una vulnerabilidad no conocida de la versión anterior. Así de sencillo.

Un ejemplo: El software para manejo de contenido que llamaremos "X" acaba de ser mejorado para resolver una vulnerabilidad de inyección de SQL, por tanto el atacante lo único que necesita hacer es ubicar una característica visible en la versión anterior de "X" que lo diferencie de la versión que no posee la vulnerabilidad. Algunas veces se trata de buscar una inocente cadena de texto como: "Powered by X version x.xxxx". Otras veces se trata de buscar un cambio en el nombre de un archivo o un cambio en el hash resultante del mismo.

Este tipo de búsqueda se realiza de forma sistemática y eficiente, parametrizando la cadena de búsqueda de Google con los "operadores" que pone a nuestra disposición el buscador y combinándolos de forma inteligente se puede afinar la búsqueda en un grado impresionante.

Par ver un listado de operadores de Google, puede visitar: http://www.googleguide.com/advanced_operators_reference.html
En este sitio encontrará una lista muy interesante de los operadores de Google para diferentes aplicaciones (stocks, groups, phonebook...) junto con su uso específico. Luego de apreciar algunos de los operadores que le parecerán sin dudad muy potentes, es muy posible de que no se haya percatado que estos operadores pueden además combinarse para hacer las búsquedas mucho más eficientes.

Por ejemplo, una búsqueda como: site:elsitio.com filetype:pdf  puede arrojar como resultado todos los archivos de formato "pdf" del sitio que coloquemos junto al operador "site:". Esta es una muestra de dos operadores muy potentes trabajando juntos. Con un poco de imaginación usted podrá entender con este simple ejemplo las razones por las que Google es la herramienta preferida de los atacantes y entenderá también como la distancia y el idioma dejan de ser barreras, ya que solo es necesario que un sitio tenga una vulnerabilidad detectable para que pueda ser accedido por los atacantes. Ah se me olvidaba el idioma, pero se preocupe, para eso existe Google Translator (el que además puede ser utilizado como "proxy" para evitar ser detectados en los test de penetración). Ah... se me olvidaba, si lo que quiere es ubicar un proxy ¡solo tiene que hacer la consulta correcta!

Quizás la idea es hacerle entender con lo anterior que su aplicación no se encuentra ya protegida por el enorme cúmulo de sitios web y aplicaciones en la red, tampoco la distancia ni el idioma son un obstáculo para el atacante. Ya no basta protegerse bajo la estrategia de la aguja en el pajar. Los operadores de Google pueden separar las agujas de la paja de forma rápida y hasta podría decirse que tan eficientemente como un verdugo experimentado aniquila a su víctima. 

Para más información puede acceder a la página:http://www.hackersforcharity.org/ghdb/
Allí podrá obtener información acerca de todos los tipos de consultas relacionados con vulnerabilidades que pueden ser detectadas mediante el uso de GHDB. También puede recurrir al libro Google Hacking Database for Penetration Testers, su versión "Volume 2" está bastante actualizada. Por otro lado allí podrá aprender la forma de combinar dichos operadores dependiendo del caso a tratar.

Le aseguro que no podrá volver al libro muchas veces, ya que pasará una gran cantidad de tiempo haciendo pruebas con el buscador entre un capítulo y otro, o mejor dicho, entre un párrafo y otro ;)

También es importante hacer notar que Google permanentemente hace esfuerzos por reducir la superficie de ataque proporcionada mediante los métodos de búsqueda avanzada y sus operadores por lo que algunos de los ejemplos del libro y del GHDB Central no son ya operativos. Claro aquí es donde su creatividad puede ser la diferencia.

Nota Importante: La información mostrada en el artículo se expone con fines estrictamente educacionales para ser utilizada como ayuda en la mejora de la seguridad de las aplicaciones web. No nos hacemos responsables del uso indebido de esta información por parte del lector.

El entrenamiento en seguridad web y lo que puede hacer por su empresa.

Para los negocios en línea, la seguridad es una parte vital en lo referente a la eficiencia y retorno de inversión de los mismos. Las aplicaciones web son las herramientas principales para las transacciones en línea, promoción de productos y servicios además de ser también las principales en presentar inconvenientes de seguridad que pudieran perjudicar a usted y a sus clientes a través de su aplicación. La capacitación de personal en el área de seguridad de aplicaciones web es definitivamente un valioso activo para las empresas. Proporcionar conocimientos básicos esenciales y la comprensión de las cuestiones de seguridad relacionadas, así como la capacitación práctica necesaria a su personal es actualmente imperativo. Este tipo de capacitación también ayuda al personal a entender y reconocer las posibles fallas de seguridad en sus negocios en tiempo real y por ende a evitar perjucios derivados.

¡Hacer las cosas bien antes desde el principio significa ahorrar dinero! 

La magnitud del riesgo actual es sin exageraciones demasiado alta para obviarla. Según fuentes de la industria, las aplicaciones web representan el 80% de las vulnerabilidades en línea. Su aplicación en línea puede tener cientos de vulnerabilidades latentes y por tanto una evaluación de riesgos al momento de la instalación de la misma es vital para el futuro de sus negocios en línea.

Aquí es donde la seguridad siempre es más eficaz, en la prevención de problemas antes de que sucedan. Pruebas exhaustivas y la comprobación de cada parte de su sistema para detectar las posibles deficiencias es parte primordial de una política preventiva. Los ahorros de costos pueden ser enormes. Infracciones o malas prácticas de seguridad pueden resultar en ataques tanto a las empresas en línea como a sus clientes, incurriendo en pérdidas financieras a veces muy graves. Y para añadir a los gastos, lo que usted no haya resuelto antes deberá resolverlo después, por tanto una política de prevención en el 80% de los casos significa un ahorro sin discusión.

Los problemas de seguridad en sus aplicaciones web son totalmente evitables. La mejor práctica es la prueba rigurosa y sistemática de todas las aplicaciones web antes de salir a la luz o entrer en línea de forma definitiva.

Piense en su aplicación web como en un buen submarino recién terminado: ¿Usted lo sumergiría a 5000 metros de profundidad sin haber hecho anteriormente una serie de pruebas de capacidad? Francamente no lo creo.

Tipos de entrenamiento necesarios:
La seguridad de aplicaciones web puede ser mucho más compleja de lo que parece por tanto existen varios tipos de entrenamiento dependiendo de las áreas en las que se desenvuelva el personal:

• Entrenamiento Básico:
  Es necesario para cualquier personal a cargo de las áreas de negocios en línea conocer los riesgos a los que están expuestos así como ciertos principios fundamentales en cuanto a seguridad de las aplicaciones en línea con las que tienen relación y con las que desempeñan su trabajo cotidiano. La idea es formar una cultura de seguridad en línea sólida que forme parte a su vez de la cultura empresarial.
  
• Entrenamiento Medio:
  Este es el que se brinda específicamente a las personas involucradas en las tomas de decisiones y que inciden en el tipo de aproximación al cliente y por tanto en el formato de las áreas de las aplicaciones en línea. Es importante que este personal esté al tanto de todos tipos de ataques que existen y cómo sus decisiones pudieran influir en que de una u otra forma estos tipos de ataque pudieran ser efectuados. Este entrenamiento debe convertirlos en conocedores de las posibles vulnerabilidades y las consecuencias que estas pudieran tener aunque no sean los encargados de corregirlas.
  
• Entrenamiento Avanzado:
  Definitivamente, es a la hora de producir código y diseñar los procesos de la aplicación cuando se comete la gran parte de los errores que dejan abiertas las puertas a futuras complicaciones. En este tipo de entrenamiento, que es el más largo y especializado el programador o desarrollador deberá reconocer las fallas a nivel de código, pero por supuesto además deberá entender cómo evitarlas. Este entrenamiento tiene dos fases: La primera se encarga de enseñar a detectar, evaluar y evitar las fallas en forma genérica, y la segunda se basa en aquellas fallas específicas que dependen de la plataforma en la cual han sido desarrolladas o se desarrollarán la aplicación o aplicaciones.

Es importante aclarar que todo el aprendizaje debe estar basado en estándares OWASP y WASC, para que de esta forma se le haga entrega al personal de las herramientas necesarias para a su vez transmitir a otros los conocimientos adquiridos y potenciar los conocimientos en seguridad web como parte del capital de conocimientos empresarial.

Hasta la próxima...