¿Por qué los sistemas operativos no protegen contra teclados USB que no son de confianza?

El modelo de confianza para un dispositivo que conecte a su computadora es inherentemente difícil. El estándar USB se creó para permitir literalmente a cualquier persona crear un dispositivo USB. La seguridad no fue un factor. Incluso si lo fuera, ¿dónde depositas la confianza? La industria del cine probó este modelo con HDMI, y esencialmente ha fallado miserablemente. No puedes darle simultáneamente a alguien un dispositivo que hace algo, y evitar que entiendan cómo hacer lo mismo.

Su ejemplo propone depositar la confianza en el usuario. El problema más obvio es que nadie quiere escribir contraseñas solo para usar un teclado. Salvo eso, ¿realmente resolvería algo?

El usuario ya confía en el dispositivo, de lo contrario no lo conectaría a su computadora. Ya que la confianza ya se ha establecido, ¿por qué no harían simplemente lo que sea necesario para que funcione?

Para empezar, los teclados tienden a ser confiables mucho antes en el proceso de arranque que en el sistema operativo: si tiene una contraseña de BIOS o una clave de Bitlocker, ingresará eso antes de que se cargue el sistema operativo, usando el teclado . De hecho, un teclado especialmente malintencionado podría hacer casi cualquier cosa para evitar que el sistema operativo se cargue, hasta, y probablemente incluya, pretendiendo ser una unidad de arranque, y comenzar un rootkit antes de permitir que el sistema operativo se inicie.

También puedes extender las mismas reglas a los ratones (pueden hacer clic en un conjunto predefinido de puntos para abrir el teclado virtual, y luego escribir lo que quieran).

Alternativamente, puedes decidir que solo usarás dispositivos en los que confías y aceptar el pequeño riesgo de que sucedan cosas malas.

La respuesta es Utilidad

¿Cómo debe el usuario dar su consentimiento para que el mouse / teclado sea de confianza? ¿Con el teclado / mouse que podría ser malicioso? ¿Cómo maneja el caso cuando uno tiene que cambiar / reemplazar el teclado? Especialmente en el escenario de servidor, tiene múltiples teclados / mouse almacenados en otro lugar y grapa el siguiente mejor cuando necesita acceso físico al servidor. No recordará qué teclado pertenecía a qué servidor después de meses / años y el teclado podría incluso destruirse. ¿Cómo usar el teclado de reemplazo? ¿Das tu consentimiento con el teclado desconocido? ¿Cómo hacer esto con el primer teclado? Digamos que usted prueba una nueva PC de un amigo y usa su propio teclado y luego se lo da a su amigo. ¿Cómo debe dar su consentimiento a su teclado? Edición: puede solicitar una contraseña antes del primer uso, pero vea mi párrafo, pero el último.

Básicamente, la pregunta no resuelta es: ¿Cómo puede la computadora establecer una conexión confiable / segura para el usuario que no pueda ser falsificada / eludida por otro hardware / software / malo / / de una manera fácil? forma utilizable?

La regla 3 de las 10 leyes inmutables de la seguridad informática es: "Si un malvado tiene acceso físico sin restricciones a su computadora, ya no es su computadora". Si pones un BadUSB de un chico malo, eres el sirviente del malo y le das acceso físico a él por medio de un proxy. Tenga en cuenta que hay ataques peores similares a los de un USB malo. Por ejemplo, poner un dispositivo de un tipo malo en un FireWire u otra interfaz DMA le permite leer / escribir cualquier memoria y ejecutar cualquier código e incluso evitar las pantallas de bloqueo de Windows / Linux / Mac. Por eso, lo mejor es nunca poner un dispositivo que no sea de confianza en su computadora.

