Testes de segurança de sistemas embebidos para firmware e dispositivos ligados

O Delta lê o estado de segurança de um dispositivo Linux embebido: portas abertas, ficheiros de persistência, contas, pacotes, binários e módulos do kernel. O Midair compara-o com a linha de base aceite e lista o que mudou.

Analise a imagem de firmware antes da entrega. Depois, acompanhe as mesmas superfícies no dispositivo em funcionamento.

Iniciar o seu piloto Explorar a superfície de ataque
delta · gw-lab-2 · cycle 4415 Exemplo 
$delta --cfg golden.json --binaries / --json
port       4444/tcp LISTEN nc      appeared
persistence/etc/cron.d/backup 0666  T1053.003
account    UID 0: svc_backup       T1136.001
package    busybox 1.31.1          CVE-2021-28831
hardening  /usr/bin/agent          no stack canary
module     diag_hook               T1547.006
risk       grade D, 6 violations, exit 1

O que são testes de segurança de sistemas embebidos.E porque precisam do dispositivo.

Os testes de segurança de sistemas embebidos verificam o que um atacante consegue alcançar num dispositivo. Verificam também se isso mudou desde o último estado conhecido como bom. Cobrem os serviços que o dispositivo expõe, o software que corre e a forma como esse software foi compilado.

Quase tudo isto só se vê na imagem compilada ou no dispositivo. O código-fonte não diz que porta um pacote abre nem que tarefa cron um instalador deixou para trás. Também não mostra que binário perdeu o stack canary numa atualização da toolchain.

O Delta lê estas superfícies numa imagem de firmware ou num dispositivo em funcionamento. Indica as diferenças em relação a uma linha de base que aceitou. Não classifica nada por si e não altera nada no dispositivo.

A superfície de ataque de um dispositivo.Seis camadas, da rede até ao kernel.

Escolha uma camada para ver o que o Delta lê nela. Alterne entre a linha de base e o estado atual para ver o que apareceu e o que desapareceu.

Portas abertas

O que o Delta lêAs portas à escuta, com o protocolo, o estado e o processo a que pertencem. Uma norma pode limitar as portas que podem estar abertas.

Exemplo

Na linha de base

  • 22/tcp LISTEN dropbear
  • 443/tcp LISTEN nginx
  • 1883/tcp LISTEN mosquitto

Apareceu 1

  • 4444/tcp LISTEN nc

Em falta 0

  • nada

Ficheiros de persistência

O que o Delta lêCron, unidades systemd com as ligações *.wants, scripts de init e perfis de shell. Cada entrada leva um identificador de técnica MITRE ATT&CK. Um ficheiro de persistência com escrita para todos é crítico, mesmo sem linha de base.

Exemplo

Na linha de base

  • /etc/crontab
  • /etc/init.d/S50nginx
  • /etc/profile

Apareceu 2

  • /etc/cron.d/backup mode 0666 T1053.003
  • multi-user.target.wants/updater.service T1543.002

Em falta 0

  • nada

Contas e chaves

O que o Delta lêAs contas com UID 0 em /etc/passwd e o número de chaves no authorized_keys de cada utilizador. Qualquer conta com UID 0 além do root é crítica.

Exemplo

Na linha de base

  • UID 0: root
  • root: 1 authorized key

Apareceu 2

  • UID 0: svc_backup T1136.001
  • root: 2 authorized keys

Em falta 1

  • root: 1 authorized key

Pacotes e CVE

O que o Delta lêOs pacotes instalados com dpkg, opkg ou apk, como uma lista de materiais de software (SBOM). O Delta compara-os com um feed local de CVE que fornece, por exemplo construído a partir do OSV.

Exemplo

Na linha de base

  • busybox 1.36.1
  • openssl 3.0.13
  • dropbear 2022.83

Apareceu 1

  • busybox 1.31.1 CVE-2021-28831

Em falta 1

  • busybox 1.36.1

Binários e hardening

O que o Delta lêPara cada ficheiro ELF: arquitetura, libc, bibliotecas ligadas, toolchain, e NX, PIE, RELRO, stack canary, FORTIFY e se tem símbolos. Uma política de hardening pode exigir cada proteção.

Exemplo

Na linha de base

  • /usr/bin/agent NX PIE RELRO canary
  • /usr/sbin/nginx NX PIE RELRO canary

