Actualiza WordPress: Dos plugins muy populares con fallos graves de seguridad

El mundo de las plataformas WordPress es muy dinámico a la par que interesante. Es el mayor CMS (Content Management System) desplegado en el mundo, el que mayor cuota de mercado tiene y, sin duda, es uno de los más investigados en busca de fallos de seguridad y es, además, el más atacado por los cibercriminales. En esta ocasión investigadores han descubierto vulnerabilidades que afectan a dos plugins de WordPress bastante populares.

Figura 1: Actualiza WordPress: Dos plugins muy populares con fallos graves de seguridad

Los plugins pertenecen a un editor/propietario llamado Revmak. El primer plugin a tratar es el de InfiniteWP, el cual permite a los administradores poder gestionar múltiples sitios de WordPress con una sola interfaz. Es útil para aquellos que tienen que administrar diferentes sitios. El segundo plugin es WP Time Capsule que, como no puede ser de otra forma, es una herramienta para llevar a cabo copias de seguridad y organizar sitios. Estos plugins están siendo utilizados entre 300.000 y 500.000 sitios para InifinteWP - se hace difícil calcular los entornos de Intranet - y unos 20.000 o más para WP Time Capsule.

Figura 2: Módulos del proceso de análisis de vulnerabilidades en plugins de WordPress

Esto nos recuerda al trabajo que hicimos en Ideas Locas hace unos años donde se analizaba el código fuente de una gran cantidad de plugins y se analizaba el código en busca de vulnerabilidades. Este trabajo viene derivado de uno más antiguo, del cual salió un script llamado OSB-Rastreator. Se encontraron plugins con vulnerabilidad que estaban desplegados en una gran cantidad de sitios con WordPress, por lo que como se puede ver es algo parecido a lo que ha sucedido.

Figura 3: Flujo de ejecución de los subsistemas de análisis de bugs en plugins de WordPress

El resultado, después del proceso que hicimos con todos los plugins públicos oficiales, para recordarlo fue el siguiente que podéis ver en la tabla, donde varios muy populares tenían bugs que se pudieron descubrir con nuestro motor de análisis.

Figura 4: Principales 0-days descubiertos en plugins WP en el proceso de análisis

A continuación, puedes ver los diferentes papers en lo relacionado con esto último que he comentado. Tanto la detección de vulnerabilidades por el uso de funciones inseguras como la detección de vulnerabilidades en plugins de WordPress con diferentes técnicas analizando el código.

Figura 5: Detección y estimación de vulnerabilidades en plugins de WordPress

Figura 6: Detección de funciones inseguras en repositorios de software libre

Lo importante aquí es que se debe actualizar lo antes posible si tienes estos plugins de WordPress. ¿Por qué? Según la empresa que informó de todo esto, indicó que un atacante puede acceder a las cuentas de administrador sin uso de la contraseña.

El bypass de InfiniteWP se encontró en la función iwp_mmb_set_request, la cual es utilizada para comprobar si el usuario está intentando una acción autorizada. Dos métodos que lo hacen son readd_site y add_site, pero ninguna de éstas implementa una comprobación de autorización, por lo que un atacante puede crear una petición maliciosa. ¿Cómo? Solamente sabiendo el nombre del usuario del administrador - y si no has fortificado tu WordPress enumerar usuarios no es muy complicado -. Una vez se realiza la petición con el parámetro adecuado, se valida y se accede como usuario administrador. Fácil y sencillo.

Figura 7: Libro "Máxima Seguridad en WordPress" de 0xWord
para aprender a Fortificar plataformas WordPress

En el plugin  WP Time Capsule puede que el fallo sea aún más sencillo. El resultado es muy similar. Lo único que el atacante hace es incluir la cadena de texto IWP_JSON_PREFIX en la petición enviada al servidor. Más fácil aún. No hace falta conocer el nombre del usuario administrador.

Como he comentado anteriormente, hay que actualizar rápidamente, ya que el desarrollador parcheó el problema al día siguiente de aparecer la vulnerabilidad. Todas las versiones de InifiniteWP son vulnerables hasta la 1.9.4.4. La 1.9.4.5 ya no lo es. En el caso de WP Time Capsule todas las versiones hasta la 1.21.15 son vulnerables, mientras que la 1.21.16 ya no lo es.

Foritificar WordPress: Faast for Wordpress, WordPress in Paranoid Mode

Como ya sabéis, hace tiempo que en ElevenPaths se lanzó una versión especial de Faast - nuestro servicio de Pentesting Persistente, para dominios con plataformas WordPress al que llamamos Faast For WordPress y del que hablamos por aquí en el blog en el artículo titulado: "Faast for WP: Pentesting as a Self Service para tu WordPress".


