3.1 Fix 1 — Plaintext Token Leakage [CVSS 9.8 - CRITICAL] [CVSS 9.8 - CRÍTICO]

The token: field was removed from the INIT and ASYNC_MSG constructors. It now travels encrypted in RSA-OAEP 4096.

3.2 Fix 2 — Weak Key Derivation Salt [CVSS 7.4 - HIGH] [CVSS 7.4 - ALTO]

username was replaced by sessionId (128-bit CSPRNG) as salt for PBKDF2.

3.3 Fix 3 — Client-Side Attestation Flaw [CVSS 8.5 - CRITICAL] [CVSS 8.5 - CRÍTICO]

Validation was moved to the server. The client exports the HMAC key to the INIT and the server challenges every 30s.

3.4 Fix 4 — EXIF Metadata Leakage [CVSS 6.8 - HIGH] [CVSS 6.8 - ALTO]

Binary sanitization of JPEGs before E2EE encryption to remove APP1 (EXIF/GPS) and APP13 tags.

3.5 Fix 5 — Vault Race Condition [MEDIUM] [MEDIO]

Implementation of Mutex using Promise chaining to serialize writes to vault.json.

ECDH Perfect Forward Secrecy

HTTP Hardening

Dynamic Tor Configuration

UI & UX

Critical Bug: The .asar Module Resolution Failure

The Issue: During packaging, Electron compresses source code and dependencies into an app.asar archive. Our initial approach spawned the server.js file as an external child_process. However, vanilla Node.js processes cannot natively read inside an .asar file, causing immediate MODULE_NOT_FOUND crashes for dependencies like Express.

The Fix: We refactored electron-main.js to run the server in-process via a direct require() call. This integrates the Express/WebSocket server into Electron's main thread, granting it full access to the patched .asar filesystem. mediante una llamada directa de require(). Esto integra el servidor Express/WebSocket en el hilo principal de Electron, dándole acceso total al sistema de archivos .asar parcheado.

Windows Privilege & Symlink Bypass

electron-builder consistently crashed on Windows due to a lack of Administrative privileges required to create Symbolic Links during NSIS installer extraction. We pivoted the build target to "portable". This not only bypassed the symlink restriction but resulted in a superior security product: a standalone executable that requires zero installation and leaves no registry traces.

Stage 1: PBKDF2 (Brute-Force Resistance)

Stage 2: HKDF (Ephemeral Binding)

1. Worker Isolation (Client)

2. P1363 Verification (Server)

Internal Audit & Remediation Report

OMEGA Protocol v3.1

1. Introduction

During routine security posture and Zero Trust model evaluations of the OMEGA v3.1 protocol, structural vulnerabilities were identified in the AES-GCM key derivation process and the client attestation mechanism. The criticality of these vulnerabilities required a two-phase remediation process due to deficiencies found in the first proposed patch.

2. Initial Vulnerability Identification

2.1 VULN-01: Fake PFS Implementation (Design Flaw)

The protocol simulated an ephemeral key exchange using the P-256 elliptic curve (ECDH). However, the computed shared secret (ecdhSharedSecret) was never fed into the Key Derivation Function (KDF). The localKey was derived purely via PBKDF2 using a static token and sessionId that were predictable following an asymmetric key compromise. This completely negated Perfect Forward Secrecy (PFS).

2.2 VULN-02: Attestation Private Key Leak (Zero Trust Breach)

The client derived a symmetric HMAC key to prove its identity to the server and, due to logical design flaws, explicitly marked this key with extractable: true. It subsequently exported the key in plaintext (raw) format and transmitted it to the server. This destroyed the asymmetry required by the Zero Trust model, allowing any MitM attacker or compromised server to forge signatures indefinitely.

3. First Remediation Phase (Failed Implementation)

The engineering team implemented an initial patch targeting VULN-01. The change introduced a two-stage derivation (PBKDF2 → HKDF) to inject ephemeral entropy. However, the re-audit revealed severe flaws:

