Recuperar dispositivos de sonido en Windows Vista y Windows 7 (Un pequeño homenaje a Windows Técnico)

Hace ya muchos años comenzamos en la antigua Informática 64 con el mundo de los blogs. Sin saber para nada cómo funcionaba este mundo comenzamos a escribir en un blog en Enero de 2008 llamado Vista-Técnica que luego evolucionó un año después a Windows Técnico. Durante seis años y menos, desde Enero de 2009 a Agosto de 2014 publicamos muchos artículos sobre temas muy diversos. Hace ya casi un año que, metidos en la vorágine de Eleven Paths, no hemos podido dedicarle mucho tiempo, así que estamos pensando en cerrarlo.

Figura 1: Un pequeño homenaje a Windows Técnico

Los contenidos, gracias a Archive.org se podrán seguir localizando en el archivo de Internet, y yo voy a rescatar algunos temas en varios ficheros PDF que voy a subir a mi canal SlideShare para que perduren. De todos ellos, como homenaje a ese blog, si he de seleccionar un post, sería este que escribió un joven Pedro Laguna en sus primeros tiempos en el SOCtano de Informática 64. Lo he usado muchas veces por la cantidad de comentarios que generó - dejando claro que la característica de Windows 7 no estaba correctamente diseñada - así que he subido el post a formato PDF con todos los comentarios (que son cientos) y el texto aquí.

Figura 2: Recuperar dispositivos de sonido en Windows Vista y Windows 7

No es verdad que cualquier tiempo pasado fue mejor, ya que la cabeza tiende a olvidar lo malo y dulcificar lo bueno, pero es cierto que el leer este post me lleva directamente a aquellos años y la historia de los "10 negritos" (Parte 1 y Parte 2) que no me cansaré de contar una y otra vez en las fiestas con amigos. Este post es un gracias a todos los que habéis trabajado alguna vez en Informática 64, habéis posteado alguna vez en Windows Técnico o habéis pasado por ese SOCtano alguna vez en vuestra vida.

Saludos Malignos!

Recuperar dispositivos de sonido en Windows Vista y Windows 7

Hoy voy a contaros un pequeño truco que os puede salvar de toda una tarde de frustración y desesperación. Os lo digo porque a mí me ha pasado y no quiero que más gente se tire de los pelos como hice yo. Mi problema fue que hace poco compre un micrófono y, al conectarlo, no funcionaba de una manera correcta (Era cuando aun tenia la beta de Windows 7 por lo que supuse que sería problema de los drivers...). Intentando hacerlo funcionar me dirigí hacia el panel de control, más concretamente hacia la zona de Sonido.

Figura 1: Opciones de hardware y sonido en el panel de control de Windows

Desde aquí, y haciendo clic sobre la zona de administrar dispositivos de audio, se accede a la lista de altavoces y micrófonos instalados en nuestro equipo. En este caso, como se puede ver, disponía de mi micrófono correctamente detectado.

Figura 2: Dispositivo de grabación detectados

Sin embargo no acababa de funcionar bien, se escuchaba al intentar grabar algo como “pssggsshhsppsss…” así que, intentando arreglarlo, entre en sus propiedades. Allí, toqueteando los parámetros (soy informático, no músico) al final acabe deshabilitando el dispositivo, esperando que al volver a conectarlo el dispositivo funcionase correctamente.

Figura 3: Deshabilitar el dispositivo micrófono

¡Cual fue mi sorpresa cuando al volver a conectar mi micrófono este ya no se encontraba disponible! ¡No encuentro mi micrófono! ¿Dónde esta mi micrófono? Durante un rato estuve probando todo aquello que se me ocurrió: reinstalar drivers, reiniciar, volver a conectarlo, etcétera. Y nada de eso parecía funcionar… 

Cuando ya estaba a punto de darlo por perdido recordé una frase que había leído hace poco: En Windows 7 hay que hacer clic derecho en todos sitios, ¡hay nuevos menús escondidos en todas partes! Con esta idea y la ventana de los dispositivos de audio abierta descubrí la solución: Por defecto la ventana solo muestra los dispositivos habilitados, si queremos volver a habilitar un micrófono o altavoz deshabilitado tenemos que mostrarlo primero.

Figura 4: Mostrar dispositivos deshabilitados

Realmente esto es algo muy simple, tan simple que no se me ocurrió hasta pasado un buen tiempo… Como seguro que a más de uno le ha pasado o le pasara expongo aquí este tema para que sirva de guía para todos aquellos que se encuentren perdidos, tanto como sus dispositivos de audio.

Un saludo y recordad el dicho: Quien canta su mal espanta,

Pedro Laguna (@p_laguna)
Fecha: 13 de Mayo de 2009
Joven Padawan en Informática64

El servidor LifeRay "descuidado" de Apple