Figura 8: Faast por WordPress
Después, si quieres tener un entorno bien fortificado, lo mejor es que leas el libro de "Máxima Seguridad en WordPress" de Daniel Maldonado, al que puedes preguntar cualquier duda a través de su buzón público en MyPublicInbox.

Figura 9: Contactar con Daniel Maldonado en MyPublicInbox

Y si quieres conocer todo el trabajo que hicimos para configurar un "WordPress in Paranoid Mode", puedes leerte los dos papers que publicamos:

- WordPress in Paranoid Mode (I de II) 

- WordPress in Paranoid Mode (II de II)

Y sobre todo ver la charla de Chema Alonso de "Cómo Fortificar WordPress Like Hacker" donde explica con demos todos y cada uno de los procesos de fortificación de WordPress para que sea una plataforma mucho más segura.


Figura 10: Fortificar WordPRess Like a Hacker
Más Referencias:

[Libro] Máxima Seguridad en WordPress
[Libro] Hardening GNU/Linux
[Paper] WordPress in Paranoid Mode (Parte 1)
[Paper] WordPress in Paranoid Mode (Parte 2)
[Paper] Detección y estimación de vulnerabilidades en WordPress
[Vídeo] Proteger WordPress con Latch
[Vídeo] Proteger WordPress con Latch Cloud TOTP
[Vídeo] MyWordPress in Paranoid Mode (conferencia Chema Alonso)
[Vídeo] MyWordPress in Paranoid Mode (ElevenPaths Talks de Pablo González)
[Vídeo] Ejemplo de uso de Latch en WordPress
[Vídeo] Hardening WordPress like a hacker
[Vídeo] WordPress Demo XSS en WP-UserAgent
[BlogPost] My WordPress in Paranoid Mode
[BlogPost] Máxima Seguridad en WordPress
[BlogPost] Hackear un WordPress con Network Packet Manipulation
[BlogPost] Fortificar comunicación entre WordPress y MySQL
[BlogPost] WordPress Latch Enforcement
[BlogPost] WordPress aún más seguro con Latch Lock After Request
[BlogPost] Fortificar WordPress frente a ataques de fuerza bruta
[BlogPost] Ataques (al corazón) de tu WordPress
[BlogPost] Cómo robarle las contraseñas a los administradores de WordPress
[BlogPost] Agrupar el control de varios WordPress con un solo Latch
[BlogPost] WordPress: Time-Based XSPA (Cross-Site Port Attack)
[BlogPost] Cómo debería ser un WordPress un poco más seguro
[BlogPost] WPHardening: Automatizar fortificación de WordPress
[BlogPost] Protege los borradores de los artículos de tu WordPress
[BlogPost] Registro de cuentas en WordPress públicos
[BlogPost] Riesgos en la ejecución de tareas de Cron
[BlogPost] WordPres: XSS en plugin WP-UserAgent
[BlogPost] MySQLDumper: Un script de backup que no debes publicar en tu WP
[BlogPost] Listar los plugins de WordPress en un pentest
[BlogPost] WordPress: SQL Injection en Scarcity Builder Plugin
[BlogPost] Docker WordPress in Paranoid Mode
[BlogPost] Faast for WordPress
[BlogPost] Cómo buscar {y encontrar} 0days en plugins de WordPress
[BlogPost] WordPress Stored XSS: Nueva vulnerabilidad para tu CMS. Actualiza.

Saludos,

Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root",  “Pentesting con Powershell” y de "Empire: Hacking Avanzado en el Red Team", Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDCO de Telefónica.
Para consultas puedes usar el Buzón Público para contactar con Pablo González

Faast: El servicio de Pentesting Persistente y el Reporte Responsable a Apple

Han pasado más de seis años desde que comenzamos a hablar de Pentesting Persistente, Pentesting Continuo, Pentesting By Design, en un momento en el que nadie hablaba de él, y donde muchas veces nos decían que era imposible. Hoy en día es una práctica muy común. Para implementar nuestra visión, nosotros cogimos el core de nuestra querida FOCA, lo transformamos en un entorno Cloud-Native, y creamos el Servicio de Pentesting Persistente Faast en ElevenPaths, del que hemos hablado muchas veces.

Figura 1: Faast: El servicio de Pentesting Persistente y el Reporte Responsable a Apple

Lejos de parar con esta visión, Faast no ha hecho más que crecer, mejorando los procesos e integraciones para ampliar la búsqueda de nuevos recursos, y optimizando los algoritmos de detección de vulnerabilidades y fallos de configuración.

Figura 2: Faast de ElevenPaths

