Seis aplicaciones peligrosas y vulnerables, una sola función autónoma

Cualquier persona puede encontrar un fallo en una aplicación deliberadamente vulnerable. La pregunta más difícil —la que realmente importa en la producción— es: ¿Puede usted ejecutar un programa de seguridad completo y demostrar que el problema se ha solucionado? Encuéntralo, comprueba que es explotable, da prioridad a ello, lo arregla y vuelves a probarlo para confirmar que ya está cerrado.

Este post recorre todo ese ciclo contra seis aplicaciones extremadamente vulnerables de una vez por todas — cuatro objetivos clásicos web/API más uno moderno Capa de IA genérica (una aplicación LLM y un servidor MCP) —con escáneres estáticos, el pentest autónomo de FaradAI, el triage y la reparación de FaradAI, y una nueva exploración que muestra exactamente qué hallazgos ya se han solucionado. Todo ello se concentra en un único espacio de trabajo Faraday.

1. Los seis objetivos

Cuatro aplicaciones clásicas deliberadamente vulnerables que abarcan cuatro idiomas y cuatro tipos de vulnerabilidad — además de dos que aplican la misma estrategia de ataque a la IA, donde las clases de vulnerabilidad son inyección de comandos, envenenamiento de herramientas y fuga de datos desde el sistema en lugar de SQLi y XSS:

¿Por qué estos seis? Cobertura. Un monolito en PHP, un JS SPA+API moderno, una aplicación empresarial Java y un servicio Python basado en API aplican reglas de SAST diferentes, ecosistemas de dependencias (Composer / npm / Maven / pip) y superficies de ataque web — mientras que la aplicación de LLM y el servidor MCP aplican las clases específicas de la IA que los escáneres clásicos nunca ven, todo ello a través de mismo Encuentra→Comprueba→Prioriza→Soluciona el ciclo.

Desplácese cuatro aplicaciones clásicas con Docker localmente — ya que también ejecutará FaradAI localmente, localhost es accesible de principio a fin (sin exposición pública, sin túneles):

docker run -d --name dvwa -p 8081:80 vulnerables/web-dvwdocker run -d --name juiceshop -p 8082:3000 bkimminich/juice-shopdocker run -d --name webgoat -p 8083:8080 webgoat/webgoatdocker run -d --name vampi -p 8084:5000 erev0s/vampi

La capa de IA GenAI requiere un par de pasos adicionales. PromptMe Necesita un Ollama local para sus modelos; MCP vulnerable como la diabla envía un archivo Docker que ejecuta todos los 10 servidores de desafío en las conexiones SSE 9001-9010 (pin mcp<2 — el código apunta al SDK v1):

# PromptMe (Top 10 de OWASP LLM) — Ollama + las aplicaciones Flask Challenge en 5001-5010docker run -d --name ollama_server -p 11434:11434 ollama/ollama:latestdocker exec ollama_server ollama pull mistral + llama3 para # algunos desafíos, luego, en la# checkout de PromptMe (Python 3.11 venv): python main.py → desafíos en 5001-5010# Damn Vulnerable MCP — 10 servidores MCP con SSE en 9001-9010git clone && cd damn- https://github.com/harishsg993010/damn-vulnerable-MCP-server vulnerable-MCP-serverdocker build -t dvmcp. && docker run -d --name dvmcp -p 9001-9010:9001-9010 dvmcpdocker exec dvmcp pip install 'mcp<2' && docker restart dvmcp # apunta a la versión 1 del SDK MCP

2. El bucle

Desactivar las 6 aplicaciones vulnerables (4 web/API + LLM + MCP) ↓Escaneos estáticos (SAST + SCA + secretos) → Faraday ↓FaradAI pentest autónomo contra cada aplicación → explotaciones validadas y enlazadas ↓Triaje de Faraday: deduplicación + priorización de los hallazgos estáticos + resultados de la prueba de penetración — en un único espacio de trabajo ↓Patchear los problemas más importantes (patch de Faraday o manualmente) ↓Re-escaneo + nuevo ensayo de Faraday → Faraday reconcilia: solucionado → cerrado, aún abierto → abierto

Todo queda en un solo espacio de trabajo — llamémosle aplicaciones-damnables — con cada aplicación como su propio host, de modo que la nueva exploración pueda indicar, por aplicación, exactamente qué se solucionó.

3. Práctica

Primero, conecte faraday-cli (autenticación con token a través de su archivo de configuración —) auth No tiene --token bandera):

pip install faraday-cliexport FARADAY_URL=http://localhost:5985"" Comunidad de # Faraday (local) — o tu instancia personalprintf 'auth:\n faraday_url: \n %s token: \n' "%s $FARADAY_URL" "$FARADAY_TOKEN" > ~/.faraday-cli.yml

