Los prácticos controles remotos ahorran mucha energía a los administradores del sistema y, al mismo tiempo, suponen un gran riesgo de seguridad cuando no pueden apagarse mediante el hardware mediante un puente o un interruptor en la placa del sistema. El bloque Intel Management Engine 11 en las plataformas modernas de Intel es uno de esos peligros: inicialmente no se puede desconectar y, además, algunos mecanismos de inicialización y funcionamiento del procesador están vinculados a él, por lo que una desactivación brusca puede simplemente conducir a una inoperabilidad completa del sistema. La vulnerabilidad radica en Intel Active Management Technology (AMT) y, con un ataque exitoso, le permite obtener un control total sobre el sistema, como se informó en mayo de este año. Pero investigadores de Positive Technologies.
El propio procesador IME es parte del System Hub Chip (PCH). Con la excepción de las ranuras de procesador PCI Express, toda la comunicación entre el sistema y el mundo exterior pasa a través del PCH, lo que significa que el IME tiene acceso a casi todos los datos. Antes de la versión 11, era poco probable que se produjera un ataque contra este vector: el procesador IME usaba su propia arquitectura con el conjunto de instrucciones ARC, que era poco conocido por los desarrolladores externos. Pero en la versión 11 jugaron una mala broma con la tecnología: se transfirió a la arquitectura x86 y se utilizó un MINIX modificado como sistema operativo, lo que significa que los estudios de terceros del código binario se han vuelto mucho más fáciles: tanto la arquitectura como el sistema operativo están bien documentados. Los investigadores rusos Dmitry Sklyarov, Mark Ermolov y Maxim Goryachy lograron descifrar los módulos ejecutables de IME versión 11 y comenzar un estudio exhaustivo de ellos.
Intel AMT tiene una calificación de 9,8 sobre 10 por vulnerabilidad. Desafortunadamente, deshabilitar completamente el IME en las plataformas modernas es imposible por la razón anterior: el subsistema está estrechamente relacionado con la inicialización y arranque de la CPU, así como con la administración de energía. Pero puedes eliminar todos los elementos innecesarios de una imagen de memoria flash que contenga módulos IME, aunque es muy difícil hacerlo, especialmente en la versión 11. Se está desarrollando activamente el proyecto me_cleaner, una utilidad que te permite eliminar la parte común de la imagen y dejar solo componentes vitales. Pero hagamos una pequeña comparación: si en las versiones IME hasta 11 (antes de Skylake) la utilidad eliminó casi todo, dejando aproximadamente 90 KB de código, entonces en la actualidad es necesario guardar alrededor de 650 KB de código, y luego, en algunos casos, el sistema puede apagarse después de media hora, desde el bloqueo. IME entra en modo de recuperación.
Sin embargo, hay algunos avances. El grupo de investigadores antes mencionado logró utilizar un kit de desarrollo, que es proporcionado por la propia Intel, e incluye utilidades Flash Image Tool para configurar parámetros IME y un flasher Flash Programming Tool que funciona a través de un controlador SPI integrado. Intel no pone estos programas a disposición del público, pero no es difícil encontrarlos en Internet.
Se analizaron los archivos XML obtenidos con este kit (contienen la estructura del firmware IME y una descripción del mecanismo de la correa PCH). Un bit llamado "reserve_hap" (HAP) parecía sospechoso debido a la descripción de "Habilitar plataforma de alta seguridad (HAP)". Una búsqueda en la web reveló que este es el nombre de un programa de plataforma de alta confianza asociado con la NSA de EE. UU. Habilitar este bit indica que el sistema ingresó al modo de inhabilitación de Alt. El bloque IME no respondió a los comandos y no respondió a las influencias del sistema operativo. Hay una serie de matices más sutiles que se pueden encontrar en el artículo sobre Habrahabr.ru, pero la nueva versión de me_cleaner ya ha implementado soporte para la mayoría de los módulos peligrosos sin establecer el bit HAP, lo que coloca al motor IME en el estado "TemporaryDisable".
La última modificación de me_cleaner deja solo los módulos RBE, KERNEL, SYSLIB y BUP incluso en la versión 11 del IME, no encontraron un código que le permita habilitar el sistema IME en sí. Además de estos, puede usar el bit HAP para asegurarse de que la utilidad también pueda hacerlo. Intel ha revisado la investigación y ha confirmado que una serie de configuraciones de IME están realmente relacionadas con las necesidades gubernamentales de seguridad mejorada. Estas configuraciones se introdujeron a pedido de los clientes del gobierno de EE. UU., Se han sometido a una validación limitada y no son oficialmente compatibles con Intel. La compañía también niega la introducción de las llamadas puertas traseras en sus productos.
En resumen, dice lo siguiente (en adelante, en el texto, mi relato libre subjetivo).
Al parecer, las grandes corporaciones de todo el mundo, incluidas Apple, Amazon y otras como ellas, han pedido servidores de alta gama caros a SuperMicro durante muchos años. Esta última estaba comiendo de tales volúmenes de pedidos, sus propias fábricas ya no podían hacer frente. Luego entregó la producción de una cierta cantidad de placas base a sus subcontratistas chinos.
Gente educada china acudió a estos mismos subcontratistas y les hizo una oferta que no puede ser rechazada. Vamos, muchachos, a petición nuestra, a petición nuestra, también instalarán un chip indocumentado ma-a-a-a-scarlet más en las placas base que produzcan. Si lo hace, le traeremos dinero adicional, pero si no lo hace, pagaremos su negocio con varios cheques. Como resultado, las placas base "modificadas" de esta manera se vendieron en todo el mundo, y algunas de ellas también terminaron en grandes empresas estadounidenses del primer escalón, bancos y agencias gubernamentales.
Pasó algún tiempo. Una de las divisiones de Amazon, una determinada empresa llamada "Elements", se encargó de la seguridad de sus soluciones en el campo del procesamiento masivo de flujos de video. Entre otras cosas, ordenaron una auditoría de seguridad de hardware de una determinada empresa canadiense. Y fue aquí donde se descubrieron chips indocumentados hábilmente escondidos implantados en placas base. Que no son tan fáciles de encontrar. Porque, en primer lugar, son muy pequeños y grises. En segundo lugar, se disfrazan de acoplamientos de soldadura ordinarios o condensadores de chip. En tercer lugar, en las últimas revisiones comenzaron a ocultarse justo en el grosor de la textolita, de modo que solo son visibles en radiografías.
Si cree en el texto, entonces, por medio del microcódigo incrustado, el chip espía a través del módulo BMC hace "ping" periódicamente a uno de sus "titiriteros" anónimos, de quien recibe más instrucciones para la acción. Y supuestamente incluso el adversario antes mencionado es capaz de descargar "desde donde" algún código, que luego se inyecta directamente en el núcleo en ejecución del sistema operativo o en el código de la aplicación.
Bueno, siguen más desvaríos sobre cuán grande es el vacío en la seguridad, qué tipo de cabras son estos chinos, cuál es su audacia e insolencia, no se puede confiar en todas las cabras, "ahora todos vamos a morir" y eso es todo. Ahí termina el razonamiento técnicamente interesante.
En general, soy un gran escéptico en la vida. Sin negar el genio de los chinos, algunos momentos personalmente me parecen poco realistas. ¿Tomarlo así, a escondidas de los ingenieros y la administración, y realizar cambios en el diseño de la placa base al nivel del fabricante, sin interrumpir su rendimiento? Y si con el conocimiento de la dirección, ¿cómo se sintió motivado para exponer una empresa tan grande a un riesgo de reputación tan grave? ¿Inyectar su código en el sistema operativo y las aplicaciones? Bueno, con Windows, está bien, estoy listo para creer con un crujido. Pero en Linux, ¿dónde no sabes de antemano quién y cómo se recopila? ¿Ejercitar la actividad de la red sin dedos? Que, si se desea, se pueden detectar y filtrar. Sin mencionar el hecho de que los administradores normales nunca exponen los BMC "para mostrar su trasero desnudo en Internet", y los buenos administradores generalmente los lanzan a una VLAN separada sin la capacidad de acceder a ningún lado.
Bueno, de nuevo, recientemente ha progresado una feroz manía por los espías y paranoia entre los estadounidenses. Y también decidieron pelear con China. Entonces, la objetividad e imparcialidad del artículo original es una gran pregunta. Por otro lado, no entiendo muy bien de dónde sacan temas tan hermosos. En 2011, la revista sensacionalista "Ksakep" escribió sobre los mismos marcadores chinos a nivel de microcódigo en la unidad flash BMC. Ese artículo también huele a delirio paranoico, pero no hay humo sin fuego. ¿O sucede?
En general, comparte tu opinión en los comentarios. Es especialmente interesante escuchar al camarada kvazimoda24 sobre la posibilidad de integrar algún tipo de microcircuitos espía en el grosor del PCB.
No soy un profesional en el campo de la seguridad de la información, mi área de interés son los sistemas informáticos de alto rendimiento. Llegué al tema de la seguridad de la información por accidente, y esto es lo que se discutirá más adelante. Creo que esta historia de ficción iluminará mejor los problemas asociados con el hardware de virtualización que una simple declaración de hechos. Incluso antes del anuncio oficial de nuevos procesadores Intel con soporte para virtualización de hardware (a principios de 2007), concibí el uso de estos chips para crear un único sistema informático basado en varios servidores, que se convertiría en una única unidad informática con una arquitectura SMP para el sistema operativo y las aplicaciones. Para ello, se requería escribir un hipervisor compacto con funcionalidad no estándar, cuya característica principal no sería la división de los recursos de una sola unidad informática entre diferentes SO, sino, por el contrario, la unificación de los recursos de varias computadoras en un solo complejo, que sería controlado por un SO. Al mismo tiempo, el sistema operativo ni siquiera tuvo que adivinar que no se trataba de un solo sistema, sino de varios servidores. El hardware de virtualización brindó tal oportunidad, aunque originalmente no estaba destinado a resolver tales problemas. En realidad, todavía no se ha creado un sistema en el que el hardware de virtualización se utilice para la informática de alto rendimiento, e incluso en ese momento yo era un pionero en esta área. El hipervisor para esta tarea, por supuesto, se escribió desde cero. Era de fundamental importancia ejecutar el SO ya en una plataforma virtualizada para que desde los primeros comandos del cargador del SO todo funcionara en un entorno virtual. Para hacer esto, tuvimos que virtualizar el modelo real y todos los modos de operación del procesador e iniciar la virtualización inmediatamente después de inicializar la plataforma antes de cargar el sistema operativo. Dado que el sistema de virtualización para este propósito resultó no ser estándar y parecía un módulo de software compacto completamente autónomo (tamaño del código no más de 40-60 Kb), el lenguaje de alguna manera no se atrevió a llamarlo hipervisor, y comencé a usar el término "hipercontrolador", ya que es más preciso transmitió la esencia del propósito funcional del sistema. El equipo en serie con hardware de virtualización aún no estaba disponible en ese momento, sin embargo, gracias a la cooperación con Craftway, tuve acceso a muestras de preproducción de procesadores y placas base con soporte de virtualización, que aún no se lanzaron oficialmente (las llamadas muestras, que Intel amablemente proporciona a su Compañeros de negocio). Por lo tanto, el trabajo comenzó a hervir en este equipo de "muestra". Se ensambló la maqueta, se escribió el hipercontrolador, todo funcionó según lo previsto. Debo decir que en ese momento el hardware de virtualización estaba muy "crudo", por lo que repetidamente se negó a funcionar como está escrito en la documentación. Tuve que lidiar literalmente con cada comando de ensamblaje, y los comandos para el hardware de virtualización tenían que escribirse en códigos de máquina, ya que entonces no había compiladores que admitieran comandos de virtualización. Estaba orgulloso de los resultados obtenidos, me sentía casi el señor de los mundos virtuales ... pero mi euforia no duró mucho, solo un mes. En ese momento, ya había ensamblado un diseño basado en servidores con hardware de virtualización, cuyas primeras muestras en serie acababan de aparecer, pero el diseño no funcionó. Comencé a resolverlo y me di cuenta de que mi sistema se cuelga al ejecutar comandos de virtualización de hardware. La impresión fue que o no funcionaron en absoluto, o funcionaron de alguna manera fuera de la caja. El bloqueo se produjo solo cuando el hardware de virtualización se estaba ejecutando en modo real, pero si mi sistema se inició desde el modo protegido después de que se cargó el sistema operativo, entonces todo estaba bien. Los profesionales saben que en las primeras revisiones, el hardware de virtualización de Intel no admitía el funcionamiento del procesador en tiempo real. Esto requirió una capa adicional lo suficientemente grande como para emular el x86 virtual. Dado que el hipercontrolador se inició antes de que se cargara el sistema operativo, para que pudiera creer plenamente en la nueva configuración virtual, se ejecutó una pequeña parte del código de arranque del sistema operativo en el modo real del procesador. El sistema murió solo en los controladores de emulación de modo real en el hipercontrolador. Al principio pensé que me había equivocado en alguna parte, no entendía algo, me olvidé de algo. Revisé todo hasta el último bit de mi código, no encontré ningún error y comencé a pecar no en mí mismo, sino en mis colegas detrás de la colina. Lo primero que hice fue reemplazar los procesadores, pero eso no ayudó. En las placas base en ese momento, el hardware de virtualización estaba solo en el BIOS, donde se inicializaba cuando se encendía el servidor, así que comencé a comparar el BIOS en las placas base (placas base del mismo tipo con muestras): todo coincidía con el byte y el número del BIOS mismo. Caí en un estupor y, como ya no sabía qué hacer, apliqué el último recurso: el "método de empujar". ¿Qué no hice? Ya no pensaba, sino simplemente combinaba, y al final descargué estúpidamente biografías del sitio web oficial de Intel y las reescribí en placas base, después de lo cual todo funcionó ... No hubo límite para mi sorpresa: el número de BIOS era el mismo , las imágenes del BIOS coincidían byte a byte, pero por alguna razón, las placas base en serie solo comenzaron a funcionar cuando cargué el mismo BIOS tomado del sitio web de Intel en ellas. Entonces, ¿la razón todavía está en las placas base? Pero su única diferencia estaba en el marcado: Assembled Canada estaba escrito en las muestras y Assembled China en las placas de serie. Quedó claro que las placas de China contienen módulos de software adicionales integrados en el BIOS, pero los programas de análisis estándar no vieron estos módulos. Aparentemente, también trabajaron con hardware de virtualización y, en consecuencia, pudieron ocultar el verdadero contenido del BIOS. La razón de la congelación de mi hipercontrolador en estas placas chinas también quedó clara: dos sistemas de software trabajaban simultáneamente con el mismo hardware de virtualización, lo que no permitía compartir sus recursos. Quería lidiar con este BIOS malicioso, y sin pensarlo dos veces en "marcadores", "puertas traseras", "características indocumentadas", solo había interés académico y nada más. Debo decir que en paralelo con la introducción del hardware de virtualización, Intel actualizó radicalmente el chipset. Este chipset, numerado 5000x, todavía se está produciendo con varias modificaciones. El puente sur de este chipset, 631xESB / 632xESB I / O Controller Hub, al que se conectan microcircuitos flash con BIOS, prácticamente no ha cambiado desde 2007 y se utiliza como chip base para casi todos los servidores en una versión de dos sockets. Descargué la hoja de datos del puente sur, leí la descripción y me quedé atónito. Resulta que tres chips de memoria flash están conectados a este nuevo puente sur: el primero es un BIOS estándar, el segundo está dedicado a los programas del procesador del controlador de red y el tercero está destinado a la unidad BMC integrada en el puente sur. La unidad de gestión del sistema (BMC) es un medio de control y supervisión remotos de la instalación informática. Es indispensable para grandes salas de servidores, donde es simplemente imposible permanecer mucho tiempo debido al ruido, la temperatura y las corrientes de aire. El hecho de que las unidades BMC tengan su propio procesador y, en consecuencia, memoria flash para sus programas, por supuesto, no es una novedad, pero hasta ahora dicho procesador y memoria se extrajeron en una placa separada que estaba conectada a la placa base: si lo desea, póngalo, no lo desea. no lo pongas. Ahora Intel ha implementado estos componentes en el puente sur, además, conectó esta unidad al bus del sistema y no usó un canal de red dedicado (como lo proporciona el estándar IPMI que describe las funciones de la unidad BMC) para el funcionamiento de la red de servicio, sino que canalizó todo el tráfico de la red de servicio a la red principal. adaptadores. Luego aprendí de la documentación que los programas en el microcircuito flash de la unidad BMC están encriptados, y un módulo criptográfico de hardware especial, también integrado en el puente sur, se usa para descomprimirlos. Tales unidades de la Armada nunca me habían encontrado antes. Para no ser infundado, aquí hay un extracto de la documentación de este puente sur:
- Procesador ARC4 funcionando a una velocidad de 62,5 MHz.
- Interfaz a ambos puertos LAN del concentrador controlador de E / S Intel® 631xESB / 632xESB que permite la conexión directa a la red y el acceso a todos los registros LAN.
- Módulo criptográfico, compatible con algoritmos de cifrado AES y RC4 y algoritmos de autenticación SHA1 y MD5.
- Mecanismo asegurado para FW regulado cargable.
- Las nuevas placas de servidor de la serie 5000 de Intel contienen programas que están integrados en la memoria flash de la unidad BMC y se ejecutan en el procesador central, y estos programas se ejecutan utilizando el hardware de virtualización del procesador central.
- Las imágenes flash del sitio web oficial de Intel no contienen dichos módulos de software, por lo tanto, los módulos de software que interfieren conmigo se instalaron ilegalmente en las placas base en la etapa de producción.
- La memoria flash de la unidad BMC contiene módulos de software cifrados que no se pueden ensamblar y verter en la memoria flash sin conocer las claves de cifrado, por lo tanto, quien insertó estos módulos de software ilegales conocía las claves de cifrado, es decir, tenía acceso a información realmente secreta.
El tiempo de ejecución que se muestra en la foto es un cierto valor condicional, que corresponde aproximadamente al ciclo del procesador. Luego realicé la misma prueba en una placa base de producción y me aseguré de mis suposiciones paranoicas: los ciclos de comando se alargaron significativamente. 
Es decir, en la memoria flash de la unidad BMC de placas de servidor de China, fabricada bajo la etiqueta Intel, había un módulo de software no declarado instalado en la etapa de producción, que opera como un host de hipervisor. Queda por convencer a otros de esto. Lo primero que hice fue contactar al representante ruso de Intel. No fue difícil en absoluto, ya que los empleados de la oficina rusa a menudo se presentaban en el Craftway. Lo conté y mostré todo, pero no estaba seguro de que el técnico entendiera todo. Estos llamados especialistas técnicos difieren poco de los gerentes en términos de su competencia. Sin embargo, prometió informar de todo a la dirección. No sé si lo hizo, pero no hubo respuesta de Intel, todo salió como arena. En ese momento, mi trabajo en Craftway había terminado y comencé un nuevo proyecto en una empresa relacionada con los sistemas de seguridad de la información. El responsable de esta firma, con quien compartí mis "descubrimientos", se tomó mis palabras en serio. Al respecto, se decidió contactar a la dirección del Centro de Seguridad de la Información y Comunicaciones Especiales del FSB. Esta estructura dentro del FSB está involucrada en garantizar la seguridad de la información en el país y regula las actividades de las organizaciones estatales y comerciales que se relacionan con la protección de la información. También regula las medidas de protección de la información para agencias gubernamentales y firmas comerciales que procesan información clasificada y confidencial. La empresa en la que trabajaba en ese momento mantenía contactos oficiales con el Centro a fin de certificar y licenciar sus proyectos comerciales, por lo que fue bastante fácil organizar una reunión a nivel de especialistas. Se asumió que los expertos del Centro comunicarían su opinión a la gerencia, y si luego la gerencia considera necesario escucharnos, la siguiente etapa será una reunión a un nivel superior. La reunión tuvo lugar, conté y mostré todo lo que pude averiguar, luego demostré la presencia de un módulo de software ilegal usando los ejemplos de placas de Canadá y China. Por cierto, esa fue la primera vez que escuché el término profesional "marcador", que denota un módulo de este tipo. Cuando la conversación giró hacia la Armada, apareció un malentendido en los ojos de los colegas del Centro. Tuve que realizar un programa educativo. En el proceso, resultó que ni siquiera sabían sobre la existencia de un microprocesador especial en el puente sur con acceso a un adaptador de red y sobre la presencia de un módulo criptográfico en la unidad naval que viola la ley rusa. En conclusión, de manera bastante inesperada escuchamos que este modelo de amenazas ya ha sido investigado, se están aplicando un conjunto de contramedidas en relación a ellas y, en general, no le tenemos miedo a los marcadores, ya que nuestros sistemas no tienen acceso a Internet. Las investigaciones posteriores no llevaron a nada, todo se basaba en el secreto, como, somos inteligentes y súper alfabetizados, y se supone que no debes saber nada. Sin embargo, dudaba mucho de su conocimiento técnico, ya que simplemente no entendían la mayor parte de lo que les decía y mostraba. Nos separamos sobre lo que informarían a sus superiores, y solo ellos decidirían sobre las acciones futuras. Más tarde descubrí cuál era este "método secreto" para detectar programas host. Y me enteré por accidente, durante las negociaciones en la empresa, el titular de la licencia del Centro, autorizado para verificar la BIOS en busca de marcadores. Los especialistas técnicos de esta empresa, que realizan una investigación sobre el BIOS, dijeron que sus módulos de software que utilizan hardware de virtualización deben buscarse mediante las firmas de los comandos de virtualización. De hecho, las instrucciones del procesador para hardware de virtualización contienen de tres a cuatro bytes en el código del programa, pero ¿quién dijo que encontrarían este código de programa sin cifrar en un microcircuito flash? ¿Cómo escanean este código en la RAM si estas áreas de la memoria están protegidas contra la visualización por hardware? En general, el resultado del primer encuentro dejó un regusto desagradable, y en el estado de ánimo más lúgubre esperaba el desarrollo de los acontecimientos. Un mes y medio después, nos invitaron al propio Centro de Protección de la Información y Comunicaciones Especiales, para que pudiéramos demostrar el marcador que habíamos descubierto. Esta vez no fueron los empleados comunes los que se reunieron para escucharnos, sino los gerentes y los principales especialistas (al menos así se presentaron). El encuentro se convirtió en una charla, me escucharon con atención durante casi tres horas, estaba claro que estaban escuchando por primera vez lo que les estaba diciendo. He enumerado nuevas vulnerabilidades en la plataforma x86, mostré el marcador y dije cómo detectarlo, y respondí muchas preguntas. Al final, nos agradecieron, dijeron que el tema debía desarrollarse en el marco de proyectos especiales de investigación, y de eso nos separamos. La euforia se desvaneció cuando nos llegó información a través de canales no oficiales de que simplemente no querían creernos. Sin embargo, esto no enfrió mi deseo de probar mi caso. Como me pareció entonces, la solución estaba en la superficie: era necesario escribir un módulo de programa de este tipo para el marcador yo mismo. No habría podido poner un marcador en la memoria flash de la Marina, pero bien podría haberlo insertado en el BIOS principal. Decidí equipar el hipervisor con un módulo de auto-seguridad para enmascarar en la memoria y en un microcircuito flash, así como bloquear la escritura en el microcircuito flash donde se colocará el código del marcador, luego de lo cual será posible eliminarlo solo desoldando el BIOS y reprogramándolo en un programador externo. Solo quedaba decidir sobre la función "maliciosa" que debería realizar el hipervisor. Recordé la declaración de uno de los especialistas de FSB de que no le temen a los marcadores, ya que sus sistemas están desconectados de la red global. Pero la información del mundo exterior debe ingresar de alguna manera a estas redes locales seguras, al menos a través de discos ópticos desechables. Así, llegué a la conclusión obvia y decidí analizar el flujo de información entrante en la pestaña por medio del hipercontrolador para implementar, por así decirlo, un arma apocalíptica, es decir, usar la pestaña para destruir el sistema informático en un comando externo, pasándolo por el flujo de información de entrada, esteganográficamente. Para escanear el flujo de información de forma encubierta, sin perder rendimiento, solo el hardware de virtualización puede manejarlo. En qué punto escanear, también está claro: en los búferes de E / S de los sistemas de disco y un adaptador de red. Escanear búferes de E / S es un gran problema para el hardware de virtualización. ¡Dicho y hecho! Dicho hipercontrolador con un tamaño de aproximadamente 20 KB se registró en el BIOS de la placa base y está equipado con una función anti-detección. Bloqueó los intentos de sobrescribirlo al actualizar el BIOS y realizó la única función: restableció el chip flash del BIOS cuando se recibió un comando de destrucción. Para facilitar la implementación, el comando en sí se cosió en un archivo de texto en formato DOC en las etiquetas de configuración. Cuando todo estuvo listo, la gerencia de la compañía fue nuevamente al FSB con una propuesta para mirar el trabajo de nuestro propio marcador y asegurarnos de que las tecnologías de virtualización representan una amenaza real. Pero nadie quería mirar nuestro marcador en el caso, un comando vino desde arriba (nunca supe de quién era el pedido) de no comunicarse más con nosotros. Los principales luchadores por la seguridad de la información no quisieron escucharnos. Luego, ya sin esperar nada, de hecho, para limpiar nuestra conciencia, intentamos transmitir información sobre el problema a los usuarios de los sistemas de seguridad de la información. Contactamos a Gazprom para informar a los especialistas de la empresa sobre las amenazas actuales a los sistemas de control de procesos distribuidos. Logramos concertar una reunión con la dirección de la seguridad corporativa y la gestión de los sistemas de seguridad complejos de esta corporación. Se ha preparado especialmente para ellos una versión más visual del marcador con una interfaz de comando simplificada. El marcador se activó después de descargar un archivo de texto a la computadora, cuyo contenido incluía dos palabras: "Gazprom" y "detener", dispuestas en orden aleatorio. Después de eso, la computadora murió, pero no de inmediato, sino con un retraso de cinco minutos. Naturalmente, era posible retrasar un día, pero entonces no habríamos cumplido el tiempo asignado para la manifestación. Los empleados de "Gazprom" se quejaron del bajo nivel de seguridad de la información y dijeron que este no es su negocio, ya que se guían por los requisitos y reglas establecidas por el FSB. Cerrado el círculo, quedó claro que este sistema monolítico de "irresponsabilidad informativa" no podía romperse. En los más de tres años que han pasado desde entonces, nunca escuché a nadie hablar del hardware de virtualización como una herramienta para penetrar en los sistemas de destino. ¿Paradoja? No lo creo. La especificidad del tema es que solo aprendemos sobre tecnologías fallidas. No conocemos tecnologías que no se hayan descubierto, y sus autores, por supuesto, guardan silencio. Debe tenerse en cuenta que la ubicación confiable de marcadores en el BIOS solo es posible en la fábrica. En condiciones de funcionamiento, esto requerirá centrarse en un modelo de placa base específico, y estas opciones no son muy interesantes para los piratas informáticos. Necesitan una escala masiva, trabajan, como dicen, "por zona". Sin embargo, hay quienes atacan apuntando, "estilo francotirador". La tecnología para colocar marcadores en el BIOS, e incluso con la activación del hardware de virtualización, que le permite ocultarlos de manera efectiva, es, por supuesto, una herramienta conveniente para tales "francotiradores". Una vez casi los atraparon, y casi por accidente. Creo que ahora no será posible hacer esto, y no hay nadie a quien atrapar, como probablemente entendiste. Hace mucho tiempo, cuando las computadoras personales se compraban en el extranjero en lotes de varios cientos de piezas, y no en millones de "circulaciones", bajo los auspicios de uno de los departamentos de la KGB, se organizaron pequeñas oficinas comerciales para "buscar marcadores". Ahora todos entendemos perfectamente que esta era una de las formas honestas de quitar dinero, porque en ese nivel de soporte y organización, podías encontrar lo que quisieras, pero no una pestaña en la composición de chips. Pero los grandes compradores de la cantidad de oficinas y empresas estatales todavía no tenían adónde ir. Ellos pagaron.
publicidad
Hoy, Intel ni siquiera oculta el hecho de que las herramientas para el control remoto de PC están integradas en los procesadores y conjuntos de chips de las plataformas informáticas modernas. La tecnología de administración activa (AMT) de Intel, altamente publicitada, debería ayudar a simplificar el mantenimiento remoto del sistema (diagnóstico y recuperación) sin la intervención del usuario. Pero nadie está asegurado de que también sea posible utilizar los derechos del administrador de AMT con fines maliciosos y, como resultado, no hay solo un marcador, hay una "hipoteca" completa.Según una publicación del experto en seguridad Damien Zammit, los chipsets Intel modernos tienen un chip microcontrolador Intel Management Engine (Intel ME) integrado y local. Esta es una solución con su propio firmware que no está disponible para ser examinada por herramientas de terceros y con control total sobre el procesador, la memoria y el sistema en su conjunto. Además, el controlador puede funcionar con la PC apagada, siempre que se suministre energía a la memoria. Por supuesto, el sistema operativo y las utilidades no dormirán ni sabrán espiritualmente sobre la actividad del controlador y no harán sonar una alarma mientras esté trabajando con el sistema y los datos.
Preocupación de que con un nivel técnico suficiente del enemigo, existe el peligro de realizar una modificación oculta de cualquier chip. El chip modificado funcionará en nodos críticos y el "caballo de Troya" o "dispositivo de hardware" introducido pasará desapercibido, socavando las defensas del país al nivel más fundamental. Durante mucho tiempo, tal amenaza siguió siendo hipotética, pero recientemente un equipo internacional de investigadores pudo implementarla a nivel físico.
Georg T. Becker de la Universidad de Massachusetts, junto con colegas de Suiza y Alemania, como parte de una prueba de concepto, crearon dos versiones de un "troyano a nivel de hardware" que interrumpe el (pseudo) generador de números aleatorios (PRNG) en el bloque criptográfico de los procesadores Intel Ivy. Puente. Las claves criptográficas creadas utilizando el PRNG modificado para cualquier sistema de cifrado serán fácilmente predecibles.
La presencia de una pestaña de hardware no está determinada de ninguna manera por las pruebas integradas especialmente diseñadas para esto, ni por un examen externo del procesador. ¿Cómo pudo pasar esto? Para responder a esta pregunta, es necesario volver a la historia de la aparición del hardware PRNG y familiarizarse con los principios básicos de su funcionamiento.
Al crear sistemas criptográficos, es necesario eliminar la posibilidad de una selección rápida de claves. Su duración y grado de imprevisibilidad afectan directamente la cantidad de opciones que el lado atacante tendría que clasificar. La longitud se puede establecer directamente, pero es mucho más difícil lograr la unicidad de las variantes clave y su probabilidad igual. Para hacer esto, se utilizan números aleatorios durante la generación de claves.
Actualmente, se acepta generalmente que solo los algoritmos de software no pueden obtener un flujo de números verdaderamente aleatorio con su distribución caótica uniforme en todo el conjunto especificado. Siempre tendrán una frecuencia alta en algunas partes del rango y serán algo predecibles. Por lo tanto, la mayoría de los generadores de números utilizados en la práctica deberían percibirse como pseudoaleatorios. Rara vez son lo suficientemente fiables criptográficamente.
Para reducir el efecto de la previsibilidad, cualquier generador de números necesita una fuente confiable de semilla aleatoria. Por lo general, se utilizan los resultados de las mediciones de algunos procesos físicos caóticos. Por ejemplo, fluctuaciones en la intensidad de las vibraciones de la luz o el registro de ruido de radiofrecuencia. Sería técnicamente conveniente utilizar tal elemento de aleatoriedad (y todo el hardware PRNG) en una versión compacta, e idealmente hacerlo integrado.
Intel ha estado construyendo generadores de números (pseudo) aleatorios en sus chips desde finales de los noventa. Anteriormente, su naturaleza era análoga. Los valores aleatorios en la salida se obtuvieron debido a la influencia de procesos físicos difíciles de predecir: ruido térmico e interferencia electromagnética. Los generadores analógicos eran relativamente fáciles de implementar como bloques separados, pero difíciles de integrar en nuevos circuitos. A medida que el proceso se hizo más pequeño, se requirieron nuevos y largos pasos de calibración. Además, la disminución regular de la tensión de alimentación empeoró la relación señal-ruido en tales sistemas. Los PRNG trabajaron constantemente y consumieron una cantidad significativa de energía, y la velocidad de su trabajo dejó mucho que desear. Estas deficiencias imponen restricciones a las posibles aplicaciones.
La idea de un generador de números (pseudo) aleatorios con una naturaleza totalmente digital ha parecido extraña, si no absurda, durante mucho tiempo. Después de todo, el estado de cualquier circuito digital es siempre rígidamente determinista y predecible. ¿Cómo introducir el elemento necesario de aleatoriedad en él si no hay componentes analógicos?
Los ingenieros de Intel han realizado intentos de crear el caos deseado basados \u200b\u200búnicamente en elementos digitales desde 2008 y se han coronado con éxito después de un par de años de investigación. El trabajo fue presentado en 2010 en el Simposio de Verano de VLSI en Honolulu e hizo una pequeña revolución en la criptografía moderna. Por primera vez, se ha implementado un PRNG completamente digital, rápido y energéticamente eficiente en un procesador comercial de uso general.
Su primer título provisional fue Bull Mountain. Luego se le cambió el nombre a Secure Key. Este bloque criptográfico consta de tres módulos básicos. El primero genera un flujo de bits aleatorios a una velocidad relativamente lenta de 3 Gbps. El segundo evalúa su varianza y los combina en bloques de 256 bits, que se utilizan como fuentes de semilla aleatoria. Después de una serie de procedimientos matemáticos, se genera un flujo de 128 bits de números aleatorios a una velocidad mayor en el tercer bloque. Sobre su base, utilizando la nueva instrucción RdRand, si es necesario, se crean números aleatorios de la longitud requerida y se colocan en un registro especialmente designado: 16, 32 o 64 bits, que finalmente se transfieren al programa que los solicitó.
Los errores en los generadores de números (pseudo) aleatorios y sus modificaciones maliciosas provocan una pérdida de confianza en los productos criptográficos populares y en el procedimiento mismo para su certificación.
Debido a la importancia excepcional de los PRNG para cualquier sistema criptográfico, se integraron pruebas en la clave segura para verificar la calidad de los números aleatorios generados, y los principales grupos de expertos participaron para la certificación. Toda la unidad cumple con los criterios de las normas ANSI X9.82 y NIST SP 800-90. Además, cuenta con la certificación NIST FIPS 140-2 Nivel 2.
Hasta ahora, la mayor parte del trabajo sobre troyanos de hardware ha sido hipotético. Los investigadores propusieron diseños adicionales a partir de pequeños circuitos lógicos que debían agregarse de alguna manera a los chips existentes. Por ejemplo, Samuel Talmadge King y sus coautores presentaron en LEET-08 una versión de dicho troyano de hardware para el procesador central que le daría control total sobre el sistema a un atacante remoto. Simplemente enviando un paquete UDP configurado, uno podría realizar cualquier cambio en dicha computadora y obtener acceso ilimitado a su memoria. Sin embargo, los circuitos lógicos adicionales son relativamente fáciles de identificar por microscopía, sin mencionar los métodos especializados para buscar tales modificaciones. El grupo de Becker fue al revés:
En lugar de conectar circuitos adicionales al chip, implementamos nuestras pestañas de nivel de hardware simplemente cambiando el funcionamiento de algunos de los microtransistores que ya están en él. Después de varios intentos, logramos cambiar selectivamente la polaridad del dopante y realizar las modificaciones deseadas en el funcionamiento de toda la unidad criptográfica. Por lo tanto, nuestra familia de troyanos ha demostrado ser resistente a la mayoría de los métodos de detección, incluida la microscopía de barrido y la comparación con chips de referencia ".
Como resultado del trabajo realizado, en lugar de números únicos con una longitud de 128 bits, el tercer bloque de clave segura comenzó a acumular secuencias en las que solo 32 bits eran diferentes. Las claves criptográficas generadas sobre la base de tales números pseudoaleatorios son muy predecibles y se pueden descifrar en unos pocos minutos en una computadora doméstica común.
El cambio selectivo en la conductividad eléctrica subyacente a la pestaña de hardware se implementó en dos versiones:
- posprocesamiento digital de señales de Intel Secure Key;
- utilizar en un canal lateral utilizando el método de caja de sustitución.
El último método es más versátil y se puede aplicar con modificaciones menores a otros chips.
La capacidad de usar PRNG integrado a través de la instrucción RdRand apareció por primera vez en los procesadores de arquitectura Ivy Bridge de Intel. Intel ha escrito guías detalladas para programadores. Describen métodos para la implementación óptima de algoritmos criptográficos y proporcionan un enlace a una descripción de cómo funciona Secure Key. Durante mucho tiempo, los esfuerzos de los expertos en seguridad estuvieron dirigidos a encontrar vulnerabilidades en la parte del software. Quizás, por primera vez, la interferencia oculta a nivel de hardware resultó ser una tecnología mucho más peligrosa y bastante factible.