Y aunque la idea fuese concebida en el año 2013, la evolución de la industria no ha hecho más que reforzar este planteamiento, donde los entornos mutan cada vez más rápido gracias al mayor uso de nubes, y al auge de tecnologías basadas en contenedores, cuales facilitan la puesta en producción de nuevos activos. A día de hoy muchas de las soluciones de detección de vulnerabilidades ofrecen este tipo de Pentesting Persistente, por los buenos resultaos que dan.


Figura 3: OWASP 2013 "¿Por qué los cibercriminales siempre ganan?" por Chema Alonso
Esto nos ha permitido reportar a las grandes tecnológicas diferentes vulnerabilidades que hemos encontrado analizando sus activos, como se puede ver en los agradecimientos de Microsoft y los reconocimientos de Apple, entre otras grandes empresas. Esto no es nuevo, ya antes se los daban a nuestra querida FOCA.

Figura 4: Agradecimientos de Apple a Faast Team en ElevenPaths

Pero ¿qué podemos encontrar en un análisis a una de las gandes como Apple? Lo lógico sería pensar que no encontraremos ningún problema ya que estas compañías invierten muchísimos recursos en mantener sus sistemas seguros. Pero se demuestra año tras año, la seguridad 100% no existe. En un scan rápido de Faast a la web WWW de Apple, podemos observar varias cosas que llaman la atención, algo que ya hemos visto muchas veces en el el pasado. Antes os dejamos los artículos del pasado:

- Think Different: Un Hostname sin Domain en los inversores de Apple
- Los certificados digitales que usa Apple en su CDN son de peor calidad
- Algunos backups de Apple son de una extensión "original"
- Una mirada "faast" a Apple buscando al caniche
- Un repaso al pentesting persistente tres años después en ElevenPaths
- Análisis de un HPP (HTTP Parameter Pollution) en Apple
- Apple atacada por la viagra en los servidores de iTunes
- Un HTTP Redirect no te libra de securizar un servidor web
- IIS Short Name Bug en los servidores de apple.com
- La FOCA se merece un iPad
- Un .SVN/Entries en Apple.com descubierto por la FOCA
- Apple se olvida de unas webs del siglo XX en sus servidores

En una reciente revisión, hemos visto aún muchas de las cosas que adolecía en el pasado, como podéis ver en este listado. Y ahora vamos con el presente

• Software desactualizado: en este caso un apache que en esa versión concreta dispone de ciertas debilidades, incluso detectadas este mismo año como se puede apreciar en los CVE asociados.

Figura 5: Versiones de Apache desactualizadas con CVEs

• Cabecera ‘Cross Origin’ demasiado permisiva: No es buena práctica aplicar wildcard (*) a este tipo de elementos, mejor mantener un listado de dominios permitidos.

Figura 6: Cabecera Cross Origin configurada con *

• Fichero dwsync.xml: clásico fichero que genera la aplicación Dreamweaver y no debería incluirse en un despliegue de la web. Nos puede proporcionar rutas o nombres de fichero que no deberían estar ahí.

Figura 7: Fichero DWSync.xml

• Target _blank phishing: en las etiquetas HTML <a> con el atributo target=’_blank’ no se está incluyendo la propiedad rel=’noopener’ (o noreferrer), la cual ya se comentó en este artículo que escribo Chema Alonso.

Figura 8: URLs con enlaces si rel='noopener'

• Metadatos: Una gran cantidad de metadatos, que revelan usuarios. Algunos de estos trabajadores son internos, y otros de compañías que prestan servicio a Apple. Además de diferente software con el que se crean estos documentos, que van desde las aplicaciones ofimáticas clásicas, a versiones concretas de librerías para la conversión de documentos a formato PDF.

Figura 9: Metadatos, Metadatos, Metadatos. Lista de usuarios.

• Cross-site scripting (XSS): Una vulnerabilidad de las más clásicas en entornos web. Se encuentra en el Top 10 de OWASP desde hace muchos años, y permite a cualquier visitante del sitio web ejecutar código Javascript inyectando en la propia URL del sitio web, o en alguno de sus campos de formularios.

Figura 10: XSS Reportado, corregido y agradecido por Apple (Figura 4)

Como es costumbre hemos vuelto a hacer una ‘Revelación Responsable’ de estos problemas, algunos considerados vulnerabilidades, y otros como relajación de la configuración. Apple lo ha recibido de buen grado y nos ha agradecido la colaboración para mantener sus servicios más seguros.

Figura 11: Client-Side Attacks: XSS, CSSP, SSRF, XSPA, SSJS

Por ahora tiene varias vulnerabilidades que está pendiente de corregir, así que os contaremos más de ellas cuando las hayan corregido. Os recomiendo el libro de Client-Side Attacks de Enrique Rando, que explica bien cómo descubrir y explotar estas vulnerabilidades.

