Pentest para dispositivos Linux incrustados

0

Lo primero que trato de descubrir utilizando pentest:

  • Los permisos de los archivos (son archivos confidenciales en mi compilación de Linux a salvo de vulnerabilidades)
  • ¿Los programas se ejecutan bajo usuarios (por ejemplo, algo que se ejecuta bajo un usuario root, no debería)

¿Existe algún marco / herramienta que pueda emplearse para descubrir puntos débiles en las dos áreas anteriores para un dispositivo Linux incorporado?

P.S: Considérame un principiante en el área de pruebas de penetración. Estoy tratando de descubrir vulnerabilidades básicas y de arreglarlas.

    
pregunta sob 06.07.2017 - 17:08
fuente

2 respuestas

2

Lee sobre binwalk (y programas similares). Normalmente suelo grabar firmware con solo dd.

A menudo, los archivos dentro del firmware están en formato upx o gzip, lo cual no es un problema, y otras veces están en formatos oscuros, usualmente identificables con file .

En webroot, a veces puedes encontrar vulnerabilidades y en otras partes puedes encontrar, por ejemplo. cuentas un / privilegiadas. Incluso si tiene una contraseña, por lo general puede romper estas cuentas.

Dropbear sshd parece lo suficientemente común como para que te interesen las nuevas vulnerabilidades y dnsmasq (bastante popular) también ha tenido problemas.

No he jugado con JTAG, pero entiendo que puedes vivir parches binarios como getty y login con un poco de esfuerzo . Así que definitivamente vale la pena, si tienes acceso físico.

Para juguetes caros como PLCs, puedes implantar arduinos por ejemplo. Los módulos LoRa o 2.4GHz simplemente anulan los relés de disparo ON / OFF (si lo hace realmente rápido, mata lo que sea que esté conduciendo), y con MCU más rápidos como Teensy, probablemente pueda interceptar el tráfico en los puertos Ethernet. Con respecto a la alimentación de estos MCU, puede instalar un pequeño circuito con los reguladores 7808 o 7805, si no hay un riel de 5V. Muchos PLC se ejecutan a 24 V, que los reguladores de 78 * pueden funcionar. Necesita algunos topes adicionales para atrapar los picos, por ejemplo:

No es mi diagrama, no estoy seguro de por qué no hay un C1; aquí, C2 y C3 se corresponden con el C1 y C2 normales. C4 y C5 atrapan los picos cuando el 7805 se está encendiendo. ¡Importante! También observa que: W_dissipate = ( V_in - V_out ) * I_load .

    
respondido por el user2497 08.08.2017 - 22:28
fuente
2

Los sistemas embebidos por lo general se encuentran en un plano propio debido a que están altamente personalizados para las necesidades especificadas, sujeto a los escenarios de casos de uso. Realmente depende de cómo se usará el sistema y de cómo se construya el sistema.

Por ejemplo, si está utilizando Wind River Linux en un sistema integrado, no existe un caso de uso único / mal uso que podamos planear para considerar que será una compilación personalizada según las necesidades de los clientes y, como tal, Hay tanto que podemos hacer. Debe definir sus requisitos y luego definir los casos en los que puede anular los requisitos de seguridad (casos de mal uso). Desde allí puede dictar los vectores de ataque y comenzar la prueba de la pluma.

    
respondido por el Joshua Faust 06.07.2017 - 17:18
fuente

Lea otras preguntas en las etiquetas