Una de las amenazas a las que hace pocos años no se les hizo mucho caso fue el Cross Site Request Forgery conocido por las siglas XSRF o CSRF. Ya hemos hablado de esta amenaza con anterioridad y si quieres conocer en detalle de qué se trata puedes acceder a este enlace.
Para resumirlo el CSRF utiliza la confianza que un sitio deposita en un usuario que ha validado correctamente su sesión, y mediante técnicas de engaño hace que el usuario sin saberlo trabaje en favor del atacante introduciendo en el sitio transacciones que redunden en beneficio de este último.
Todas las medidas de autentificación de usuarios a este punto ya han validado al usuario por lo que no sirven ya de nada para evitar el ataque. Un ejemplo podría darse en un sistema de banca en línea en el que el usuario ha accedido y mientras aún su sesión sigue activa el atacante logra mediante alguna treta que el usuario pulse por ejemplo un enlace como este:
https://mibanco.com/transferir.php?cuenta=NroCuentaDelAtacante&monto=1000
Algunas personas tienen la creencia de que este tipo de ataques solo puede ser ejecutado mediante el método GET, y siento decirles que por el método POST son inclusive mucho más efectivos. El ejemplo fue realizado con un enlace (GET) solo por fines didácticos.
Si bien el usuario ha validado su sesión, todos sus datos de verificación como por ejemplo su "cookie" de sesión serán enviados por el navegador a la aplicación del banco ya que este mantiene una sesión abierta con dicho sitio y esos datos son válidos. Esto sucede aunque el usuario haya pulsado el enlace desde otra página en el mismo navegador.
Es siempre importante educar al usuario acerca del hecho de que no debe desviar su atención y mantener la sesión con el sitio de su banco abierta mientras hace otras cosas. Sin embargo sabemos bien que cuando se trata de una cantidad grande de usuarios esto puede llegar a ser un trabajo enorme.
¿Cómo evitar entonces este problema a nivel de desarrollo?
Existen varias formas:
Doble-posted cookie (envío doble de cookie):
Esta técnica se basa en que si bien el navegador envía toda la información relacionada a la sesión, si agregamos un campo oculto a cada formulario con el valor del identificador de sesión, podremos evitar el ataque, ya que el atacante debe conocer este valor para incluirlo en el enlace o el formulario oculto en su página. El navegador no se lo proporcionará por las políticas de seguridad de dominios cruzados. Sin embargo aunque de forma más compleja el atacante podría robar el cookie de sesión mediante otras técnicas, por lo que este método no es el más confiable.
Unique form nonce (formulario único para cada solicitud):
Se trata de generar un formulario con un campo oculto dinámico que es generado por cada solicitud. El contenido del campo debe ser generado aletoriamente utilizando un buen sistema de PRNG (Pseudo Random Number Generator) para que no pueda ser adivinado mediante técnicas estadísticas avanzadas. Este campo se guardará en el servidor y será eliminado apenas el formulario sea utilizado ya que una nueva solicitud del formulario deberá ser acompañada por un nuevo contenido en el campo. Si se recibe un formulario con un contenido no válido, simplemente se rechaza la solicitud. Hay quienes han perfeccionado la técnica también asignando un nombre aleatorio al campo mediante el mismo concepto. Esta técnica es muy interesante ya que no solo elimina el XSRF sino evita que un usuario introduzca dos veces la misma transacción (lo que puede suceder facilmente si el usuario presiona el botón de enviar dos veces porque la conexión es lenta y no ha recibido la respuesta esperada). Además este sistema evita también que el formulario sea escaneado en busca de vulnerabilidades, ya que la gran mayoría de los "scanners" de vulnerabilidades, cargarán el formulario una sola vez para luego proceder a "jugar" con el contenido de los diferentes campos.
Requerir credenciales de autentificación nuevamente:
Es una interesante técnica que se basa en requerir nuevamente los datos de ingreso del usuario al momento de generar una transacción. Algunos sitios han inclusive generado lo que denominan "clave para transacciones" que no es más que un factor adicional de validación solicitado solamente en caso de generar un procedimiento que involucra movimiento de capital. La desventaja de este método es lo fastidioso que puede llegar a ser si se hacen muchas transacciones, o el problema que puede significar para el usuario recordar una nueva clave.
One time Passwords:
Un OTP o dispositivo que genera claves de acceso de un solo uso es una solución definitiva ante el XSRF y muchos otros problemas, sin embargo su costo es el principal factor a tomar en cuenta en estos casos. Este tipo de solución podría ser sobre-dimensionada dependiendo del tipo de aplicación y la cantidad de usuarios de la misma. Si necesitas saber algo más acerca de este tipo de componentes puedes visitar el artículo que trata acerca de este tema.
Espero que estas técnicas puedan ser tan útiles para ustedes como lo han sido para mí.
Hasta la próxima!
29 de abril de 2011
21 de abril de 2011
Protegiendo los formularios de autentificación e ingreso.
Los formularios de autentificación de usuarios son unas de las rutinas más atacadas de las aplicaciones web, debido a que ellos son los que separan a los atacantes de los que podríamos definir como el cofre al final del arcoiris. En los sitios web que utilizan formularios de autentificación basados en consultas SQL, varios tipos simples de "SQL injectión" pueden ser utilizados para eludir la validación del usuario. Por ejemplo, una consulta SQL típica para verificar dicha validación podría ser la siguiente:
SELECT * FROM users WHERE username = 'nombreUsuario' AND password = 'claveUsuario'
En esta consulta se reemplazarían a nivel de aplicación "nombreUsuario" y "claveUsuario" por los contenidos introducidos por el usuario en el formulario de validación y si una validación correcta de los parámetros ingresado no es efectuada, un atacante podría introducir en el primer campo la secuencia de caracteres "admin' --" (las comillas dobles son para efectos de redacción de este artículo, no las tome en cuenta). Lo anterior significaría que al reemplazar los valores la consulta resultante sería:
SELECT * FROM users WHERE username = 'admin' --AND password = 'cualquier cosa'
La consulta resultante sería realmente:
SELECT * FROM users WHERE username = 'admin'
Todo lo que se encontrara después de los dos guiones pasarían a ser simples partes de un comentario, por tanto la consulta devolvería los datos del usuario "admin" sin siquiera haber verificado la clave del mismo. Como se podrá observar esta es una consulta demasiado simple para necesitar herramientas automatizadas de pen-testing, y su principal error además de la falta de desinfección de parámetros es el uso común de un nombre de usuario como "admin" que de seguro se encuentra en absolutamente todas las listas de las herramientas de intrusión existentes.
Otro método un poco más elaborado se basa en introducir un condicional en el campo de la clave, en este caso introduciremos el código inyectado "' OR 1=1 --" (nuevamente no tome las comillas dobles en cuenta).
La consulta resultante esta vez sería:
SELECT * FROM users WHERE username = 'admin' AND password = 'cualquierCosa' OR 1=1 --'
La segunda parte de esta consulta preguntará a la maquinaria SQL si el password del usuario es correcto o si uno es igual a uno, y como basta que una de las dos sea cierta la sentencia devolverá nuevamente TRUE por lo que el resultado traerá nuevamente los datos del usuario sin verificar la clave.
Lo que importa realmente entender de los anteriores ejemplos son dos detalles importantes:
Los ataques de profundidad son aquellos que se realizan intentando ingresar con un mismo "login" o nombre de usuario y miles de diferentes posibles claves de acceso. Solo cuando se termina de comprobar la lista de claves de acceso se pasa entonces a otro nombre de usuario. Sin embargo los ataques de amplitud son aquellos en los que se utiliza una misma clave o password, para una lista de posibles usuario.
En base a lo anterior, un ataque de amplitud sería mucho más útil si ya conocemos una cantidad determinada de nombres de usuario, debido a que el atacante sabe sin duda alguna que estos no pueden repetirse bajo ningún concepto, sin embargo las claves de acceso si pueden ser iguales para usuarios diferentes, no existe ninguna regla que lo prohiba.
También hay formularios no validan contra una maquinaria SQL sino por ejemplo contra un servicio LDAP o archivos estaticos XML. En estos casos la diferencia no es tan notable, en vez de usar técnicas de "SQL injection" se utilizarán "LDAP injection" o "XPath injection", y aunque la sintaxis de la injección sea diferente los principios de defensa son exactamente los mismos. A saber:
Esperando que estos consejos le sean útiles me despido hasta la próxima...
SELECT * FROM users WHERE username = 'nombreUsuario' AND password = 'claveUsuario'
En esta consulta se reemplazarían a nivel de aplicación "nombreUsuario" y "claveUsuario" por los contenidos introducidos por el usuario en el formulario de validación y si una validación correcta de los parámetros ingresado no es efectuada, un atacante podría introducir en el primer campo la secuencia de caracteres "admin' --" (las comillas dobles son para efectos de redacción de este artículo, no las tome en cuenta). Lo anterior significaría que al reemplazar los valores la consulta resultante sería:
SELECT * FROM users WHERE username = 'admin' --AND password = 'cualquier cosa'
La consulta resultante sería realmente:
SELECT * FROM users WHERE username = 'admin'
Todo lo que se encontrara después de los dos guiones pasarían a ser simples partes de un comentario, por tanto la consulta devolvería los datos del usuario "admin" sin siquiera haber verificado la clave del mismo. Como se podrá observar esta es una consulta demasiado simple para necesitar herramientas automatizadas de pen-testing, y su principal error además de la falta de desinfección de parámetros es el uso común de un nombre de usuario como "admin" que de seguro se encuentra en absolutamente todas las listas de las herramientas de intrusión existentes.
Otro método un poco más elaborado se basa en introducir un condicional en el campo de la clave, en este caso introduciremos el código inyectado "' OR 1=1 --" (nuevamente no tome las comillas dobles en cuenta).
La consulta resultante esta vez sería:
SELECT * FROM users WHERE username = 'admin' AND password = 'cualquierCosa' OR 1=1 --'
La segunda parte de esta consulta preguntará a la maquinaria SQL si el password del usuario es correcto o si uno es igual a uno, y como basta que una de las dos sea cierta la sentencia devolverá nuevamente TRUE por lo que el resultado traerá nuevamente los datos del usuario sin verificar la clave.
Lo que importa realmente entender de los anteriores ejemplos son dos detalles importantes:
- Todos lo campos deben ser desinfectados. Existe la absurda creencia de que el único campo vulnerable es el que contiene la clave del usuario, y como se ha podido observar se puede iniciar la inyección de código desde el primer campo de una forma ridículamente simple.
- No solo es necesario proteger la clave de los usuarios, el hecho de que el identificador comúnmente conocido como nombre o "login" pueda ser obtenido, es una vulnerabilidad en si misma. Esto sucede principalmente por devolver respuestas inadecuadas a la hora de un ingreso erróneo en el formulario de acceso.
- "Error de ingreso: la clave proporcionada no es correcta", en este caso si la clave no es correcta entonces debe ser que el usuario si lo es.
- "Error de ingreso: El nombre de usuario proporcionado no existe!", y en este otro caso se despeja la duda, este usuario en realidad no existe.
- "Error de ingreso: La combinación de usuario y clave proporcionados no es válida" o algo parecido que no indique a ciencia cierta cual de los dos campos es el incorrecto o si ambos lo son.
Los ataques de profundidad son aquellos que se realizan intentando ingresar con un mismo "login" o nombre de usuario y miles de diferentes posibles claves de acceso. Solo cuando se termina de comprobar la lista de claves de acceso se pasa entonces a otro nombre de usuario. Sin embargo los ataques de amplitud son aquellos en los que se utiliza una misma clave o password, para una lista de posibles usuario.
En base a lo anterior, un ataque de amplitud sería mucho más útil si ya conocemos una cantidad determinada de nombres de usuario, debido a que el atacante sabe sin duda alguna que estos no pueden repetirse bajo ningún concepto, sin embargo las claves de acceso si pueden ser iguales para usuarios diferentes, no existe ninguna regla que lo prohiba.
También hay formularios no validan contra una maquinaria SQL sino por ejemplo contra un servicio LDAP o archivos estaticos XML. En estos casos la diferencia no es tan notable, en vez de usar técnicas de "SQL injection" se utilizarán "LDAP injection" o "XPath injection", y aunque la sintaxis de la injección sea diferente los principios de defensa son exactamente los mismos. A saber:
- Desinfectar los datos recibidos por parte del usuario.
- Proteger los "logins" o nombres de usuario, mediante respuestas de error que no aseguren nada. Este punto es válido también para los sistemas derecuperación de clave, que suelen ser uno de los primeros agujeros por donde obtener usuarios válidos.
- Utilizar sistemas de bloqueo de acceso con máximo de intentos. Estos deben ser procedimientos del lado del servidor. El bloqueo mediante "cookies" no es útil cuando los formularios son forjados o el ataque proviene de una herramienta de ingreso por fuerza bruta.
Esperando que estos consejos le sean útiles me despido hasta la próxima...
17 de abril de 2011
Mejorando la seguridad del Internet Information Server (IIS).
Consejos para mejorar la seguridad del Internet Information Service (IIS)
Una programación segura es muy importante, pero no podemos olvidar la plataforma del servidor en la que la aplicación reside, empezando por el sistema operativo y llegando hasta el software encargado de prestar el servicio HTTP, por lo que ciertos consejos de seguridad en lo referente a este último nunca deben despreciarse. Sin embargo debido a los diferentes tipos de servidores web y sistemas operativos, estos consejos pueden variar sustancialmente aunque los principios de protección sean los mismos.
En este artículo especialmente vamos a centrar nuestra atención en el Internet Information Service conocido comúnmente como IIS, que es la plataforma que ofrece Microsoft para sus servidores Windows 2000, 2003 y 2008.
IIS es una plataforma mixta de servicios web (HTTP/HTTPS, FTP, SMTP y NNTP) y las versiones con las que comunmente podemos conseguirnos son la 5, 6, 7 y 7.5. Sin embargo si usted actualmente tiene algún tipo de servicio en la primera de estas (versión 5) o anteriores, el mejor consejo que podría darle es que trate de mudar sus aplicaciones a cualquiera de las versiones superiores.
Entrando en materia a continuación mostraremos una lista de acciones o consejos que aumentarán la seguridad de este tipo de plataformas:
Reduzca la superficie de ataque apagando o eliminando los servicios que no necesita.
Ya que el IIS es una plataforma de servicios múltiples lo primero que debe hacer es reducir radicalmente la superficie de ataque apagando o eliminando los servicios de dicha plataforma que no se utilizan. Es muy sabido que un servidor SMTP mal configurado puede dedicar la mayor parte de los servicios de su sistema operativo a enviar SPAM. Tener un servicio FTP activo permanentemente es una brecha por la cual el atacante podría introducir sus scripts malignos en nuestra web. Y ni hablar del NNTP!
Desactive la opción de mensajes de error detallados.
Si bien en el ambiente de desarrollo esta opción es de gran ayuda, mantenerla activa solo sirve para que un atacante intente generar errores que le entreguen información adicional y le descubran algún dato que abra la brecha de seguridad esperada. Para información acerca de cómo desactivar esta opción en ASP.NET puede visitar este enlace. También puede manejar sus errores de forma dinámica, es decir haciendo que la página de especial de error que usted cree sea también una página dinámica que reporte el error a una base de datos o un archivo de registros personal, así como que envíe un e-mail dependiendo del tipo de error. Algunos ejemplos puede encontrarlos aquí.
Instale sus directorios de aplicación web en una unidad diferente a la unidad que aloja el sistema operativo.
En caso de que un atacante pudiera obtener acceso a la unidad en la que usted aloja su aplicación, usted agradecerá sobremanera que este no tenga a mano utilidades importantes del sistema operativo como cmd.exe y otros igualmente poderosos.
Remueva el mapeo de extensiones no utilizadas.
Su servidor probablemente pueda y esté listo para resolver el mapeo de extensiones asp, php, cgi y otras dependiendo de los diferentes módulos CGI o librerías ISAPI instaladas. Nuevamente, si usted no necesita ejecutar ASP clásico o PHP simplemente deshabilite este tipo de extensiones.
Use URLScan.
URLscan es un módulo que permite filtrar direcciones URL con determinadas características que pudieran considerarse como intentos de ataque. Inclusive actúa como una especie de firewall de aplicación que puede evitar una gran parte de los problemas. Sin embargo recuerde: la mejor manera de eliminar una brecha de seguridad en su aplicación es corregirla en el código en la que se origina. Descargue el URLscan aquí
Siempre utilice el sistema de archivos NTFS para las unidades en las que debe alojar sus aplicaciones.
El problema con los sistemas de archivo FAT y FAT32 es que no utilizan un sistema de control de acceso lo suficientemente cerrado como para alojar aplicaciones web en las que los recursos deban restringirse de forma eficiente o variadas. El sistema ACL de NTFS es muy superior y por tanto mucho más seguro.
Mantenga los archivos de registro de sus servicios web fuera del directorio de su aplicación.
Por defecto los archivos de registro se encuentran en el directorio "c:\windows\system32\logs" lo cual es perfecto, pero algunos administradores los ubican en otros directorios para evitar que los programadores u otros usuarios que los necesiten tengan acceso a un directorio tan crítico como este. La idea no es mala, pero tampoco se deben ubicar bajo el directorio web de nuestra aplicación. Los archivos de registros de IIS como en cualquier otro sistema, tienen un formato de nombre preestablecido, por lo que son muy fáciles de ubicar una vez conseguido un directorio "logs", "weblogs" o algo parecido mediante el uso de un scanner de rutas y archivos como por ejemplo OWASP Dirbuster. Usted no querrá que el atacante pueda obtener información detallada de la ubicación de los recursos simplemente bajando a su equipo uno de estos archivos.
Renombre, borre o restrinja el acceso a cualquier utilidad potencialmente peligrosa.
Quizás por esto es que principalmente hay que colocar la aplicación en una unidad diferente a la del sistema operativo. Sin embargo si en la unidad en la que está ubicada la aplicación usted encuentra alguna aplicación potencialmente peligrosa trate de eliminarla, restringir el acceso a la misma o renombrarla.
Desative el usuario "guest" y elimine el acceso de usuarios del grupo "guests" a áreas fuera de su directorio principal de IIS (webroot).
Usuarios como IUSR_machinename e IWAM_machinename pertenecientes al grupo "guests" no deben tener acceso a ninguna otra parte que no sea el directorio de la aplicación web. Tampoco deben tener atributos de escritura o ejecución en ninguna carpeta de sus aplicación. Utilidades para subir archivos necesitan a veces atributos de escritura en algún directorio, y si no puede evitar usar este tipo de componentes arcaicos, pues almenos en las propiedades del directorio seleccionado elimine todo tipo de permisos de ejecución de secuencias de comandos y archivos ejecutables.
Utilice si es posible los módulos de Restricción dinámica de IPs.
Este módulo relativamente nuevo, le permitira defenderse de ataques de DoS limitando las solicitudes múltiples de ciertas características que las pudieran identificar como intentos de DoS. Lo único malo de este módulo es que solo está disponible para IIS 7.0 y 7.5 - http://www.iis.net/download/dynamiciprestrictions.
Hasta la próxima...
Una programación segura es muy importante, pero no podemos olvidar la plataforma del servidor en la que la aplicación reside, empezando por el sistema operativo y llegando hasta el software encargado de prestar el servicio HTTP, por lo que ciertos consejos de seguridad en lo referente a este último nunca deben despreciarse. Sin embargo debido a los diferentes tipos de servidores web y sistemas operativos, estos consejos pueden variar sustancialmente aunque los principios de protección sean los mismos.
IIS es una plataforma mixta de servicios web (HTTP/HTTPS, FTP, SMTP y NNTP) y las versiones con las que comunmente podemos conseguirnos son la 5, 6, 7 y 7.5. Sin embargo si usted actualmente tiene algún tipo de servicio en la primera de estas (versión 5) o anteriores, el mejor consejo que podría darle es que trate de mudar sus aplicaciones a cualquiera de las versiones superiores.
Entrando en materia a continuación mostraremos una lista de acciones o consejos que aumentarán la seguridad de este tipo de plataformas:
Reduzca la superficie de ataque apagando o eliminando los servicios que no necesita.
Ya que el IIS es una plataforma de servicios múltiples lo primero que debe hacer es reducir radicalmente la superficie de ataque apagando o eliminando los servicios de dicha plataforma que no se utilizan. Es muy sabido que un servidor SMTP mal configurado puede dedicar la mayor parte de los servicios de su sistema operativo a enviar SPAM. Tener un servicio FTP activo permanentemente es una brecha por la cual el atacante podría introducir sus scripts malignos en nuestra web. Y ni hablar del NNTP!
Desactive la opción de mensajes de error detallados.
Si bien en el ambiente de desarrollo esta opción es de gran ayuda, mantenerla activa solo sirve para que un atacante intente generar errores que le entreguen información adicional y le descubran algún dato que abra la brecha de seguridad esperada. Para información acerca de cómo desactivar esta opción en ASP.NET puede visitar este enlace. También puede manejar sus errores de forma dinámica, es decir haciendo que la página de especial de error que usted cree sea también una página dinámica que reporte el error a una base de datos o un archivo de registros personal, así como que envíe un e-mail dependiendo del tipo de error. Algunos ejemplos puede encontrarlos aquí.
Instale sus directorios de aplicación web en una unidad diferente a la unidad que aloja el sistema operativo.
En caso de que un atacante pudiera obtener acceso a la unidad en la que usted aloja su aplicación, usted agradecerá sobremanera que este no tenga a mano utilidades importantes del sistema operativo como cmd.exe y otros igualmente poderosos.
Remueva el mapeo de extensiones no utilizadas.
Su servidor probablemente pueda y esté listo para resolver el mapeo de extensiones asp, php, cgi y otras dependiendo de los diferentes módulos CGI o librerías ISAPI instaladas. Nuevamente, si usted no necesita ejecutar ASP clásico o PHP simplemente deshabilite este tipo de extensiones.
Use URLScan.
URLscan es un módulo que permite filtrar direcciones URL con determinadas características que pudieran considerarse como intentos de ataque. Inclusive actúa como una especie de firewall de aplicación que puede evitar una gran parte de los problemas. Sin embargo recuerde: la mejor manera de eliminar una brecha de seguridad en su aplicación es corregirla en el código en la que se origina. Descargue el URLscan aquí
Siempre utilice el sistema de archivos NTFS para las unidades en las que debe alojar sus aplicaciones.
El problema con los sistemas de archivo FAT y FAT32 es que no utilizan un sistema de control de acceso lo suficientemente cerrado como para alojar aplicaciones web en las que los recursos deban restringirse de forma eficiente o variadas. El sistema ACL de NTFS es muy superior y por tanto mucho más seguro.
Mantenga los archivos de registro de sus servicios web fuera del directorio de su aplicación.
Por defecto los archivos de registro se encuentran en el directorio "c:\windows\system32\logs" lo cual es perfecto, pero algunos administradores los ubican en otros directorios para evitar que los programadores u otros usuarios que los necesiten tengan acceso a un directorio tan crítico como este. La idea no es mala, pero tampoco se deben ubicar bajo el directorio web de nuestra aplicación. Los archivos de registros de IIS como en cualquier otro sistema, tienen un formato de nombre preestablecido, por lo que son muy fáciles de ubicar una vez conseguido un directorio "logs", "weblogs" o algo parecido mediante el uso de un scanner de rutas y archivos como por ejemplo OWASP Dirbuster. Usted no querrá que el atacante pueda obtener información detallada de la ubicación de los recursos simplemente bajando a su equipo uno de estos archivos.
Renombre, borre o restrinja el acceso a cualquier utilidad potencialmente peligrosa.
Quizás por esto es que principalmente hay que colocar la aplicación en una unidad diferente a la del sistema operativo. Sin embargo si en la unidad en la que está ubicada la aplicación usted encuentra alguna aplicación potencialmente peligrosa trate de eliminarla, restringir el acceso a la misma o renombrarla.
Desative el usuario "guest" y elimine el acceso de usuarios del grupo "guests" a áreas fuera de su directorio principal de IIS (webroot).
Usuarios como IUSR_machinename e IWAM_machinename pertenecientes al grupo "guests" no deben tener acceso a ninguna otra parte que no sea el directorio de la aplicación web. Tampoco deben tener atributos de escritura o ejecución en ninguna carpeta de sus aplicación. Utilidades para subir archivos necesitan a veces atributos de escritura en algún directorio, y si no puede evitar usar este tipo de componentes arcaicos, pues almenos en las propiedades del directorio seleccionado elimine todo tipo de permisos de ejecución de secuencias de comandos y archivos ejecutables.
Utilice si es posible los módulos de Restricción dinámica de IPs.
Este módulo relativamente nuevo, le permitira defenderse de ataques de DoS limitando las solicitudes múltiples de ciertas características que las pudieran identificar como intentos de DoS. Lo único malo de este módulo es que solo está disponible para IIS 7.0 y 7.5 - http://www.iis.net/download/dynamiciprestrictions.
Hasta la próxima...
8 de abril de 2011
SHODAN - Buscador de servicios y servidores
Hoy estaba revisando literatura vieja y me encontré con un enlace muy interesante que quise comprobar si aún estaba activo, y mi sorpresa fue mayúscula al ver cómo esa aplicación o mejor dicho herramienta web ha progresado desde que dejé de usarla.
Como debiéramos saber, una de las primeras cosas que necesita saber el atacante de nuestra aplicación son:
Como debiéramos saber, una de las primeras cosas que necesita saber el atacante de nuestra aplicación son:
- La plataforma y versión de nuestro sistema operativo.
- Tipo de servidor web.
- Plataforma de desarrollo.
Conocer esta información a veces suele ser muy fácil debido a que una buena parte se puede deducir por el contenido de los headers HTTP que recibimos del servidor cuando solicitamos una página o recurso al mismo.
Por cierto, algo de esa información se puede eliminar para hacerle el trabajo más difícil al atacante. Por ejemplo en el IIS el "header" incluye siempre por defecto "X-Powered-by: ASP.NET" o algo parecido dependiendo de la versión, pero eso podemos eliminarlo simplemente modificando en la opción de encabezados HTTP del sitio web. Podemos cambiarlo a gusto, ya que no es para nada relevante en cuanto al funcionamiento del sitio.
Volviendo al tema: ¿Pero y si lo que queremos es encontrar servidores dentro de un rango específico que muestren una característica dada? pues entonces aparece la utilidad de la que les venía hablando: SHODAN
No solo busca servidores por características sino por regiones geográficas y tipo de puerto. En fin que SHODAN es algo así como un "escanner" de puertos a nivel mundial.
Aquí les dejo un pantallazo para que se den una idea:
Por ejemplo se puede hacer una búsqueda de todos los servidores Apache bajo Ubuntu en Suiza. ¿Interesante? Es una herramienta muy potente y tiene muchos otros plugins y ventajas para algunas de las cuales necesitarás comprar créditos. Sin embargo las consultas básicas son gratis.
Los reportes son muy completos e interesantes, ya que incluyen la respuesta de los encabezados comunes de los servidores que cumplen con la consulta. ¡Disfrútenlo!
Hasta la próxima...
5 de abril de 2011
Razones por las que no se eliminan las vulnerabilidades en las aplicaciones web.
El reciente estudio publicado por WhiteHat Security denominado Winter 2011, 11th Edition, nos ofrece entre muchos otros datos interesantes tomados de un estudio estadístico tomado de 3,000 websites a través de 400 organizaciones, el resultado de las razones por las cuales las vulnerabilidades de los sitios de dicho estudio no fueron corregidas a tiempo.
A continuación me permito traducirlas para ustedes para que puedan comentarlas y estudiarlas:
Factores que inhiben a las organizaciones a remediar las vulnerabilidades de sus aplicaciones web:
A continuación me permito traducirlas para ustedes para que puedan comentarlas y estudiarlas:
Factores que inhiben a las organizaciones a remediar las vulnerabilidades de sus aplicaciones web:
- Nadie en la organización entiende o es responsable de mantener el código.
- Nadie en la organización conoce o entiende los aspectos de la vulnerabilidad.
- Mejoras en las características de la aplicación se priorizan por delante de los parches de seguridad.
- Falta de presupuesto para solucionar los problemas.
- El código afectado es propiedad de un tercero que no responde.
- Sitio web será dado de baja o sustituido "pronto ". Es necesario acotar, que algunos de los sitos que presentaron esta razón se mantuvieron en línea por más de dos años.
- El riesgo de la explotación de la vulnerabilidad es aceptado.
- Solución de la vulnerabilidad entra en conflicto con negocios en proceso.
- El cumplimiento de las normas vigentes no requiere la eliminación de la vulnerabilidad.
Es muy probable que ustedes hayan usado o escuchado estas razones en más de una ocasión. Lo que definitivamente es cierto es que el estudio también refleja en una de sus lecciones lo siguiente:
La explotación de una sola vulnerabilidad en una aplicación web es suficiente para perturbar de manera significativa la línea de negocios, causar la pérdida de datos, sacudir la confianza del cliente, y mucho más. Por lo tanto, las vulnerabilidades mientras antes se identifiquen y más rápido que se eliminen más corta será la ventana de oportunidad para que un atacante malicioso pueda explotarlas.
Hasta la próxima...
1 de abril de 2011
¿Porqué atacan a las aplicaciones web?
Las motivaciones para el hacking de aplicaciones web son numerosas y se han discutido en profundidad durante muchos años en una variedad de foros. No vamos hacer un refrito de muchas de esas conversaciones, pero es importante señalar algunas de las características de las aplicaciones web que las hacen tan atractivas para los atacantes. La comprensión de estos factores conducirá a una perspectiva mucho más clara de las defensas que deben ser adoptadas para mitigar el riesgo.
Ubicuidad:
Las aplicaciones web están en casi todas partes hoy en día y siguen extendiéndose rápidamente a través de redes públicas y privadas. Para los hackers de aplicaciones web la probabilidad de encontrar una aplicación "jugosa" y vulnerable es cada vez mayor.
Técnicas simples de ataque:
Las técnicas de ataque de aplicaciones web son bastante fáciles de entender, incluso para los legos, ya que son en su mayoría basadas en texto. Esto hace que la manipulación de datos de entrada de la aplicación sea realtivamente trivial. En comparación con los conocimientos necesarios para atacar aplicaciones más complejas o sistemas operativos (por ejemplo, la elaboración de desbordamientos de buffer), atacar aplicaciones web es como quitarle un dulce un niño.
Anonimato:
El Internet todavía tiene muchas regiones no catalogadas o auditadas, y es bastante fácil para lanzar ataques con poco o sin temor de ser rastreado. El rastro del Web Hacking, en particular, es de fácil lavado (y a menudo sin darse cuenta) a través de proxys HTTP/S que son abundantes en la Red. Hackers sofisticados enrutan cada solicitud a través de un proxy diferente para hacer las cosas aún más difíciles de rastrear. Sin duda, ésta sigue siendo la razón principal para la proliferación del hacking malicioso, ya que el anonimato protege al atacante de uno de los principales factores de disuasión en el mundo físico (es decir, ser atrapado y castigado).
Incapacidad de los Firewalls:
El HTTP/S entrante (puertos 80 y 443) es permitido por todos los cortafuegos o firewalls. Está de más decir que esta no es una vulnerabilidad de los mismos, sino un comportamiento necesario para poder recibir las solicitudes de los navegadores clientes. Inclusive esto seguirá sucediendo a pesar de que cada vez más aplicaciones emigren a la Web.
Código personalizado:
Con la proliferación de plataformas para facilitar el desarrollo web como ASP.NET y LAMP (Linux / Apache / MySQL / PHP), una gran parte de las aplicaciones web son ensambladas por desarrolladores que tienen poca o ninguna experiencia previa en seguridad de aplicaciones.
Seguridad inmadura:
HTTP ni siquiera pone en práctica control desesiones para reconocer usuarios únicos. La autenticación básica y la autorización de principal para HTTP fue adosada en años posteriores a que la tecnología se popularizara y aún sigue evolucionando en nuestros días. Muchos desarrolladores generan código propio de control de sesiones y autorización y logicamente muchos también se equivocan (aunque esto está cambiando con el creciente despliegue de plataformas de desarrollo web que incorporan procesos de gestión de sesiones y autorización nativos.
Cambio constante:
Por lo general, un montón de gente constantemente manipula una aplicación web: desarrolladores, administradores de sistemas y gestores de contenidos de todo tipo. ¡Hemos visto muchas empresas donde el equipo de marketing tiene acceso directo a la granja de servidores web de producción! Muy pocas de estas personas tienen la formación adecuada seguridad y sin embargo, están facultados para realizar cambios en un complejo entorno de aplicaciones web de forma constante. En este nivel de dinamismo, es difícil llevar un control de cambios sencillo, y mucho menos garantizar que la política seguridad se aplique de manera coherente.
...y por supuesto: Dinero.
A pesar de los contratiempos de la era punto-com, está claro que el comercio electrónico a través de HTTP apoyará muchos negocios lucrativos en un futuro previsible. Como era de esperar, las estadísticas recientes indican que la motivación para la piratería informática web ha pasado de la fama a la fortuna, en paralelo con la maduración de la propia web. Cada vez más, las autoridades están descubriendo empresas delictivas organizadas construidas sobre el hacking de aplicaciones web con fines de lucro. Ya sea de forma particular mediante robos de datos a los servidores web, el fraude contra los usuarios finales (también conocido como "phishing"), o la extorsión mediante la denegación de servicio, el hecho lamentable de la situación actual es que el crimen web paga bien.
Hasta la próxima!
Ubicuidad:
Las aplicaciones web están en casi todas partes hoy en día y siguen extendiéndose rápidamente a través de redes públicas y privadas. Para los hackers de aplicaciones web la probabilidad de encontrar una aplicación "jugosa" y vulnerable es cada vez mayor.
Técnicas simples de ataque:
Las técnicas de ataque de aplicaciones web son bastante fáciles de entender, incluso para los legos, ya que son en su mayoría basadas en texto. Esto hace que la manipulación de datos de entrada de la aplicación sea realtivamente trivial. En comparación con los conocimientos necesarios para atacar aplicaciones más complejas o sistemas operativos (por ejemplo, la elaboración de desbordamientos de buffer), atacar aplicaciones web es como quitarle un dulce un niño.
Anonimato:
El Internet todavía tiene muchas regiones no catalogadas o auditadas, y es bastante fácil para lanzar ataques con poco o sin temor de ser rastreado. El rastro del Web Hacking, en particular, es de fácil lavado (y a menudo sin darse cuenta) a través de proxys HTTP/S que son abundantes en la Red. Hackers sofisticados enrutan cada solicitud a través de un proxy diferente para hacer las cosas aún más difíciles de rastrear. Sin duda, ésta sigue siendo la razón principal para la proliferación del hacking malicioso, ya que el anonimato protege al atacante de uno de los principales factores de disuasión en el mundo físico (es decir, ser atrapado y castigado).
Incapacidad de los Firewalls:
El HTTP/S entrante (puertos 80 y 443) es permitido por todos los cortafuegos o firewalls. Está de más decir que esta no es una vulnerabilidad de los mismos, sino un comportamiento necesario para poder recibir las solicitudes de los navegadores clientes. Inclusive esto seguirá sucediendo a pesar de que cada vez más aplicaciones emigren a la Web.
Código personalizado:
Con la proliferación de plataformas para facilitar el desarrollo web como ASP.NET y LAMP (Linux / Apache / MySQL / PHP), una gran parte de las aplicaciones web son ensambladas por desarrolladores que tienen poca o ninguna experiencia previa en seguridad de aplicaciones.
Seguridad inmadura:
HTTP ni siquiera pone en práctica control desesiones para reconocer usuarios únicos. La autenticación básica y la autorización de principal para HTTP fue adosada en años posteriores a que la tecnología se popularizara y aún sigue evolucionando en nuestros días. Muchos desarrolladores generan código propio de control de sesiones y autorización y logicamente muchos también se equivocan (aunque esto está cambiando con el creciente despliegue de plataformas de desarrollo web que incorporan procesos de gestión de sesiones y autorización nativos.
Cambio constante:
Por lo general, un montón de gente constantemente manipula una aplicación web: desarrolladores, administradores de sistemas y gestores de contenidos de todo tipo. ¡Hemos visto muchas empresas donde el equipo de marketing tiene acceso directo a la granja de servidores web de producción! Muy pocas de estas personas tienen la formación adecuada seguridad y sin embargo, están facultados para realizar cambios en un complejo entorno de aplicaciones web de forma constante. En este nivel de dinamismo, es difícil llevar un control de cambios sencillo, y mucho menos garantizar que la política seguridad se aplique de manera coherente.
...y por supuesto: Dinero.
A pesar de los contratiempos de la era punto-com, está claro que el comercio electrónico a través de HTTP apoyará muchos negocios lucrativos en un futuro previsible. Como era de esperar, las estadísticas recientes indican que la motivación para la piratería informática web ha pasado de la fama a la fortuna, en paralelo con la maduración de la propia web. Cada vez más, las autoridades están descubriendo empresas delictivas organizadas construidas sobre el hacking de aplicaciones web con fines de lucro. Ya sea de forma particular mediante robos de datos a los servidores web, el fraude contra los usuarios finales (también conocido como "phishing"), o la extorsión mediante la denegación de servicio, el hecho lamentable de la situación actual es que el crimen web paga bien.
Hasta la próxima!
Suscribirse a:
Entradas (Atom)
Suscribirse a
Entradas
Todos los comentarios