Sorry, this entry is only available in Español.

Solucionario propuesto por Andrés Bedoya (a.k.a @killr00t) al reto Security Challenge #CTF #Web + Premio: Libro Ethical Hacking 2.0, quien como siempre nos tiene acostumbrados ver en sus escritos un excelente nivel técnico y que ahora combina con un  magnífico video.

Como siempre animar y recordar a los recién iniciados y expertos a participar de estos desafíos, pues no hay mejor manera de aprender que enseñando…

Video solucionario al reto Security Challenge #CTF #Web por @killr00t

video

Documento Online

Solucionario propuesto por Fernando Quintero (a.k.a @nonroot) al reto Security Challenge #CTF #Web + Premio: Libro Ethical Hacking 2.0.

Como siempre animar y recordar a los recién iniciados y expertos a participar de estos desafíos, pues no hay mejor manera de aprender que enseñando…

Felicitaciones a nonroot quien se convierte en el ganador del libro Ethical Hacking 2.0 de Héctor Jara y Federico Pacheco. Gracias además por compartir ese magnífico solucionario.

Aunque los solucionarios recibidos (que pronto estaré publicando también) no incluyeron el desarrollo de un exploit destaco el solucionario de nonroot debido a que evidencia muchos posibles puntos de intrusión, completamente aplicables no solo a este reto, sino a proyectos reales. Me gustó también los diferentes cuestionamientos que deja al final. Esto gracias a las experiencia recogida durante años en la profesión, sumado a los conocimientos y prácticas en el propio desarrollo de CTF’s. Para quienes no tenían conocimiento les comparto la lista dedicada exclusivamente al aprendizaje mediante el desarrollo conjunto de CTF’s. En este caso CTF Colombia.

Ahora que el solucionario ha sido liberado, dejo las correspondientes referencias del autor que desarrollo esté excelente Web CTF.

Anestis Bechtsoudis - Web oficial del CTF

Al final del solucionario dejo un exploit desarrollado por mr.pr0n que automatiza el proceso. Obviamente realizado una vez analizó en detalle la aplicación e identificó las fallas presentes en la misma.

///////////

Solución por nonroot:

La solución se va escribiendo en el mismo orden en que se van encontrando las cosas, puede parecer que la ruta era obvia y me desvío en otros asuntos, pero así funcionaba la mente en ese momento. La solución del reto me tomó 3 horas aproximadamente porque estuve pensando en posibles rutas que no me llevaron a ningún lado.

A. Lo primero como siempre es descargar la maquina del juego, chequear su integridad y buscar pistas en la descripción del reto que se publicó en el sitio web.

Link: http ://www.sec-track.com/security-challenge-ctf-web-premio-libro-ethical-hacking-2-0

SecTracker> md5sum Web_Sec_Challenge_Img.rar 328ddbf34e00d662ea4c89672dac29d3 Web_Sec_Challenge_Img.rar (OK)

SecTracker>

Pistas:

• Una maquina linux (boot)
• Servicio web corriendo en el puerto 8880 posiblemente (imagen del post introductorio)
• Uso de MySQL (boot de la maquina)
• Nombre de la maquina drunkadm (boot)

B. Hay que encontrar la maquina corriendo en la red local, un barrido de ping NO muestra maquinas activas en la red, es posible que la VM este filtrando.

SecTracker> fping -g 192.168.0.0/24
192.168.0.25 is alive
ICMP Port Unreachable from 192.168.0.152 for ICMP Echo sent to 192.168.0.152
192.168.0.159 is alive
192.168.0.160 is alive
ICMP Port Unreachable from 192.168.0.152 for ICMP Echo sent to 192.168.0.152
192.168.0.1 is unreachable 192.168.0.2 is unreachable
…

Si se observan los 3 tipos de respuesta con la utilidad fping, se pueden tener las maquinas que posibles.

“Is alive” la maquina esta activa y acepta los pings. “is unreachable” la maquina no esta disponible “ICMP port Unreachable” la maquina esta en otro estado (filtrada?), esta es nuestra candidata.

En mi caso la maquina mas sospechosa es 192.168.0.152. Veamos si tiene el puerto web (8880) abierto:

SecTracker> nmap -sS 192.168.0.152 -p 8880
Starting Nmap 5.61TEST4 ( http ://nmap.org ) at 2013-01-22 13:15 EST
Nmap scan report for 192.168.0.152
Host is up (0.00067s latency).
PORT STATE SERVICE 8880/tcp open cddbp-alt
MAC Address: 00:0C:29:26:4B:A8 (VMware)
Nmap done: 1 IP address (1 host up) scanned in 11.36 seconds
SecTracker>

C. Entramos al sitio web y leemos el código fuente en busca de scripts php.

Observamos varios scripts php desde el source: info.php, index.php, upload.php, myphp.php

Empezamos a evaluarlos de forma básica:

• index.php carga el sitio normal

 

El sitio permite subir imágenes que son desplegadas inmediatamente, las imágenes son almacenadas en el directorio /images/ sobre la raíz del sistema, mas adelante volvemos a esto.

• upload.php requiere el envío de parámetros por POST

http :// 192.168.0.152:8880/myphp.php?id=101

Obtenemos información del sistema, al corrérle SQLMap contra este script nos dice que id no es una variable inyectable.

21:25:18] [WARNING] GET parameter ‘id’ is not injectable

Al cambiar valores del id, obtenemos diferentes respuestas, busquemos algunas mas:

SecTracker>for i in {1..10000}; do wget http ://192.168.0.152:8880/myphp.php?id=$i ; done

Obtenemos un resultado así:

SecTracker>ls -l
…
-rw-r–r–     1  root     staff     70 Jan 2 1 2 1:51 myphp.php?id= 1671
-rw-r–r–     1  root     staff     70 Jan 2 1 2 1:51 myphp.php?id= 1672
-rw-r–r–     1  root     staff     70 Jan 2 1 2 1:51 myphp.php?id= 1673
-rw-r–r–     1  root     staff     70 Jan 2 1 2 1:51 myphp.php?id= 1674
-rw-r–r–     1  root     staff     70 Jan 2 1 2 1:51 myphp.php?id= 1675
-rw-r–r–     1  root     staff     70 Jan 2 1 2 1:51 myphp.php?id= 1676
…

SecTracker>

Las respuestas con 70 bytes son las del mensaje de error, busquemos respuestas diferentes:

SecTracker>ls -la | grep -v “70 Jan”
total 10976
drwxr-xr-x 1346 root staff 45764 Jan 2 1 2 1:47 .
-rw-r–r–     1  root      staff 4598 Jan 2 1 2 1:47 myphp.php?id= 101
-rw-r–r–     1  root      staff 1326 Jan 2 1 2 1:47 myphp.php?id= 102
-rw-r–r–     1  root      staff 11012 Jan 2 1 2 1:47 myphp.php?id= 104
-rw-r–r–     1  root      staff 49949 Jan 2 1 2 1:47 myphp.php?id= 108
-rw-r–r–     1  root      staff 2031 Jan 2 1 2 1:47 myphp.php?id= 116
-rw-r–r–     1  root      staff 3475 Jan 2 1 2 1:47 myphp.php?id= 132
-rw-r–r–     1  root      staff 1867 Jan 2 1 2 1:47 myphp.php?id= 164
-rw-r–r–     1  root      staff 57314 Jan 2 1 2 1:47 myphp.php?id=99
SecTracker>

Según esto, los id 101, 102, 104, 108, 116, 132, 164 y 99 darán mensajes diferentes.

Con el id=132 logro identificar que la aplicación esta configurando cookies que pueden ser usadas para validar durante el proceso de upload de las imágenes …
Después de las pruebas me di cuenta que no funcionaba en ninguna validación, FAIL

D. Algo que intento en este punto es tratar de configurar una cookie “trypios” con diferentes valores. Ninguno de los valores configurados funcionó. FAIL

E. Lo que intento a continuación es validar la integridad de las imágenes que subo al sistema, para eso subo una imagen y luego la descargo para verificarla.

