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.
No hay comentarios:
Publicar un comentario