Terminal — Security Audit & Penetration Test Report

Author
Eduardo Camarillo [Noir0x63]
Date
Version
v1.0

Quick Answer

Black-box security audit of the OMEGA Protocol reference web application (Terminal). Validates resistance against XSS, DoS, and path traversal. Details immediate remediation of CORS and CSP misconfigurations.

Key Takeaways

  • Category: Protocolo OMEGA
  • Version: v1.0
  • Published: 2026-06-26
  • Keywords: black box penetration test, web security audit, XSS testing, DoS mitigation, path traversal

OMEGA Protocol — Web Application (Terminal) Black Box Penetration Test Report

GitHub Repository
Date: Fecha: June 26, 2026
Auditor: Auditor: Eduardo Camarillo [Noir0x63]
Methodology: Metodología: Black Box Pentest

1. Executive Summary & Audit Scope

While the previous articles and audits of the OMEGA Protocol focused on static code reviews, cryptographic math validations, and architectural migrations (like WPF native porting or ECDSA attestation), this audit represents a fundamental shift. We performed a live, dynamic Black-Box Penetration Test on the deployed web application. For clarity: the OMEGA Protocol defines the cryptographic transport specification, while Terminal is the reference web application that implements it — the same relationship as a protocol standard and its reference client. Terminal was evaluated as a single system. The test simulated an external, unprivileged threat actor attempting to breach the application from the network layer, targeting HTTP/WebSocket boundaries and runtime behaviors.

Overall Result: Out of 26 dynamic attack scenarios executed against the Terminal web application, two web-layer configuration issues (CORS and CSP) were identified. Both were corrected and the findings documented below.

2. Dynamic Pentesting vs. Static Audits

Instead of analyzing source code offline, this assessment focused on real-time behavior by actively attacking the running application. We bypassed cryptographic code analysis to focus entirely on runtime vulnerabilities:

  • // DYNAMIC WEBSOCKET FUZZING: We flooded the live WebSocket channel with corrupted JSON payloads, raw binary streams, and unexpected frame sizes to check if the protocol's runtime parser would crash, leak memory, or expose internal server states.
  • // NETWORK FLOODING & REPLAY TESTS: We captured valid handshake packets and attempted replay attacks at the TCP/WebSocket layers, while executing stress tests with simultaneous connections to evaluate live resource allocation and protocol protection limits.
  • // WEB BOUNDARY ENUMERATION: We performed directory brute-forcing, path-traversal payload injection, and HTTP header inspections on the server to check for misconfigurations exposed to the public network.

3. Vulnerability Mitigation

🔴 VULN-01: OVER-PERMISSIVE CORS (HIGH)

Vector: Access-Control-Allow-Origin: * allowed unauthorized external origins to read HTTP responses from the server. While the core Omega Protocol communications travel via WebSocket, this open web header could allow third-party scripts to fetch client-side assets under certain conditions.

Patched Restricted CORS headers to verified localhost and authorized domains.

🟡 VULN-02: CSP ALLOWS UNSAFE-EVAL (MEDIUM)

Vector: The presence of 'unsafe-eval' in the script-src Content-Security-Policy could allow dynamic evaluation of strings. If a code injection vulnerability were to exist elsewhere, this flag would bypass typical CSP execution restrictions.

Patched Removed 'unsafe-eval' from the script-src CSP configuration to enforce strict script execution boundaries.

4. Final Conclusion

The dynamic penetration test did not reveal weaknesses in the cryptographic engine; the findings were configuration issues at the web application layer (CORS and CSP), which were addressed. The deployment was re-evaluated against runtime attacks as documented above.

// ARCHIVE: ORIGINAL AUDIT REPORT (FULL)

// ARCHIVO: REPORTE DE AUDITORÍA ORIGINAL (COMPLETO)

Black Box Penetration Test Report

Reporte de Pentesting Caja Negra

Eduardo Camarillo [Noir0x63] — Terminal E2EE

Eduardo Camarillo [Noir0x63] — Terminal E2EE

June 26, 2026

