Una sección importante de la seguridad de los equipos de autoservicio por la exposición física que se tienen de dichos equipos en calle o en ubicaciones con bajo control de acceso físico, es la sección de BIOS o firmware que generalmente se cubre únicamente con una contraseña de acceso a las configuraciones de BIOS y a las de orden de boot.

Ataques como reemplazo de disco  para bootear un nuevo sistema operativo que permita interaccionar con la capa de hardware mediante XFS, este tipo de ataques son muy comunes en instituciones financieras donde las configuraciones criptográficas de la sesión de los perimetrales es extremadamente pobre o mal implementada.

Pero no hay que olvidar que ataques como Meltdown and Spectre a procesadores intel que inclusive han tenido afectación en equipos de autoservicios, esto debido a fallas de seguridad de los fabricantes.

Para adentrarnos en una parte de la seguridad extremadamente olvidada o nula hemos implementado una cierta cantidad de pruebas de seguridad para diferentes procesadores de PC core de ATM para validar controles de seguridad y configuraciones que vienen dentro de los PC core y firmwares que los fabricantes operan productivamente y entregan por defecto sin mayor explicación.

Esto con el fin de poder identificar riesgos que ya están pasando en diferentes entornos de ciberseguridad como son los ataques UEFI y ataques persistentes para mantener la inyección del malware o ataque inclusive con el cambio de disco o re-grabado de información o ataques al boot o SMM.

Mediante diferentes pruebas en los procesadores de los ATMs de nuestra propiedad en entornos controlados se han efectuado estas pruebas con tal fin de evaluar la diferencia de controles de seguridad de firmware entre PC cores de fabricantes.

En Cyttek Group también ofrecemos consultorías de seguridad de ATMs para acompañar a nuestros clientes en evaluaciones de seguridad de bajo nivel y ataques de firmware para identificar falencias de los equipos de autoservicio y evitar asi vector de ataques que puedan ser explotados no solamente explotando y demostrando sino implementando  soluciones de seguridad y monitorización para mejorar la seguridad frente a estas casuísticas y muchas otras de casos de ataques de bajo nivel indagados.

Para este grupo de pruebas se han tomado como muestra los siguientes tipos de PC Core :

NCR

  • Pocono
  • Estoril

Diebold Nixdorf:

DN

  • Opteva
  • Sierra
  • Canyon

Procesadores o PC cores fuera de alcance de las prueba o para una segunda verificación:

  • NCR Talladega, Riverside, Skylake
  • Wincor p280
  • Hyosung Q87 y H81

Resultados seguridad sobre los PC Cores productivos de ATMs que los fabricantes entregan:

WARNING o FAILED: son resultados de la evaluación a considerar como posibles riesgos

ERROR o not Supported: son resultados que en el momento de la prueba la configuración o el procesador no se ha podido efectuar por varios motivos, arquitectura del procesador, o controles de seguridad que han resaltado o limitado el acceso a la memoria para efectuar la prueba.

PASSED: control legible y correctamente implementado .

N/A: nuestras pruebas no se han podido efectuar por diferente firmware o implementación del firmware y como por falta de tiempo también dejamos fuera varios procesadores decidimos incluir el restante de pruebas y procesadores en un segunda investigación

  • Alguno de las pruebas que se han efectuado manualmente para validar como acceso a Buffer KBRd y DMA entre otras el resto se ha efectuado mediante frameworks de validación de seguridad de firmware.

En esta sección hablaremos de ataques que son realmente prácticos con los resultados obtenidos de los PC core de ATMs para esto hemos desarrollado unos casos prácticos que pueden variar de acuerdo a tipo de firmware versiones y otras peculiaridades de protección de entorno fisico y logico sobre cada ATM pero partiendo de que un atacante tenga acceso a un entorno físico de un ATM , estos son los casos prácticos:

Caso 1

Borrado o flasheado de contraseña de bios para insertar algún equipo de dispositivo que permite parear perimetrales o comunicarse (in contemplar que existe una capa de software como es la criptografía de comunicación entre perimetrales y CPU) .

Poder borrar editar o flashear la contraseña de BIOS: los ATM ESTORIL con firmware v40 son los más seguros de la base evaluada.

