Por si no querés leer todo lo anterior, te resumo, es un ataque desde el hardware al software inspirado en un hecho real, una falla de software en un sistema crítico.
Dependiendo del flujo del programa, detectar que está ejecutando un “momento interesante” y producir una alteración en el comportamiento.
El escenario real sería un expendedor de cervezas, un bloque recibe el pedido y otro lo autoriza. El funcionamiento normal es apretamos el botón de "dame cerveza" y si el botón de "ok" está apretado, te la da. En la demo es con una barrera y los botones son "abrir" y "autorizar".
Tras el ataque, si vamos en un cierto momento y apretamos el "dame cerveza", sale independientemente de que "ok" esté apretado.
El programa víctima es entonces:
while (1) {
sensor1 = gpio1.read(); // leer botón 1
sensor2 = gpio2.read(); // leer botón 2
if (sensor1) { // si pide cerveza...
if (sensor2) { // si está autorizado...
gpio3.write(1); // abrir
} else {
printf(“no way\n”); // denegar
}
}
}
El diseño atacante:
if ( secuencia de instrucciones && condición de tiempo) {
register = 1;
}
Recordemos que para hacer posible e interesante este ataque, agregué un módulo de RTC y otro de servo, un PWM restringido, superpuesto con la placa:
 |
| SOC icicle en edu-ciaa-fpga |
Anticipándome, el ataque estará en bien adentro de rv32 y con una pista desde el RTC.
Explicación del programa
Para comprender el siguiente código necesitás saber unas pocas instrucciones.
La lectura de los botones
 |
| Lectura de botones |
lui: Carga en a5 el valor 0x10 desplazado doce bits a la izquierda
addi: Le suma 4 a a5, observá que coincide con 0x10004 como corresponde con el código HDL y el código C.
lw: Lee en a5 la memoria apuntada por a5, o sea, 0x00010004, o sea, el valor de los botones.
zext.b: esto es el equivalente a andi rd,rs,255, le mete todo cero a los 24 bits superiores de a5.
not: invierte los valores, corresponde a ~.
sb: guarda en lo apuntado por s0 menos 29 lo que haya en a5
fast forward, estamos en...
La zona de interés
 |
| Zona de interés |
El punto de ataque es el naranja, queremos que independiente de los botones, no tome el branch, que pase directo a "state = BarrierUp;"
Para ello, necesitamos que a4 y a5 sean iguales. En el punto rojo, cuando se cargue ese 1 en a5, necesitamos forzar esa igualdad.
Antes, la zona amarilla es la secuencia que nos señala que el ataque debe activarse.
Despues, la instrucción resaltada en verde pisa el valor de a5 antes de que sea usado, esto produce que no hayan efectos colaterales relacionados a a5, lo mismo pasa con a4, pero búscalo vos en el código.
Hay varias maneras de obtener este archivo, como es pedirle a gcc que compile a assembly, que conserve las piezas intermedias o lo que hice, decompilar:
riscv64-unknown-elf-objdump main.o -d -S > main.s
-d es disassemble
-S es que incluya el código fuente
Pero no es tan fácil, ese main.o no está aún ubicado en el lugar definitivo del programa ni tiene resueltas las direcciones de salto, es entonces conveniente:
riscv64-unknown-elf-objdump progmen -d -S > progmem.s
y ahí te van a saltar unas diferencias, nos quedamos con los valores de la derecha.
 |
| main.s vs progmem.s |
En amarillo la diferencia por desplazamiento, en naranja los placeholders de los saltos y su resolución y en rojo el código binario correspondiente.
Esta bueno comprobar que el código de máquina corresponda:
 |
| Zona de interés |
Pero, siempre hay un pero, RISC-V es little endian, así que hay que darlos vuelta en el .hex:
 |
| Zona de interés en el binario final |
Fijate que hay una colisión con uno de los pasos de la secuencia, de todos modos no es el primero, no hay problema.
Hasta acá ya tenemos que conocemos la secuencia previa y sabemos cuál instrucción debe ser afectada.
Si encontramos una parte de esa secuencia, hay que cambiar unos registros. ¿Cómo? ya veremos...
- H4CK3D 2021: configuración básica
- H4CK3D 2021: leyendo los botones de la placa
- H4CK3D 2021: un desvío necesario
- H4CK3D 2021: un desvío innecesario
- H4CK3D 2021: sigue el desvío, para bien
- H4CK3D 2021: cambios al Makefile
- H4CK3D 2021: mejor resolución de dependencias en Makefile
- H4CK3D 2021: el escenario y el programa víctima
- H4CK3D 2021: el ataque concreto
- the missing pieces
- La charla con la demo
- El código fuente del SOC mejorado
- El código fuente del ataque
No hay comentarios:
Publicar un comentario