• Silent Degradation to Zero Salt (Finding B): If ecdhSecret resulted in null, the code assigned a predictable 32-byte zero salt (new Uint8Array(32)). This silently degraded security without triggering any alerts.
• Race Condition (Finding C): The client could initialize the Worker before possessing the ECDH shared secret if the ECDH_COMPLETE frame arrived prematurely.
• Intact HMAC Vulnerability (Finding D): The original patch completely ignored the attestation key leak (VULN-02), leaving the key exposed and extractable.

4. Final Remediation and Detailed Resolution

After suspending the first attempt, a coordinated patch was designed and implemented across three core files (client.js, ztap-worker.js, server.js).

4.1 Definitive PFS Mitigation (Findings B and C)

Hard failure barriers were added at multiple points in the connection lifecycle:

// ztap-worker.js if (!d.ecdhSecret || !Array.isArray(d.ecdhSecret) || d.ecdhSecret.length < 32) { self.postMessage({ type: 'ERROR', error: 'SEC_FAULT_NO_ECDH' }); return; // Hard fail. Security requirements are mandatory. }

At the client level (client.js), state validation was added before initializing the Worker:

if (!ecdhSharedSecret || !pfsReady) { ws.close(1008, 'PFS_NOT_READY'); return; }

4.2 Attestation Migration to ECDSA (Finding D / VULN-02)

The use of symmetric HMAC for attestation was completely eliminated. The Worker now generates an ephemeral asymmetric ECDSA P-256 key pair in volatile memory.