Este jueves en el evento de Eleven Paths entregué los premios del Latch Plugin Contest a los ganadores del concurso. Como tenéis publicado en la web de los ganadores, el tercer premio fue para una implementación de Latch para LifeRay, que se llevó su premio de 1.000 USD. En el evento, los ganadores subieron al escenario a contarnos sus plugins, y mientras yo escuchaba la parte del plugin de Latch para LifeRay, mi cabeza estaba haciendo memoria... ¿dónde había visto yo un servidor LifeRay no hacía mucho?

Entonces me acordé, lo había visto en un dominio de Apple.com. No esperes leyendo este post grandes bugs, sino pequeños detalles de seguridad sutiles que pueden dejar un servidor de una gran empresa menos fortificado que el resto por descuidar pequeños detalles. Solo os voy a contar mis reflexiones al respecto.

Figura 1: El servidor LifeRay descuidado de Apple

Había llegado a ese servidor tiempo atrás gracias al módulo de descubrimiento de Faast, pero para cualquiera que busque un rato no es muy difícil dar con él en Internet. Está en un dominio que cuenta con un certificado digital renovado no hace mucho, lo que parece indicar que tiene cierto mantenimiento. Lo que llama poderosamente la atención es que, cuando llegas a él, lo único que se ve es una página por defecto de una instalación recién hecha de LifeRay.

Figura 2: Aspecto del portal de LifeRay en el dominio de Apple.com

Por supuesto, es imposible no ver la versión de LifeRay que aparece en el pie de la plantilla, donde se ve que es la versión LifeRay Portal Community Edition 6.1.2 de Agosto de 2013. Casi dos años de antigüedad en un software hace más que probable que existieran algunos bugs sin parchear. Lo cierto es que existen algunos, como este CVE-2014-2963 que permite inyectar XSS en algunas partes del sistema, aunque también podrían haber aplicado el fix manualmente sin hacer un upgrade de versión.

Figura 3: Bug CVE-2014-2963

Para que se pudiera probar si es vulnerable o no a ese bug, se necesitaría tener acceso a tus propiedades de cuenta, así que habría que intentar acceder al sistema. Cuando intentas hacer login te lleva a la web de registro de cuentas Apple, pero la web cuenta con parte de registro de cuentas para el portal de LifeRay para esta instalación en concreto y sacarse una cuenta. Esto de darse de alta, muchas veces da juego en servidores WordPress que permiten esa opción y puedes sacar cosas interesantes, así que se puede probar.

Figura 4: Creación de cuentas en el servidor LifeRay

Además, como parece que está integrado con Apple.com, te puedes sacar una cuenta de AppleID y luego pedir el acceso a este portal. La autenticación se produce correctamente, pero en la fase de autorización no es posible conseguir ver los recursos, porque está protegido para algunas cuentas de algunos grupos de Active Directory. No es raro, ya hemos visto que Apple tiene mucha tecnología Microsoft internamente, desde servidores web con bugs IIS Short Name y aplicaciones en tecnologías Microsoft como hemos visto en el pasado. Recordad la famosa foto de Tim Cook en la fábrica de MacBook que usa Windows.

Figura 5: Una vez autenticado, falla la autorización para acceder a recursos

Sí que, una vez registrado, puedes jugar con las opciones de Olvidé la Contraseña para sacar información de la infraestructura de Apple que hay detrás. La idea es tan fácil como forzar que te envíe un correo electrónico con un token para cambiar la contraseña de la cuenta recién creada, tal y como se explica en este artículo de "Enviar a un amigo". Mirando el código fuente se puede ver cómo el correo se genera en localhost (el servidor web de LifeRay) y va pasando por la red de Apple.

Figura 6: Correo envidado por el servidor LifeRay con info de la red

A primera vista no he conseguido mucho más donde rascar. Corre sobre un servidor Apache 2.4.7 sin actualizar a la última versión, y tiene un servidor JSP que probablemente sea un JBossWeb, tal y como muestra este mensaje de error indexado en Archive.org. Si pruebas un foca.jsp para forzar el error JSP, da también una respuesta anómala.

Figura 7: Un error de JBossWeb cacheado en Archive.org

Como me tenía intrigado, fui a buscar más información en la red sobre ese servicio, y topé con un currículo en Linkedin que explicaba más detalles de la infraestructura que hay detrás, algo que parece corroborar lo que ya se habíamos visto de servidores LifeRay, Oracle y JBoss. Eso sí, aparecen más detalles útiles.

Figura 8: Información del proyecto en un CV de Linkedin

Lo cierto es que lo que más me sorprende sigue siendo el que esté un servidor desactualizado, configurado por defecto, en un dominio público de Apple.com sin más. No es como yo creo que deben dejarse las cosas si te preocupa la seguridad. Tal vez sea un honeypot - que parece que no por la info del perfil de Linkedin - o tal vez un descuido, a tu elección queda. Al final, la seguridad de una empresa se rompe por el punto más débil, y este no parece de los más robustos.

Saludos Malignos!