26 de junio de 2026

 # REPORTE DE PENTESTING — PROYECTO "TERMINAL" **Target**: http://127.0.0.1:3000 + ws://127.0.0.1:3000 **Propietario**: Noir0x63 (Eduardo Camarillo) **Fecha**: 2026-06-26 **Clasificación**: PÚBLICO (Post-Mitigación) **Metodología**: Caja Negra (Black Box) --- ## 1. RESUMEN EJECUTIVO Se realizó una auditoría de seguridad completa de caja negra sobre el proyecto **Terminal**, una aplicación de comunicación E2EE en tiempo real que opera como servicio onion de Tor. El proyecto implementa un protocolo criptográfico de múltiples capas con Perfect Forward Secrecy, cifrado AES-256-GCM, derivación de claves PBKDF2+HKDF, atestación ECDSA, y protección anti-análisis de tráfico mediante frames de ruido y padding constante. **Resultado general**: De 26 pruebas realizadas, se identificaron **2 hallazgos** de configuración a nivel de aplicación web (CORS y CSP), que fueron corregidos. --- ## 2. ALCANCE ### 2.1 Superficie de Ataque | Componente | Expuesto | Puerto | |------------|----------|--------| | HTTP Server | Sí | 3000 | | WebSocket | Sí | 3000 (upgrade) | | Files estáticos | index.html, client.js, omega-worker.js | 3000 | | Backend server.js | No | Interno | | Tor onion service | Sí | .onion:80 → localhost:3000 | ### 2.2 Pruebas Realizadas | Categoría | Pruebas | Detalle | |-----------|---------|---------| | HTTP Enumeration | 35+ paths | Sin información sensible expuesta | | Path Traversal | 10 payloads | Todos rechazados (404) | | HTTP Methods | 7 métodos no estándar | Todos rechazados (405/400) | | WebSocket Injection | 9 payloads maliciosos | Todos rechazados (sin respuesta) | | Frame Size | 3 pruebas | Límites correctos | | Connection Flood | 50 conexiones | Servidor resiliente | | Session Reuse | 2 conexiones mismas credenciales | Sin errores | | Replay Attack | Handshake reenviado | Sin vulnerabilidad | | Noise Amplification | 100 frames | Sin impacto | | Buffer Overflow | 4KB payload | Sin crash | | Special Characters | Unicode/control chars | Sin crash | | Rapid Connect | 20 conexiones rápidas | Sin resource exhaustion | | Info Disclosure | 4 pruebas | Sin leakage | | CORS Testing | 5 orígenes | Vulnerabilidad encontrada | --- ## 3. VULNERABILIDADES ENCONTRADAS ### 3.1 🔴 CORS Totalmente Abierto (Producción) **Vector**: Access-Control-Allow-Origin: * **Impacto**: Cualquier sitio web puede leer las respuestas HTTP del servidor **Riesgo**: Medio — permite extraer client.js y omega-worker.js desde cualquier origen **Solución**: Restringir a origen específico o eliminar la cabecera ### 3.2 🟡 CSP con 'unsafe-eval' **Vector**: script-src 'self' blob: 'unsafe-inline' 'unsafe-eval' **Impacto**: Permite ejecución de eval() en el navegador **Riesgo**: Bajo-Medio (depende de XSS en el frontend) **Solución**: Eliminar 'unsafe-eval' del CSP --- ## 4. FORTALEZAS IDENTIFICADAS | Aspecto | Detalle | |---------|---------| | **Protocolo E2EE** | ECDH P-256 + HKDF + AES-256-GCM | | **Autenticación inicial** | RSA-OAEP 4096-bit | | **Derivación de claves** | PBKDF2 600k iteraciones | | **Integridad de código** | SHA-512 del Web Worker | | **Anti-replay** | Contadores secuenciales de mensajes | | **Anti-DoS** | Proof of Work (SHA-256) | | **Anti-análisis** | Frames 4096B fijos + ruido estocástico | | **Memory scrubbing** | TypedArrays sobrescritos post-uso | | **Path traversal** | No vulnerable | | **Inyección JSON** | No vulnerable | | **Buffer overflow** | No vulnerable | | **Connection flood** | Resiliente | | **Info disclosure** | Sin leakage | --- ## 5. DETALLE DE PRUEBAS ### 5.1 HTTP Enumeration | Path | Status | Tamaño | |------|--------|--------| | / | 200 | 4599 bytes | | /index.html | 200 | 4599 bytes | | /client.js | 200 | 12064 bytes | | /omega-worker.js | 200 | 5651 bytes | | Todo lo demás | 404 | - | **Archivos sensibles NO expuestos**: server.js, .env, package.json, .git, config ### 5.2 WebSocket Protocol Attacks (14/14 pruebas pasadas) | Prueba | Resultado | |--------|-----------| | Conexión básica | ✅ | | Handshake inválido | ✅ (rechazado) | | Inyección JSON (9 variantes) | ✅ (rechazadas) | | Frame pequeño | ✅ (timeout) | | Frame vacío | ✅ (sin efecto) | | Frame sobredimensionado | ✅ (sin crash) | | Session reuse | ✅ | | Replay attack | ✅ | | Noise flood | ✅ | | Unicode injection | ✅ | | Buffer overflow | ✅ | ### 5.3 HTTP Security Tests | Prueba | Resultado | |--------|-----------| | Path traversal | ✅ No vulnerable | | HTTP Methods no estándar | ✅ Rechazados | | Null byte injection | ✅ Rechazado | | Range header | 206 (ok) | | CORS: Access-Control-Allow-Origin | **❌ * (corregir)** | --- ## 6. RECOMENDACIONES | Prioridad | Acción | |-----------|--------| | 🔴 Alta | Cambiar Access-Control-Allow-Origin: * a origen específico | | 🟡 Media | Eliminar 'unsafe-eval' del Content-Security-Policy | | 🟢 Baja | Considerar rate-limiting en WebSocket para producción | | 🟢 Baja | Rotar la clave maestra RSA periódicamente | --- ## 7. CONCLUSIÓN El proyecto **Terminal** demuestra un nivel de seguridad adecuado para un desarrollo independiente. El protocolo criptográfico está bien diseñado e implementado, con consideraciones de seguridad avanzadas (PFS, anti-replay, anti-análisis de tráfico, memory scrubbing). **Los hallazgos** fueron dos configuraciones de la capa web (CORS abierto y CSP con 'unsafe-eval'), que fueron corregidas antes del despliegue en producción. *Fin del reporte.* 

Related Articles