Descubre 4n4lDetector Pro y Pescan.io

Analiza archivos de forma avanzada con 4n4lDetector Pro y prueba la versión online en Pescan.io. Todo desde tu navegador o tu escritorio.

Intelligent String para priorizar IOCs útiles, heurísticas de flujo anómalo, generación de reglas YARA con un clic, carving de encabezados PE, y detección de firmas Microsoft manipuladas. Compatible con 32/64-bit y formatos comunes (.exe, .dll, .sys, .ocx, .scr, .drv, .cpl). Funciona desde cualquier navegador o en tu escritorio con CLI, GUI y plataforma web integrada. Incluye hash intelligence, gamificación interna, Interest Words, y más de 10,000 reglas para detección avanzada de malware.

Mostrando entradas con la etiqueta Full Path Disclosure. Mostrar todas las entradas
Mostrando entradas con la etiqueta Full Path Disclosure. Mostrar todas las entradas

viernes, 6 de abril de 2012

El típico 404... ¿o no?


¡Empiezo a pensar que me estoy volviendo loco! Mientras todos mis amigos están preparando el ritual del Viernes Santo... que si los hielos en casa del Pablo porque en la mía incomodan, que si nos acercamos al “Ahorra Más” por la tarde, porque ir al chino a por alcohol debería llamarse “Ahorra Menos”, que si llamamos a las chiquichuelas y las invitamos, el truco del paganinis ayuda a culminar lo que nos ahorramos en el Ron...¡ya saben! ¡Las preocupaciones típicas de los chavales de 23! ¿Y yo? Aquí estoy enelpc, contando lo que todo el mundo sabe, errores 404... ¡vaya cosa!

Y es que cada uno vive la semana santa a su manera, unos utilizan palabras violentas para lastimar a los seguidores del palo cruzado y otros simplemente ponemos comillas, porque sabemos que las palabras las borra el viento.

Si recuerdan mi anterior entrada sobre los errores de acceso denegado (403), que controlaban de forma automática las librerías exportadas desde el Framework de UniGUI, me sumo un “+1” en esta nueva publicación, pues vengo a contar la misma mi**da pero de distinto color... ¡Sí! ¡Los 404!

Resulta que se pasan de interesantes estas librerías ISAPI corriendo en Apache, ya que en ISS el control de errores viene de parte del servidor, con lo que no podremos explotar la vulnerabilidad. Es sencillamente irritante dicho control de errores, ya que todos sabemos que si inventamos un nombre de fichero en una URL cualquiera, deberíamos de llegar al ansiado 404.



¡Pero no! Deberemos de forzarlo hasta dar con lo que “para la aplicación”, es un auténtico 404.


Hasta aquí todo normal... un Full Path Disclosure, pero eso es arenilla...

Si pruebo a inyectar HTML detrás del nombre del archivo, nos encontraremos con la redirección a un error 403, que siendo igualmente vulnerable hasta la fecha, no es el objetivo de la entrada, así que vamos a intentar sacar el 404 inyectándolo al principio, dejando la inyección de forma inocua a la librería.


Parece que funciona, probaré un Iframe en Chrome...



Y de paso un Script en Firefox...


Por curiosidad, se me ocurrió abrir como hice anteriormente, el ejecutable con Hex WorkShop y a escasos milímetros se encontraba el error 404 ¡y yo sin darme cuenta en la anterior entrada! me da a mi que todavía hay mucha chicha que sacarle a este FrameWork en cuestión seguridad.


Para esta versión no he desarrollado parche ¡y es que tengo prisa! ¡ahora sí que me voy de fiesta!

Saludos 4n4les! ;)

martes, 31 de enero de 2012

De fiesta con UniGUI Framework

Esta que vengo a contar, es una de esas historias que me llenan de ganas de publicar, junto al pequeño hilo que se escapa de felicidad, después de lograr algo que nos parece interesante, no cuanto menos de mostrar.

Para deleite de programadores en Delphi tirando a ser muy curiosos, va más bien encaminada la entrada. Esta vez tocaremos un poco de todo, seguridad web, desde Cross Site Scripting hasta Full Path Disclosure, pasando por edición de binarios en hexadecimal, acortadores URL y un par de softwares de regalo en mi querido Visual Basic 6 y ensamblador.