SecTracker>md5sum webchall*.png
9937c44d2c0f6a2f11240d8e2b 1069a0 webchall.png (Imagen que subo al sistema)
9937c44d2c0f6a2f11240d8e2b 1069a0 webchall2.png (Imagen que descargo del sistema)
SecTracker>

Con esto compruebo que el sistema conserva la integridad de las imágenes que se suben, pero lo que me llama la atención es el nombre de la imagen cuando sube al sistema, tiene cara de MD5

Lo primero que intento es generar el hash MD5 de las imágenes que subo al sistema para compararlas con sus respectivos nombres cuando se almacenan, pero los valores no corresponden, entonces empiezo un proceso manual para intentar identificar un patrón.

a.jpg 394659692a460258b45a99f1424ea357.jpg
a.png 32d3ca5e23f4ccf1e4c8660c40e75f33.png
a.gif a7200b4bac77e8804f9e48304a92b6d9.gif
a.jpeg 14a53cac5a312f3d1ad4980fec051d42.jpeg
b .jpg efaf98db2eac3a61946ca0282ae6ddd4.jpg

Los nombres que aparecen en el sistema corresponden a los valores MD5 de los nombres de las imágenes que se suben :

SecTracker>echo -n “a.jpg” | md5sum
394659692a460258b45a99f1424ea357 –
SecTracker>echo -n “a.png” | md5sum
32d3ca5e23f4ccf1e4c8660c40e75f33 –
SecTracker>echo -n “a.gif” | md5sum
a7200b4bac77e8804f9e48304a92b6d9 –
SecTracker>

F. Descargo un shell en php con la intención de hacerlo pasar por una imagen.

El shell lo pueden descargar desde aquí:
http://xploitaday.komodin.org/tools/php-encoder/

 

G. Como paso siguiente intento subir un shell en php al sistema, pero obtengo un error relacionado con la extensión que uso en el nombre del archivo.

H. Intento camuflar la extensión del shell usando una doble extensión y genero el MD5 en caso de que suba al sistema.

SecTracker>cp shell.php shell.jpg.php
SecTracker>echo -n “shell.jpg.php” | md5sum
809d9ef057f63c676e 1d78dbb7a43826 –
SecTracker>

I. Subo el archivo shell.jpg.php al sistema y no se visualiza ninguna imagen, pero tampoco se genera un error, entonces intento cargar el archivo .php en el directorio /images/.

Con esto tenemos el shell web dentro del sistema.

J. Una vez dentro del sistema empiezo a buscar información como por ejemplo identificar la versión del kernel, verificar si el sistema tiene netcat, gcc, etc.

También busco los usuarios en /home y me encuentro con un usuario bob, como es el único usuario pareciera que tiene algo que ver con el reto.

 

Los scripts que están en el home del usuario bob requieren de una palabra secreta, cualquier palabra se puede usar pero no producen resultados coherentes (texto plano legible).

K. Sigo explorando buscando las posibilidades de comunicación del usuario bob, por eso intento encontrar archivos que tengan la palabra bob y termino entrar al inbox de correo del usuario en /var/mail/, sin embargo no tengo los permisos para poder leer los archivos, pero sospecho que el usuario puede tener mensajes que ayudan a resolver el tema. FAIL

L. Al no encontrar mucha información por este lado intento abrir puertos en la maquina para conectarme desde la consola (netcat).

Los puertos siguen apareciendo filtrados, lo intento con varios puertos pero obtengo el mismo resultado, por lo que pienso que el sistema debe tener el ip tables habilitado. Buscamos las reglas que deben cargar al inicio del sistema. En /etc/init.d/ encontramos que el archivo firewall.sh tiene permisos modificados y no puedo leerlos, pero eso me da indicios que seguramente si hay un firewall filtrando la salida y entrada de paquetes en puertos diferentes al 22/TCP y al 8880/TCP. FAIL

M. Ya un poco perdido con el asunto empiezo a probar exploits locales (exploits*.c) contra el kernel, exploits contra phpinfo(), contra apache, contra todo lo que se aparezca y nada, no logro escalar privilegios en el sistema, entonces pienso que quizá no sea necesario ya que el reto se trata de una aplicación web. FAIL

 

 