Los Modelos OPTEVA, CANYON, POCONO  tiene una exposición en el buffer head pointer que permite exponer contraseñas de boot o de mala administración de gestión de cifrados de disco un ejemplo de las pruebas , esto como se muestra a continuación puede ser un riesgo operativo importante ya que con acceso físico se puede llegar a borrar estas contraseñas y editarlas en el buffer

Caso 2 :

Ataques de DMA para poder evitar o saltar los discos cifrados y poder hacer inyecciones en memoria para editar procesos en RAM como puedan ser procesos de WFS_CDM_CMD_EXEC o otros procesos de ejecución en un atm

Otro ataque practico son ataque de DMA o direct memory access con acceso físico a los ATM aunque en los procesadores más nuevos estoril y opteva son posibles de implementar estos ataques ,los modelos de procesador ESTORIL en v40 vienen desde fábrica ya con las variables correctamente seteadas pero desde la v36 de bios a la 39 es posible efectuar ataques  como se muestra en la imagen de la izquierda y si hablamos  procesadores OPTEVA, CANYON y POCONO ya que la configuración por defecto de Intel v-TD viene deshabilitada es posible efectuar estos ataques como se muestra en un procesador opteva en la imagen de la derecha , este tipo de ataques DMA se vuelven prácticos puesto que  las variables de protección de memoria para estos ataques no están bien seteadas por defecto ni en bios ni en Sistema operativo, un ejemplo de ataque con PCIleetch a procesadores Estoril v39 y opteva:

Aunque ataques de DMA como podemos ver en los resultados son mucho más factibles a procesadores Sierra, Canyon, Opteva y Pocono sobre windows 7 , en estoril windows 7 también es factible dicho ataque para esquivar cifrado de disco y editar la memoria ram en caliente pero ncr estoril sobre windows 10 con kernel DMA protection y con Estoril v40 con v-TD activado estos ataques no son factibles, para el procesador estoril tiene diferentes posibilidades  cuando los firmware se encuentren en versiones anteriores a la 39.

CASO 3

Ataques como Spectre v2 en los procesadores estoril última versión vienen ya protegidos con el parche de intel pero en procesadores opteva para atm 5500 o 5550 y en procesadores canyon y sierra por defecto no viene de fábrica, se debe aplicar el parche de intel para esta protección que afecta al rendimiento del procesador, esto puede suponer riesgos de escalada de privilegios y acceso a la maquina riesgos importantes en un ATM productivo por que el atacante puede tener acceso físico parcial o total dependiendo del nivel de explotación física que se requiera .

CASO 4

Ataque de persistencia o malware que permita mantenerse en el Firmware para luego replicarse en la siguiente instalación de la imagen o disco este es el último y todavía no hemos visto ataques prácticos en ATM puesto que el proceso de persistencia en UEFI es posible pero existen otras limitantes que son las ACLs de software como HDE, Checker , Trendmicro entre otros, pero si en casos como Malware de real de kits de explotación como hacking team que requiere acceso físico para implementar backdoors de firmware sobre x86 .

En este caso los procesadores ESTORIL y OPTEVA que generalmente en windows 10 el 100% de implementaciones se están efectuado con boot UEFI son los más susceptibles de acuerdo a las réplicas y pruebas que hemos efectuado de manipulación de uefi sobre la documentación de implantes UEFI disponible , aunque  el objetivo del blog no es explicar ataques de atms , si es importante revisar todas las variables UEFI para evitar este tipo de ataques sobre arquitecturas x64

Variables UEFI  que deben estar protegidas para evitar implantes UEFI en el boot en este ejemplo los procesadores estoril están al 100% protegidas pero los procesadores OPTEVAS  no todas las variables están correctamente implementadas:

[] Testing UEFI variables ..
[] Variable dbxDefault (BS+RT)
[] Variable dbDefault (BS+RT)
[] Variable KEKDefault (BS+RT)
[] Variable PKDefault (BS+RT)
[] Variable IrsiInfo (BS+RT)
[] Variable MokListRT (BS+RT)
[] Variable BootCurrent (BS+RT)
[] Variable VarEdit (BS+RT)
[] Variable ErrOutDev (BS+RT)
[] Variable ConOutDev (BS+RT)
[] Variable ConInDev (BS+RT)
[] Variable DynamicBar (BS+RT)
[] Variable FixedBar (BS+RT)
[] Variable ConOutCandidateDev (BS+RT)
[] Variable ConInCandidateDev (BS+RT)
[] Variable IccMbpData (BS+RT)
[] Variable PlatformLangCodes (BS+RT)
[] Variable LangCodes (BS+RT)
[] Variable VendorKeys (BS+RT)
[] Variable SignatureSupport (BS+RT)
[] Variable PostMsgStatusCode (BS+RT)
[] Variable OsIndicationsSupported (BS+RT)
[] Variable MemoryOverwriteRequestControl (NV+BS+RT)
[] Variable BootOrder (NV+BS+RT)
[] Variable Boot0000 (NV+BS+RT)
[] Variable Setup (NV+BS+RT)
[] Variable dbx (NV+BS+RT+TBAWS)
[] Variable SystemSupervisorPw (NV+BS+RT)
[] Variable SystemSupervisorSalt (NV+BS+RT)
[] Variable ConIn (NV+BS+RT)
[] Variable ConOut (NV+BS+RT)
[] Variable MeBiosExtensionSetup (NV+BS+RT)
[] Variable WhiteListHeader (NV+BS+RT)
[] Variable WhiteListVar (NV+BS+RT)
[] Variable SioIt8785eSetup00 (NV+BS+RT)
[] Variable Boot0001 (NV+BS+RT)
[] Variable HddSerialNumber (NV+BS+RT)
[] Variable OfflineUniqueIDEKPubCRC (NV+BS+RT)
[] Variable OfflineUniqueIDEKPub (NV+BS+RT)
[] Variable CRNvData (NV+BS+RT)
[] Variable CapsuleLongModeBuffer (NV+BS+RT)
[] Variable FullReset (NV+BS+RT)
[] Variable MsdmAddress (NV+BS+RT)
[] Variable SecureFlashInfo (NV+BS+RT)
[] Variable AcpiGlobalVariable (NV+BS+RT)
[] Variable OemBestTolud (NV+BS+RT)
[] Variable SpdData (NV+BS+RT)
[] Variable CrConfig (NV+BS+RT)
[] Variable CrConfigDefault (NV+BS+RT)
[] Variable Custom (NV+BS+RT)
[] Variable BootType (NV+BS+RT)
[] Variable Timeout (NV+BS+RT)
[] Variable CustomPlatformLang (NV+BS+RT)
[] Variable AdvBootOrderVar (NV+BS+RT)
[] Variable PegDataVar (NV+BS+RT)
[] Variable MrcS3RestoreVariable (NV+BS+RT)
[] Variable BiosGuardStatus (NV+BS+RT)
[] Variable PlatformLang (NV+BS+RT)
[] Variable Lang (NV+BS+RT)
[] Variable MTC (NV+BS+RT)
[] Variable PhysicalPresenceFlags (NV+BS+RT)
[] Variable PhysicalPresence (NV+BS+RT)
[] Variable OemFuncSwSmiNum (NV+BS+RT)
[] Variable CustomSecurity (NV+BS+RT+AWS)
[] Variable EventStorageVar (NV+BS+RT)
[] Variable SecureBoot (BS+RT)
[] Variable Kernel_EntRevokeSiStatus (NV+BS+RT)
[] Variable Kernel_ATPSiStatus (NV+BS+RT)
[] Variable Kernel_WinSiStatus (NV+BS+RT)
[] Variable Kernel_SkuSiStatus (NV+BS+RT)
[] Variable Kernel_RvkSiStatus (NV+BS+RT)
[] Variable Kernel_SiStatus (NV+BS+RT)
[] Variable CurrentPolicy (NV+BS+RT+TBAWS)
[] Variable certdb (NV+BS+RT+TBAWS)
[] Variable SerialNumberVar (NV+BS+RT)
[] Variable UuidVar (NV+BS+RT)
[] Variable DefaultPasswordValid (NV+BS+RT)
[] Variable SystemUserPw (NV+BS+RT)
[] Variable SystemUserSalt (NV+BS+RT)
[] Variable RestoreFactoryDefault (NV+BS+RT+AWS)
[] Variable SecureBootEnforce (NV+BS+RT+AWS)
[] Variable SetupMode (BS+RT)
[] Variable AuthVarKeyDatabase (NV+BS+RT+AWS)
[] Variable db (NV+BS+RT+TBAWS)
[] Variable KEK (NV+BS+RT+TBAWS)
[*] Variable PK (NV+BS+RT+TBAWS)

 CASO 5