Hasta hace bien poco, un nuevo concepto de desarrollo web se cruzó por mi camino, gracias a un compañero de trabajo, era el llamado UniGUI Framework. Destinado en exclusiva, para dar opción a desarrolladores que trabajan con Delphi, de poder diseñar proyectos destinados a aplicaciones web. El Framework entre otras funciones de publicación, trae la de exportar el proyecto a librerías DLL para su integración en ISS o Apache mediante Mod ISAPI.

¿Y como no? ¡Tenía que reventarlo!

Así que cargando mis jeringuillas de sustancias psicotrópicas, me topé con un Cross Site Scripting, en el control de errores que trae de forma interna la aplicación y aunque no vean el típico mensaje de alert, observen bien la imagen, pues podemos llamarle Blind-XSS.


Cualquier URL agregada de forma externa por un atacante, o interna por el propio programador en el código de la librería, se adjunta a la ruta actual y prescinde del protocolo, en el cual se realizan las peticiones.

¿Por qué ocurre esto? ¡Muy simple! La librería se encarga de filtrar los slashes modificándolos por barras invertidas. Esto quiere decir que el Cross Site Scripting existe y es explotable, pero su margen de acción, se ve reducido para ataques externos, a no ser que logremos bypassearlo.

Detrás de “Access denied”, encontramos ese Full Path Disclosure tan llamativo, que muestra la letra de la unidad y el tipo de servidor que utilizo ¡Genial más datos para realizar un ataque!

Después de hacer pruebas con diferentes navegadores y ver su eficiencia ;) , lo que más asombro me causó, es lo que os muestro en la siguiente captura.


¡Google Chrome se lleva la palma! Así que él solito, fuerza la petición y muestra el enlace corregido. Por si alguno no se había dado cuenta, el servidor de Bit.ly trabaja con un certificado firmado por una autoridad certificadora, con lo que podremos explotar la vulnerabilidad mediante protocolo seguro, pudiendo así, visitar cualquier página sin restricciones.

Podremos incluir un IFRAME sin ningún tipo de problema, gracias al Bypass de Google Chrome y el certificado de Bit.ly, para no sé... ¿visitar enelpc?

O echarle imaginación, y tirar de onMouseOver para jugar en Firefox a ser hackers malos.


Pero nosotros somos buenos ¿verdad? Y queremos corregir vulnerabilidades a toda costa, así que como ya reporté con anterioridad el fallo al foro de UniGUI y no me hicieron ni p*** caso, decidí armarme de valor y buscar entre las strings en hexadecimal del binario, para ver de que forma podría contrarrestar el dichoso ataque.


El HTML que muestra la ruta y la unidad de disco, se muestra mediante una llamada a una variable de tipo string, la cual en caso de contener un valor añadido no alfabético, por ejemplo un número o símbolo en la URL, busca la nueva ruta y si no la encuentra, terminamos con el aviso de acceso denegado en pantalla.

La enfermedad debía de venir acompañada de la cura, y ya que encontré la variable, no me quedó otra que suprimirla de forma definitiva del control de errores, así que un par de Offsets en 00, corregían ambas vulnerabilidades y me daban pie a sacar un nuevo proyecto en VB6. El parche muestra en hexadecimal, la opción de seleccionar los caracteres y la localización en el binario a modificar, más de un avispado le habrá sacado similitud a un AVFucker, ya que si lo desean también puede hacerse con tal función.


Ya que dependiendo de la versión de UniGUI y del proyecto, la ubicación del valor vulnerable puede cambiar, me armé una opción más simple programada en ensamblador y compilada con MASM. Gracias a un código similar de diablo2oo2, que modifica ambos Offsets y corrige la vulnerabilidad para todas sus versiones, buscando una cadena exclusiva de este tipo de binarios, logré modificarlo.


El resultado a la inyección, sería el siguiente:


Ahora sí, reportaré al equipo de desarrollo, algo que posiblemente les haga ver lo que planteé anteriomente de forma más clara... ¿Qué loco iba a corregir un XSS con un editor hexadecimal?

Saludos 4n4les! ;)