N. Vuelvo a la raíz del servidor web a leer detalladamente los archivos que se encuentran allí y veo un archivo que no había visto antes, el archivo /var/www/.proof .

En este archivo se menciona un código secreto, así que supongo que es el código del usuario bob.

O. Pruebo el código en el sistema y NO obtengo resultados correctos.

¿Será que el código está en base64?

SecTracker>echo -n “TGglMUxecj JDSDclN 1Ej ” | base64 -d
Lh%1L^r2CH7%7Q#
SecTracker>

WIN

 

P. El lugar donde se van a encontrar Alice y Bob es Akti Tompazi 4 , como se puede ver en la siguiente imagen de googlemaps donde se usaron las coordenadas encontradas.

Con esto se termina el reto, pero aún quedan cosas pendientes por investigar:

TODO: COSAS POR HACER

1. Escalar privilegios en el sistema (#).
2. Encontrar las claves de los usuarios root y bob.
3. Examinar si el servicio MySQL (127.0.0.1) tiene información.
4. Examinar si el servicio EXIM (127.0.0.1) tiene información o es vulnerable.
5. Buscar otra forma de explotar el sistema web (vulnerabilidad diferente).
6. Verificar si las librerías de AES usadas para cifrar el mensaj e de bob tienen algún bug introducido que permita romper el cifrado de forma diferente.
7. Identificar el motivo por el cual el archivo .php que se sube en el directorio /images/ del sistema se elimina cada cierto tiempo.

Si tienen alguna duda sobre el solucionario pueden escribir a: fernando.a.quintero (at) gmail (dot) com o contactarme por twitter en: @nonroot

Gracias por el reto!

/////////////////////

Exploit from mr.pr0n

PDF Online:

 

Esta publicación continúa desde: Familiarizándonos con OWASP – Top 10 OWASP vs Sitios Web Colombia II

Es complicado generalizar sobre un panorama o estado del arte en Seguridad de Aplicaciones Web de Colombia, esto debido a que no existen cifras exactas de incidentes registrados. Sobre todo desde las entidades que deberían generar estos registros. Tan solo encontramos supuestas organizaciones líderes en el tema, pero estas se limitan a publicar noticias sacadas de otras fuentes y totalmente fuera de la problemática en cuestión. Un total desperdicio de recursos…

Lo más cercano a estos propósitos y como excelente iniciativa del experto en seguridad Jeimy J. Cano, es la reconocida Encuesta Latinoamericana de Seguridad de la Información. En la encuesta obtendremos un panorama global, no solo sobre seguridad en aplicaciones web, sino también en otros tópicos relacionados a la seguridad de la información.

Lamentablemente la encuesta no cuenta con todos los datos específicos que quisiéramos tener, pero por lo menos cubre algunos puntos de interés para esta publicación. Cabe notar que la encuesta no está dirigida exclusivamente para la población Colombiana, sino también para otros países de América Latina.

Como apreciación personal, considero como factor determinante el que no existan registros más profundos sobre incidentes de seguridad en aplicaciones web en Colombia,  a las propias empresas que no reportan los mismos. Esto posiblemente a la vergüenza y escándalo que puede producir el reconocer las debilidades existentes en sus propios sistemas.  Y por supuesto reconocer que mucha de su información ya fue comprometida y muy posiblemente sus propios datos y los de sus clientes se encuentran públicos en los famosos “leaks“, y en el peor de los casos ni por enterados se dan.

Veamos algunos resultados de la encuesta. Sobre todo los que están dirigidos a Fallas de Seguridad (tipos de fallas, identificación del incidente, notificación, etc.)… De total interés para nuestra publicación.

Población encuestada

Sectores encuestados

Fallas de seguridad identificadas (resaltas las más relacionadas a la publicación)

Mecanismos de protección utilizados

Notificación del incidente

Motivos por los que NO denuncian

La encuesta completa puede consultarse desde el propio sitio web de ACIS >>

Ahora bien, estos datos nos dan un panorama muy general del estado del arte, tendremos entonces que consultar por cuenta propia, acerca de incidentes reportados o “leaks” publicadas en otras fuentes de información…

Una de esas fuentes y relativamente nueva, pero con muy pocos datos (para nuestro país y otros en general) es Datalossdb. En este sitio bajo previo registro, podemos consultar algo de información que posiblemente nos amplíe el panorama. Veamos:

Incidentes en organizaciones Colombianas con su respectiva descripción de la actividad maliciosa

Otra fuente de información aun más cruda, pero más actualizada, así como real y con respecto a vulnerabilidades específicas en aplicaciones web, puede ser el sitio Zone-H. Un servicio que recopila diariamente (gracias a la propia notificación de los atacantes) los diferentes incidentes a organizaciones por medio de las aplicaciones web y que tienen como finalidad modificar el contenido de la página inicial (en su mayoría), conocido como Defacement (desfiguración).

Considero muy apropiado contar en esta publicación con datos como los expuestos en Zone-H, esto debido a que el dato/registro de la actividad maliciosa es realizada por el mismo atacante. Es decir, nada que ocultar y aun mejor, verificado por un agente externo (tercero, equipo de Zone-H). Ni el atacante, ni la víctima podrán manipular los datos.

Veamos entonces un corto análisis de resultados para nuestro país y por supuesto, los principales actores de esta actividad.

Resultados de la consulta sobre sitios web con dominio *.gov.co que han sufrido ataques y como resultado final un defacement (2.573)

Ahora lo mismo con dominios *.edu.co

Safety Last Group & ISLAM 47, como uno de los grupos más reconocidos en la “scene”, debido a la importancia de los sitios atacados y al nivel técnico mostrado para realizar los mismos.

Ataque específico del grupo Safety Last Group – ISLAM 47 al sitio web de la procuraduría general de la nación, al sitio de elecciones (precisamente con fecha cercana a los comicios) 

 

Casi el 100% de dominios *.mil.co, víctimas de los ataques de Safety Last Group – ISLAM 47

Finalmente podemos concluir que nuestro panorama es bastante gris (siendo generosos), pues si bien no tenemos un estado del arte completo sobre la efectividad de las medidas de seguridad implementadas en las organizaciones de Colombia, con los resultados expuestos anteriormente queda bastante claro sobre el alto grado de vulnerabilidad de los sitios por ahora más representativos.

Ya sobre estos sitios publicaré en detalle en el próximo post, además de la evaluación de las fallas con respecto a los sitios web de Colombia.

Esta publicación continúa desde: Uso de Tecnologías en Aplicaciones Web – Top 10 OWASP vs Sitios Web Colombia I

OWASP es una de las más respetadas autoridades en el campo de la seguridad en aplicaciones Web. OWASP es el acrónimo de Open Web Application Security Project (Proyecto Abierto de Seguridad en Aplicaciones Web), y como su nombre indica es una organización abierta y sin ánimo de lucro con el objetivo de mejorar la seguridad en las aplicaciones Web.

OWASP es básicamente una fundación que reúne a colaboradores e investigadores individuales y por supuesto empresas patrocinadoras, quienes en conjunto, contribuyen al crecimiento del proyecto. Estas contribuciones incluyen documentos guías para el desarrollo de código seguro, guías para llevar a cabo pruebas de seguridad a las propias aplicaciones, herramientas para realizar ambas actividades (desarrollo seguro y evaluación de vulnerabilidades), librerías que pueden ser utilizadas para prevenir vulnerabilidades desde el código fuente, entornos de entrenamiento en desarrollo y testing, conferencias y otros recursos.

Uno de los mejores recursos es el conocido OWASP Top 10. Este listado recopila las 10 más críticas vulnerabilidades de seguridad en aplicaciones Web. Esta recopilación contiene datos objetivos de empresas patrocinadoras que informan sobre las diferentes vulnerabilidades que identifican en sus propias infraestructuras o en las que resguardan. Asimismo contiene unos datos subjetivos provistos por investigadores expertos que intentan clasificar la severidad de los daños que pueden causar dichas vulnerabilidades.

La primera versión de este documento fue creada en el año de 2004, luego actualizada en 2007 y actualmente contamos con una última actualización en el año de 2010. De aquí que muchos consideremos más que necesario una nueva actualización para el presente año. (nuevas tecnologías, nuevas vulnerabilidades y nuevos riesgos).
La lista viene organizada desde el riesgo más alto, hasta el más bajo (no por esto menos importante, pues recordemos que es el top 10 de muchos más).

Antes de arrancar con el listado, me gustaría hacer notar la importancia que le dan en el documento a la identificación y gestión de riesgos en las aplicaciones, pues va más allá de listar vulnerabilidades identificadas en gran proporción a vulnerabilidades que realmente tienen impacto técnico (objetivo) como al negocio (subjetivo). Veamos:

Dejo entonces la lista oficial desde el documento publicado en OWASP:

Otro de los aspectos y para mi el más importante, corresponde al tratamiento descriptivo que hacen de cada una de las vulnerabilidades  Pues involucra todos los diferentes aspectos que están relacionados con el análisis del riesgo (atacante, vector de ataque deficiencia de seguridad, impacto técnico y del negocio), veamos un ejemplo con Inyección:

Asimismo se incluyen unos parámetros para la identificación de la vulnerabilidad y por supuesto algunas de las maneras en que podemos evitar las mismas (todas estas como simples referencias de estudios y análisis más profundos)

Para profundizar sobre la Organización OWASP y todos sus proyectos, pueden consultar la página Web oficial >>

 

Para detallar y tener el completo listado del Top 10 OWASP, pueden descargar el documento en formato pdf >>

Continuamos pronto…

 

El año pasado tuve el placer de asistir a la primera versión del ACK Security Con. Allí presenté parte de una investigación que vengo realizando sobre el estado del arte en la seguridad de las aplicaciones Web en Colombia.

El tema es complejo y profundo, por ello, he decidido publicar la propia presentación del evento en diferentes posts, con el objetivo de detallar las ideas y planteamientos… Y por supuesto recibir nuevas opiniones de ustedes los verdaderos expertos.

Una de las primeras problemáticas que presenté, hace referencia a la implementación de tecnologías comunes o de uso masivo en las aplicaciones Web. Esto quiere decir, sobre la utilización de CMS, servidores Web, lenguajes de programación del lado del servidor entre otros, con reconocidas fallas de seguridad por defecto o por lo menos muy regulares o de constante identificación.

Este tema abre un debate entre defensores y detractores. Por ejemplo en el uso de CMS, (por poner sólo un ejemplo, que ya con lenguajes de programación es aún peor y ni que decir de Sistemas Operativos) ya que unos hablarán y argumentarán sobre las bondades del uso de alguno, por la fácil gestión de contenidos, la constante actualización de funcionalidades y por supuesto, mejoras en seguridad. Asimismo los detractores argumentarán sobre el alto impacto negativo que representa una falla en uno de estos gestores o lenguajes, debido principalmente al uso masivo que comentaba en un inicio. Y sobre todo acerca de la generosidad de tener un software hecho a la medida de las necesidades del usuario “sin manos extrañas que toquen nuestro código”.

Personalmente soy partidario del argumento “Depende”. Pues nada más cierto que cada quien con sus gustos y preferencias. Obviamente estas mismas por debajo del bien común del negocio. Y este mayormente representado en prestación del servicio y confidencialidad del mismo. Con todo lo que implica.

Vuelvo y repito… Nos abriría un eterno debate, por ejemplo sobre la posibilidad de auditoría de código, efectividad de escáneres de vulnerabilidades, malas prácticas de programación, facilidad de explotación, propagación masiva de otros ataques y un largo etcétera.

Lo presento como una constante problemática en seguridad. Pues finalmente será casi imposible ponernos de acuerdo en esto. Pero el riesgo es real.

Lo siguiente, es un listado de resultados de uso de tecnologías en Internet a nivel mundial, específicamente en relación a aplicaciones Web. Todas estas extraídas desde W3Techs, veamos:

 CMS (Content Management System / Sistema de Gestión de Contenidos)

El gráfico nos informa sobre un total de 68.1 % de NO uso de sistemas de gestión de contenidos. Un 17.5%  de uso del CMS WordPress sobre el total de sitios en Internet (una cifra bastante alta), además este mismo CMS representa el 54.8% del total de sitios Web que usan gestores de contenido para administrar los mismos.

Desde el sitio Web W3Techs, será posible además detallar las versiones específicas de estos gestores, veamos los resultados con los dos CMS más utilizados (WordPress & Joomla)

WordPress

Joomla

Lenguajes de programación del lado del servidor

Lenguajes del lado del cliente

Autoridades Certificadoras

Servidores Web

Versiones específicas de Apache

Versiones específicas de IIS

Sistemas Operativos

Versiones específicas de derivados UNIX

Versiones específicas Linux

Top Dominios

Algunos resultados son tranquilizadores con respecto a las versiones específicas de la tecnología. Pues confirman que se están utilizando las últimas versiones, que en su gran mayoría, no presentan vulnerabilidades (por lo menos no públicas hasta el momento, pero como todos sabemos y por lo que hemos visto últimamente es solo cuestión de tiempo). Algunos otros datos nos dejan esa sensación de preocupación. Sobre todo cuando consultamos informes como los siguientes (CVEDetails):

Vulnerabilidades Apache

Vulnerabilidades IIS

Vulnerabilidades PHP

Vulnerabilidades ASP.NET

Vulnerabilidades WordPress

Vulnerabilidades Joomla

Continuamos pronto…

 

Assessing and Exploiting Web Applications with Samurai-WTF es nada más y nada menos que un entrenamiento especializado y de alto nivel que se ve solo en espacios como BlackHat.

Como si esto fuera poco los desarrolladores del mismo, han decidido compartir dicho entrenamiento con licencia: Creative Commons Attribution-ShareAlike 3.0 License.

El course outline va de los siguiente:

Day 1 Morning Testing Methodology Recon & Map Walkthrough Target 1: Mutillidae – Mapping Walkthrough

Day 1 Afternoon Target 1: Mutillidae – Discovery Walkthrough – Exploitation Walkthrough Target 2: DVWA – Mapping Walkthrough

Day 2 Morning Target 2: DVWA – Discovery Walkthrough – Exploitation Walkthrough

Day 2 Afternoon Target 4: Samurai Dojo – Student Challenge – Challenge Answers En definitiva… Más de 200 slides de conocimiento puro…

Ver Online: Evaluación y Explotación de Aplicaciones Web con Samurai Web Testing Framework (Online version)

Descargar Evaluación y Explotación de Aplicaciones Web con Samurai Web Testing Framework (pdf)

Sorry, this entry is only available in Español.

DVWA (Damn Vulnerable Web Application) es un reconocido entorno de entrenamiento en explotación de  seguridad Web, que permite estudiar e investigar sobre las diferentes temáticas involucradas en dicho campo.

Ahora se encuentra disponible la versión número 1.0.7, y desde hace algún tiempo se distribuye, además de los archivos , un LiveCD (iso) para facilitar aun más la implementación del entorno de entrenamiento.

Entre las mejoras de esta nueva versión, se destaca la página de ayuda del entorno, la implementación de las prácticas de Blind SQL Injection y la documentación oficial del proyecto.

Las temáticas cubiertas en el Framework, son las siguientes:

Login Brute Force
XSS (Cross-Site Scripting)
LFI (Local File Inclusion)
RFI (Remote File Inclusion)
Command Execution
Upload Script
CSRF (Cross-Site Remote Forgery)
SQL Injection
Blind SQL Injection

Para más información sobre el proyecto Blog >>

Web Oficial del Proyecto >>

Descargar DVWA (ISO)(480Mb) >>

Pronto estaré publicando algunos tutoriales y video tutoriales de la implementación y desarrollo de cada uno de los niveles propuestos en el Framework, obviamente estos recursos serán generados a través de la lista de correo y de los comentarios en el Blog.

Hace varios años tuve el placer de conocer este magnífico FAQ sobre Seguridad en Aplicaciones Web desarrollado por OWASP. Recientemente volví a encontar el documento (pdf) y un website habilitado por OWASP para consultarlo On-Line.

Read the rest of this entry »