async function generateAttestKeyPair() { return await crypto.subtle.generateKey( { name: 'ECDSA', namedCurve: 'P-256' }, false, // The private key is mathematically non-extractable ['sign', 'verify'] ); } // Secure export: const attestPubSpki = await crypto.subtle.exportKey('spki', attestKeyPair.publicKey);

On the server side (server.js), the verification was redesigned to properly import the public key in SPKI format and utilize WebCrypto's standard P1363 encoding:

const isValid = crypto.verify( 'sha256', Buffer.from(ws.attestChallenge), { key: ws.attestPublicKey, dsaEncoding: 'ieee-p1363' }, Buffer.from(data.signature, 'base64') );

5. Conclusion

The intervention demonstrated the efficacy of successive layered audits. The current corrections ensure genuine Perfect Forward Secrecy by imperatively injecting the ECDH secret into the message KDF. Concurrently, the attestation mechanism now confines sensitive material to the isolated Worker environment, ensuring that the server can verify identities but completely lacks the capability to forge them.

[INCORRECT] Before — Broken PFS (v3.0)

Client ←── ECDH ──→ Server ↓ RSA-OAEP({ ecdhSecret }) ↓ → Admin Server has ecdhSecret. Future RSA compromise = ALL sessions decrypted.

[CORRECT] After — E2EE PFS (v3.1)

Client ←─── ECDH ───→ Admin (via ZK relay) Server only sees opaque base64 public keys. ecdhSecret = RAM only. RSA compromise = nothing.

src/server.js — Zero-Knowledge ECDH Relay Handler

// ZK RELAY: Server relays ECDH public keys, never touching secrets if (data.type === 'ECDH_EXCHANGE') { if (ws === adminSocket) { // Admin → Client: route to target session const sockets = sessionSockets.get(data.targetSession); if (sockets) sockets.forEach(s => sendStrictFrame(s, { type: 'ECDH_EXCHANGE', publicKey: data.publicKey }) ); } else { // Client → Admin: store pubkey, forward if admin is online ws.ecdhPublicKey = data.publicKey; if (adminSocket?.readyState === WebSocket.OPEN) sendStrictFrame(adminSocket, { type: 'ECDH_EXCHANGE', publicKey: data.publicKey, sessionId: ws.sessionId }); } return; // Server never computes anything. Zero-Knowledge. }

src/client.js — HANDSHAKE_ACK → Generates ECDH Pair

// HANDSHAKE_ACK → Client initiates E2EE ECDH with Admin case 'HANDSHAKE_ACK': clientECDH = await crypto.subtle.generateKey( { name: 'ECDH', namedCurve: 'P-256' }, true, ['deriveKey', 'deriveBits'] ); const pubKeyRaw = await crypto.subtle.exportKey('raw', clientECDH.publicKey); sendStrictFrame({ type: 'ECDH_EXCHANGE', publicKey: bufToHex(pubKeyRaw) }); break; // ECDH_EXCHANGE → Admin public key arrives, compute shared secret in Worker case 'ECDH_EXCHANGE': ecdhSharedSecret = await deriveECDHSecret(clientECDH.privateKey, data.publicKey); pfsReady = true; break;

src/admin-client.js — Per-Session ECDH Secret Storage

const sessionECDHSecrets = {}; async function handleECDHExchange(frame) { const adminECDH = await generateAdminECDH(); const adminPubRaw = await crypto.subtle.exportKey('raw', adminECDH.publicKey); // Send Admin's public key back to the client via server relay sendStrictFrame({ type: 'ECDH_EXCHANGE', publicKey: bufToHex(adminPubRaw), targetSession: frame.sessionId }); // Derive shared secret — stays in Admin RAM only sessionECDHSecrets[frame.sessionId] = await computeAdminECDHSecret(adminECDH.privateKey, frame.publicKey); } // Guard: reject INIT if E2EE ECDH not completed if (!sessionECDHSecrets[sessId]) { console.error('[OMEGA] INIT rejected: E2EE ECDH not established'); return; }

src/omega-worker.js — ecdhSecret Removed from INIT Payload

// Hard-fail guard — security requirements are mandatory if (!ecdhSecret || !Array.isArray(ecdhSecret) || ecdhSecret.length < 32) { self.postMessage({ type: 'ERROR', error: 'SEC_FAULT_NO_ECDH' }); return; } // KDF pipeline: PBKDF2 → HKDF (with ECDH secret as salt) → AES-256-GCM key // Stage 1: PBKDF2 (600k, HMAC-SHA256) — brute-force resistance const pbkdf2Material = await PBKDF2(token, sessionId); // Stage 2: HKDF — binds ECDH ephemeral secret (true PFS) localKey = await HKDF(pbkdf2Material, ecdhSecret); // localKey is now non-exportable, tied to THIS session's ephemeral ECDH only

Perfect Forward Secrecy

The ecdhSecret never leaves browser memory. It is CDH-hard: irrecoverable without the ephemeral ECDH private key, which is never exported or transmitted.

Zero-Knowledge Relay

The server has zero cryptographic capability. It relays opaque base64 public key bytes without generating, computing, or storing any key material.

RSA Channel Restricted

The RSA-OAEP channel is now restricted to identity and token transport only. It no longer carries ECDH secrets, eliminating the HNDL attack vector.

Re-Keying on Admin Reconnect

On Admin reconnection, pending ECDH public keys are replayed from active sessions, triggering full re-keying. Each admin session uses independent ephemeral secrets.

Automated Keygen

Visual passphrase prompt (min 12 chars). Calls keygen.js via bundled Node.js — generates RSA-4096 key pair and stores master_private.enc (AES-256-GCM + PBKDF2 600k). Master public key written as master_public.pem.

Volatile Identity

On every launch, ProcessManager.cs wipes the previous onion service keys and bootstraps a fresh .onion v3 address via Tor — making long-term tracking impossible.

Live Progress UI

Real-time Tor bootstrap percentage, log stream, .onion address detection, and HMAC admin route display — all in a minimal Neo-Brutalist WPF interface. No Chromium runtime required.

// Linux Dedicated Engine

Developing a native Linux build using Avalonia UI and direct .NET Core bindings. This bypasses the heavyweight Electron wrappers on Linux while preserving extreme execution speeds and native memory management.

// Unix Security Parity

Implementing Linux-specific process isolation via direct prctl(PR_SET_PDEATHSIG) bindings and memory protection policies like mlockall, guaranteeing identical zero-footprint properties and secure process lifecycle governance.

🔴 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.

🟡 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.

 # 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**: El servidor demostró una resistencia excepcional a ataques. De 26 pruebas realizadas, **25 pasaron** y **1 observación** fue identificada como configuración de desarrollo que debe ser corregida para producción. --- ## 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 excepcional 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). **El único hallazgo significativo** es la configuración de CORS abierto, que debe restringirse antes del despliegue en producción. **Puntuación de seguridad general**: 9.5/10 *Fin del reporte.*