Apareceu 2

  • /usr/bin/agent csum 9f2c…e10c
  • Binary '/usr/bin/agent' lacks required mitigation: stack canary

Em falta 1

  • /usr/bin/agent csum 41ab…07c2

Módulos do kernel

O que o Delta lêOs módulos do kernel carregados e o /etc/ld.so.preload. O Delta assinala um módulo que não está na linha de base. Um ficheiro de preload que não esteja vazio é crítico.

Exemplo

Na linha de base

  • 8021q
  • nf_conntrack
  • wireguard

Apareceu 1

  • diag_hook T1547.006

Em falta 0

  • nada

No Midair, Accept as baseline junta uma diferença à linha de base. Watch this again retira uma entrada, e o dispositivo volta a reportá-la.

Imagem de firmware ou dispositivo ligado.As mesmas verificações, antes e depois da entrega.

Com --root, o Delta lê uma imagem de firmware montada ou um rootfs extraído, sem o arrancar. Nada corre dentro da imagem. Monte-a ou extraia-a primeiro, por exemplo com mount -o loop ou unsquashfs.

SuperfícieImagem de firmware (--root)Dispositivo em funcionamento
Pacotes e CVE Da base de dados de pacotes da imagem Da base de dados de pacotes do dispositivo
Binários e hardening Todos os ficheiros ELF da imagem Todos os ficheiros ELF do dispositivo
Checksums e ficheiros de persistência Sim Sim, e verifica que os ficheiros de persistência do sistema pertencem ao root
Linha de base de referência Capturada da imagem Capturada do dispositivo
Processos e portas abertas Nenhum: uma imagem não executa nada Sim
Interfaces de rede Como estão declaradas na configuração da imagem Como estão, incluindo o modo promíscuo
Montagens A partir de /etc/fstab Como estão montadas

Compilado para o dispositivo.Um binário estático por arquitetura.

O Midair pede o sistema operativo e a arquitetura do CPU de cada dispositivo. Compila o Delta para essa plataforma e instala-o por SSH.

cerca de 104 KBA build mais pequena do agente, otimizada para tamanho e sem símbolos.
x86
x86_64
ARM
aarch64armv7 hard-floatarm hard-floatarm soft-float
RISC-V
riscv64riscv32
MIPS
32 bits big-endian32 bits little-endianhard-float e soft-float64 bits n64 e n32, nas duas ordens de bytes

As builds para Linux são binários musl estáticos, por isso não precisam de libc no dispositivo. Uma build só de relatório deixa de fora todo o código que pode alterar o host.

Perguntas.Respostas curtas.

O que são testes de segurança de sistemas embebidos?

Os testes de segurança de sistemas embebidos verificam o que um atacante alcança num dispositivo: portas abertas, contas, pacotes, ficheiros de persistência, binários e módulos do kernel. Verificam também se algo disto mudou desde um estado conhecido como bom.

O Delta consegue analisar uma imagem de firmware sem o dispositivo?

Sim. Com --root, o Delta lê uma imagem montada ou um rootfs extraído, sem o arrancar. Verifica pacotes, ficheiros, binários e ficheiros de persistência. Os processos e as portas abertas precisam de um dispositivo em funcionamento.

O Delta altera alguma coisa no dispositivo?

Não por iniciativa própria. O Delta indica as diferenças em relação a uma linha de base ou a uma política. Qualquer ação no host exige um comando explícito, e uma build só de relatório não tem código capaz de agir.

Como é que o Delta encontra vulnerabilidades conhecidas?

O Delta lê os pacotes instalados com dpkg, opkg ou apk e compara-os com um feed local de CVE que fornece. Uma ferramenta converte registos OSV nesse feed e exporta o inventário em CycloneDX 1.5 ou SPDX 2.3. O Delta não lê a base de dados rpm.

Em que dispositivos corre o Delta?

Em dispositivos Linux com x86_64, ARM, RISC-V e MIPS, como binários estáticos. O Midair compila o agente para a arquitetura do dispositivo e instala-o por SSH.

Qual é a diferença em relação aos testes de cibersegurança?

A nossa página de testes de cibersegurança segue uma fraqueza desde o código até um teste e ao dispositivo. Esta página trata do próprio dispositivo: o que expõe e o que mudou.

Comece por um dispositivo.Ou por uma imagem de firmware.

Um piloto captura uma linha de base da sua imagem ou do seu dispositivo e mostra o que muda entre builds.

Iniciar o seu piloto