Esta publicación continúa desde:

Comenzamos entonces con algunos apartados un poco más técnicos en el proceso de investigación que decidí llamar Top 10 OWASP Vs Sitios Web Colombia.

Como primera etapa vamos a identificar los posibles sitios web considerados más importantes. Esto es solo un supuesto, pues el listado solo corresponde a los más visitados según diferentes sitios de ranking en internet. No quiere decir que sean los más importantes con respecto a la funcionalidad del mismo, por ejemplo servicios públicos, gestión de gobierno o similares. Vuelvo y repito SOLO los más visitados.

Para la muestra seleccioné los primeros 50 sitios web reportados como más visitados de Colombia. Cabe aclarar que en el ranking NO incluyo sitios Web extranjeros, es decir, sitios como facebook, google, bing, etc. NO hacen parte del Top, pues los mismos NO son administrados y/o gestionados desde Colombia, objetivo directo de la muestra. Veamos:

http://www.alexa.com/topsites/countries/CO

Ejemplo de la muestra:

Por lo tanto el listado quedó así:

  1. eltiempo.com
  2. elespectador.com
  3. grupobancolombia.com
  4. elcolombiano.com
  5. exito.com
  6. elempleo.com
  7. caracol.com.co
  8. canalrcnmsn.com
  9. elpais.com.co
  10. caracoltv.com
  11. claro.com.co
  12. davivienda.com
  13. tucarro.com.co
  14. portafolio.co
  15. unal.edu.co
  16. avianca.com
  17. sena.edu.co
  18. guiacereza.com
  19. falabella.com.co
  20. tecnoautos.com
  21. senasofiaplus.edu.co
  22. enter.co
  23. soho.com.co
  24. bancodebogota.com
  25. metrocuadrado.com
  26. dinero.com
  27. diarioadn.co
  28. elheraldo.co
  29. movistar.co
  30. eluniversal.com.co
  31. poligran.edu.co
  32. dian.gov.co
  33. cinecolombia.com
  34. noticiascaracol.com
  35. policia.gov.co
  36. pagosonline.net
  37. rcn.com.co
  38. wradio.com.co
  39. etb.net.co
  40. colpatria.com
  41. une.net.co
  42. laneros.com
  43. tigo.com.co
  44. procuraduria.gov.co
  45. chatiapues.com
  46. udea.edu.co
  47. saludcoop.coop
  48. lafm.com.co
  49. tuboleta.com
  50. bancodeoccidente.com.co

Una vez definida la muestra a analizar, definamos también la información que queremos recolectar de estos sitios. Esta información será la que normalmente tomo cuando recién inicio un Test de Penetración formal, obviamente sin realizar actividades intrusivas, pues estas van más allá del alcance de esta publicación.

Esta es la serie de fases metodológicas que utilizo cuando realizo algún proyecto relacionado. Señalando obviamente solo las que nos interesan en esta publicación.

Así, dentro de esta información nos interesa recolectar:

Archivos robots.txt, datos de registro de dominio, Google Hacking (correos electrónicos, archivos/directorios sensibles, metadatos), infraestructura de red, footprinting de aplicaciones y servicios web, manejo de errores, validación simple de datos, historial en internet, etc…

Comencemos entonces por la identificación del archivo robots.txt.

A modo muy general, el archivo robots.txt nos permitirá identificar algunos de los directorios que los webmaster o administradores consideran importantes/sensibles para ser indexados o no por los motores de búsqueda. En pocas palabras, el archivo robots.txt es de mucha importancia para nosotros los PenTesters, pues como sabemos realizaremos las mismas técnicas que realizarían los delincuentes informáticos para hacerse a la información.

Dicho archivo permite mediante una simple configuración autorizar o no que nuestro sitio o recursos del mismo sean almacenados en los motores de búsqueda (bing, yahoo, google, etc.)

Veamos esto con un práctico ejemplo:

http://www.sec-track.com/robots.txt

User-agent: *
Disallow: /wp-admin/
Disallow: /wp-includes/

Con estas sencillas líneas, le estoy estableciendo a google (ejemplo) que NO indexe estos directorios específicos.
Es decir… Si un atacante llegase a buscar dichos directorios en mi sitio web se encontraría con lo siguiente:


Obviamente el archivo robots.txt tiene una verdadera funcionalidad, y no se trata solamente de decir “no ingreses a este directorio”. Asimismo como le indicamos NO ingreses, también podemos decirle Ingresa (allow). Esto principalmente se utiliza en actividades de SEO y posicionamiento de contenido. En resumen, una interacción directa con los motores de búsqueda.

