Ejemplo de SID

Aunque a todos nos debe haber ocurrido, es la primera vez que me ocurre a mi de modo tan evidente, comparto la experiencia.

Me contactaron unas personas para ver unos temas de seguridad y uno de los items era "revisar las seguridad de un firmware".

Los actores somos el end user, mi interlocutor que es el cliente y yo.

Este firmware era el resultado de la siguiente situación, el que hayan dos dispositivos y cada uno con dos firmwares representa las posibilidades, el end user termina conectándose a un firmware en un dispositivo:

 

Situación actual

Los end users tienen un dispositivo de hardware que para mejor interactuar con el  sistema del cliente requiere cambiar un aspecto de su configuración con frecuencia. Como la alta frecuencia de ese cambio no está prevista por el fabricante del firmware, no ofrece almacenar configuraciones alternativas, mediante la interfaz web del firmware hay que pisar con la nueva la existente en lugar de dar de alta varias y sólo elegir luego la activa.

La idea del cliente era tomar el firmware que es opensource y extenderlo.

Actualización de Firmware

Inmediatamente me generó incomodidad debido a que el firmware es una pieza delicada y cualquier cambio o extensión aumenta la superficie de ataque y aumenta la responsabilidad, tanto de seguridad como de funcionamiento. Además, pensaba estos inconvenientes adicionales:

• Si hay upgrades al firmware oficial, el cliente va a tener que portar los cambios.
• Si el cambio es aceptado e incorporado al firmware oficial, probablemente tenga que mantenerlo.
• Hasta acá quizás es aceptable, pero si hubieran distintos firmwares, se multiplica el esfuerzo.

Esto viene de la mano de un concepto de seguridad que dice que a menos que te dediques a la criptografía, no diseñes criptografía, sólo usala, pues vas a meter la pata. En este caso aplica si no te dedicás a hacer firmware, no diseñes firmware.

 

La primera propuesta que se me ocurrió fue implementar una web que haga de fachada ante esos dispositivos y mediante un poquito de scrapping, opere contra el dispositivo, almacenando las configuraciones alternativas, que de paso no haría falta que las cargue el end user, sólo seleccionarlas.

 

Con servidor web en el medio

 

El scrapper, al que elegantemente llamé "conector", sería uno por cada versión de firmware de cada dispositivo. Este concepto de conector se repite en todas mis propuestas.

Nuevamente una mala sensación, las credenciales de los dispositivos de los end users pasan por la infraestructura del cliente, eso aumenta su responsabilidad en términos de seguridad. Aunque sólo reciba las credenciales y las use sin persistirlas, que es una buena reducción de superficie, resulta inútil frente un APT en la infraestrucura del cliente.

Y están estos problemas adicionales:

• El dispositivo debe ser accesible desde la red del cliente
• Hay que darle una nueva credencial ante este sistema
• Cuando el end user ingrese la IP del dispositivo sobre el cual operar... podría ser cualquier IP, se podría usar mal por error o a propósito.
  

Finalmente, evolucioné la idea a elaborar un plugin para el browser, que usando los conectores de scrapping, tomen las configuraciones o de un storage local o de la infraestructura del cliente.

 

Con plugin de browser

Sólo hay que mantener dos versiones, no hace falta actualizar permanentemente, pues el cambio de arquitectura de los plugins de los browsers no es para nada frecuente. Las credenciales del dispositivo quedan del lado del end user

Los ataques que quedan pasan por influenciar al end user para que ponga la IP de un dispositivo atacante en lugar del suyo y así tomarle las credenciales, pero quien caiga en ese ataque probablemente caiga tambien en "dame las credenciales".

Una posibilidad extra es hacer una aplicación mobile, pero quizás nuevamente estás entrando en terreno desconocido y aumentando la superficie de ataque.

Por si no te diste cuenta, SID es un término nuevo que inventé, o quizás reinventé, pero no tengo ganas de andar buscando a ver si ya existe, Security Influenced Design, en la línea de TDD (Test Driven Design de Kent Beck), BDD (Behavior Driven Design), DDD (Domain Driven Design de Evans). No llega a guiar el diseño pero si lo influencia.

Teensy al rescate

Me había contado una persona, obviamente no puedo decir cuál, que cuando entró hace ya muchos años en una importante empresa informática de alcance mundial, precursora por ese entonces en tener la modalidad de algunos días remotos, que en la laptop que le habían dado había un agente que reportaba a un sistema de monitoreo y si no interactuabas con la máquina te escrachaba. No recuerdo que recurso utilizó para engañarlo, si fué físico o por software.

Como te había contado trabajo con dos máquinas físicas, la power del trabajo llena de virtuales y la de medio pelo mía, llena de pantallas y con un buen teclado. Normalmente no uso de modo directo la del trabajo, pero a veces me viene bien poner algo en las pantallas, por ejemplo durante un reciente ejercicio de ciberseguridad mostrar un mapa de la red.

El problema es que se bloquea por falta de interacción y tiene una política que me impide cambiar el tiempo de activación del bloqueo, que debe andar por unos diez minutos. Encima está lejos y me tengo que desplazar...

Aunque a mi me moleste, es una política correcta, pues la idea es que el equipo no debe quedar expuesto si uno se distancia.

Me encuentro en una situación parecida, pero no para evitar ser controlado. En el caso de la otra persona, había un escenario adversarial entre la empresa y la persona. En mi caso, estoy pagando el efecto colateral del escenario de un tercero, adversario, afecta la usabilidad.

Necesito entonces algún método para evitar el bloqueo. Entonces recuerdo que tengo algún teensy libre, esto es un microcontrolador que se puede comportar como un dispositivo usb, en este caso en particular me interesa como teclado o mouse. 

El teensy viene a ser como un arduino, de hecho arduino ide con la extensión apropiada se usa para programarlo. No voy a repetir los detalles de la instalación de arduino ide más teensy, están en Rescatando un touchpad y Usando un touchpad con usb, donde tambien hay más detalles respecto a los botones y a comportarse como un teclado.

Lo primero que pensé es que envíe un evento de teclado, pero ¿cuál? No tiene que escribir. Usar algún modificador tambien es un problema si justo estoy escribiendo que me cambie minúscula por mayúscula y no me de cuenta.

Lo mejorcito será entonces mover apenas el mouse para un lado, luego revertir.

Necesito tambien algún feedback de que está activo, de que está actuando y poder desactivarlo sin desconectarlo, pero esto último me obligaría a armarle un gabinete, pues no tiene botón, sólo un led.

El programa es increiblemente sencillo, sólo hay que configurar apropiadamente el entorno.

 

const int ledPin = 6;

void setup() {
   pinMode(ledPin, OUTPUT);
}
void loop()
{
   Mouse.move(1, 1);
   digitalWrite(ledPin, HIGH);
   delay(1000);
   Mouse.move(-1, -1);
   digitalWrite(ledPin, LOW);
   delay(10000);   
}
 

Me lleva más tiempo mirar fijo la máquina a ver si esta funcionando que

sudo modprobe usbmon

sudo wireshark

 

Selección de usb en wireshark

 

Elegir el monitor correcto al inicio, atinarle al filtro, esperar dos mensajes y mirarlos fijos y ver que uno corresponde a Mouse.move(1, 1) y otro a Mouse.move(-1, -1).

Mouse.move(-1,-1)

Mouse.move(1,1)

De todos modos, mientras escribo esto, lo dejé conectado y ya pasaron 29 minutos sin bloquearse, debe andar bien.