MetaShield 3.0: Control de fugas de información DLP en documentos ofimáticos en entornos empresariales

Ayer fue el día elegido para presentar al público MetaShield 3.0, una familia de productos que hemos creado en Eleven Paths para dotar a las empresas de una solución que permita gestionar el control la información que va los metadatos de los documentos ofimáticos de toda una organización gestionando todos los puntos de fuga de datos. No es una revisión más de nuestro sistema de eliminación de metadatos, información oculta y datos perdidos en documentos, es una solución de gestión para grandes empresas.

Figura 1: Familia de productos de MetaShield 3.0

Dentro de la nueva familia de productos en MetaShield 3.0 hay tres elementos fundamentales para entender cómo se ha diseñado todo el sistema, que son la consola centralizada de administración, los motores de limpieza de metadatos, información oculta y datos perdidos, y las soluciones de interceptación de documentos para aplicar la política de control de fugas de información dentro de la estrategia DLP (Data Loss Prevention) que se haya establecido. Vamos a verlos caso a caso.

MetaShield 3.0 Console

La pieza fundamental de esta solución empresarial es MetaShield 3.0 Console. Desde aquí se definen toda la política DLP que se va a aplicar al control de metadatos, información oculta y datos perdidos de la empresa.

Figura 2: Dahsboard de MetaShield 3.0 Console

Es una solución de administración web desde la que se pueden gestionar los siguientes elementos:

- Plantillas (Templates): Una template es una configuración de qué es lo que se quiere hacer con cada uno de los metadatos que aparezcan. Por ejemplo, una Template podría definir que se borrasen todos los metadatos, información oculta y datos perdidos a excepción de los campos Autor y Compañía que queremos re-escribir. Además, podemos añadir campos extras para, por ejemplo, poner información legal de la compañía.

Figura 3: Configuración de una Template

- Perfiles (Profiles): Un perfil es la configuración completa de una política aplicada a todos los tipos de documentos que se quiera. La idea es que por cada tipo de documento se puede configurar una Plantilla distinta, y el Profile es la configuración de todas y cada una de las Templates asociadas a todos y cada uno de los tipos de documentos.

Figura 4: Configuración de Profiles

- Motores de limpieza (Engines): La solución permite que una compañía decida si los motores de limpieza los quiere tener en el mismo equipo o distribuidos por la red para controlar la carga y la distribución de software. Desde aquí se controlan todos los motores de limpieza de la red y su configuración. 

- Equipos e Instancias: Por cada equipo se pueden tener instalados diferentes herramientas de MetaShield 3.0 para aplicar la configuración de la política DLP en las herramientas que monitorizan los clientes de Outlook, de Internet Information Services, SharePoint, Windows o File Servers. A cada una de esas instancias - o a todas a la vez - se les va a asignar un Perfil (Profile) completo desde la consola centralizada.

Figura 5: Configuración de políticas de equipos e instancias de MetaShield

Con esta herramienta el administrador de la política DLP de la compañía puede gestionar la configuración de toda una red de equipos clientes y servidores desde un único punto central y forzarla a toda la empresa.

MetaShield 3.0 Engine

El motor de limpieza de metadatos, información oculta y datos perdidos de MetaShield 3.0 es un servicio independiente que funciona con un API REST al que se le puede pedir localmente o de forma remota que limpie, cambie o añada metadatos a todos los documentos que soporta.

Figura 6: Configuración de MetaShield 3.0 Engine

Su configuración se gestiona desde la consola de administración a la que esté subyugado. Esta disociación del motor y la herramienta de interceptación de documentos permite una mayor flexibilidad a todos niveles, e integrar nuestras soluciones de limpieza de documentos en otras arquitecturas como Linux, Apache, Mac OS X o WAFs que pueden interceptar el documento y pedir al engine que le de servicio remotamente.

MetaShield 3.0 for IIS

Este es el primer producto que creamos, y en esta evolución ha mejorado su arquitectura. Como se puede ver en la imagen, el Engine sigue siendo de lo más rápido y garantizar que un documento sale de tu empresa con la política DLP que tú hayas definido es cuestión de unos milisegundos nada más, tal y como se puede ver en la siguiente imagen.

Figura 7: MetaShield 3.0 for IIS

En el cálculo de los tiempos se tiene en cuenta todo el proceso que toma la limpieza de los archivos, desde que se accede a él hasta que se retorna limpio al cliente.

MetaShield 3.0 for File Servers

Esta es una solución que permite monitorizar las carpetas de un servidor para garantizar que todos los documentos quedan con la política DLP de la empresa. Para ello, se utilizan "watchers" en el sistema de ficheros y cada vez que un documento es creado o modificado, éste es enviado al Engine para que le aplique la Template que le corresponde según el Profile que le hayan configurado a MetaShield 3.0 for FileServer.

Figura 8: MetaShield 3.0 for File Servers

Además, esta herramienta gestiona la configuración de carpetas de Backup para guardar las configuraciones originales de los documentos - si se desean conservar - en otra ubicación.