El problema radica como vemos, en que así como le indicamos al buscador el recurso no-permitido, también le estamos diciendo al atacante el recurso que “estamos protegiendo” o de información sensible. Y es justo aquí donde siempre he manifestado sobre el doble filo que puede tener este archivo.

Cuando me consultan sobre el utilizar o no este archivo robots.txt, siempre respondo: Depende! y es sobre todo porque así como los desarrolladores web/webmasters definen un público objetivo, los CEO/Gerentes/CISOs deben definir también un posible público “enemigo”. Y este puede ser prácticamente todos…

En otras palabras, (1) o le decimos solo a “algunos” (utilizando el archivo robots.txt) donde están nuestros directorios sensibles ej.

User-agent: *
Disallow: /admin/
Disallow: /secreto/

Y estos “algunos” serán estrictamente nuestros reales “enemigos”, los que están buscando directamente en este archivo.

(2) O le decimos a todos,  solo lo que queremos decirle.

Un ejemplo más claro, es cuando se identifica una falla tipo (0)day en algún CMS, para este ejemplo: Joomla. Es justo allí cuando los cientos de defacers/delincuentes/competencia, etc comienzan su rápida búsqueda de posibles sitios vulnerables. Por ejemplo, identificaron una falla en alguno de sus plugins (sin hacer referencia si es del propio core o de un tercero, solo un plugin X )

Si el ataque fuera directo, a un objetivo “militar”, los delincuentes buscarían directamente el archivo en la raíz del webserver: ej. http://www.joomlaencolombia.net/robots.txt

User-agent: *
Disallow: /administrator/
Disallow: /cache/
Disallow: /components/
Disallow: /images/
Disallow: /includes/
Disallow: /installation/
Disallow: /language/
Disallow: /libraries/
Disallow: /media/
Disallow: /modules/
Disallow: /plugins/
Disallow: /templates/
Disallow: /tmp/
Disallow: /xmlrpc/

Desde allí con algo de suerte (listado de directorios por ejemplo) verían si este sitio web tiene efectivamente el plugin en cuestión, sino optarían por realizar la consulta directamente a la URL para verificar.

Si el atacante no tiene un objetivo definido y solo quiere vulnerar la mayor cantidad de sitios posibles utilizaría por lo tanto google como herramienta de recolección e identificación de objetivos. Veamos el ejemplo como entonces identificarían la mayor cantidad de sitios vulnerables por utilizar X plugin:

En definitiva yo recomiendo el uso del archivo, obviamente bien configurado y no solo el que viene por defecto en el CMS de turno. Pues prefiero enfrentarme a un atacante directo (busca directamente el archivo robots.txt //GET /robos.txt HTTP/1.1 ) y no dejar todo abierto a los motores de búsqueda, para que los atacantes programen un webspider que recolecte los miles de sitios que usamos determinado CMS, directorio o archivo específico.

Cierro entonces con los resultados de la consulta al archivo robots.txt de la muestra de sitios más visitados. Mencionando también que nos interesa saber si alguno de estos NO lo utiliza y además no tiene un sistema adecuado de manejo de errores. En pocas palabras, nos interesa saber si lo tienen o no, y si falta, qué nos responde ante dicha petición. (pues veremos entonces posiblemente algo de revelación de información del servidor web)

Solo algunos resultados de interés:

Disallow: /blogs/cgi-bin/mt-search.cgi
Disallow: /estadisticas
Disallow: /participa
Disallow: /blogs/mt-static
Disallow: /registro

GET /robost.txt HTTP/1.0

HTTP/1.1 404 Not Found
Content-Length: 1635
Content-Type: text/html
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Date: Tue, 19 Feb 2013 04:53:03 GMT
Connection: close

Disallow: /js/
Disallow: /css/
Disallow: /common/
Disallow: /account/
Disallow: /search/
Disallow: /test/
Disallow: /dialog/
Disallow: /email/
# Directories
Disallow: /AdditionalSitesForms/
Disallow: /Admin/
Disallow: /AdminSchema/
Disallow: /Billing/
Disallow: /bin/
Disallow: /Companies/
Disallow: /cgi-bin 
Disallow: /inicio
Disallow: /home
Disallow: /Home/*
Disallow: /forms/*
Disallow: /forms/
Disallow: /forms/inscrihoyxhoy/yrpoTerun2345.asp
Disallow: /forms/inscrihoyxhoy/slista.asp
Disallow: /buscar.aspx
Disallow: /buscar/*
Disallow: /?q=admin/
Disallow: /?q=comment/reply/
Disallow: /?q=contact/
Disallow: /?q=logout/
Disallow: /?q=node/add/
Disallow: /?q=search/
Disallow: /?q=user/password/
Disallow: /?q=user/register/
Disallow: /?q=user/login/

Not Found
The requested URL /robots.txt was not found on this server.
IBM_HTTP_Server at www

Disallow: /robots.txt
Disallow: /admin/
Disallow: /guiadesitios/admin/
Disallow: /comunidad/
Disallow: /comunidad4/
Disallow: /banners/
Disallow: /cgi-bin/
Disallow: /chat.php
Disallow: /chat/
Disallow: /imagenes/
Disallow: /images/
Disallow: /Visual/
Disallow: /ajaxstarrater_v122/
Disallow: /ajaxvotacion/

type Informe de estado
mensaje /robots.txt
descripción El recurso requerido (/robots.txt) no está disponible.
JBossWeb/2.0.1.GA

Disallow: /custom/plugins/
Disallow: /custom/themes/
Disallow: /custom/upgrade/
Disallow: /wp/wp-includes/
Disallow: /wp/wp-admin/
Disallow: /pls/portal/url/page/porvenir_2006/
Disallow: /pls/portal/url/PAGE/GAVAL/
Disallow: /pls/portal/url/page/atefi/
Disallow: /pls/portal/url/page/web_ath/
Disallow: /pls/portal/url/page/ValoresBog/
Disallow: /pls/portal/url/page/LEASING2010/
Disallow: /pls/portal/url/page/PLANETA_AZUL/
Disallow: /pls/portal/url/page/aladdin2008/
Disallow: /pls/portal/url/page/web_fidupopular/
Disallow: /pls/portal/url/page/VALORES_DE_OCCIDENTE/
Disallow: /pls/portal/url/page/FIDUBOGOTA_NEW/
Disallow: /pls/portal/url/page/LEASING_OCCIDENTE/
Disallow: /pls/portal/url/page/SITIO_BCOPOPULAR/
Disallow: /pls/portal/url/page/web_bcopopular/
Disallow: /pls/portal/url/page/NEW_SITIO_ATH/
Disallow: /pls/portal/url/page/SITIO_ATH/
Disallow: /albummovistar/
Disallow: /conectadospodemosmas/
Disallow: /correonokia/
Disallow: /demos_ServEnLinea/
Disallow: /demos_supertarifasmovistar/
Disallow: /foro_smartphones/
Disallow: /media/
Disallow: /media/paso_a_paso/
Disallow: /motorola_milestone/
Disallow: /smartblog/
Disallow: /Soy_Digital/
Disallow: /Buscador_Fija_Aqui/
Disallow: /brm2013/
Disallow: /Buscador_test/
Disallow: /PEAR/
Disallow: /tlMoviles/
Disallow: /xmlSms/
Disallow: /adminPilotoTienda2/
Disallow: /pruebaCap/
Disallow: /db/
Disallow: /class/
Disallow: /dataExtract/
Disallow: /templates/
Disallow: /templates_c/

Error
No se ha encontrado el objeto. (WWC-50003)
Atrás
Copyright © 2005, Oracle. Todos los Derechos Reservados

HTTP Status 404 – /robots.txt
type Status report
message /robots.txt
description The requested resource (/robots.txt) is not available.
Apache Tomcat/7.0.6

The requested URL /robots.txt was not found on this server.
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.
Apache/2.2.23 (Unix) mod_ssl/2.2.23 OpenSSL/1.0.0-fips mod_bwlimited/1.4 mod_fcgid/2.3.6 Server at www.

Disallow: /administrator/
Disallow: /cache/
Disallow: /components/
Disallow: /images/
Disallow: /includes/
Disallow: /installation/
Disallow: /language/
Disallow: /libraries/
Disallow: /media/
Disallow: /modules/
Disallow: /plugins/
Disallow: /templates/
Disallow: /tmp/
Disallow: /xmlrpc/

A modo general observamos una correcta configuración del archivo en la mayoría de sitios web, salvo algunos otros que no lo tienen y que además no configuran adecuadamente los parámetros de respuesta ante la falta de un determinado archivo. Observamos también (resultado total) un alto uso del CMS Drupal como gestor de contenidos. Sabemos además que este, es relativamente un poco más seguro que muchos otros. Pero eso será materia de estudio para otro post.

Continuamos pronto…

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 @nonrootal 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

1

Empezamos a evaluarlos de forma básica:

  • index.php carga el sitio normal

2

 

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

3

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

4

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

5

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.

6

7

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 :)

8

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 :P

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/

9

 

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.

10

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/.

11

Con esto tenemos el shell web dentro del sistema.

12

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.

13

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.

14

 

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).

15

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 :)

16

17

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

18

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 :)

19

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 :)

20

 

21

 

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 .

22

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.

23

24

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

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

WIN :)

25

 

26

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.

27

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

1poblacion

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.

Continuamos pronto…

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)

Programación Web Segura – Hackeando tu aplicación

Posted by 4v4t4r On junio - 9 - 2011

Programación Web Segura – Hackeando tu aplicación, es un libro escrito por Luis Parravicini que como bien dice su título, se enfoca directamente al desarrollo y testing en seguridad de aplicaciones web. Destaca sobre otras publicaciones el hecho de que incluya una completa aplicación desarrollada por el propio escritor, que de manera guiada nos lleva por cada uno de los capítulos aplicando el conocimiento adquirido sobre esta. Recomiendo este libro a las personas que recién inician en este campo, y quieren dirigir sus esfuerzos y energías a las temáticas relacionadas con las aplicaciones web. Una vez finalizada la lectura del mismo considero que pueden afrontar de mejor manera las publicaciones de OWASP (que algunas veces son tratadas con alto nivel técnico).

Desde el website oficial nos dejan las diferentes maneras de comprar el libro… Yo opté por la versión para Amazon Kindle (tan solo 3.99 USD$).

Desde este lector copié un fragmento de la introducción que dejo a continuación (espero no moleste al autor):

Este libro explica de manera sencilla los problemas de seguridad más comunes en las aplicaciones web y sus posibles soluciones. Es útil tanto para aquellos con poca experiencia en este tipo de desarrollos como para los que ya se dedican a esto y desean crear aplicaciones más seguras. Para sacar el mayor provecho de la lectura de este libro es necesario tener conocimientos mínimos en SQL, programación (sin importar el lenguaje) y HTML. Los problemas que se van a tratar no afectan a una tecnología o a un lenguaje en particular sino que aplican a todos los lenguajes usados actualmente para desarrollar aplicaciones Web.

Como el lenguaje de programación usado no es demasiado importante, no se suele mencionar ninguna función, método, o clase específica ya que cambian según el lenguaje. El objetivo es que el lector entienda cómo resolver el problema de un modo abstracto y que luego recurra a la documentación específica de las herramientas que tenga que usar.

Nos referimos a sitio, aplicación, aplicación web y sistema como sinónimos. Al igual que página y pantalla, refiriendose éstas a un documento que sea accesible por medio de una dirección Web (URL). Y se asume que, al menos para algunos de los problemas descritos (como inyección SQL) la aplicación almacena sus datos en una base de datos relacional  (RDBMS).
No haremos distinción sobre si la aplicación será de acceso interno o tendrá una dirección con la cual sea posible acceder desde Internet. Es cierto que si la aplicación es pública, cualquiera podría intentar atacarla pero también es importante tener en cuenta que los ataques internos son muy peligrosos ya que los atacantes suelen tener más información sobre el funcionamiento y las debilidades del sistema.

Dejo a continuación el índice detallado del libro. En el website oficial nos dejan además un fragmento del capítulo titulado “Almacenando contraseñas“.

  • Introducción
  • Organización del libro
  • Aplicación de ejemplo
  • HTTP
    • Pedidos/Respuestas
    • Cookies
    • Refer
  • Analizar tráfico
    • Firebug
    • TamperIE
    • WebKit Web Inspector
    • WebScarab
    • Fiddler
    • Wireshark
    • Proxies HTTP
  • Fugas de información
    • Páginas de error
    • Comentarios
  • Validaciones
  • XSS
  • CSRF
  • Inyección SQL
    • Inyección básica
    • Ejecutar múltiples sentencias
    • Ataques de segundo orden
    • Inyección a ciegas
    • Soluciones
    • Escapar parámetros
    • Prepared Statements
    • ORM
    • Permisos
    • Detección automática
  • Autenticación
  • Almacenando contraseñas
    • Criptografía
    • Casos prácticos
      • Texto plano
      • Funciones de hash
    • Openid
  • Uso de frameworks
  • Conclusiones

Espero disfruten la lectura…

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 »