Daños operativos o ejecución de inhabilidad para botear en los procesadores OPTEVA, CANYON, POCONO probados desde la capa de software de S.O. es posible editar interaccionar con diferentes variables del SPI, SMM o TPM en cambio en procesadores SIERRA y ESTORIL es necesario tener los drivers y al parecer los fabricantes vienen con sus propias imágenes de flasheo para tal fin requiriendo un reboot con su propio S.O. esto quiere decir que de la imagen Windows 10 LSTB del 2016 por ejemplo es más vulnerable a interaccionar desde la capa de software los procesadores CANYON y OPTEVA que ESTORIL, pero el daño no sería ataque prácticos para desfalcar o generar faltantes este tipo de casos están más enfocados  en daños de integridad para evitar bootear.

Otro punto a considerar con la migración a Windows 10 los procesadores soportados de los fabricantes son:

NCR

  • Estoril, Skylake (INSYDE, AMI)

Diebold

  • Opteva , Canyon (AMI Opteva y Canyon intel )

Hyosung

  • Q87 y H81 (AMI Aptio 4 y V)

Según nuestras observaciones para los ataques prácticos probados del caso 1, 2, y 3 nuestra  recomendación va enfocada el firmware más seguro evaluado que son los procesadores ESTORIL , aunque en algunas versiones de firmware de estoril ataques de DMA y de borrado o flasheado de contraseñas y nuevo firmware se pueden ejecutar sin problemas , en definitiva los procesadores OPTEVA  y CANYON tienen una mayor cantidad de vectores o de configuraciones inseguras.

Para ataque UEFI son más factibles en procesadores ESTORIL y OPTEVA  ya que en tecnologias o procesadores com sierra , talladega o p210 de wincor no son soportados los boot por UEFI.

En general muchos ataques todavía no se han terminado de portar o integrar en el mundo de ATM y XFS ya que esto vectores de vulneración con acceso a interfaces físicas son solo la primera fase de unos ataques más complejos que pueda delimitar un resultado práctico como pueda ser un compromiso o infección de XFS para dispensar sobre un ATM concreto.

Estas son las pruebas de seguridad y revisión de configuraciones efectuadas en los diferentes procesadores de los fabricantes aplicando las configuraciones por defecto que vienen en los PCs productivos

  • bios_kbrd_buffer :  Este parametro o prueba que revisa que las  Contraseñas de Preboot en el buffer del  teclado de bios queden expuestas esto puede afectar tanto las contraseñas de BIOS, Contraseña de cifrado de discos o de boot .
  • bios_smi: Revisión de las configuraciones "SMI Events Configuration" para identificar si existe una protección frente a la escritura  de la región SMM de la BIOS.
  • bios_ts: Revisión de la interfaz de bios que evita que puedan existir ataques de hijacking en el boot mediante un control de prohibición implementando en el Top Swap mode.
  • bios_wp: La región en la bios que permite ser flasheada puede ser protegida para evitar implementaciones de bios maliciosas que luego comprometan al Sistema operativo, estas protecciones se puedan proteger usando la protección basada en SMM o configurando la protección desde los controladores de SPI, para la protección de SPI dichas protecciones deberán cubrir  toda la región de la bios para poder aprobar y pasar la prueba y no ser implementadas parcialmente.
  • spectre_v2: Revisión si la implementación del fabricante incluye mitigaciones para  Speculative Execution Side Channel. En especial verificar si la CPU soporta la implementación de la protección    Target Injection vulnerability a.k.a. Spectre Variant 2 (CVE-2017-5715)