Autor: Ioseba Palop, Senior Software Architect Faast team (Contactar con Ioseba Palop)

CyberMonday en @0xWord y en @ElevenPaths #CiberLunes #CyberMonday

Desde hace algunos años existe el CyberMonday, o el CiberLunes, donde se da una segunda oportunidad vía servicios de e-commerce al famoso BlackFriday. Y nosotros nos hemos sumado desde ElevenPaths y desde 0xWord a la edición de este año.

Figura 1: CyberMonday en 0xWord y en ElevenPaths

En 0xWord venimos sumándonos a esta iniciativa los últimos años, y vamos a tener un descuento del 10% en todos los productos. Es decir, en los Vídeo-Books, en los pósters, cómics, y pegatinas de 0xWord Cómics, en los packs oferta, en el peluche y pendrive de Cálico Electrónico y en todos los libros tanto de lectura en 0xWord Pocket como de 0xWord que forman el Máster de Seguridad.

Hoy es el CyberMonday en 0xWord y tienes un 10% de descuento en todos los productos con el código CYBERMONDAY2018 https://t.co/SOoEwx4fmy pic.twitter.com/M1CIVg7rsh

— 0xWORD (@0xWORD) 26 de noviembre de 2018

Para obtener este descuento debes utilizar el código CYBERMONDAY2018 cuando vayas a finalizar la compra, y automáticamente recibirás un 10% de descuento que podrás utilizar tanto para entrega en tienda como para envío por correo.

Figura3: Master en Ciberseguridad con 0xWord

En ElevenPaths hemos puesto dos productos Online al 50% de su valor, para que puedas disfrutar de ellos a un precio más que asequible. Son mASAPP Online y Faast for WordPress

- mASAPP Online: Este producto permite realizar un análisis de aplicaciones móviles para prevenir ataques de actores maliciosos. De este modo, avisa de comportamientos que realiza la app que pudieran afectar a la reputación del usuario. De forma muy sencilla, se sube un fichero a la aplicación para que esta lo analice y acto seguido, obtienes recomendaciones de medidas correctivas.

Figura 4: mASAPP Online

- Faast for WordPress: WordPress se ha convertido en el CMS de más rápido crecimiento en todo el mundo. Por ello, es una de las plataformas más atacadas, divulgándose sus errores públicamente. Además, el software y la infraestructura utilizada por un sitio WordPress también están sujetos a ataques. Faast for WordPress es una forma simple y cómoda pero efectiva de detectar todos estos errores que son difíciles de rastrear por un administrador.

Figura 5: Faast For WordPress

Estas ofertas solo duran 24 horas y para contratarlos solo debes registrarte en la página de las herramientas mASAPP Online y Faast for WordPress, y suscríbete al producto. Te dejamos aquí los links para que te sea más sencilla la suscripción:

- Contratar mASAPP Online en CyberMonday 

- Contratar Faast For WordPress en CyberMonday

Por supuesto, si deseas contratar el servicio de Faast for WordPress, el complemento ideal es el libro de Máxima Seguridad en WordPress de 0xWord, para que tu CMS esté lo más seguro posible contra los ataques online.

Saludos Malignos!

"El leak del login: Cómo evitar fugas de información en la creación y recuperación de cuentas en aplicaciones web que pueda usar cualquier Cambridge Analytica

Tener una cuenta en un determinado servicio puede decir mucho de una persona. Por ejemplo, si alguien se saca una cuenta en un sitio web para amantes de la pesca, probablemente es porque le guste la pesca. Si alguien se saca una cuenta en un sitio de contactos adultos de personas del mismo sexo, probablemente esté reflejando una determinada tendencia. Si alguien se saca una cuenta en una web de un equipo de fútbol quizá es porque tenga afición por él.

Figura 1: Cómo evitar fugas de información en la creación y recuperación de
cuentas en aplicaciones web que pueda usar cualquier Cambridge Analytica

Siempre son "quizás", y "puede qué", pero para las empresas que se dedican, como hacía Cambridge Analytica, a perfilar a los ciudadanos de un determinado, país o región, es información muy valiosa, y por tanto se venden y se compran bases de datos con esos datos. 

Figura 2: Información de Cambridge Analytica en Wikipedia

Datos que pueden reflejar mucho de ti, ya que al final tú te sacas cuentas en los sitios que te suelen aportar algo, o que parece que te los pueden aportar al principio. Como dice en la Wikipedia de Cambridge Analytica, entre 4.000 y 5.000 datos diferentes de cada individuo. No está mal.

El e-mail con nombre de usuario