MetaShield 3.0 for Outlook

Este es quizá uno de los más cómodos y deseados, basta con activarlo y a partir de ese momento cada correo electrónico que lleve adjuntos, cuando se de a enviar, enviará los ficheros al Engine, los limpiará y saldrán por el correo electrónico con la política DLP que se haya establecido.

Figura 9: MetaShield 3.0 for Outlook

En esta captura se puede ver el proceso de limpieza de los archivos, pero no es necesario ni que se muestre esa pantalla, por lo que el proceso sería totalmente transparente al usuario.

MetaShield 3.0 Client

Esta es la solución de EndPoint que permite a los usuarios algo tan sencillo como seleccionar un documento y con el botón derecho del ratón acceder a la opción de Clean del documento ... y ya está.

Figura 10: MetaShield 3.0 for Clients

Una vez que el documento esté limpio ya se puede copiar en pendrives, enviar por un webmail, firmar digitalmente - por eso de no firmar digitalmente las fugas de información de tu empresa - o lo que se desee hacer con él, pero con la política DLP establecida.

MetaShield 3.0 for SharePoint, MetaShield Forensics, MetaShield Analyzer y PoCs

Además de estas soluciones, están la versión de MetaShield 3.0 for SharePoint y las versiones Stand Alone de todos los productos - sin la consola de administración - , la solución para los equipos de seguridad de las empresas MetaShield 3.0 Forensics y la versión web que tienes disponible online y que te permite ver si un documento tiene metadatos MetaShield Analyzer. Si quieres más información, tienes todos los productos en la nueva Web de MetaShield 3.0 y si quieres probar estos productos, ponte en contacto con nosotros y vemos como armar un piloto.

Saludos Malignos!

Spam con Phishing para robarte Tokens OAuth de tus cuentas de Microsoft o Google

Últimamente me he topado con muchos casos de personas que han sufrido un espionaje y robo de sus cuentaas de Google y Microsoft Live con un truco bastante sencillo y bien pensado. Se trata de conseguir unos Tokens OAuth que autoricen al atacante a acceder a las partes de la cuenta que le interesen. Con el Token OAuth con los permisos correctos, una atacante podría acceder a todos los datos de la cuenta, además de realizar múltiples acciones con la cuenta, como enviar correos electrónicos, leer tus mensajes, descargarse tu lista de contactos, etcétera.

Figura 1: Spam con Phishing para robarte tokens OAuth de tus cuentas Microsoft o Google

Para entenderlo, digamos que las cuentas de Microsoft, Google, Facebook o Twitter, tienen una serie de datos en ellas, además de una serie de funciones. Cuando se quiere autorizar a un tercero, por ejemplo una aplicación que configure el calendario de eventos - por poner algún caso de manipulación de cuenta -, o a un lector de noticias RSS para que lea tu dirección de correo electrónico, se debe pedir permiso al usuario. Para ello, el usuario debe aprobar que se genere un token OAuth que permitirá a cualquier app identificarse e interactuar con la cuenta con los permisos que se le hayan concedido. 

Figura 2: Esquema de flujo de funcionamiento de OAuth 2.0

Estas implementaciones de OAuth 2.0 en Microsoft se conocen como Live Connect, y en cada uno de los proveedores de identidad tiene un nombre similar, como Facebook Connect, o Mobile Connect cuando hablamos de la identidad de los números de teléfono.

Un spam con phishing para lograr el token OAuth

Para conseguir este token con permisos autenticados hay que conseguir que la víctima acepte conceder dichos permisos, así que como siempre, el recurso más fácil es el de hacer una campaña de phishing con un buen gancho. En los últimos días he visto campañas de falsos premios de Netflix, Media Mark y Spotify, que te permitían acceder a servicios gratis.

Figura 3: Correo de spam con un phishing de Spotify que lleva un enlace a una web

El enlace del "call-to-action" que lleva cada uno de estos mensajes lleva a un servidor web hackeado de alguna empresa, pero que, cada vez que se hace clic, fuerza un redirect, tal y como se puede ver en la siguiente imagen.

Figura 4: El redirect para la generación del token OAuth

El sitio al que lleva es al panel de aprobación de Tokens OAuth con permisos de acceso a la cuenta del proveedor de la identidad que se quiere robar.

Figura 5: Login para generar un token OAuth que de acceso a tu cuenta de Microsoft

En el caso de Microsoft, como es este ejemplo, llegaremos a la página de login de Live, donde se solicitará el usuario, la contraseña, y el segundo factor si fuera necesario, para poder aprobar la generación del token.

Los permisos del token OAuth

Por supuesto, el sitio es un sitio original de Microsoft por lo que para muchos usuarios puede parecer normal, pero si nos fijamos en la URL del redirect, podemos ver que estamos concediendo los permisos de: wl.signing, wl.basic, wl.emails, wl.emails_contacts. Si revisamos los permisos en la documentación de Microsoft podemos ver que esto significa lo siguiente:

Figura 6: Permisos de acceso a tu cuenta Microsoft con Live Connect

Al final, le estamos permitiendo que esa app maliciosa que ha sido creada para esta campaña, sea capaz de acceder a todos los datos de las cuentas a los que permiten los permisos que se conceden a ese token y que como veis son muchos.

Figura 7: Lista de permisos de acceso extendidos de Live Connect

Una vez que se consigan esos accesos, es fácil para la aplicación maliciosa conseguir expandiéndose como un gusano enviando nuevos correos electrónicos al resto de los contactos de la víctima para conseguir más tokens y más objetivos.

Revisar los Tokens de acceso a tu cuenta condecidos

Tanto en Microsoft, como en Google, como en Facebook, puedes revisar que apps han sido autorizadas con un Token OAuth y con qué permisos, por lo que lo suyo es que lo revises periódicamente. En el caso de Microsoft puedes ir al siguiente enlace y ver qué apps tienes conectadas, si ves algo raro, quítale el acceso.

Figura 8: Aplicaciones conectadas con una cuenta Microsoft

Lo mismo en Google, en el siguiente enlace de tu cuenta puedes ver qué apps tienes conectadas y revocarle el acceso si lo consideras oportuno.

Figura 9: Aplicaciones conectadas a una cuenta Google

Una vez más, ten mucho cuidado con los enlaces que te llegan en correos electrónicos de conocidos o amigos, pero sobre todo evita autenticarte y aprobar accesos a tus cuentas si no sabes a qué lo estás haciendo. Como recomendaciones finales, revisa periodicamente las propiedades de seguridad de tu cuenta y pon segundos factores de autenticación en todas tus identidades.

Saludos Malignos!

Migrar un exploit en Python a un módulo de Metasploit

Una de las cosas que más llaman mi atención últimamente es mirar las tripas del framework de explotación Metasploit. Al final nos damos cuenta de que tantos años de desarrollo y el apoyo de la comunidad hace de este entorno una navaja suiza con miles de funcionalidades. Preparando el Rooted Lab de este año topé con un pequeño software que proporciona un servidor web llamado Kolibri. Visitando algunos sitios de exploits, como PacketStorm o Exploit-DB, encontré uno público escrito en Python. Además, preparando el curso de Metasploit con Criptored del mes de Julio, decidí meter esta práctica.

Figura 1: Cómo migrar un exploit en Python a un módulo de Metasploit

Este exploit se aprovecha de un Stack Buffer Overflow, con CVE-2014-4158, escrito por Christian Ramirez. El exploit se encontraba testeado para sistemas operativos Windows XP SP3 en español.

Figura 2: Exploit para CVE-2014-4158

Como mencioné anteriormente, estaba probando algunas cosas para el Rooted Lab y decidí migrar dicho exploit a un módulo de Metasploit, ya que para este software no teníamos un módulo implementado en el framework. En este artículo vamos a hablar de cómo llevar a cabo la migración de este exploit a un módulo de tipo exploit en Metasploit.

Requisitos de un módulo exploit en Metasploit

En primer lugar, vamos a ver cuáles son los requisitos. Cuando creamos un módulo de tipo exploit necesitamos, al menos dos funciones. La primera es la función initialize y la segunda es la función exploit. Opcionalmente, se puede implementar la función check cuyo objetivo es indicar al pentester si el target es vulnerable o no.

Figura 3: Include de HttpClient

Otro requisito que el framework nos va a facilitar es saber cómo conectaremos con el software remoto, en este caso con el servidor web. Metasploit nos proporciona esto de forma trasparente, por lo que podemos utilizar la clase HTTPClient para interactuar con el servidor web de manera sencilla. Para poder utilizar HTTPClient se utilizará include Msf::Exploit::Remote::HttpClient.

Función initialize()

Esta función proporciona diferente tipo de información. Es la función encargada de inicializar el módulo y sus diferentes atributos, como por ejemplo la descripción de éste cuando el usuario ejecuta el comando info en la consola. Otros atributos descriptivos son Author, References, DisclosureDate o License.

El atributo Platform y Arch indican para qué plataforma y arquitectura se implementa el módulo. Esto es importante para los payloads disponibles, ya que si Platform no es Windows, no podremos configurar un Payload para este sistema. El atributo Payload es una colección de elementos, entre los que podemos destacar BadChars y Space. Badchars indica que bytes no deben ser generados por Metasploit cuando el Payload se genere.

Figura 4: Funcion initialize()

El atributo Targets indica la colección de diferentes versiones del software que son vulnerables. En este caso solo tenemos la versión Kolibri 2.0 sobre Windows XP SP3. Un parámetro muy importante es Ret, ya que en este se indica la dirección de memoria a la que apuntará el EIP cuando se realice la explotación. Esta dirección de memoria apuntará a la dirección de memoria dónde encontraremos una instrucción JMP ESP con la que conseguiremos llegar a nuestra shellcode.