Edit: debido a esta regla y tales ataques no se pensaron cuando se pensó en el estándar (la seguridad física era menos importante en ese momento, excepto en los casos en que el acceso físico estaba restringido de todos modos), algo así como nunca fue parte del estándar . Ya había muchos más posibles ataques con acceso físico, por lo que no valía la pena considerar un caso tan pequeño. Habría aumentado enormemente la complejidad del sistema, especialmente si la autorización se debe compartir entre varios sistemas operativos y el BIOS ( "Presione F10 para BIOS") y cuántos almacenar. El siguiente problema surge al decidir dónde mostrar la contraseña, especialmente si se detectan varios monitores como una pantalla de computadora portátil defectuosa. Todo esto también habría tenido un impacto negativo en la aceptación por parte de los usuarios y un estándar más fácil de usar podría haberse convertido en el estándar. Dado que los dispositivos son producidos por compañías de trabajo económico, mayor complejidad (= costo) y menor aceptación (menos piezas vendidas) este caso de borde delgado no habría sido importante en ese momento.

Hay un software especializado en el mercado que le permite definir dispositivos USB confiables para entornos corporativos de alta seguridad, pero debido a los puntos que mencioné no están en uso generalizado.

La pregunta siempre parece estar entre la seguridad y la conveniencia. Con los ataques HID, el equilibrio parece estar a favor de las comodidades debido al acceso físico necesario para estos ataques. Obviamente, esto podría implementarse, pero no parece ser necesario hacerlo en este momento, por qué agregar código y problemas adicionales si la amenaza es mínima en ese momento.

El sistema operativo no sabe nada sobre el mundo fuera de sí mismo. Naturalmente, está diseñado para confiar en el hardware, porque no tiene forma de verificar si realmente existe el hardware. De hecho, si comparara el concepto de un sistema operativo que se ejecuta en hardware con la película The Matrix , prácticamente ser puntual en El sistema operativo es simplemente una colección de bytes que eventualmente son procesados por el hardware. Puede ejecutarse en una pieza de hardware real, virtualizado con otros sistemas operativos que tampoco son conscientes entre sí, o incluso distribuirse físicamente en varias unidades de hardware que actúan como un todo cohesivo. El único requisito real es que el hardware actúe de manera coherente con el modo en que el sistema operativo cree que debería comportarse.

Al final del día, el sistema operativo no puede existir sin el hardware, y depende completamente del hardware para decir la verdad. Si bien se han hecho algunos avances hacia la creación de sistemas más seguros (por ejemplo, cuando comenzaron a restringir la forma en que los buses PCI pueden usar DMA), aún son soluciones de seguridad en su mayoría en hardware. El sistema operativo puede rechazar la entrada de dispositivos USB, pero no puede determinar de manera confiable qué es un dispositivo USB al examinarlo, ya que el dispositivo puede mentir. Puede identificarse como lo que quiera, y el sistema operativo no puede hacer nada al respecto. Cualquier verificación de hardware tendría que venir de más hardware. Todo lo que sabe el sistema operativo es que está recibiendo una señal en un bus conocido que cumple con un protocolo conocido. Puede emular fácilmente que, por ejemplo, utilice cualquier otro tipo de software que se ejecute en un hipervisor; el sistema operativo no puede notar la diferencia.

Ciertamente podemos hacer cosas para hacer las cosas más difíciles para el software malintencionado, como requerir algún tipo de chip de cifrado con claves asíncronas, quizás utilizando un sistema de listas negras / listas blancas, que protegería contra actos casuales de malicia, pero eso solo lo haría. obstaculizar el desarrollo y aumentar el costo del nuevo hardware, frustrar a los consumidores y bloquear la competencia que no puede acceder a la lista blanca o incluso está bloqueada activamente por una lista negra. No hay una solución perfecta para el problema, y cualquier solución razonable tendría que hacerse a nivel de hardware, ya que el sistema operativo no puede determinar fácilmente si el hardware es lo que dice que es.

Mi lema de software es 3-D:

• Divergencia
• División
• dominio

Todos los componentes DEBEN hacer lo que se supone que deben hacer y nada más / lo demás , porque no espera que su refrigerador abra su cerveza. El sistema operativo debe proporcionar un entorno unificado y una consistencia API. Incluido para la protección real contra mal usb , pero la protección en sí misma debe ser un módulo, una extensión basada en API's aceptadas comúnmente. Eso es todo, es una cuestión arquitectónica.