Ya he hablado mucho de esto, pero básicamente hay algunas identidades que te identifican más que ninguna otra. Lo más probable es que tu número de teléfono cambie poco a lo largo de tu vida, o que tus cuentas de Gmail, Outlook, y pocas más, te acompañen para el resto de tu vida. Son parte de ti. Son tus correos electrónicos de piedra de clave que te identifican.

Y es por eso que la mayoría de los servicios online utilizan como identificador único esos elementos. Si te quieres sacar una cuenta de correo electrónico en Yahoo!, Gmail u Outlook, lo más probable - según el país en el que estés - que te pidan un número de teléfono como verificación.

Sin embargo, si te sacas una cuenta en cualquier otro servicio, es probable que validen que tú eres tú contra tu cuenta de correo electrónico. Es el identificador único más utilizado en servicios online. Una cuenta de correo electrónico que se usa, normalmente, para recuperar la cuenta del servicio de Internet al que te has registrado.

El leak en la creación de la cuenta del servicio

En el proceso de creación de la cuenta, y también en el de la recuperación de la contraseña, se suele pedir una cuenta de correo electrónico. Bien para saber si puedes crear o no la cuenta con esa dirección de e-mail, bien para saber si puedes recuperar o no la contraseña de esa cuenta.

Lo cierto es que en la mayoría de los servicios en Internet hay fugas de información - los llamados "leaks" - que permiten saber si la cuenta existe o no en ese servicio. Es decir, una empresa que tenga 20 millones de direcciones de correo electrónico podría probarlas una a una contra el servicio de Internet - por ejemplo la página de los amigos de la pesca - y saber si los dueños de esas direcciones de e-mail se han sacado una cuenta en ese servicio o no. Y así enriquecer la base de datos con más información.

Esto es algo muy común, como por ejemplo el caso que os publiqué con las cuentas de Grindr, lo que permitía - ya parece que lo han arreglado -, que cualquier empresa "Cambridge Analytica" se dedicara a saber qué personas tenían cuenta en ese servicio.

El fallo y la solución

El error es muy común, y muchas veces se produce solo porque "no parece tan importante" esa información. O por lo menos no lo parecía antes. Ahora que hemos visto que cualquier dato es importante, nos tomamos mucho más en serio la privacidad de nuestras aplicaciones web.

En el caso de ElevenPaths hemos cambiado absolutamente todos los procesos internos de desarrollo para meter en QA una verificación de estos leaks de información, y hemos cambiado muchas aplicaciones web que, como la de nuestro querido Latch, era "verbose" y daba un leak que no queríamos tener - y que hemos quitado -.

Figura 3: Un leak que informaba de que la cuenta existía

El error se produce por que el mensaje de error de que la cuenta existe se da a la persona que introduce la cuenta de e-mail sin verificar por un instante que esa persona es la dueña de la identidad que está introduciendo.

Figura 4: Se informa al que introduce el e-mail de si la cuenta existe o no

Para evitar eso el mensaje de error se debe enviar al dueño de esa identidad de e-mail, utilizando el canal de e-mail como forma de comunicación que garantiza que estamos dando la información del error al dueño de esa identidad y no a cualquiera que la introduzca.

Figura 5: Proceso sin leak de información

Esto, además, evita situaciones desastrosas como la del registro de cuentas de Uber a cuentas de e-mail por error que lleva a que pasen desgracias no deseadas, o como pasaba hace tiempo en Instagram. Salvaguardamos la privacidad de los usuarios que se dan de alta, evitamos un error en la introducción de direcciones de e-mail y verificamos que la cuenta funciona y tenemos contacto con ella. Todo son ventajas.

El mes pasado me puse muy pesado con mi equipo para que introdujera esta fuga de información como una vulnerabilidad en la detección persistente de sitios web que monitorizamos con nuestro motor de Pentesting Persistente Faast, y a partir de ahora reportaremos a nuestros clientes estos leaks con un nivel de serveridad mayor, para que lo arreglen antes. Revisa tú tus webs, que tenemos mucho que mejorar para garantizar la privacidad en Internet con la mayor de las garantías.

Saludos Malignos!

Security Rocks: Vídeos Online en Youtube

Ya están disponibles en el Canal Youtube de ElevenPaths todos los vídeos de las sesiones del pasado Security Innovation Day 2017: Security Rocks!. En ellos se pueden ver algunos de los productos e innovaciones que hemos ido trabajando durante este año 2017, y que estarán disponibles para 2018. Entre ellos el nuevo Path 8, la FOCA Open Source, Faast for WP, Security Portal, WiFi con Mobile Connect, etcétera.

Figura 1: Vídeos online en Youtube

