{"id":28287,"date":"2023-01-19T12:52:26","date_gmt":"2023-01-19T10:52:26","guid":{"rendered":"https:\/\/www.kaspersky.es\/blog\/?p=28287"},"modified":"2023-01-19T12:52:26","modified_gmt":"2023-01-19T10:52:26","slug":"7-threema-vulnerabilities","status":"publish","type":"post","link":"https:\/\/www.kaspersky.es\/blog\/7-threema-vulnerabilities\/28287\/","title":{"rendered":"Las vulnerabilidades de Threema. \u00bfQu\u00e9 aplicaci\u00f3n de mensajer\u00eda est\u00e1 mejor protegida?"},"content":{"rendered":"<p>Esta semana, Threema, una de las aplicaciones de mensajer\u00eda segura m\u00e1s populares, se ha visto envuelta en un esc\u00e1ndalo: los investigadores de ETH Zurich, una universidad p\u00fablica de investigaci\u00f3n en Suiza, han encontrado siete (s\u00ed, \u00a17!) vulnerabilidades en sus protocolos.<\/p>\n<p>Como respuesta, los desarrolladores de la aplicaci\u00f3n han restado importancia a estos errores y han publicado en un blog que ya hab\u00edan resuelto todos estos problemas en unas pocas semanas y que ninguno de ellos hab\u00eda tenido un impacto considerable en el mundo real. Entonces, \u00bfqu\u00e9 est\u00e1 pasando realmente? \u00bfDeber\u00edas cambiarte a Signal de inmediato?<\/p>\n<p>Es dif\u00edcil llegar al fondo de la cuesti\u00f3n, dado que el comportamiento de ambas partes, aunque civilizado, no es el ideal. El equipo de ETH Zurich claramente ha exagerado la importancia de su trabajo, que describe no solo vulnerabilidades sino tambi\u00e9n situaciones hipot\u00e9ticas de explotaci\u00f3n, mientras que los desarrolladores de Threema claramente subestiman la gravedad de las vulnerabilidades, alegando que son casi imposibles de explotar.<\/p>\n<p>Si est\u00e1s interesado exclusivamente en las conclusiones pr\u00e1cticas, te sugerimos que <a href=\"#takeways\" target=\"_blank\" rel=\"noopener\">vayas<\/a><a href=\"#takeways\" target=\"_blank\" rel=\"noopener\"> directamente a ellas (al final de esta publicaci\u00f3n).<\/a><\/p>\n<h2>Las vulnerabilidades de Threema<\/h2>\n<p>Todas las vulnerabilidades se reportaron en octubre y se arreglaron r\u00e1pidamente. Ambos coinciden en que estas vulnerabilidades no se han explotado en activo, por lo que no habr\u00eda motivos para temer la divulgaci\u00f3n de informaci\u00f3n al respecto. Dicho esto, s\u00ed que hay algo por lo que preocuparse.<\/p>\n<p>Centr\u00e9monos en las conclusiones que se pueden sacar tras una lectura detenida del informe de ETH Zurich, las declaraciones de Threema y otros estudios disponibles sobre la aplicaci\u00f3n Threema y sus protocolos.<\/p>\n<p>La aplicaci\u00f3n utiliza algoritmos cifrados con una implementaci\u00f3n de NaCl estandarizada y robusta. Sin embargo, todo esto entra dentro del protocolo de intercambio de informaci\u00f3n de Threema, que no est\u00e1 perfectamente implementado. Esto abre la posibilidad de varios ataques te\u00f3ricos, como enviar un mensaje en un grupo que cada destinatario ve de manera diferente, pero tambi\u00e9n pr\u00e1cticos. Por ejemplo, cualquier persona con acceso f\u00edsico al smartphone objetivo podr\u00eda leer f\u00e1cilmente las bases de datos y las copias de seguridad de Threema, si la aplicaci\u00f3n no est\u00e1 protegida con una frase de contrase\u00f1a. Tambi\u00e9n se puede clonar un ID de Threema, lo que permite al ciberdelincuente enviar mensajes haci\u00e9ndose pasar por la v\u00edctima (pero no al mismo tiempo). Obviamente, todas las situaciones que dependen del acceso f\u00edsico al smartphone suelen ser las peores para cualquier aplicaci\u00f3n, adem\u00e1s, resulta extremadamente dif\u00edcil protegerse contra ellas.<\/p>\n<p>Algunos de los posibles ataques que facilitan estas nuevas vulnerabilidades funcionar\u00edan \u00fanicamente si el atacante tuviera el control total sobre la red de intercambio de datos. Pero eso en s\u00ed mismo no es suficiente, tambi\u00e9n se necesitan otras condiciones de explotaci\u00f3n m\u00e1s complejas. Por ejemplo, uno de estos escenarios requiere que la v\u00edctima se vea obligada a enviar un mensaje con un contenido muy extra\u00f1o a trav\u00e9s de Threema, lo cual es muy complicado que funcione en la pr\u00e1ctica.<\/p>\n<p>De entre los errores en el protocolo de comunicaci\u00f3n, el m\u00e1s preocupante es la falta de <a href=\"https:\/\/www.kaspersky.es\/blog\/33c3-private-messenger-basics\/9841\/\" target=\"_blank\" rel=\"noopener\"><em>forward secrecy y future secrecy<\/em><\/a>. Es decir, que una vez que has conseguido descifrar un mensaje, puedes descifrar los posteriores. Esta debilidad se <a href=\"https:\/\/soatok.blog\/2021\/11\/05\/threema-three-strikes-youre-out\/\" target=\"_blank\" rel=\"noopener nofollow\">conoce<\/a> desde hace tiempo y es el motivo por el cual, aparentemente, Threema anunci\u00f3 en diciembre una versi\u00f3n totalmente renovada y m\u00e1s segura de su protocolo: Ibex, que todav\u00eda tiene que someterse a auditor\u00edas de seguridad independientes.<\/p>\n<p>Por el momento, solo nos queda confiar en los desarrolladores cuando afirman que cubre todas las facetas de la criptograf\u00eda pr\u00e1ctica actual. Ser\u00eda muy inteligente por parte de Threema acatar el consejo de ETH Zurich de externalizar la auditor\u00eda de los protocolos en las etapas tempranas de su desarrollo, no despu\u00e9s de su lanzamiento.<\/p>\n<p>Para explotar algunas de las vulnerabilidades, primero hay que comprometer el servidor de Threema, adem\u00e1s, alguien en el lado del operador deber\u00eda estar intentando de forma deliberada el robo de datos intercambiados o la interrupci\u00f3n de la comunicaci\u00f3n. Por tanto, si una empresa que utiliza Threema Work no puede poner sus datos en riesgo, deber\u00eda considerar el cambio a Threema OnPrem, donde contar\u00e1 con su propio servidor Threema interno. En este caso, los administradores tendr\u00e1n que investigar nuevas formas de reforzar la seguridad del servidor, lo que se conoce como endurecimiento (<em>hardening<\/em> en ingl\u00e9s).<\/p>\n<p>Los desarrolladores de la aplicaci\u00f3n tambi\u00e9n deben extraer sus propias conclusiones de esta situaci\u00f3n. \u201c\u00a1No elabores tus propios algoritmos cifrados!\u201d, este es el grito incesante de los expertos en criptograf\u00eda que, por ejemplo, Telegram no escuch\u00f3. Pero los desarrolladores de Threema utilizaron algoritmos cifrados comprobados con su implementaci\u00f3n est\u00e1ndar correcta; los errores llegaron debido al uso de criptograf\u00eda est\u00e1ndar en el protocolo de comunicaci\u00f3n cliente-servidor original, que se implement\u00f3 en lugar del TLS est\u00e1ndar. Parece que los expertos deber\u00edan haber gritado \u201c\u00a1No inventes tus propios algoritmos ni protocolos cifrados!\u201d.<\/p>\n<h2><span id=\"takeways\">Conclusiones <\/span><\/h2>\n<p>Si has elegido Threema pensando que es la \u201caplicaci\u00f3n de mensajer\u00eda mejor cifrada\u201d, no te importa tener que vincular tu n\u00famero de tel\u00e9fono y no quieres enredarte en detalles t\u00e9cnicos, es mejor que cambies a Signal. Como demuestran los ataques reales y resoluciones judiciales, los principios de criptograf\u00eda y el almacenamiento de datos de Signal son m\u00e1s robustos y resistentes. Si necesitas seguir usando Threema para el trabajo o te gusta el hecho de que el ID de Threema no est\u00e9 asociado a tu n\u00famero de tel\u00e9fono, puedes seguir us\u00e1ndolo, pero debes ser consciente de los riesgos. Por mucho que sean hipot\u00e9ticos, no deber\u00edas subestimarlos.<\/p>\n<p>Las medianas y grandes compa\u00f1\u00edas que utilizan Threema en sus procesos empresariales deber\u00edan considerar seriamente la migraci\u00f3n a Threema OnPrem para un control total sobre los servidores de esta aplicaci\u00f3n de mensajer\u00eda.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>C\u00f3mo actuar si tu mensajero secreto no es tan secreto como pensabas.<\/p>\n","protected":false},"author":2722,"featured_media":28289,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[10,2202,2754],"tags":[184,323,3517,220],"class_list":{"0":"post-28287","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-tips","8":"category-business","9":"category-enterprise","10":"tag-cifrado","11":"tag-consejos","12":"tag-mensajeros","13":"tag-privacidad"},"hreflang":[{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/7-threema-vulnerabilities\/28287\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/7-threema-vulnerabilities\/25074\/"},{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/7-threema-vulnerabilities\/20568\/"},{"hreflang":"ar","url":"https:\/\/me.kaspersky.com\/blog\/7-threema-vulnerabilities\/10437\/"},{"hreflang":"en-us","url":"https:\/\/usa.kaspersky.com\/blog\/7-threema-vulnerabilities\/27657\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/7-threema-vulnerabilities\/25397\/"},{"hreflang":"es-mx","url":"https:\/\/latam.kaspersky.com\/blog\/7-threema-vulnerabilities\/25714\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/7-threema-vulnerabilities\/34527\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/7-threema-vulnerabilities\/46772\/"},{"hreflang":"fr","url":"https:\/\/www.kaspersky.fr\/blog\/7-threema-vulnerabilities\/20011\/"},{"hreflang":"pt-br","url":"https:\/\/www.kaspersky.com.br\/blog\/7-threema-vulnerabilities\/20584\/"},{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/7-threema-vulnerabilities\/29669\/"},{"hreflang":"ja","url":"https:\/\/blog.kaspersky.co.jp\/7-threema-vulnerabilities\/33163\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/7-threema-vulnerabilities\/25764\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/7-threema-vulnerabilities\/31437\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/7-threema-vulnerabilities\/31150\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.es\/blog\/tag\/cifrado\/","name":"cifrado"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/posts\/28287","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/users\/2722"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/comments?post=28287"}],"version-history":[{"count":3,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/posts\/28287\/revisions"}],"predecessor-version":[{"id":28291,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/posts\/28287\/revisions\/28291"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/media\/28289"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/media?parent=28287"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/categories?post=28287"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/tags?post=28287"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}