Etapa 1 — Escáneres estáticos → Faraday

Ejecute el mismo conjunto de ficheros estáticos sobre la fuente de cada aplicación y envíe todos los informes al espacio de trabajo compartido. Una herramienta de SAST (Semgrep, multilingüe), una herramienta de SCA/containers (Trivy) y una herramienta de secretos (Gitleaks):

Para la aplicación en dvwa juiceshop, el promptme dvmcp de vampi muestra: "Si quieres comprobar la compatibilidad de tu $aplicación con vampi, puedes usar el comando "scan" de gitgrep. Para ello, añade la opción "--config auto" y "sarif" a la ruta de comando. Por ejemplo: "./src/app" + trivy fs --format json -o "$app-trivy.json" "./src/app $" + gitleaks detect -s "./src/app $" -f json -r "$ $app-gitleaks.json" + faraday-cli tool report "$ $app-semgrep.sarif" -w damn-vuln-apps --create-workspace + faraday-cli tool report "app-$trivy.json" -w damn-vuln-appsdone

Ahora el espacio de trabajo contiene la gama de datos: los depósitos de SAST, las dependencias vulnerables y cualquier secreto divulgado en todas las seis aplicaciones. Amplio, ruidoso y aún no issues probados.

Pas 2 — FaradAI autómata de prueba de penetración

FaradAI funciona como un escáner de seguridad dentro de tu Faraday — puedes activarlo a través de la API REST con curl y empuja validado Encuentros en el mismo espacio de trabajo. Debido a que el Faraday y su agente se ejecutan localmente (véase §6), el agente llega a localhost Contenedores directamente. Inicie el fuego una vez por aplicación en vivo:

declara -A TARGETS=( [dvwa]=http://localhost:8081"" [juiceshop]=http://localhost:8082"" [webgoat]=http://localhost:8083/WebGoat"" [vampi]="")para http://localhost:8084 cada app en "${!TARGETS[@]}"; haz un curl -sS -X POST "$FARADAY_URL/_api/v3/cloud_agents/$FARADAI_AGENT_ID/run" \ -H "Authorization: Token FARADAY_ $TOKEN" \ -H "Content-Type: application/json" \ -d '{ "args": { "TARGET": "'"${TARGETS[$app]}"'", "INSTRUCTION": "Pentest completo de la web/API: autenticación, IDOR/BOLA, SQLi, inyección de datos, XSS, SSRF, asignación masiva, JWT." } } Validar ["damn-vuln-apps"] y concatenar exploits reales.", "MODE": %{http_code} "Dual", "ROUNDS": 40 }, "workspaces': }" -w "\nHTTP \n" hecho

FaradAI descubre la superficie de cada aplicación, la ataca y vincula lo que es real — convirtiendo lo que antes era un ’quizá“ en ”aquí está el exploit funcional“.”

Para el Capa de IA genérica, solo el INSTRUCCIONES y TARGET en el args Cambio: punto de inicio de la ejecución de PromptMe http://localhost:5001-5010 y solicitar ataques OWASP-LLM (inyección de comandos, fuga de datos del sistema, divulgación confidencial); dirigir la ejecución del MCP hacia http://localhost:9001-9010 y le entregamos el flujo MCP-over-SSE (ver §6) para que enumere y abuse de las herramientas de cada servidor. El mismo agente, el mismo espacio de trabajo —las conclusiones son idénticas. promptme or dvmcp El tag permite que la triaje se pueda realizar por aplicación.

Pas 3 — Triaje y parcheo de FaradAI

Una operación de triaje que se realiza a lo largo de todo el espacio de trabajo permite enriquecer, deduplicar y priorizar todo junto — hallazgos estáticos y resultados de pentest, todas las seis aplicaciones —y pueden ser la base para la solución. dry-run (solo plan):

curl -sS -X POST "$FARADAY_URL/_api/v3/cloud_agents/$FARADAI_TRIAGE_AGENT_ID/run" \  -H "Authorization: Token $FARADAY_TOKEN" \  -H "Content-Type: application/json" \  -d '{    "args": {"WORKSPACE_NAME": "damn-vuln-apps", "MODE": "Dual", "PATCHING_MODE": "dry-run"},    "workspaces": ["damn-vuln-apps"]  }' -w "\nHTTP %{http_code}\n"

Ahora tienes una única cola priorizada issues probados problemas. Revise el plan de parcheo y, a continuación, deje que FaradAI aplique las correcciones seguras ("PATCHING_MODE": "apply") o mediante un parche manual — por ejemplo, parametrizar la consulta SQL de DVWA, eliminar la dependencia vulnerable de WebGoat, añadir la verificación de propiedad de VAmPI /usuarios/v1/{username} La ruta no está disponible.

Pas 4 — Reescanear y confirmar lo que se ha solucionado

Redeploye las aplicaciones reparadas y luego repítelo exactamente lo mismo Las exploraciones estáticas y el FaradAI pentest se realizan en el mismo espacio de trabajo. Debido a que Faraday concilia los hosts y los hallazgos, no acumula duplicados — en realidad, cierra lo que está arreglado y deja el resto abierto:

# Después de realizar la reparación y volver a desplegar el sistema, vuelva a ejecutar los pasos 1 y 2 sin cambios# y verifique qué se cerró: lista de vulnerabilidades de Faraday-CLI -w damn-vuln-apps --status closedlista de vulnerabilidades de Faraday-CLI -w damn-vuln-apps --status open

Ese punto de vista dividido en abierto/cerrado es todo el punto: no “encontramos 300 cosas”, sino “demostramos que eran explotables, las arreglamos y confirmado Ellos ya se fueron — mientras que estos todavía están abiertos.”

4. ¿Qué resultado real produjo?

En realidad, recorrimos este ciclo de forma completa — seis aplicaciones en total. localhost, FaradAI se activó a través de la API REST contra un Faraday local, todo ello convergido en un único espacio de trabajo. El resultado final: 620 hallazgos En las seis aplicaciones. Aquí tienes la amplitud, por aplicación y por herramienta:

Este es el pilar de “abertura” en números: ~564 hallazgos estáticos — SAST, dependencias vulnerables, secretos filtrados — en Composer/npm/Maven/pip y la pila de Python ML. Amplio, ruidoso y en su mayoría No está comprobado: la mayor parte de ellos regresó informativo.

Luego FaradAI convirtió “tal vez” en “aquí está el exploit”.” Los 48 hallazgos de pentest no eran ecos de escáner — eran ataques validados y con pruebas de solicitud/respuesta:

• DVWA — Inyección de comandos de OS → RCE como www-data, Subir archivos sin restricciones → RCE en el shell web, dumping de la clave admin mediante UNION SQLi, XSS almacenado y reflejado, cambio de contraseña CSRF mediante GET.
• Juice Shop — Bypass del login SQLi mediante la creación de un JWT de administrador, JWT alg:none aceptado, escritura no autenticada PUT /api/Productos/{id}, IDOR en cestas y seguimiento de pedidos, almacenamiento de XSS a través de la imagen del producto, escalamiento de roles mediante asignación masiva.
• WebGoat — revelación no autenticada de la configuración del env/config de Spring Actuator, XXE en modo de anonimato y registro propio sin restricciones.
• VAmPI — BOLA restablecimiento de la contraseña admin, sin autenticación /_debug la filtración de credenciales en texto plano, admin:true asignación masiva en el momento de la inscripción, sin autenticación /createdb Reiniciar.
• PromptMe (Top 10 de OWASP LLM) — Inyección directa sin pasar por el filtro de entrada (LLM01), divulgación de información sensible (LLM02, flag capturado mediante inyección), fuga de información del sistema que expone una clave API predefinida (LLM07), un backend de Ollama no autenticado accesible desde detrás de la aplicación y consumo ilimitado/sin limitación de velocidad (LLM10).
• MCP vulnerable como la diabla — una herramienta MCP (execute_command) cuya lista blanca se puede eludir con metacharacteres de shell → RCE no autenticado como root, un segundo RCE mediante un sistema de cifrado no estándar eval() que evaluar_expresión, salto de ruta / lectura arbitraria de archivos en una herramienta de archivo, inyección indirecta de prompt a través de una herramienta de procesamiento de documentos y credenciales (una cadena de conexión a Postgres) filtradas directamente desde la descripción de la herramienta.

La capa de IA es el punto clave aquí: las inyecciones de preguntas, el envenenamiento de las herramientas y la fuga de preguntas del sistema no aparecen en ningún informe de SAST/SCA — pero mismo El pentest autónomo que enlaza un SQLi en DVWA también habla con MCP a través de SSE y jailbreaka un LLM local, y cada hallazgo se almacena en el mismo espacio de trabajo junto a los hallazgos clásicos.

Priorización: una pasada de triage FaradAI a través del espacio de trabajo, delimitada en función de 77 crítico + alto Encontrados, revalidados cada uno contra los objetivos en vivo y los fallos fueron pospusidos con la documentación adjunta: 65 confirmados, 2 cerrados (no se pudo reproducir), 9 deduplicados (por ejemplo, un clúster XStream de 20 nodos se redujo a uno principal). De esto surgió un ranking Plano de reparaciones de 71 artículos — 41 mejoras de depuración (XStream → 1.4.21+, PyJWT → 2.13+, Flask → 2.3.2+), 29 correcciones de código (cuestiones parametrizadas, JWT algoritmos lista de permisos, MCP execute_command → argv con shell=False, evaluar_expresión → AST allow-list, canonicalización de rutas, eliminación de la clave API en la pantalla de inicio del sistema LLM), además de cambios en la configuración y el control de la red.

Así es el arco en una carrera: 620 vulnerabilidades brutas → ~564 brechas estáticas → 48 exploits probados → 77 vulnerabilidades prioritarias → 71 correcciones prácticas. Los escáneres te indican dónde buscar; FaradAI te dice qué obtiene realmente un atacante —tanto en el caso de web clásico como de LLM y MCP— y la triaje te dice qué arreglar primero.

5. ¿Qué prueba esto?

Una aplicación deliberadamente vulnerable es el lugar más adecuado para probar la seguridad programa, No solo un escáner:

• Amplitud — Semgrep / Trivy / Gitleaks marca todo de forma estática, en seis bases de código y múltiples ecosistemas.
• La prueba — FaradAI muestra qué de estos puede aprovechar realmente un atacante, y los enlazará —incluyendo las clases específicas de IA (inyección de comandos, abuso de la herramienta MCP)— que las herramientas estáticas nunca ven.
• Priorización — La triaje reduce el ruido a una lista ordenada y basada en pruebas.
• Cierre — Patch, re-scan y Faraday te indican qué se solucionó realmente.

Este círculo completo — encontrar → probar → priorizar → arreglar → confirmar — es la diferencia entre una pila de hallazgos y un programa de seguridad, y puedes ensayar todo ello de forma segura en estas seis aplicaciones antes de aplicarlo en la producción.

6. Configurar Faraday + FaradAI localmente

Todo este proceso se ejecuta en tu computadora; es lo que le permite llegar al localhost Contenedores:

1. Faraday — corre Faraday Community autohostado (http://localhost:5985) o apunta hacia tu Personal ejemplo. Set FARADAY_URL y un token de API (FARADAY_TOKEN) — esos son los que curl llamadas realizadas con el uso de los servicios mencionados anteriormente.
2. FaradAI como escáner de seguridad — FaradAI funciona como un agente dentro de ese Faraday, registrado localmente para llegar directamente a cada objetivo: las aplicaciones clásicas de 8081-8084, los desafíos de PromptMe LLM en 5001-5010, y los servidores MCP en 9001-9010. Para el pentest de MCP, dígale el flujo SSE (abierto) GET /sse para una sesión, entonces POST JSON-RPC inicializar / Herramientas/lista / Herramientas/llamada to /messages/?session_id=…, (leemos las respuestas desde el flujo SSE) — eso es todo lo que necesita para enumerar y abusar de las herramientas.
3. Identificadores de agente — obtenga el ID del agente de pentest y el de la triaje Cloud Agents en la interfaz de usuario (o GET /_api/v3/cloud_agents) y los configuro como FARADAI_AGENT_ID / FARADAI_TRIAGE_AGENT_ID utilizado por el curl Los desencadenantes en los pasos 2 y 3.

(El desencadenante es la misma llamada REST en todas partes — curl to /_api/v3/cloud_agents//run. La única diferencia aquí es que Faraday y su corredor corren localmente, así que el corredor puede llegar localhost que un escáner de seguridad alojado no podría hacer).

Probá FaradAI

Todo esto —el pentest autónomo, la validación de explotabilidad y el triage— es FaradAI, corriendo dentro de Faraday. En vez de armar el flujo a mano, dejá que un agente ofensivo autónomo pentestee cada target y te deje los hallazgos priorizados en un solo lugar.

👉 Conocé a FaradAI: faradaysec.com/faradai

Un lugar para configurarlo todo: FaradAI

Configuras FaradAI una vez, en Faraday Personal, y todo lo anterior solo apunta a ello:

1. Crea tu inquilino en scan.faradaysec.com.
2. Su instancia vive en scan.apps.faradaysec.com.
3. En Security Scanner, el FaradAI Autonomous Pentest es donde configuras los objetivos, el alcance, las rondas y el workspace destino, y luego lo inicias manualmente desde la interfaz de usuario o automáticamente desde la integración continua (CI)
4. Para acceder al panel de FaradAI (https://faradai-scan.apps.faradaysec.com/_ai/), debe hacer clic en FaradAI desde la interfaz de usuario. No se admite el acceso directo a la URL.

Dale a tu pentester con IA un lugar para sus hallazgos — Faraday Community · Faraday Personal →