Evilgrade framework de pruebas de penetración
Evilgrade framework de pruebas de penetración
Evilgrade es un marco (framework) de pruebas de penetración histórico desarrollado para evidenciar fallos de seguridad en los mecanismos de actualización de software. Su objetivo principal es demostrar cómo las aplicaciones que no aseguran o no verifican sus descargas pueden ser vulnerables a la inyección de código.
¿Cómo funciona a nivel teórico?
El escenario que simula Evilgrade requiere que el auditor o atacante esté posicionado en la red para interceptar el tráfico mediante un ataque de tipo Man-in-the-Middle (MitM) o suplantación de DNS (DNS Spoofing):
Interceptación del tráfico: Se redirige el dominio al que la aplicación consulta sus actualizaciones hacia la máquina del auditor.
Detección de la petición: Evilgrade emula el servidor de actualización legítimo y detecta cuando la aplicación realiza una consulta en texto plano (HTTP).
Inyección de binario: En lugar de la actualización real, el sistema entrega un ejecutable alternativo que la aplicación descarga e intenta instalar.
¿Por qué las aplicaciones modernas ya no son vulnerables?
Evilgrade aprovecha dos fallos de diseño fundamentales en el software antiguo:
Uso de HTTP sin cifrar: Las peticiones de búsqueda de actualización viajaban en texto plano, permitiendo la lectura y manipulación en tránsito.
Ausencia de firma digital: La aplicación cliente no validaba la integridad del archivo ni la identidad del autor antes de ejecutarlo.
Hoy en día, las buenas prácticas de desarrollo evitan este vector mediante:
HTTPS obligatorio: Uso de canales cifrados para verificar la identidad del servidor de origen.
Firmas de código (Code Signing): Verificación obligatoria de firmas criptográficas (PGP, firmas Authenticode) e integridades por hash (SHA-256) previo a cualquier instalación.
Gestores de paquetes centralizados: En sistemas como Kali Linux o distribuciones basadas en Debian, el gestor
aptvalida siempre las llaves GPG de los repositorios antes de instalar paquetes.
La verificación de firmas GPG se basa en una regla simple: necesitas el archivo, su firma y la clave pública del autor. Con esos tres elementos, puedes confirmar que el archivo no ha sido modificado y proviene realmente de quien dice ser.
El proceso en 3 pasos
1. Importar la clave pública del autor
Para poder verificar una firma, primero debes añadir la clave pública del desarrollador a tu depósito local (keyring).
gpg --import clave_publica.asc
Si la clave está publicada en un servidor de claves (Keyserver), puedes descargarla e importarla directamente:
gpg --keyserver keyserver.ubuntu.com --recv-keys ID_DE_LA_CLAVE
2. Descargar el archivo y su firma
Normalmente, los proyectos distribución ofrecen el ejecutable (por ejemplo, programa.tar.gz) y un archivo adjunto con extensión .sig o .asc (por ejemplo, programa.tar.gz.sig).
3. Ejecutar la verificación
Usa el comando gpg --verify indicando primero el archivo de firma y después el archivo descargado:
gpg --verify programa.tar.gz.sig programa.tar.gz
Si ambos archivos tienen el mismo nombre y están en la misma carpeta, basta con apuntar al archivo de firma:
gpg --verify programa.tar.gz.sig
¿Cómo interpretar el resultado?
Al ejecutar el comando de verificación, busca el mensaje principal en la salida del terminal:
Firma correcta (
Good signature): Significa que el archivo es auténtico y no ha sufrido ninguna modificación desde que fue firmado.Firma no válida (
BAD signature): El archivo ha sido alterado, se descargó de forma incompleta o la firma no se corresponde con ese ejecutable. No lo ejecutes.
Nota sobre el aviso de "No confiable": Es común ver un mensaje como
WARNING: This key is not certified with a trusted signature!. Esto no significa que la firma sea falsa, sino que tu sistema no ha validado personalmente la identidad del dueño de la clave mediante la red de confianza de GPG (Web of Trust). Mientras digaGood signature, la integridad del archivo está garantizada.