Función check()

Como se comentó anteriormente, esta función indica si el objetivo es vulnerable o no. Para la implementación en este módulo se utiliza el método http_fingerprint, el cual devuelve el banner de Kolibri. Después hay que realizar la comparación, por ejemplo mediante el uso de una expresión regular, para verificar que el servidor remoto coincide con la versión de Kolibri vulnerable.

Figura 5: Implementación de la función check()

Función exploit()

Esta función es la más compleja del módulo, aunque en este caso tenemos que hacer una migración del exploit original escrito en Python. Observando el exploit de Christian podemos ver que hay una parte de 33 A’s y 20 bytes con valor ‘\x90’. Si utilizamos una transcripción tal cual, almacenamos en una variable basura las 33 A’s y utilizando make_nops generamos 20 nops almacenados en la variable nops.

Ahora, en la variable pay se almacena el Payload encodeado. Este valor es introducido por el pentester cuando ejecuta la instrucción set PAYLOAD [ruta payload], por ejemplo set PAYLOAD windows/meterpreter/reverse_tcp.

En el código se puede ver dos puts a modo de debbuging, ya que deberíamos utilizar funciones como print_status, print_good o print_error. Estos puts nos muestran la longitud de nops y del payload, ya que éste último es de longitud variable, ya que podemos optar por una meterpreter, una shell o la ejecución de una calculadora.

Luego toca rellenar la parte denominada junk. Aquí introduciremos C’s hasta llegar al byte 515. Para saber cuántas C’s debemos introducir se resta a la suma de nops y el tamaño variable del payload. El valor que sobreescribirá el EIP está almacenado cuando se lanzó la función initialize, por lo que para recuperarlo debemos utilizar target.ret.

Figura 6: Implementación de la función exploit

La instrucción [target.ret].pack(‘V’) recupera el valor, que es la dirección de memoria a la que el EIP apuntará y realizará el salto, y lo añade en la posición adecuada. Esto es muy importante, podríamos colocar el valor en Little Endian, es decir ret = ‘\x63\x46\x92\7c’. Ruby nos pone las cosas fáciles y con pack podemos indicarle que la dirección de memoria va en Little Endian, pero el programador la escribe tal cual, en este caso, y como puede verse en el código 0x7c924663.

Una vez configurados los trozos parciales, utilizamos la variable sploit para concatenar las diversas partes en el orden adecuado. Por último, se utiliza la función send_request_cgi para enviar la petición con el código malicioso. En este caso, el stack buffer overflow se encontraba en el envío de la URI. Se lanza un GET a la raíz y se le concatena la variable sploit y después se concatena el típico “HTTP/1.1\r\n” que nos indica la versión del protocolo.

PoC: Probando el módulo exploit en Metasploit

Tras añadir el módulo al framework, lo cargamos mediante el uso del comando use. Una vez el módulo está cargado configuramos los siguientes atributos:

• RHOST, indicándole la dirección dónde se encuentra el software vulnerable.
• RPORT, indicándole el puerto dónde se encuentra Kolibri a la escucha, por defecto el 8080.
• PAYLOAD, el que queramos que se ejecute una vez realizada la explotación.
• Si el payload es de tipo reverse, tenemos que configurar el atributo LHOST para indicar al payload dónde debe devolver el control.

En este momento ya tenemos la sesión, y vemos que tenemos el control de la máquina gracias a esta vulnerabilidad y la migración del exploit. Se puede observar los valores de los nops, del payload y de junk en el propio cuerpo del módulo. Ahora vamos a cambiar el payload por uno “de juguete”.

Figura 7: PoC de explotación del módulo exploit

El payload que vamos a utilizar es el de windows/messagebox, dónde podemos indicarle qué texto y qué tipo de message box de Windows vamos a sacarle al usuario por pantalla. Para ello ejecutamos set PAYLOAD windows/messagebox, y os recomiendo que miréis las opciones de este payload. El resultado es el que se puede ver, en la máquina dónde se ejecuta Kolibri, tras explotar la vulnerabilidad podemos encontrar un “Hello, from MSF!”.

Figura 8: Resultado tras explotar el módulo en un servidor Kolibri vulnerable

En la tercera edición del libro de Metasploit para Pentesters podéis encontrar información sobre cómo realizar módulos de tipo exploit, auxiliary, creación de scripts de Meterpreter, etcétera. Por otro lado, el día 1 de Julio, a través de Criptored, comienza el Curso Online de Especialización en Seguridad Informática para la Intrusión de Sistemas. Metasploit en Profundidad, en el que inscribiéndote recibirás el libro de Metasploit para Pentesters.

Autor: Pablo González Pérez (@pablogonzalezpe)
Escritor de los libros "Metasploit para Pentesters" y "Ethical Hacking"

WordPress: 0day XSS almacenado en plugin WP-UserAgent