Estas verificaciones incluyen las siguientes mitigaciones sean soportadas y habilitadas en la CPU y habilitadas por el S.O. :

  1. Indirect Branch Restricted Speculation (IBRS) y Indirect Branch Predictor Barrier (IBPB): CPUID.(EAX=7H,ECX=0):EDX[26] == 1
  2. Single Thread Indirect Branch Predictors (STIBP): CPUID.(EAX=7H,ECX=0):EDX[27] == 1 IA32_SPEC_CTRL[STIBP] == 1
  3. Enhanced IBRS: CPUID.(EAX=7H,ECX=0):EDX[29] == 1 IA32_ARCH_CAPABILITIES[IBRS_ALL] == 1 IA32_SPEC_CTRL[IBRS] == 1
  • debugenabled: Revisar si el firmware tiene las opciones de Debug habilitadas en producción especialmente mediante la interfaz   Direct Connect Interface (DCI), Para esto revisamos los bits pertenecientes a los siguientes registros:
  1. HDCIEN bit in the DCI Control Register
  2. Debug enable bit in the IA32_DEBUG_INTERFACE MSR
  3. Debug lock bit in the IA32_DEBUG_INTERFACE MSR
  4. Debug occurred bit in the IA32_DEBUG_INTERFACE MSR
  • ia32cfg: Pruebas que verifique que todas las CPU lógicas sobre arquitecturas   IA-32/IA-64 estén configuradas y protegidas incluyendo  IA32 Model Specific Registers (MSRs)
  • me_mfg_mode: Revisión que el modo ME Manufacturing no esté habilitado
  • memconfig: identificar que las configuraciones de memoria map estén correctamente aseguradas en concreto los siguientes registros :
  1. "PCI0.0.0_GGC": 'GGCLOCK',
  2. "PCI0.0.0_PAVPC": 'PAVPLCK',
  3. "PCI0.0.0_DPR": 'LOCK',
  4. "PCI0.0.0_MESEG_MASK": 'MELCK',
  5. "PCI0.0.0_REMAPBASE": 'LOCK',
  6. "PCI0.0.0_REMAPLIMIT": 'LOCK',
  7. "PCI0.0.0_TOM": 'LOCK',
  8. "PCI0.0.0_TOUUD": 'LOCK',
  9. "PCI0.0.0_BDSM": 'LOCK',
  10. "PCI0.0.0_BGSM": 'LOCK',
  11. "PCI0.0.0_TSEGMB": 'LOCK',
  12. "PCI0.0.0_TOLUD": 'LOCK'
  • memlock: identificar que el Bit MSR_LT_LOCK_MEMORY MSR esté correctamente configurado para proteger el SMM con un valor de  Bit [0]
  • remap: revisión de la configuración de re-mapeo de memoria sobre las variables de registro

PCI0.0.0_REMAPBASE
PCI0.0.0_REMAPLIMIT
PCI0.0.0_TOUUD
PCI0.0.0_TOLUD
PCI0.0.0_TSEGMB

  • rtclock: Revisión por controles de memoria RTC , el objetivo es identificar si no están aplicados los controles de memoria ya que dependerá del S.O. si será usado o no.
  • secureboot.variables: Verificar que todas las llaves de arranque seguro estén seteadas sobre UEFI y estén autenticadas(BS+RT+AT) , además de revisar sobre la  protección de acceso y modificación
  • sgx_check: revisar si Intel SGX está habilitado en la BIOS y que sus configuraciones de SGX estén correctamente  parametrizadas sobre PRM (Protected Memory Range)
  • smm: Revisión si la Memoria SMM (SMRAM) está configurada correctamente sobre el modo de protección con la variable D_LCK correctamente implementada
  • smm_code_chk: el bit SMM_Code_Chk_En esta en el registro MSR_SMM_FEATURE_CONTROL del firmware, es importante tener el control de la memoria SMRR , habilitando dicho bit el fabricante puede mitigar ataques de vulnerabilidades de buffer sobre la memoria SMM .
  • memlock: revisar si el firmware del fabricante implementa protección SMM mediante la configuración de la variable MSR_LT_LOCK_MEMORY MSR (0x2E7)  este correctamente configurada a Bit [0]
  • smm_dma: Igual que en la SMRAM la protección de ejecución de software en la CPU necesita de protección de acceso directo a memoria (DMA) para que el Kernel no pueda exponer de forma lógica el acceso a rangos de memoria SMRAM de forma lógica o mediante ataques físicos de (DMA), este tipo de ataques permiten que en un ATM el atacante con acceso físico pueda esquivar el cifrado de disco o pueda mantener ataques sobre procesos o información que opera sobre las interfaces SPI, lo que buscamos es que la protección DMA esté implementada desde fábrica y no sea una configuración de BIOS extra como es el caso con la aplicación de Intel v-TD, ya que implicaría conocimientos más extensos para implementar por defecto un PC core en un proyecto de despliegue de  nuevas versiones de windows o de PC-Cores
  • spd_wd: Revisión si los permisos de escritura están deshabilitados sobre el controlador de SMBus , mediante la configuración correcta de SMBUS_HCFG.SPD_WD
  • spi_access: revisar si el fabricante por defecto da acceso  región  de Flash del SPI para tener permisos de programar la región del descriptor de flash de firmware
  • spi_desc: después de revisar si tenemos acceso a la región para hacer un flash de SPI , revisamos si tenemos permisos de escritura y lectura para la capa de software esto con tal fin que desde la capa de software se puede definir un ataque que pueda esquivar cualquier protección del sistema de intercambio de memoria
  • spi_fdopss: Revisar si el Controlador de flasheo del SPI , si tiene correctamente configurado el Security Override Pin Strap (FDOPSS), que en algunas ocasiones se setea como variable y en otras se rutea hacia un jumper en la placa madre para resetear
  • spi_lock: Revisar si la configuración del controlador del SPI desde los rangos protegidos de la sección de operación del SPI iniciando y  incluyendo PRO-Pr4,  está correctamente configurado mediante la variable HSFS[FLOCKDN] , el objetivo es identificar la correcta configuración de la protección de rangos del SPI que sean rangos protegidos de acceso .

