{"id":25259,"date":"2022-09-16T12:39:18","date_gmt":"2022-09-16T18:39:18","guid":{"rendered":"https:\/\/latam.kaspersky.com\/blog\/?p=25259"},"modified":"2022-09-16T12:39:18","modified_gmt":"2022-09-16T18:39:18","slug":"defcon30-zoom-vulnerability","status":"publish","type":"post","link":"https:\/\/latam.kaspersky.com\/blog\/defcon30-zoom-vulnerability\/25259\/","title":{"rendered":"Una vulnerabilidad en Zoom y la guerra entre hackers y desarrolladores"},"content":{"rendered":"

En marzo de 2020, cuando el home office <\/em>crec\u00eda al rededor del mundo, una vulnerabilidad<\/a> fue descubierta en el instalador de Zoom (una de las principales herramientas de comunicaci\u00f3n a distancia del mundo) la cual permit\u00eda ejecutar c\u00f3digo arbitrario en computadoras Apple. Zoom resolvi\u00f3 el problema\u2026 o casi.<\/p>\n

La verdad es que en agosto de 2022 un fallo similar (tanto en t\u00e9rminos de localizaci\u00f3n como en las consecuencias de su explotaci\u00f3n) fue encontrado. En este art\u00edculo analizaremos el reciente problema de seguridad y trataremos de explicar por qu\u00e9 los agujeros en el software<\/em>, a veces, aparecen de nuevo en el mismo sitio. Por \u00faltimo, daremos algunos consejos sobre qu\u00e9 hacer al respecto.<\/p>\n

\u00bfDe qu\u00e9 va esta \u00faltima vulnerabilidad?<\/h2>\n

Patrick Wardle, conocido investigador, revel\u00f3<\/a> este nuevo problema en Zoom en la DEF CON 30 de este a\u00f1o, a inicios de agosto. En resumen, se encontraron unos cuantos fallos en el sistema de actualizaci\u00f3n autom\u00e1tica del cliente Zoom en Apple. Estos fallos, en teor\u00eda, permit\u00edan obtener los llamados derechos de superusuario, lo que permite que un atacante pueda hacer lo que quiera en la computadora del anfitri\u00f3n.<\/p>\n

No obstante, para explotar la vulnerabilidad, el atacante necesita tener un acceso f\u00edsico a la computadora, aunque sin derechos especiales. Esta situaci\u00f3n ante la que nos encontramos no es tan descabellada: por ejemplo, un usuario puede ir a comer y olvidar bloquear su computadora. Te\u00f3ricamente, la vulnerabilidad tambi\u00e9n podr\u00eda ser explotada por un malware<\/em>, que de otro modo no causar\u00eda da\u00f1os graves al usuario.<\/p>\n

M\u00e1s detalles, por favor<\/h2>\n

El tiempo de ejecuci\u00f3n, as\u00ed como la f\u00e1cil instalaci\u00f3n de las actualizaciones son importantes requisitos para cualquier software <\/em>moderno. Lo ideal es que las correcciones de errores sean instaladas sin que el usuario se d\u00e9 cuenta, pero esto no siempre es posible. Usualmente, para una actualizaci\u00f3n se complete hay que reiniciar un programa, volver a iniciar sesi\u00f3n o inclusive reiniciar el equipo.<\/p>\n

A todos nos molestan los mensajes emergentes que nos recuerdan que debemos actualizar un programa, un sistema operativo o el firmware<\/em> de un smartphone<\/em> o tablet<\/em>. Pero es important\u00edsimo hacerlo: las actualizaciones parchean agujeros de seguridad que podr\u00edan ser usados en tu contra en caso de no cerrarse. Especialmente en casos graves, es necesario proteger de inmediato el software<\/em> vulnerable ante ciberataques activos: un d\u00eda de retraso puede costarte tus datos.<\/p>\n

La forma est\u00e1ndar de actualizar una aplicaci\u00f3n de macOS es igual que su primera instalaci\u00f3n: descargas la nueva versi\u00f3n, ejecutas el archivo y escribes una contrase\u00f1a de usuario. Zoom trat\u00f3 de simplificar dicho procedimiento: el cliente accede al servidor, descarga versi\u00f3n actualizada y esta se instala sola sin necesidad de que el usuario introduzca una contrase\u00f1a. Por desgracia, este proceso de comunicaci\u00f3n con el servidor, y de descarga e instalaci\u00f3n de la actualizaci\u00f3n, no se lleva a cabo de manera correcta en todos los casos.<\/p>\n

Hace diez a\u00f1os, el acceso a los servidores sin cifrado de datos era una pr\u00e1ctica usual, y hac\u00eda posible que un atacante sustituyera el archivo de actualizaci\u00f3n por un malware<\/em> de forma bastante simple. Al implementarse el cifrado, esto se complic\u00f3, pero todav\u00eda es posible sustituir el archivo despu\u00e9s de la descarga cuando ya est\u00e1 guardado en el disco, pero no ha sido instalado todav\u00eda.<\/p>\n

En la versi\u00f3n m\u00e1s reciente de Zoom, de finales del a\u00f1o pasado cuando Patrick comenz\u00f3 su investigaci\u00f3n, todo parec\u00eda estar en orden. El cliente accede a un servidor especial de actualizaciones mediante un canal seguro, descarga el archivo, verifica la autenticidad (comprueba que est\u00e1 firmado por el certificado del proveedor) y lo instala. Para la instalaci\u00f3n, el SW solicita al sistema derechos temporales de superusuario, de esta manera el usuario no necesita introducir una contrase\u00f1a.<\/p>\n

Extracto de la presentaci\u00f3n de Patrick Wardle que muestra la ventaja de las actualizaciones de las firmas. <a href=\"https:\/\/speakerdeck.com\/patrickwardle\/youre-muted-rooted\" target=\"_blank\">Fuente<\/a>.

Extracto de la presentaci\u00f3n de Patrick Wardle que muestra la ventaja de las actualizaciones de las firmas. Fuente<\/a>.<\/p><\/div>\n

La firma digital es importante. A final de cuentas, el programa es descargado en la computadora del usuario desde alg\u00fan rinc\u00f3n de Internet y se ejecuta con m\u00e1ximos privilegios. Por tanto, hay que estar seguros de que lo que se descarg\u00f3 es el programa correcto. Una versi\u00f3n falsa del archivo descargado no funcionar\u00e1: como se muestra arriba en la diapositiva de la presentaci\u00f3n de Patrick, la sustituci\u00f3n del archivo da lugar a un mensaje de error. En resumen, la actualizaci\u00f3n falsa no tiene firma digital (y es casi imposible poder falsificar una).<\/p>\n

Lamentablemente, el proceso de validaci\u00f3n de la firma digital en Zoom ten\u00eda errores. Funcionaba al ejecutar una utilidad del sistema. Esta mostraba los par\u00e1metros de la firma digital de la actualizaci\u00f3n descargada, incluyendo una l\u00ednea que indicaba qu\u00e9 empresa hab\u00eda recibido el certificado:<\/p>\n

Zoom Video Communications, Inc. Developer ID Certification Authority Apple Root CA<\/em><\/p>\n

Se procesaba la salida de la utilidad y, si esta l\u00ednea estaba presente, la instalaci\u00f3n comenzaba. El problema era que el nombre del archivo tambi\u00e9n aparec\u00eda en la salida. Entonces, te\u00f3ricamente un atacante podr\u00eda crear una actualizaci\u00f3n maliciosa con el nombre \u201cZoom Video Communications, Inc. <\/em>Developer ID Certification Authority Apple Root CA.pkg<\/em>\u201d en lugar del est\u00e1ndar \u201cZoomUpdate.pkg\u201d.<\/em> Y con esto bastar\u00eda para enga\u00f1ar al procedimiento de validaci\u00f3n: la l\u00ednea requerida est\u00e1 ah\u00ed, por tanto, el archivo debe ser leg\u00edtimo \u2013 \u00a1aunque sea el archivo equivocado y las palabras m\u00e1gicas est\u00e9n en el lugar equivocado!<\/p>\n

Un ataque podr\u00eda ser as\u00ed: se inicia el procedimiento de validaci\u00f3n de la actualizaci\u00f3n (no es dif\u00edcil de hacer), luego se descarga la actualizaci\u00f3n leg\u00edtima, se sustituye por malware<\/em> y se le cambia el nombre para burlar el proceso de validaci\u00f3n del certificado roto. El archivo malicioso se ejecuta con privilegios del sistema y\u2026 \u00a1la computadora est\u00e1 hackeada!<\/p>\n

Pero el 20 de diciembre de 2021 una actualizaci\u00f3n de Zoom que puso fin a esta v\u00eda de ataque fue publicada. Era un cambio simple: se forzaba un cambio de nombre del archivo tras la descarga. Patrick Wardle pudo modificar el ataque: si Zoom es seguro desde la versi\u00f3n 5.9.0, \u00bfqu\u00e9 pasa si \u201cactualizamos\u201d el cliente a una versi\u00f3n anterior? Y funcion\u00f3: la antigua actualizaci\u00f3n ten\u00eda un certificado digital leg\u00edtimo y la versi\u00f3n no se comprobaba durante la instalaci\u00f3n.<\/p>\n

\u00bfY cu\u00e1l es el problema?<\/h2>\n

La investigaci\u00f3n de Patrick Wardle demuestra que instalar actualizaciones es de suma importancia. Es m\u00e1s, la historia de esta falla demuestra de manera clara c\u00f3mo, algunas veces, los desarrolladores de software <\/em>tratan de resolver un problema con un cambio simple sin terminar de entenderlo. Al principio (incluso antes de que Wardle informara del problema a Zoom), en diciembre de 2021, derrotaron la versi\u00f3n m\u00e1s sencilla de un ataque que utilizaba la sustituci\u00f3n de archivos y elud\u00eda la validaci\u00f3n de certificados.<\/p>\n

Despu\u00e9s de que se informara sobre esta vulnerabilidad, en abril de 2022, cerraron la opci\u00f3n de \u201cdowngrade<\/em>\u201c, es decir, la instalaci\u00f3n de una versi\u00f3n m\u00e1s antigua y vulnerable de Zoom mediante el mecanismo est\u00e1ndar de actualizaciones. Pero fue hasta seis meses despu\u00e9s del informe de Wardle, cuando se el mecanismo de validaci\u00f3n de certificados digitales fue reparado.<\/p>\n

No obstante, esto no termin\u00f3 de resolver el problema. S\u00ed, los dos m\u00e9todos de ataque m\u00e1s sencillos fueron eliminados de los posibles recursos de los hacker<\/em>s: la sustituci\u00f3n del archivo de actualizaci\u00f3n por malware<\/em> y el cambio a una versi\u00f3n vulnerable. Pero todav\u00eda exist\u00eda otro problema: un archivo de actualizaci\u00f3n ejecutado con privilegios de superusuario pod\u00eda modificarse por cualquiera con acceso a la computadora. El atacante solo deb\u00eda encontrar la manera de introducir un archivo malicioso en el instalador de Zoom en el momento correcto: Justo tras validar la firma digital, pero antes de la instalaci\u00f3n comenzara. Y funcion\u00f3.<\/p>\n

Por lo tanto, cuando Patrick Wardle present\u00f3 sus descubrimientos en la DEF CON 30 de agosto de 2022 \u2013 ocho meses despu\u00e9s de informar del problema a Zoom \u2013 \u00a1la vulnerabilidad no hab\u00eda sido parcheada por completo! Cinco d\u00edas despu\u00e9s del informe de Patrick, los desarrolladores finalmente parchearon el problema. Sin embargo, esta afirmaci\u00f3n debe ser verificada de manera independiente.<\/p>\n

Sobre los hackers y los desarrolladores<\/h2>\n

Al leer el informe de Patrick Wardle, uno no puede evitar preguntarse por qu\u00e9 tiene que ser as\u00ed. \u00bfC\u00f3mo surgen vulnerabilidades tan simples en partes cr\u00edticas del software<\/em>, y por qu\u00e9, incluso despu\u00e9s de que se informe de un problema, este se soluciona hasta ocho meses despu\u00e9s y al tercer intento? Hay que dejar en claro que no buscamos tachar de incompetentes a los desarrolladores, ya que en todos los programas existen fallos y errores de vez en vez. Y, si todos los programadores cometen errores, culparlos no resolver\u00e1 el problema, ya que son los \u00fanicos desarrolladores que hay en el mundo.<\/p>\n

Tal vez la raz\u00f3n se deba a que los hackers <\/em>de sombrero blanco (que informan a los proveedores de sus hallazgos) y los ciberdelincuentes (que aprovechan los agujeros para atacar a los usuarios y obtener beneficios) tienen distintas prioridades a las de los desarrolladores de software<\/em>. Cuando desarrollas un programa, lo m\u00e1s importante es que realice cientos de tareas diferentes de manera correcta. Tu prioridad es proporcionar confort a los usuarios, lo que se traduce, en el caso de Zoom, a ofrecer una buena calidad de comunicaci\u00f3n y compatibilidad con distintos sistemas operativos y miles de dispositivos, tanto nuevos como antiguos.<\/p>\n

No obstante, lo \u00fanico que el hacker <\/em>necesita es encontrar un fallo que pueda utilizar para sus sucios trucos. Ahora imagina que alguien te informa de una vulnerabilidad. S\u00ed, debes parchearla, pero sin acabar con el delicado sistema de software<\/em> cliente-servidor. Tienes que probarlo en cientos de configuraciones diferentes. Naturalmente, el desarrollador quiere resolver el problema con m\u00ednimas modificaciones que, usualmente, no son suficientes.<\/p>\n

Con el paso del tiempo y con cada peque\u00f1o parche, los programas se vuelven cada vez m\u00e1s seguros. No se pueden resolver todos los problemas de tajo o crear una aplicaci\u00f3n ideal sin m\u00e1s. O, mejor dicho, s\u00ed se puede, pero solo si se parte de cero. Pero algunos elementos cr\u00edticos deben tener el mejor mantenimiento posible, y el sistema de entrega de actualizaciones es uno de ellos.<\/p>\n

Los usuarios necesitamos poder confiar en los programas que instalamos en nuestras computadoras y, en este sentido, la historia de las vulnerabilidades de Zoom es un ejemplo positivo de un investigador independiente y un desarrollador trabajando de la mano para resolver un problema. Esto demuestra de forma clara la actitud responsable del desarrollador.<\/p>\n

Terminamos este art\u00edculo con un recordatorio importante: el malware<\/em> suele entrar en una computadora durante la primera instalaci\u00f3n del software<\/em>. Por lo tanto, es importante comprobar que las utilidades sean descargadas de fuentes oficiales, mediante tiendas de aplicaciones siempre que sea posible, y en ning\u00fan caso descargar programas de sitios web sospechosos. De lo contrario, existe la posibilidad de que tus datos sean robados a trav\u00e9s de simples m\u00e9todos de hackeo, sin que sea necesario explotar sofisticadas vulnerabilidades en el software <\/em>oficial.<\/p>\n

\"M\u00e1s<\/a><\/p>\n

\u00a0<\/p>\n","protected":false},"excerpt":{"rendered":"

Conclusiones de la DEF CON 30: una vulnerabilidad en Zoom para macOS.<\/p>\n","protected":false},"author":665,"featured_media":25260,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[2795,3539,3540],"tags":[26,1349,816,5264,647],"class_list":{"0":"post-25259","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-enterprise","9":"category-smb","10":"tag-apple","11":"tag-def-con","12":"tag-macos","13":"tag-videoconferencias","14":"tag-vulnerabilidades"},"hreflang":[{"hreflang":"es-mx","url":"https:\/\/latam.kaspersky.com\/blog\/defcon30-zoom-vulnerability\/25259\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/defcon30-zoom-vulnerability\/24561\/"},{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/defcon30-zoom-vulnerability\/20027\/"},{"hreflang":"en-us","url":"https:\/\/usa.kaspersky.com\/blog\/defcon30-zoom-vulnerability\/27010\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/defcon30-zoom-vulnerability\/24918\/"},{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/defcon30-zoom-vulnerability\/27616\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/defcon30-zoom-vulnerability\/33925\/"},{"hreflang":"tr","url":"https:\/\/www.kaspersky.com.tr\/blog\/defcon30-zoom-vulnerability\/11012\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/defcon30-zoom-vulnerability\/45420\/"},{"hreflang":"fr","url":"https:\/\/www.kaspersky.fr\/blog\/defcon30-zoom-vulnerability\/19410\/"},{"hreflang":"pt-br","url":"https:\/\/www.kaspersky.com.br\/blog\/defcon30-zoom-vulnerability\/20011\/"},{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/defcon30-zoom-vulnerability\/29272\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/defcon30-zoom-vulnerability\/25412\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/defcon30-zoom-vulnerability\/30967\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/defcon30-zoom-vulnerability\/30663\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/latam.kaspersky.com\/blog\/tag\/vulnerabilidades\/","name":"vulnerabilidades"},"_links":{"self":[{"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/25259","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/users\/665"}],"replies":[{"embeddable":true,"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/comments?post=25259"}],"version-history":[{"count":3,"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/25259\/revisions"}],"predecessor-version":[{"id":25263,"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/25259\/revisions\/25263"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/media\/25260"}],"wp:attachment":[{"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/media?parent=25259"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/categories?post=25259"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/tags?post=25259"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}