Hace ya un tiempo me acuerdo de haber leído un post en el blog de Chema Alonso sobre cómo explotar vulnerabilidades XSS (Cross-Site Scripting) utilizando el User Agent en sitios que permiten mostrar esta información en una página web. Desde ese instante me pareció bastante interesante óomo algunos sitios webs utilizaban la información provista en las cabeceras de las peticiones para personalizar el contenido dependiendo del tipo de navegador que utilicemos. Tomando en consideración este escenario se me ocurrió la idea de ver si este tipo de ataque se podía replicar en otras plataformas, no siendo muy complejo lograr encontrar casos similares.

Figura 1: Bug 0day de XSS en  el plugin WP-UserAgent de WordPress

Lo primero que se me ocurrió fue buscar algún plugin que realizara esta tarea, llegando a WP-UserAgent. Este plugin de WordPress permite insertar un icono en cada comentario puesto por un usuario, en el que se indican además el sistema operativo y la versión navegador - entre otros parámetros - que utiliza dicho usuario.

Figura 2: Plugin WP-UserAgent

WP-useragent con más de 600 instalaciones activas.

Una vez descargado el código fuente comencé a revisar el código para ver cómo extraía la información desde el campo de User Agent y estudiar cómo la procesaba, encontrado algo bastante interesante. El siguiente fragmento de código muestra cómo se buscan cadenas dentro del valor de User Agent.

elseif(preg_match('/Xandros/i', $useragent))
{
  $link="http://www.xandros.com/";
  $title="Xandros";
  $code="xandros";

  if(preg_match('/x86_64/i', $useragent))
  {
    $title.=" x64";
    }
  }

Figura 3: Ejemplo tipo de identificación useragent

En general el funcionamiento es bastante simple, se detecta una cadena específica y se asignan textos ya preestablecidos, así no se utiliza directamente la información del valor de User Agent salvo por un caso particular para los dispositivos Mac OS X.

elseif(preg_match('/Mac/i', $useragent) || preg_match('/Darwin/i', $useragent))
{
  $link="http://www.apple.com/macosx/";

  if(preg_match('/Mac OS X/i', $useragent))
  {
    $title=substr($useragent, strpos(strtolower($useragent), strtolower("Mac OS X")));
    $title=substr($title, 0, strpos($title, ")"));

    if(strpos($title, ";"))
    {
      $title=substr($title, 0, strpos($title, ";"));
      }

    $title=str_replace("_", ".", $title);
    $code="mac-3";
    }
  elseif(preg_match('/Mac OSX/i', $useragent))
  {
    $title=substr($useragent, strpos(strtolower($useragent), strtolower("Mac OS X")));
    $title=substr($title, 0, strpos($title, ")"));

    if(strpos($title, ";"))
    {
      $title=substr($title, 0, strpos($title, ";"));
      }

    $title=str_replace("_", ".", $title);
    $code="mac-2";
    }
  }

Figura 4: Código fuente de WP-useragent para identificar la versión exacta de OS X

En el caso de los dispositivos Mac OS X el proceso de identificación es distinto. En primer lugar si el User Agent contiene la cadena "Mac" o "Darwin" entra en la sección vulnerable. Luego se revisa si en $useragent posee la cadena "Mac OS X" o "Mac OSX", en ambos casos se ejecuta la misma porción de código duplicado. Se limpia el inicio del valor de useragent hasta la ocurrencia de la cadena "Mac OS X" (en el caso de "Mac OSX" no funciona). Luego limpia la parte final de useragent, sin embargo se utiliza como identificador el carácter ")", eso significa que todo código que este antes de este carácter no será filtrado. Ya en última parte se intenta acortar el string title utilizando como identificador el carácter ";" y reemplazar todos los guiones bajos por puntos.

Explotación del bug de XSS en WP-UserAgent

Este escenario nos permite desarrollar con cualquier plugin para cambiar queuseragent custom como por ejemplo el siguiente:

Mozilla/4.0 (Macintosh; U; PPC Mac OS X <img http:="" onerror="javascript:document.location.href=" site.com="" src="1" /&gt 10_5_8;
zh-cn) AppleWebKit/533.20.25 (KHTML, like Gecko) Version/5.0.4
Safari/533.20.27

El cual se salta las restricciones y filtros generando un Stored-XSS que se ejecuta cada vez que visualiza el comentario asociado que se generó con el plugin WP-UserAgent activo. Acá una pequeña PoC sobre este ejemplo:


Figura 5: Prueba de Concepto de Stored-XSS en plugin WP-UserAgent de WordPress
Consideraciones finales sobre la explotación del XSS almacenado

• El código a inyectar no debe utilizar el string ")".
• El código a inyectar no debe utilizar el string ";".
• El código a inyectar cambiará todos los "_" por ".".
• La versión 1.0.5 del plugin (única) es vulnerable.

