{"id":2641,"date":"2023-10-30T08:33:22","date_gmt":"2023-10-30T14:33:22","guid":{"rendered":"https:\/\/blogs.uo.edu.cu\/seginf\/?p=2641"},"modified":"2023-10-30T09:08:00","modified_gmt":"2023-10-30T15:08:00","slug":"troyano-o-virus-troyano-que-es-y-como-detectarlo","status":"publish","type":"post","link":"https:\/\/blogs.uo.edu.cu\/seginf\/?p=2641","title":{"rendered":"Troyano o virus troyano: qu\u00e9 es y c\u00f3mo detectarlo."},"content":{"rendered":"
\"Troyano\"

Troyano de hardware<\/p><\/div>\n

Hace unos d\u00edas se trabaja en la tipolog\u00eda de los c\u00f3digos malignos. Es cierto que existe bastante informaci\u00f3n en las redes y que los criterios var\u00edan de un autor a otro, pero esta no es la esencia de la entrada de hoy.<\/p>\n

En las b\u00fasquedas realizadas apareci\u00f3 un art\u00edculo curioso que se ha considerado provechoso compartir por su novedad.<\/p>\n

La pregunta a responder ser\u00eda: \u00bfSon los troyanos como c\u00f3digos malignos exclusivos el software?<\/strong>.<\/p>\n

Una respuesta a la interrogante que podr\u00e1 ser el punto de partida de una b\u00fasqueda para constatar la fortaleza del criterio puede ser la lectura del art\u00edculo que se reproduce en esta entrada.<\/p>\n

<\/p>\n

A partir de aqu\u00ed se reproduce el art\u00edculo publicado el 3 de julio de 2022 en el sitio Profesional Review<\/a>.<\/p>\n

Un hardware trojan, o troyano de hardware, tambi\u00e9n resulta un potencial problema para los sistemas inform\u00e1ticos, y no demasiadas personas le dan la importancia que merece. No solo existen los troyanos de software como podr\u00e1s comprobar, y los estragos que pueden causar los de hardware pueden ser incluso peores\u2026<\/p>\n

\u00bfQu\u00e9 es un troyano?<\/strong><\/p>\n

Un caballo de Troya o simplemente troyano es un tipo de malware que puede aparentar ser un programa leg\u00edtimo y \u00fatil, pero que escode un c\u00f3digo malicioso. Este tipo de malware que puede tener diferentes objetivos cuando infecta un equipo, como por ejemplo:<\/p>\n

\n – Usar los recursos de la m\u00e1quina infectada para una botnet (por ejemplo, para realizar ataques de denegaci\u00f3n de servicio o env\u00edo de spam).
\n – Instalaci\u00f3n de otros programas (incluyendo aplicaciones maliciosas).
\n – Robo de informaci\u00f3n personal. Por ejemplo, robo de informaci\u00f3n bancaria, contrase\u00f1as, c\u00f3digos de seguridad, robo de archivos varios, etc\u00e9tera.
\n – Borrado, modificaci\u00f3n o transferencia de archivos de forma remota.
\n – Borrado completo o cifrado de los medios de almacenamiento.
\n – Control de procesos.
\n – Apagado o reiniciado del equipo de forma constante o cuando ocurre alg\u00fan evento espec\u00edfico.
\n – Captura de las pulsaciones del teclado (keylogger).
\n – Capturas de pantalla para poder robar cierta informaci\u00f3n como credenciales, etc.
\n – Monitorizaci\u00f3n del sistema y seguimiento de las acciones del usuario.
\n – Captura de im\u00e1genes, v\u00eddeos y sonidos a trav\u00e9s de la c\u00e1mara del dispositivo y su micr\u00f3fono.
\n – Acceso a la agenda y registros.
\n – Modificaci\u00f3n de datos del usuario.
\n – Otros\n<\/p>\n

Hardware trojan o troyano de hardware<\/strong><\/p>\n

Un hardware Trojan o HTH es, a diferencia de un troyano de software, una modificaci\u00f3n malintencionada de un circuito electr\u00f3nico con fines diferentes para los que fue dise\u00f1ado. Por ejemplo, para espionaje, destruir el sistema, permitir backdoors o puertas traseras para el f\u00e1cil acceso de forma remota, etc. Para que esto sea posible, se deben componer de diferentes partes:<\/p>\n

– Representaci\u00f3n f\u00edsica: son las alteraciones del hardware como tal, que pueden ser a su vez de dos tipos:<\/p>\n

* Modificaci\u00f3n funcional: se pueden alterar algunos transistores o puertas l\u00f3gicas del circuito original para implementar un circuito que puede hacer algo ligeramente diferente al original. Adem\u00e1s, una vez encapsulado y vendido, es muy complicado o, incluso, imposible detectar este tipo de hardware trojan. En cuanto a la distribuci\u00f3n de los troyanos de este tipo, tenemos que puede ser de distribuci\u00f3n suelta o de distribuci\u00f3n ajustada:<\/p>\n

\n – Loose distribution: cuando los componentes del troyano est\u00e1n dispersos en varios chips de la m\u00e1quina. Esto es positivo cuando los troyanos de hardware son demasiado complejo como para integrarse en un mismo circuito, ya que eso supondr\u00eda un gran cambio de la superficie y se podr\u00eda detectar m\u00e1s f\u00e1cilmente.
\n – Tight distribution: se concentra en un \u00fanico circuito integrado, puesto que el \u00e1rea necesaria para su implementaci\u00f3n no es demasiado grande.\n<\/p>\n

* Modificaci\u00f3n param\u00e9trica: se modifica el circuito original sin alterar la l\u00f3gica, por ejemplo, haciendo unas malas interconexiones, debilitando los transistores, produciendo algunos problemas intencionadamente. El objetivo es que el dispositivo no sea tan fiable y pueda fallar.<\/p>\n

* Sistema de activaci\u00f3n: los c\u00f3digos hardware Trojan necesitan de un sistema que active sus funciones ocultas en muchos casos. Puede ser mediante el uso de sensores, para programar un evento, o tambi\u00e9n cuando ocurre cualquier otro evento.<\/p>\n

* Accionador: no se refiere a accionar el troyano en s\u00ed, que de eso se encarga la parte anterior como hemos comentado. En este caso es el accionador del c\u00f3digo malicioso, si lo hay, cuando se realiza lo que se pretend\u00eda de este troyano, desde robo de informaci\u00f3n sensible, acceso a informaci\u00f3n de forma remota, escalada de privilegios, control del sistema, etc.<\/p>\n

* Auxiliares: por supuesto, tambi\u00e9n podr\u00eda haber otras partes auxiliares para dar soporte al hardware trojan y, dependiendo del tipo de troyano, pueden ser muy diversos, y m\u00e1s o menos numerosos. Pero siempre suelen ser menos importantes que los anteriores puntos.<\/p>\n

Los troyanos de hardware pueden permanecer latentes durante mucho tiempo, sin consecuencias para el sistema con este tipo de manipulaci\u00f3n, pero una vez activos pueden ser bastante agresivos, con riesgos realmente graves. Y lo peor es que las herramientas de an\u00e1lisis de hardware convencionales que se usan para el software no sirven para detectar este tipo de troyanos.<\/p>\n

\u00bfExisten formas de detectarlo?<\/strong><\/p>\n

Por \u00faltimo, para concluir este art\u00edculo, tambi\u00e9n es importante decir que estos troyanos de hardware son mucho m\u00e1s complicados de detectar que los de software, y en muchas ocasiones pasan totalmente desapercibidos incluso para los ojos expertos.<\/p>\n

* Inspecci\u00f3n f\u00edsica: se inspeccionan cosas desde las m\u00e1s transcendentales, como el n\u00famero de pines, mediciones del \u00e1rea, hasta otras m\u00e1s profundas des-encapsulando el chip y empleando t\u00e9cnicas de termograf\u00eda, an\u00e1lisis de consumo, microscop\u00eda \u00f3ptica (MO), barrido SEM (Scanning Electron Microscopy), an\u00e1lisis PICA (Picosecond Imaging Circuit Analysis), inspecci\u00f3n de im\u00e1genes VCI (Voltage Contrast Imaging), t\u00e9cnicas LIVA (Light-induced Voltage Alteration), FANCI (Functional Analysis for Nearly-unused Circuit Identification), y CIVA (Charge-Induced Voltage Alteration). Por ejemplo, las t\u00e9cnicas FANCI, que parec\u00edan muy prometedoras, mediante un an\u00e1lisis booleano est\u00e1tico para etiquetar las conexiones que pueden ser potencialmente maliciosas, ha resultado tambi\u00e9n poco efectivo, ya que se puede hacer que el dise\u00f1o del troyano de hardware parezca m\u00e1s benigno ante este tipo de t\u00e9cnicas.<\/p>\n

* Test funcional: pueden usar aparatos de laboratorios electr\u00f3nicos como sondas l\u00f3gicas para generar una serie de estados en las entradas de un circuito y se monitorizan los estados de la salida, para detectar posibles alteraciones en los patrones.<\/p>\n

* BIST (Built-in self-test) y DFT (Design For Testing): en los circuitos integrados a nivel del chip se suele emplear una circuiter\u00eda adicional para verificar la funcionalidad de un circuito o si tiene defectos. Pero estos pueden haber sido alterados para camuflar estos cambios. Los chips originales generan una firma determinada, pero si est\u00e1 alterado generar\u00eda una firma desconocida con estos tests. Pero es como cuando compruebas una suma de verificaci\u00f3n de un software\u2026 \u00bfy si la han alterado tambi\u00e9n?<\/p>\n

* An\u00e1lisis del canal lateral: los CI activos emiten se\u00f1ales como campos magn\u00e9ticos y el\u00e9ctricos concretos (como una especie de firma tambi\u00e9n, v\u00e9ase el ejemplo de los side-channel attacks). Esas se\u00f1ales son causadas por la actividad el\u00e9ctrica del chip, por lo que pueden ser estudiados para obtener informaci\u00f3n, al igual que se puede emplear una termograf\u00eda.<\/p>\n

Como puedes comprobar, son complicados de detectar, o imposibles en algunos casos, y las herramientas necesarias no est\u00e1n al alcance de los usuarios.<\/p>\n

\u00bfUn usuario podr\u00eda detectarlo?<\/strong><\/p>\n

La respuesta es un no rotundo. A veces los cambios son nanom\u00e9tricos, y un usuario no podr\u00eda detectar estos problemas aunque quisiera porque no tiene los medios para hacerlo. Incluso si lo pudiera detectar, imaginando que tenga un microsc\u00f3pio electr\u00f3nico y otro tipo de aparataje realmente caro, las pruebas implicar\u00edan desempaquetar y decapar el chip en muchos casos, lo que lo dejar\u00eda destruido. Es decir, son pruebas destructivas.<\/p>\n

Al ser as\u00ed, el chip quedar\u00eda totalmente inservible, y se tendr\u00eda que usar otro chip o circuito integrado diferente para la aplicaci\u00f3n pr\u00e1ctica para la que se requiera. Sin embargo, no se tiene la certeza de que esa otra placa o circuito integrado est\u00e9 libre de este tipo de troyanos. Es decir, se entra en un infierno de incertidumbre que no se puede disipar por ning\u00fan m\u00e9todo.<\/p>\n

En definitiva, los usuarios dom\u00e9sticos solo podemos hacer una cosa: confiar en que el hardware que se nos vende es confiable. Eso quiere decir que tenemos que considerar que todos los implicados en la cadena de dise\u00f1o y producci\u00f3n son de confianza.<\/p>\n

El problema del control<\/strong><\/p>\n

El problema es una cadena muy larga de producci\u00f3n hasta que llega a las tiendas, y el hecho de que muchas empresas son simplemente dise\u00f1adores, y de la fabricaci\u00f3n y otras etapas se encargan terceros en los que se debe confiar. Y lo peor de todo es que se pueden implementar los hardware Trojan en varias partes del procedimiento:<\/p>\n

Desde que se dise\u00f1a un chip hasta que sale a la venta pueden pasar a\u00f1os. Esto es lo \u00fanico que va en contra de la implementaci\u00f3n de un troyano de hardware. No obstante, existen otros chips que son mucho menos complejos que las CPUs, GPUs, etc., y que pueden acortar mucho sus tiempos para hacer pr\u00e1ctico lanzar el ataque.<\/strong><\/p>\n

I. Primeras etapas de dise\u00f1o del ASIC o PCB:<\/strong> <\/p>\n

1. Durante la descripci\u00f3n de las especificaciones que tendr\u00e1 el dispositivo a producir, es posible que el dise\u00f1ador del mismo, el IDM o el fabless, pueda implementar algunas funciones indocumentadas con fines que solo ellos saben para qu\u00e9, y no el resto de usuarios. Tambi\u00e9n podr\u00eda generar inconsistencias intencionadas en su funcionamiento l\u00f3gico para que pueda fallar.<\/p>\n

2. Durante la emulaci\u00f3n y RTL del dise\u00f1o tambi\u00e9n se puede agregar c\u00f3digo malicioso en los archivos de lenguajes HDL tipo VHDL, Verilog, Chisel, etc. Y no solo por parte del desarrollador principal, tambi\u00e9n podr\u00edan estar implementadas en algunas bibliotecas empleadas durante el desarrollo.<\/p>\n

3. Las etapas de despu\u00e9s de la programaci\u00f3n HDL, como la s\u00edntesis y netlist, etc., tambi\u00e9n puede ser vulnerable a este tipo de amenazas, ya que cualquier personal implicado en el desarrollo podr\u00eda implementar cambios en el dise\u00f1o original. Igual ocurre con las celdas b\u00e1sicas que se pueden usar desde el EDA, que podr\u00edan estar manipuladas, por ejemplo, para crear un layout poco fiable.<\/p>\n

II. Manufactura del ASIC o del PCB:<\/strong><\/p>\n

1. Si seguimos hacia delante en el proceso, despu\u00e9s se generar\u00eda el layout y el archivo tipo GDSII para enviarlo a la f\u00e1brica. Y los que dise\u00f1an las m\u00e1scaras para la litograf\u00eda tambi\u00e9n podr\u00edan crear vulnerabilidades en el circuito si los anteriores no lo hicieron, tan solo tienen que modificar alguna de las m\u00e1scaras empleadas en el dise\u00f1o.<\/p>\n

2. Una vez el chip o placa de circuito impreso ha sido fabricada, ya no habr\u00eda forma de manipularla en el primer caso. En cuanto a los circuitos impresos s\u00ed que se podr\u00eda modificar si se retira alg\u00fan chip de los montados superficialmente y se suelda otro manipulado que aparentemente hace la misma funci\u00f3n. Es decir, que incluso hasta despu\u00e9s de la cadena de producci\u00f3n se puede alterar un circuito. De ah\u00ed el potencial de peligrosidad de estos troyanos.<\/p>\n

Ahora comenzar\u00e1s a ver el hardware como otra nueva fuente de amenazas, como un vector de ataque m\u00e1s y ver\u00e1s lo desatendido que est\u00e1. Las auditor\u00edas se centran en el 99% de los casos en el software, y dejan de lado el hardware. Hemos visto c\u00f3mo vulnerabilidades como Meltdown y Spectre han estado ah\u00ed durante d\u00e9cadas sin que nadie pusiera remedio a ellas. Y no son las \u00fanicas. \u00bfCrees que el hardware est\u00e1 demasiado descuidado en cuestiones de ciberseguridad?<\/p>\n

Nota: Se omitieron im\u00e1genes que est\u00e1n en archivo original. Algunas por compatibilidad del formato con la plataforma.<\/strong><\/p>\n

Im\u00e1genes Relacionadas:<\/h3>","protected":false},"excerpt":{"rendered":"

Hace unos d\u00edas se trabaja en la tipolog\u00eda de los c\u00f3digos malignos. Es cierto que existe bastante informaci\u00f3n en las redes y que los criterios var\u00edan de un autor a otro, pero esta no es la esencia de la entrada … Sigue leyendo →<\/span><\/a><\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"ngg_post_thumbnail":0,"footnotes":""},"categories":[2,6,52,57,15],"tags":[],"class_list":["post-2641","post","type-post","status-publish","format-standard","hentry","category-amenazas","category-codigos-malignos","category-denegacion-de-servicios","category-educacion-de-usuarios","category-informaciones"],"_links":{"self":[{"href":"https:\/\/blogs.uo.edu.cu\/seginf\/index.php?rest_route=\/wp\/v2\/posts\/2641","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs.uo.edu.cu\/seginf\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.uo.edu.cu\/seginf\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.uo.edu.cu\/seginf\/index.php?rest_route=\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.uo.edu.cu\/seginf\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=2641"}],"version-history":[{"count":4,"href":"https:\/\/blogs.uo.edu.cu\/seginf\/index.php?rest_route=\/wp\/v2\/posts\/2641\/revisions"}],"predecessor-version":[{"id":2649,"href":"https:\/\/blogs.uo.edu.cu\/seginf\/index.php?rest_route=\/wp\/v2\/posts\/2641\/revisions\/2649"}],"wp:attachment":[{"href":"https:\/\/blogs.uo.edu.cu\/seginf\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=2641"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.uo.edu.cu\/seginf\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=2641"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.uo.edu.cu\/seginf\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=2641"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}