De cada una de las sesiones vamos a ir desgranando los temas tocados en diferentes artículos en el blog de ElevenPaths, pero desde ya puedes verlas todas, incluida la última sesión de Mikko Hyppönen que nos habló del futuro que nos espera.


Figura 2: Welcome & Keynote

Figura 3: Security 4All

Figura 4: Partnership "Delivery Mode"

Figura 5: Innovation "A Path to Success"

Figura 6: Special Guest

Figura 7: Closing Session
Y esto es todo por hoy viernes. Espero que disfrutéis las sesiones y el fin de semana que se nos viene por delante.

Saludos Malignos!

Faast for WP: Pentesting as a Self Service para tu WordPress

A lo largo de los últimos años hemos ido desarrollando nuestra visión del Pentesting Persistente a través de dos herramientas, como son Faast y Vamps. Con estas soluciones hacemos un pentesting 365 días al año, 24 x 7, de la superficie expuesta a Internet de una organización, y nos permite hacer una revisión voraz de todo la infraestructura.

Figura 1: Faast for WP: Pentesting as a Self Service para tu WordPress

Durante el último Security Innovation Day 2017 presentamos la evolución de nuestras soluciones empresariales B2B para llevarlas a verticales de empresas mono-plataforma, y comenzamos por WordPress lanzando Faast for WordPress.

Figura 2: Evolución de nuestra visión del Pentesting

La aproximación que utilizamos para la construcción de esta solución verticalizada es la existencia de muchas pequeñas empresas que utilizan WordPress como único framewok en su única exposición a Internet. Es decir, que toda la infraestructura que tienen en la red es un servidor de WordPress en el que basan su negocio.

Figura 3: QRCode para garantizar la propiedad del sitio

Nosotros hemos estudiado a fondo los problemas de seguridad de WordPress, incluso sus limitaciones en arquitectura. Dichos trabajos se han plasmado en plugins para Faast, en el libro de Máxima Seguridad en WordPress y lo que se explica en la charla de Hardening WordPress like a Hacker que hicimos a finales del año pasado.

Figura 4: Resultados de las auditorías periódicas de un sitio WordPress

Ahora, hemos querido juntar todo ese en una herramienta "Self Service" en la que el administrador de un sitio pueda lanzar cuando lo desee un escaneo de seguridad a su WordPress desde nuestro servicio Faast for WordPress. Para ello debe demostrar que el servidor le pertenece añadiendo un QRCode (figura 3) que genera nuestra plataforma a su servicio.

Figura 4: Resultados de cada evaluación del sitio

Después, desde una consola muy sencilla cada usuario puede dar de alta su WordPress y lanzar los procesos de pentesting periódica o diariamente. Nosotros mantenemos toda la información de la knowledge base actualizada, y dando consejos de cómo solucionar cada una de las vulnerabilidades y/o debilidades que se detecten.

Figura 5: Funcionamiento de Faast for WordPress

El funcionamiento es muy sencillo, y para que lo veáis os hemos hecho este pequeño vídeo que muestra cómo sería la experiencia del usuario. Simplemente dar de alta del dominio, lanzar el escaner y recibir las indicaciones. Por detrás, toda la arquitectura de Faast funciona con un proceso de algoritmo voraz revisando todos los puntos del sitio.

Saludos Malignos!

Los ficheros CFC de ColdFusion: Otro pequeño leak a evitar

Son muchos los trucos que se utilizan para sacar información de los objetivos en un Ethical Hacking. Yo me he dedicado a coleccionar muchos de ellos en Mensajes de Error, configuraciones inseguras, o exploraciones de los diferentes motores que procesan los Query String en una página web. La suma de todos ellos hace que al final sea más fácil conocer el sistema operativo, la versión del servidor web, los "local paths", etcétera, que podrán unirse a otras técnicas para seguir avanzando en el pentesting.

Figura 1: Los ficheros CFC de ColdFusion: Otro pequeño leak a evitar

Todos ellos los comencé a incluir en nuestra FOCA, y con el tiempo pasaron a formar parte de Faast, nuestra plataforma de Cloud Persistent Pentesting en ElevenPaths que utilizamos para escanear miles de dominios de nuestros clientes cada día para reducir las ventanas de exposición de las debilidades al mínimo posible. Hoy os vengo a contar una de las últimas que hemos metido, que no es más que un leak que se produce con los ficheros CFC de ColdFusion.

Figura 2: Búsqueda de ficheros CFC en la ruta cfcomponets/core/
Se pueden encontrar en otras rutas también con un ext:cfc