Una vez encontrada la vulnerabilidad notifiqué al desarrollador y a la gente de WordPress de forma inmediata, sin embargo no obtuve respuesta hasta esta semana, donde me contactó la gente de WordPress indicando que por el gran volumen de correos que les llega normalmente no habían podido responder antes.

Figura 6: WP-UserAgent ha sido deshabilitado en WordPress.org

Como acciones a tomar han notificado al desarrollador sobre la vulnerabilidad  - ojalá les responda a ellos al menos - y momentáneamente lo han dado de baja de la lista de plugins de WordPress. Si lo tienes configurado en tu servidor WordPress, anúlalo temporalmente.

Autor: Marcelo Clavel G.
Ing. Civil Informático de Chile

Exposición insegura de WebServices .NET en apps Android

Aunque cada vez más en desuso, todavía podemos encontrar bastantes servicios web desarrollados en .NET utilizando ASMX, y curioseando en nuestra plataforma Tacyt en búsqueda de posibles servicios web expuestos que implementen esta tecnología uno puede descubrir un buen número de aplicaciones que hacen uso de ellos, tal y como se puede ver en la Figura 2.

Figura 1: Exposición insegura de servicios web .NET en apps Android

Una de las curiosidades de este tipo de servicios es que, dependiendo de la versión utilizada de .NET y de la configuración establecida en el fichero web.config bajo el elemento <WebServices>, se puede proveer cómodamente una forma de testear un webservice a través de un simple botón.

Figura 2: Aplicaciones Android en Tacyt con links que apuntan a webservices

Para conseguir esta ejecución, basta con pulsar el botón Invoke, tal y como se puede ver en la Figura 3. Esta facilidad de botón gordo (habilitada por defecto sólo para pruebas locales en sus últimas versiones) no supone un riesgo mayor que la exposición de un servicio que no disponga de las medidas de seguridad adecuadas, ya que si encontramos dicho botón deshabilitado podremos suscribirnos al servicio igualmente e invocar a los servicios web a través de un cliente.

Figura 3: Botón de Invoke para ejecutar un webservice

Sin embargo esta facilidad puede llegar a suponer un riesgo doble al facilitar un posible abuso por parte de un usuario malintencionado que esté inspeccionando, por ejemplo, aplicaciones Android. La siguiente imagen muestra cómo en los enlaces de una app se puede llegar a localizar información de webservices fácilmente.

Figura 4: enlaces de una app de Android con links a webservices

Entre los ejemplos de servicios web expuestos que me han llamado la atención por su falta de seguridad destacaría por ejemplo el siguiente listado de información de usuarios basado en un ID que se le puede facilitar e incluso por el que se podría iterar para obtener un volcado de cuentas de correo y passwords (en este caso pasadas por una función hash):

Figura 5: Un Webservice descubierto en una app de Android que devuelve los datos de las cuentas

Curiosamente bajo ese mismo servicio web existe otro método web que sin solicitar ningún tipo de credenciales de forma adicional permiten el borrado dado un ID… ¿peligroso verdad?:

Figura 6: Webservice para borrar una cuenta de usuario

Otro ejemplo interesante lo he encontrado en un conocido juego de billar que nos permitirá listar todas las partidas en curso que están realizando los jugadores:

Figura 7: Webservice para acceder a los datos de las partidas

Y por el mismo precio, eliminarlas:

Figura 8: Webservice para eliminar todas las partidas del juego

Podemos llegar incluso a encontrar servicios que, por el mero hecho de ser invocados, provoquen errores devolviendo información como nombres de bases de datos, tablas, columnas, relaciones…

Figura 9: Leaks de información conseguidos a través de un webservice inseguro

O como explicábamos en un principio, servicios que no disponen de ese botón gordo Invoke…

Figura 10: Webservices sin botón "Invoke"

… pero que igualmente nos permitirán realizar una suscripción al servicio:

Figura 11: Invocación del webservice. Se puede hacer también con SoapUI.

Reflexiones finales

Finalmente y sacando algunas conclusiones sobre estas líneas:

- Todo servicio expuesto debe implementar los mecanismos de seguridad que le apliquen según su criticidad y funcionalidad. Cifrado, autenticación y autorización son nuestros aliados cuando tenemos información sensible, contenido al que sólo se puede acceder si se es reconocido como un usuario válido del sistema o cuando necesitamos una granularidad fina como para que un determinado método web sólo lo ejecute un usuario concreto. 

- Recordar que cualquier código entregado al cliente (como lo es una app Android) es susceptible de ser analizado de forma estática y dinámica, de modo que cualquier servicio externo finalmente quedará expuesto. 

- Y esto último ya más como un apunte curioso, es interesante ver como aunque Microsoft recomienda utilizar WCF frente a ASMX, si buscamos las apps publicadas desde hace 3 meses encontraremos bastantes más servicios ASMX:

Figura 12: Los WebServices con ASM siguen siendo más usados que en WCF

Autor: Miguel Ángel García (@nodoraiz)
Software Engineer en Eleven Paths