hacktricks/physical-attacks/firmware-analysis/firmware-integrity.md

4.1 KiB

Aprende hacking en AWS desde cero hasta experto con htARTE (Experto en Red Team de AWS de HackTricks)!

Otras formas de apoyar a HackTricks:

Integridad del Firmware

Los firmwares personalizados y/o binarios compilados pueden ser cargados para explotar fallos de integridad o verificación de firmas. Los siguientes pasos pueden seguirse para compilar un backdoor bind shell:

  1. El firmware puede ser extraído usando firmware-mod-kit (FMK).
  2. Debe identificarse la arquitectura y el endianness del firmware objetivo.
  3. Se puede construir un compilador cruzado usando Buildroot u otros métodos adecuados para el entorno.
  4. El backdoor puede ser construido usando el compilador cruzado.
  5. El backdoor puede ser copiado al directorio /usr/bin del firmware extraído.
  6. El binario QEMU apropiado puede ser copiado al rootfs del firmware extraído.
  7. El backdoor puede ser emulado usando chroot y QEMU.
  8. El backdoor puede ser accedido a través de netcat.
  9. El binario QEMU debe ser eliminado del rootfs del firmware extraído.
  10. El firmware modificado puede ser empaquetado de nuevo usando FMK.
  11. El firmware con backdoor puede ser probado emulándolo con la herramienta de análisis de firmware (FAT) y conectándose a la IP y puerto del backdoor objetivo usando netcat.

Si ya se ha obtenido un shell de root a través de análisis dinámico, manipulación del cargador de arranque o pruebas de seguridad de hardware, se pueden ejecutar binarios maliciosos precompilados como implantes o reverse shells. Herramientas automatizadas de carga/implante como el framework Metasploit y 'msfvenom' pueden ser aprovechadas siguiendo los siguientes pasos:

  1. Debe identificarse la arquitectura y el endianness del firmware objetivo.
  2. Msfvenom puede ser utilizado para especificar el payload objetivo, la IP del host atacante, el número de puerto de escucha, el tipo de archivo, la arquitectura, la plataforma y el archivo de salida.
  3. El payload puede ser transferido al dispositivo comprometido y asegurarse de que tenga permisos de ejecución.
  4. Metasploit puede ser preparado para manejar las solicitudes entrantes iniciando msfconsole y configurando los ajustes según el payload.
  5. El reverse shell de meterpreter puede ser ejecutado en el dispositivo comprometido.
  6. Las sesiones de meterpreter pueden ser monitoreadas a medida que se abren.
  7. Se pueden realizar actividades de post-explotación.

Si es posible, las vulnerabilidades dentro de los scripts de inicio pueden ser explotadas para obtener acceso persistente a un dispositivo a través de reinicios. Estas vulnerabilidades surgen cuando los scripts de inicio hacen referencia, enlazan simbólicamente, o dependen de código ubicado en ubicaciones montadas no confiables como tarjetas SD y volúmenes flash utilizados para almacenar datos fuera de los sistemas de archivos raíz.

Referencias