Volvemos nuevamente con una entrada de la serie #MundoHacker, destinada a ofrecer un acercamiento a los principales vectores de ataque informático, esta vez centrada en profundizar en la seguridad web.
¿Y qué mejor manera de aprender que con una colección de ejercicios de exploits con solución incluida?
PentesterLab es un proyecto destinado al aprendizaje de técnicas de intrusión y exploits web en diferentes plataformas y ecosistemas, y que recientemente ha incluido en su haber una muy jugosa colección de ejercicios para principiantes que vienen como anillo al dedo para nosotros los desarrolladores para entender qué debemos hacer y qué no a la hora de segurizar una web.
En Web For Pentester (ya no disponible, lo siento) encontraréis la descarga de un archivo .ISO que contiene el desarrollo de una web de ejercicios bajo Debian. Así mismo, tenéis a vuestra disposición un PDF con la documentación y explicación de cada exploits, aunque éste último recomiendan usarlo únicamente después de haberte peleado un tiempo con cada problema.
El PDF contiene información realmente interesante para conocer de primera mano, con ejemplos reales, las técnicas de intrusión usadas para atacar webs, y que a continuación resumiré brevemente.
¿Te preocupa tu Seguridad y Privacidad Online?
He diseñado este curso online en 8 módulos en el que cubriremos todos los fundamentos de la ciberseguridad, ayudándote paso por paso a configurar la seguridad y privacidad de tus cuentas digitales y de tus dispositivos.
Índice de contenido
Ataques XSS o cross-site scripting
En español tendría un nombre parecido a Secuencia de comandos en sitios cruzados (ahí es nada…), y viene a definir uno de los ataques más comunes, que busca vulnerabilidades que permitan ejecutar código JavaScript (principalmente, aunque podría tratarse de cualquier lenguaje de cliente).
Este tipo de ataques los vemos tanto en webs como aplicaciones locales, y muchas veces en el propio navegador, que queda abierto para el robo de credenciales de acceso y demás información confidencial (historial de navegación, cookies,…).
Existen dos métodos de ataques XSS,
- Directo o persistente: consiste en embeber código en algún sitio de la web (formularios, comentarios,…) que permita a a su vez ejecutar código. Se ve mucho con etiquetas HTML en comentarios (que normalmente están permitidas), y que estas a su vez ejecutan comandos Java.
- Indirecto o reflejado: Normalmente se usa la misma URL para inyectar un frame, de tal forma que una web del tipo www.example.com/home.asp?frame=menu.asp, podría ser vulnerable al inyectarle en el frame código ajeno. Se usa sobre todo para casos de Phishing (entras en una web, pero en verdad te están redirigiendo a otra).
Paradójicamente, tenéis un tutorial muy sencillo de entender sobre estos exploits en la Wikipedia.
RFI o inclusión remota de archivos
Poco hay que decir sobre este ataque. Se puede llevar a cabo en aquellas webs que permiten la subida de archivos. Es quizás la vulnerabilidad más sonada de PHP (en ASP no se puede dar ya que no contempla funciones de inclusión), y se basa en aprovecharse del potencial de include() para enlazar contenido alojado fuera del servidor en el propio dominio.
La forma de defenderse es realmente sencilla, y puesto que se aprovecha de una familia de funciones, basta con restringir su uso al estrictamente necesario, mediante la validación de la variable enviada como parámetro (URL o formatos permitidos).
De nuevo os dejo la explicación de la Wikipedia.
Ataques LDAP
Alguien te dice LDAP y te quedas a cuadro. Pero seguramente si os hablo de Active Directory, ya vais entendiendo por donde van los tiros. El Active directory es el LDAP que usa Windows (a groso modo, no me matéis todavía), es decir, el encargado de las listas de acceso de un dominio o red determinado.
Un ataque de este tipo lo que busca es hacerse con el control del sistema de validación de usuarios, de tal forma que así podremos crear o modificar los usuarios de una web, y acceder a contenido que de base estaba oculto mediante permisos.
Para ello, se suele usar la picaresca (como ya hemos explicado en la entrada sobre SQL injection), forzando al servidor a devolvernos la contraseña de un usuario al incluir el usuario.string nombre = Request.Querystring("nombre")
String ldapSearchQuery = "(cn=nombre)(|(password=*))
A esto únele una biblioteca de nombres, un poco de tiempo, y ya tienes un script para acceder a foros muy concurridos.
La forma de defenderse pasa por validar (de cara al servidor, por favor, no uséis JavaScript) cada parámetro de entrada (vamos, lo mismo que en SQL injection, pero en vez de con SQL, con el LDAP que estemos usando).
Tenéis un tutorial muy completo (5 entradas) en el blog de Chema Alonso.
SQL injection
Son ataques hacia una base de datos SQL. Ya he dedicado una entrada completa a este tipo de ataques (debido principalmente a que son de los exploits más usados), por lo que doy por zanjado el tema.
Code injection
Hablamos normalmente de SQL injection, por ser lo más habitual, pero en la práctica se podría aprovechar cualquier vulnerabilidad para inyectar código, sea del lenguaje que sea (siempre y cuando el servidor lo contemple).
Debido a que crear medidas contra todos y cada uno de los lenguajes habidos y por haber es una locura, la mejor defensa contra inyecciones de código es tener la plataforma en la que se ha desarrollado actualizada (muy atentos sobre todo a plataformas open source como los típicos CMS que todos usamos, y que debido a ello, son las más atacadas).
La mayoría de actualizaciones menores de servicios como WordPress, Joomla y compañía vienen a solucionar vulnerabilidades 0-day, así que ya sabéis.
File upload
Se parece bastante al RFI, aunque en este caso afectaría a cualquier plataforma de subida de archivos, ya que usa como método de entrada hacerse con el control de la shell que lo gobierna.
Os dejo con un vídeo donde se ve en funcionamiento el ataque:
Seguramente en este punto ya os habréis dado cuenta que la mejor forma de defenderse de exploits basados en ataques file upload es restringiendo la ejecución en la carpeta de destino de las aplicaciones, así como el control de la extensión o el tamaño.
Directory traversal o ataque punto punto barra (../)
Este ataque no se aprovecha de un bug de la aplicación, sino que directamente fuerza a casos extremos que no están contemplados en el código.
Se trata de navegar entre directorios, aprovechándose de la falta de restricción de los usuarios, de tal forma que si una dirección es del tipo www.web.com/pages/category/seguridad.php, podríamos lanzar un script que navegase entre los directorios hacia atrás hasta llegar al directorio raiz (normalmente de linux), y luego hacia el archivo de contraseñas.GET /vulnerable.php HTTP/1.0
Cookie: TEMPLATE=../../../../../../../../../etc/passwd
La solución pasa por restringir el acceso a directorios superiores a todo usuario (no lo necesitan para nada). Afortunadamente, la mayoría de servidores ya vienen con una configuración inicial correcta.
Tenéis el enlace al tutorial de estos exploits en la Wikipedia.
Command injection
Se trata de un ataque muy parecido a code injection, ya que parte de distinta metodología para acabar obteniendo lo mismo. En code injection, el atacante intenta inyectar código que se ejecutará con la aplicación, mientras que en command injection, el código no pertenece a la aplicación y no tiene porqué ejecutarse a la vez.
Tenéis un pequeño ejemplo en el siguiente PDF, además de numerosos ejemplos de algunos de los vectores de ataque que ya hemos comentado.
Ataques XML
Sobre XML ya hemos hablado hace tiempo, por lo que no entraré en más detalles. XML no es el problema, ya que solo sirve para el intercambio de información. Las vulnerabilidades vienen entonces de la mano de los parseadores de XML, y que con algo de conocimiento, se pueden atacar, modificando por tanto el contenido (que puede ser un simple párrafo, como una contraseña o un número de cuenta).
Debido a que XML es hoy en día un estandar de intercambio de información, y es base de muchas de las tecnologías que usamos en la web (Ajax o Web Services por ejemplo), existen muchos crackers interesados en vulnerar todo lo referente a este lenguaje, aprovechándose por ejemplo de la posibilidad de incrustar contenido externo en ficheros XML, o incluso denegación de servicios al forzar al parse XML a procesar datos exponencialmente.
Para defenderse, bastaría con evitar que el parser que nuestro servidor o aplicación esté usando no contemple el uso de entidades externas.
________
Puedes ver más artículos de esta serie en #MundoHacker, donde tratamos en varios tutoriales las medidas para atacar y/o defenderse en el mundo digital.
Y si el contenido que realizo te sirve para estar actualizado en tu día a día, piensa si merece la pena invitarme a lo que vale un café, aunque sea digitalmente.