Información pública al respecto sobre este tipo de ataques y seguridad:

• Security Issues Related to Pentium System Management Mode (CSW 2006)

• Implementing and Detecting an ACPI BIOS Rootkit (BlackHat EU 2006)

• Implementing and Detecting a PCI Rootkit (BlackHat DC 2007)

• Programmed I/O accesses: a threat to Virtual Machine Monitors? (PacSec 2007)

• Hacking the Extensible Firmware Interface (BlackHat USA 2007)

• BIOS Boot Hijacking And VMWare Vulnerabilities Digging (PoC 2007)

• Bypassing pre-boot authentication passwords (DEF CON 16)

• Using SMM for "Other Purposes“ (Phrack65)

• Persistent BIOS Infection (Phrack66)

• A New Breed of Malware: The SMM Rootkit (BlackHat USA 2008)

• Preventing & Detecting Xen Hypervisor Subversions (BlackHat USA 2008)

• A Real SMM Rootkit: Reversing and Hooking BIOS SMI Handlers (Phrack66)

• Attacking Intel BIOS (BlackHat USA 2009)

• Getting Into the SMRAM: SMM Reloaded (CSW 2009, CSW 2009)

• Attacking SMM Memory via Intel Cache Poisoning (ITL 2009)

• BIOS SMM Privilege Escalation Vulnerabilities (bugtraq 2009)

• System Management Mode Design and Security Issues (IT Defense 2010)

• Analysis of building blocks and attack vectors associated with UEFI (SANS Institute)

• (U)EFI Bootkits (BlackHat USA 2012 @snare, SaferBytes 2012 Andrea Allievi, HITB 2013)

• Evil Maid Just Got Angrier: Why Full-Disk Encryption With TPM Is Insecure On Many Systems (CSW 2013)

• A Tale of One Software Bypass of Windows 8 Secure Boot (BlackHat USA 2013)

• BIOS Chronomancy (NoSuchCon 2013, BlackHat USA 2013, Hack.lu 2013)

• Defeating Signed BIOS Enforcement (PacSec 2013, Ekoparty 2013)

• UEFI and PCI BootKit (PacSec 2013)

• Meet „badBIOS‟ the mysterious Mac and PC malware that jumps airgaps (#badBios)

• All Your Boot Are Belong To Us (CanSecWest 2014 Intel and MITRE)

• Setup for Failure: Defeating Secure Boot (Syscan 2014)

• Setup for Failure: More Ways to Defeat Secure Boot (HITB 2014 AMS)

• Analytics, and Scalability, and UEFI Exploitation (INFILTRATE 2014)

• PC Firmware Attacks, Copernicus and You (AusCERT 2014)

• Extreme Privilege Escalation (BlackHat USA 2014)

• Summary of Attacks Against BIOS and Secure Boot (DEF CON 22)

• https://www.trendmicro.com/en_us/research/15/g/hacking-team-uses-uefi-bios-rootkit-to-keep-rcs-9-agent-in-target-systems.html

•http://www.legbacore.com/Research_files/HowManyMillionBIOSesWouldYouLikeToInfect_Whitepaper_v1.pdf

• https://github.com/hardenedlinux/firmware-anatomy/blob/master/hack_ME/firmware_security.md