Este leak me lo paso mi amigo Rootkit (¡gracias una vez más!) y lo descubrió mientras hacia un poco de Hacking con Buscadores, que tanto le gusta. La fuga de información se produce en las aplicaciones de ColdFusion que han dejado estos ficheros de componentes CFC = ColdFusion Component publicados en Internet.

Figura 3: Fichero CFC de ClodFusion

Lo que se obtiene de ello puede llegar a ser de gran utilidad, ya que son los interfaces de invocación de los componentes de una librería, junto con los parámetros que hay que utilizar, el comportamiento del componente y la ubicación local en la que se encuentra el fichero.

Figura 4: Rutas locales de la intranet en el servidor Windows

En algunas ocasiones, se puede acceder a información más detallada, en la que se describen uno a uno los parámetros, lo que ayuda a entender mejor, en un proceso de pentesting, qué es lo que se puede hacer con cada uno de ellos.

Figura 5: Información sobre los parámetros que se usan en cada componente

En estos ejemplos, además, se puede ver cómo algunos de estos sitios forman parte de un hosting, con lo que se podría utilizar esta información para realizar un ataque contra otro dominio alojado en el mismo servidor.

Figura 7: Rutas locales en un servicio de hosting.

No es el primer leak de ColdFussion del que os hablo, y ya he publicado posts sobre los errores 404 de esta plataforma - tirando de JSP como en el ejemplo de Apple - , o de los Errores 500 de Licenciamiento que se pueden obtener. Además, hay que recordar que ColdFusion usa Java al final de la cadena por debajo, así que si restringes el acceso a los CFC, acuérdate de revisar los errores Java que puedas provocar, ya que el leak puede migrar de un motor a otro.

Figura 8: Error de ColdFusion manejado por el motor Java

Al final, la suma de pequeñas fugas, debilidades de configuración, y fallos de seguridad, es lo que permite que un atacante sea capaz de saltarse todas las barreras de seguridad de un sistema - sea una aplicación, un servicio o una red entera -.

Saludos Malignos!

Cómo encontramos tu HTTP Response Splitting olvidado

Las vulnerabilidades de HTTP Response Splitting pueden ser utilizadas para hacer muchos ataques peligrosos. De hecho, están catalogadas con un nivel de criticidad alto y cuando aparecen se deben cerrar lo antes posible. La idea de una vulnerabilidad de HTTP Response Splitting es que un atacante es capaz de inyectar código en la cabecera de la respuesta HTTP y por tanto reescribir toda la página que llega al cliente. Esto se produce cuando se puede inyectar en un campo que va uno de los campos de la cabecera y el atacante decide escribir, en su inyección, campos HTTP para cambiar la respuesta por completo.

Figura 1: Cómo encontramos tu HTTP Response Splitting olvidado

Nosotros nos encontramos con uno de ellos hace poco utilizando nuestro sistema de Pentesting Persistente Faast con el que monitorizamos la seguridad de las webs haciendo pentesting 365 días al año de manera continua, y aplicando un algoritmo voraz, es decir probando todo lo que haya que probar en cada punto. La gracia en el artículo de hoy no está en la vulnerabilidad en sí, sino en cómo el sistema recursivo funcionó para localizar el bug, que ya está corregido, así que os lo cuento rápidamente hoy sábado.

Figura 2: Bug de HTTP Response Splitting detectado por Faast en un proyecto

El comienzo fue bastante sencillo. Como en cualquier proceso de Ethical Hacking, el motor de Faast tiene una fase de Discovery en la que busca en todos los lugares posibles los recursos expuestos en Internet. Por supuesto, también haciendo hacking con buscadores. En una de esas búsquedas apareció una URL que, como tantas otras, y al igual que se hace con FOCA, pasa a ser analizada por el motor de Faast.

Figura 3: Descubrimiento de una URL indexada y extracción de URLs para Spidering

El código HTML de la página de respuesta de esa URL se pasa por una serie de plugins, y uno de ellos lo que hace es, por supuesto, buscar nuevas URLs a partir de enlaces en la página. Esto es una tarea básica en cualquier pentesting. Hacer spidering a partir de una URL, tal y como se explica en el libro de Hacking Web Technologies. Nosotros, antaño, lo hacíamos con Burp y luego lo pasábamos a FOCA.

Figura 4: Proceso de Spidering con Burp

De esa URL sacamos más URLs con directorios y recursos enlazados. Y, por supuesto, cada directorio que es descubierto se pasa por una serie de plugins de forma recursiva. En búsqueda de cosas como fallos de Directory Listing, de IIS Shortname, Múltiple Choices, errores no controlados, etcétera.

Figura 5: Descubrimiento de un DWSync.xml

Una buena batería, donde también se buscan los sensitive files, tipo .DS_Store, WS_FTP.log o ficheros .listing, por poner algún ejemplo. En este caso, lo que apareció fue un DWSync.xml de los que se quedan cuando alguien sube una web usando Dreamweaver, como ya hemos hablado muchas veces.

Figura 5: Descubrimiento del fichero CGI olvidado por medio de Spidering

Esto es un leak en sí mismo, y como tal quedó reportado en el proyecto para los responsables de seguridad, pero de él sacamos nuevas URLs, como la que se puede ver en la captura del mismo.

Conclusiones

Al final, ese CGI (Common Gateway Interface) resultó ser vulnerable a HTTP Response Splitting. Un fichero que hacía mucho tiempo que se había quedado sin utilidad en la web, pero que aún estaba presente en el servidor. No lo habían limpiado, y el motor de Faast, buscando de manera persistente dio al final con él. 

Figura 6: Encadenamiento recursivo de plugins en Faast hasta llegar al HTTP Response Splitting

Si quitas algo de la web, quítalo. Este es uno de los errores más comunes que encontramos en los proyectos de pentesting persistente - como los que os dejé de Apple - y a partir de ellos se pueden localizar muchas cosas peligrosas. En este caso, un HTTP Response Splitting. Si quieres, puedes pedirnos un piloto de Faast sin compromiso para tu empresa a través de nuestra web de contacto de ElevenPaths.

Saludos Malignos!

Think Different: Un Hostname sin Domain en los inversores de Apple

Si has entrado a leer este artículo por el título, tienes mi más sincero respeto y admiración, porque la verdad es que no sabía bien qué título poner a este artículo donde trato de contaros una pequeña anécdota que me ha llamado la atención y de la que nos ha alertado nuestro queridísimo sistema de Pentesting Persistente Faast.

Figura 1: Think different

Como sabéis, periódicamente le reportamos vulnerabilidades a Apple o Microsoft porque probamos con nuestro motor los nuevos plugins que vamos introduciendo. Escanear un dominio completo como el de Apple.com o Microsoft.com es un reto, pero gracias a la potencia de tenerlo en cloud el sistema se porta como un campeón y los chic@s de Microsoft y Apple nos lo agradecen periódicamente.

Figura 2: Agradecimiento de Apple al equipo de Faast

Entre las cosas que miramos, se encuentra el descubrimiento de servicios web, y para ello probamos muchos trucos. Esta es la historia de uno de ellos.

El dominio investor.apple.com 

En el dominio de apple.com hay un servidor web con información para los inversores que ya ha sufrido en el pasado algún que otro problemilla de seguridad. En este caso no se trata de nada similar, simplemente de una curiosidad en la gestión del hosting. Si entramos en la web vemos que hay una web normal y corriente.

Figura 3: Web de Investor.apple.com

Cuando el motor de Faast encuentra un hostname en formato FQDN, lo que intenta es averiguar si hay más hostnames en el mismo servidor, así que haciendo una sencilla consulta al servicio DNS se puede dar con otros nombres de host en la misma dirección IP.

Figura 4: nslookup a investor.apple.com

Por supuesto, como todo buen pentester, el servicio Faast prueba a localizar todas las webs en esos hostnames, obteniendo resultados diversos, como la misma web accesible por otro nombre de dominio.

Figura 5: La misma web accesible por otro hostname

O un servidor web que no atiende por ese nombre de dominio. Hasta aquí todo dentro de lo normal, como es de suponer.

Figura 6: Not Found en ese dominio

Eso sí, ya se puede ver que hay un servidor que no es de Apple, que tiene alojada una web de Apple.com, lo que abre muchas posibilidades.

El hostname sin FQDN

Como en muchas ocasiones se montan servicios en local, lo que hace nuestro querido Faast es ejecutar un plugin que busca el servicio web en ese servidor, pero utilizando el hostname local, sin utilizar el FQDN, tal y como se puede ver en la captura siguiente hecha con Burp Proxy (un poco de hacking de tecnologías web).

Figura 7: Cambiando el host a solo "investor" la web cambia
(Se ve a la izquierda en la captura)

El resultado es que aparece la web de otra empresa que está en el mismo servidor. Si utilizamos un plugin de tampering en el navegador, podemos ver la renderización completa de la web manipulando el host de la misma forma.

Figura 8: Faast alerta de una web en investor diferente a la que hay en investor.apple.com

Al final, lo que ha sucedido es que se ha extendido la superficie de exposición del dominio Apple.com, ya que, ahora hay otra web que podría tener más vulnerabilidades para conseguir llegar a un servidor del dominio Apple.com. Un truco de "discovery" que tenemos en nuestro Faast, y que nos ha dado un resultado curioso.

Saludos Malignos!