CyberSecurityPulse (by ElevenPaths)


Гео и язык канала: не указан, не указан
Категория: не указана


Canal de noticias y reflexiones sobre ciberseguridad del equipo de innovación y laboratorio de ElevenPaths. Visita https://cybersecuritypulse.e-paths.com para más información

Связанные каналы

Гео и язык канала
не указан, не указан
Категория
не указана
Статистика
Фильтр публикаций


Se ha descubierto un fallo en Google Drive que permite a un atacante engañar muy fácilmente a un usuario. Puede pensar que descarga un documento o fotografía, pero en realidad estaría descargando cualquier otro fichero con extensión diferente. O sea, malware. Es un fallo muy simple pero que se corregirá pronto. Sin embargo, tiene algunas curiosidades. Veamos cómo se realiza el ataque:

* Un atacante sube a Google Drive un documento “normal”. PDF, JPG, etc.
* Añade como nueva versión del mismo documento por ejemplo un ejecutable que sea malware. Con extensión “exe” y que nada tenga que ver con el primero subido. Servirá.
* Envía el enlace por cualquier medio a la víctima, que podrá ver el PDF en su navegador normalmente.
* El problema es que cuando lo intente descargar… en realidad bajará el ejecutable, o sea, esa supuesta versión nueva del mismo documento.

Como el usuario ve una cosa pero descarga otra, los atacantes podrían empezar a compartir documentos maliciosos masivamente que podrían confundir a las víctimas.

Un detalle no menor sobre el que no se ha hablado lo suficiente, es que el navegador no marcará como malware ese ejecutable. Si bien ese mismo fichero sería identificado como malicioso por el propio Chrome cuando se descarga bajo cualquier otra circunstancia, en este caso, al venir de Drive, no alerta sobre su maliciosidad. La razón es que Drive se basa en la reputación de la descarga, no tanto en las características del fichero. Por tanto en realidad el fallo se aprovecha de dos circunstancias: el de las versiones maliciosas y además las alertas de descargas de malware que vienen de Drive.

Más información: https://thehackernews.com/2020/08/google-drive-file-versions.html


Malos tiempos para la seguridad de los cajeros. Hace poco se conoció que algunos atacantes estaban aprovechando un fallo en la lógica de cajeros pertenecientes a Banco Santander y presentes en Estados Unidos. Con tarjetas falsas o de prepago legítimas, conseguían sacar dinero o sobrepasar su saldo con un “truco” en el uso de las pantallas.

En principio no relacionado, el CERT de Estados Unidos ha comunicado varios fallos de seguridad en el software de los cajeros automáticos más importantes del mercado:

* En la marca NCR, en su modelo posterior a APTRA XFS 05.01.00. Dos fallos graves. Uno en el USB HID que conecta el dispensador con el ordenador. Permitiría ser SYSTEM en el sistema si se tiene acceso físico. Otro fallo es en el cálculo de claves de sesión. Permitiría que el atacante las generase y sacar dinero. Ciertas versiones de APTRA vulnerables no tienen soporte desde 2015.

* De la misma marca, las versiones APTRA XFS 04.02.01 y 05.01.00 sufren tres vulnerabilidades. Una porque directamente no cifra una comunicación, otra por usar claves de 512 bits en certificados RSA para firmar su software. Y otra porque no comprueba bien el software al actualizarse y permitiría ejecutar código desde un USB. Todas necesitan acceso al cajero.

* La otra marca dominante, Diebold Nixdorf también tiene problemas. Sus cajeros ProCash 2100xe que corran Wincor Probase versión 1.1.30 no cifran la comunicación con sus Cash/Check Deposit Modules (CCDM). Este fallo ya lo conocía la compañía desde febrero.

Más información: https://kb.cert.org/vuls/id/116713


Desde febrero ha circulado en la sombra una vacuna contra la familia de malware Emotet gracias a un fallo en su código. Curiosamente, esta “vulnerabilidad” en el código de un malware ha permitido evitar la infección de muchas máquinas pero además, casi consigue un CVE.

Analistas que le pisaban los talones a la familia Emotet descubrieron que escribía una rama del registro (codificada con XOR) para persistir. Pero también comprobaba su existencia antes de establecerla. Bastaba con crear en el sistema limpio esta rama del registro con un valor falso, y el malware tendría un desbordamiento de búfer cuando lo leyese. Dejaría de funcionar y no infectaría la máquina.

Con este planteamiento crearon un sistema (EmoCrash) muy simple que creaba la rama en sistemas limpios y esto evitaba la infección. Como ventaja adicional, el hecho de que este intento de crear la rama fuese identificable a través de logs muy específico, permita recuperar muestras “inactivas” o muertas en sistemas que afortunadamente no habían sido infectados gracias a la vacuna.

Para evitar que el malware notase que se estaba desarrollando la vacuna, actuaron sigilosamente. A través de Team Cymru proporcionaron el script a 125 CERTs de todo el mundo. Desafortunadamente el 14 de agosto, Emotet modificó su código y la vacuna ya no es efectiva.
Como pequeño intento de troleo final, el investigador James Quinn que descubrió el problema, solicitó un CVE para Emotet… que la organización Mitre denegó porque no se asignan CVEs a malware…

Más información: https://www.binarydefense.com/emocrash-exploiting-a-vulnerability-in-emotet-malware-for-defense/


No toda la información cifrada posee el mismo valor. Algunos datos lo pierden inmediatamente tras su uso, mientras que otros pueden conservarlo durante muchos años. Los ordenadores cuánticos amenazan con romper el cifrado basado en RSA, Diffie-Hellman y Curvas Elípticas, los pilares de la criptografía actual. ¿En qué momento debería una organización inquietarse y comenzar la transición hacia una criptografía cuántico-resistente?

En 2015, el director del IQC propuso la siguiente ecuación para que cada organización calcule el momento: D + T ≥ Q. Esta ecuación establece que debemos empezar a preocuparnos por el impacto de los ordenadores cuánticos cuando D (la cantidad de tiempo durante el cual deseamos que nuestros datos estén seguros) sumado a T (el tiempo que tardarán nuestros sistemas de seguridad en pasar de la criptografía clásica a la post-cuántica), sea mayor que Q (el tiempo que tardarán la computación cuántica la potencia necesaria para romper los protocolos de cifrado existentes). El valor que se baraja hoy para Q es alrededor de quince años.

Ahora bien, cambiar la tecnología de cifrado de una organización no es tarea fácil. El grupo de trabajo Quantum-Safe Cryptography (QSC) del ETSI publicó el 11 de agosto un informe técnico para ayudar a las organizaciones en su migración hacia la criptografía post-cuántica, en el que define un marco de acciones a tomar. El marco de migración, y el plan de migración que lo documenta, comprende las tres etapas siguientes:

1. Recopilación del inventario.
2. Preparación del plan de migración.
3. Ejecución de la migración.

Este informe ayudará a dar los pasos hacia una criptografía más longeva.

Más información: https://www.etsi.org/newsroom/press-releases/1805-2020-08-etsi-releases-migration-strategies-and-recommendations-for-quantum-safe-schemes


120 vulnerabilidades corregidas este mes en productos Microsoft. Se cumplen así 6 meses con más de 100 vulnerabilidades corregidas en cada uno. Antes de esto, solo una vez en 2017 se sobrepasaron las 100 correcciones por mes.

* Parece que han corregido un fallo ya conocido en la forma en la que se firmaban los binarios y permitía dar por válidos ficheros mal firmados. Estaba siendo aprovechada por atacantes. (CVE-2020-1464).

* El otro fallo conocido está en Internet Explorer, una ejecución de código (CVE-2020-1380).

* Algunos de los fallos críticos importantes: En el lector de PDF de Edge, en el framework .NET (Se aprovecha subiendo un fichero a un sistema web), en el motor MSHTML y de scripting de Edge, en Outlook, en Microsoft Windows Codecs Library, el en Windows Media.

CVE-2020-1472 es especialmente interesante, se da en los controladores de dominio y se trata de una elevación vulnerando el Netlogon Remote Protocol (NRP). Este parche no soluciona el problema por completo. Si se aplica en servidores y clientes Windows, los clientes Windows no podrán elevar en el Controlador aprovechando la vulnerabilidad. Pero sí podrán los clientes no Windows que seguirán pudiendo usar NRP vulnerable. Hasta que en febrero de 2021 Microsoft fuerce por defecto el Remote Procedure Call (RPC) seguro con un canal de Netlogon seguro, el fallo no estará completamente solucionado. En resumen, este parche de agosto introduce en realidad una clave del registro FullSecureChannelProtection, que permitirá subsanar el problema, pero obviamente solo para los Windows. A partir de febrero esa clave estará activa independientemente de su valor. Microsoft ha publicado una guía para esto.

Más información: https://support.microsoft.com/en-us/help/4557222/how-to-manage-the-changes-in-netlogon-secure-channel-connections-assoc


A pesar de que en agosto se supone que han endurecido las medidas para poder evitar que se cuelen extensiones maliciosas en la Web Store de Chrome… ha vuelto a ocurrir. AdGuard ha descubierto 300 extensiones maliciosas que robaban información del usuario para prestar servicios de adware, disfrazadas de bloqueadores de anuncios falsos. Nada nuevo, lamentablemente. AdGuard va más allá y se queja abiertamente de la gestión de Google.

“Hemos necesitado tres semanas y una entrada de blog pública para que las retiren”. “Google falla a la hora de manejar la seguridad de Web Store”. Afirma un responsable de AdGuard. Y es que efectivamente, la Web Store sigue la misma filosofía que Google Play, donde es habitual encontrar adware y malware cada poco.

En junio se colaron 106 extensiones que trabajaban de forma coordinada para robar información del usuario. En mayo y abril, se detectaron más de 70. Se trataba de extensiones que se hacían pasar por gestores de wallets de bitcoins pero que en realidad robaban la información de las carteras de las víctimas. A principios de 2019, ElevenPaths encontró una extensión que robaba tarjetas de crédito de las webs y que llevaba un año online.

Más información: https://adguard.com/en/blog/fake-ad-blockers-part-3.html


El grupo de atacantes Oilrig, también conocido como APT34, ha sido el primero en incorporar DoH como parte de sus ataques. Algo que se preveía y que han hecho aprovechando herramientas de terceros.

Kaspersky descubrió que Oilrig normalmente usaba DNSExfiltrator, una herramienta de código abierto clásica para sacar información a través de una conexión DNS normal en texto claro. La herramienta ha añadido la opción de utilizar DoH y los atacantes la han aprovechado.

Usando DNS “normal” eludían ciertas alarmas, pero transmitían en texto claro. Con DoH añaden cifrado y un protocolo poco habitual para exfiltrar información, con lo que pueden pasar algo más desapercibidos, apoyándose en servidores de CloudFare o Google.

Esta es precisamente una de las polémicas alrededor de DoH, pero si se quiere privacidad en la resolución de nombres, es el precio que se de pagar.

Más información: https://www.zdnet.com/article/iranian-hacker-group-becomes-first-known-apt-to-weaponize-dns-over-https-doh/


La carrera para proteger a largo plazo los datos sensibles contra la amenaza de los ordenadores cuánticos ha entrado en la recta final. Tras tres años de análisis de los candidatos propuestos, el NIST ha anunciado los ganadores de la segunda ronda para la selección del nuevo estándar de criptografía post-cuántica. En la tercera y última ronda, el NIST especificará uno o más algoritmos resistentes a la computación cuántica para firma digital, cifrado de clave pública y generación de claves criptográficas. Los algoritmos que pasan a la tercera ronda son Classic McEliece, CRYSTALS-KYBER, NTRU y SABER, en las categorías de cifrado de clave pública y gestión de claves; y CRYSTALS-DILITHIUM, FALCON y Rainbow, en la categoría de firma digital.

De acuerdo con el informe Post-Quantum Cryptography (PQC): A Revenue Assessment publicado el 25 de junio por la firma de analistas de tecnología cuántica Inside Quantum Technology, el mercado de software y chips de criptografía post-cuántica se disparará hasta los 9.500 millones de dólares para 2029. Aunque las capacidades de la PQC se incorporarán en numerosos dispositivos y entornos, según el informe, los ingresos de PQC se concentrarán en los navegadores web, IoT, 5G, las fuerzas de seguridad, servicios financieros, servicios de salud y la propia industria de la ciberseguridad.

Más información: https://www.nist.gov/news-events/news/2020/07/pqc-standardization-process-third-round-candidate-announcement


Aunque parezca mentira, desde hace muchos años existe una simple estafa en la que se apremia a un usuario a saldar un pago retrasado. Puede ser una tarjeta de crédito, un impuesto… Y se le pide que, para solucionar el problema, pague en tarjetas regalo de Apple. La víctima proporciona al atacante el pin y el número por el valor acordado y éste revende la tarjeta, compra material o lo blanquea de alguna forma.

Apple ha sido demandada en California por no poner remedio efectivo a esta situación más allá de advertir en una web de la existencia de este tipo de estafas. Según los demandantes Apple se queda con un 30% de comisión, sean o no destinadas a estafadores. Apple afirma que el 100% del dinero no es recuperable tras una estafa, pero según los demandantes (que ahora buscan más pruebas para la demanda) no es cierto, y que dispone del tiempo suficiente tras una denuncia para intentar devolver al menos ese 30% de comisión a las víctimas.

Según los demandantes, Apple ha violado la California Consumers Legal Remedies Act (CLRA), y que Apple se ha beneficiado de unos 300 millones de dólares del valor total de mil millones en estafas.

Más información: https://www.zdnet.com/article/apple-sued-for-not-taking-action-against-itunes-gift-card-scams/


Veamos algunos datos generales de los resultados del #CyberSecurityReport20H1.

* Con respecto a Microsoft, el número total de fallos descubiertos y corregidos es de más de 600 durante el semestre. Qihoo es de nuevo la que descubre más fallos, con un total de 237 vulnerabilidades reportadas a Microsoft en lo que llevamos de año, pero con respecto al trimestre anterior, los números cambian sustancialmente (el semestre pasado fueron 79). Google pasa de descubrir 35 en el último semestre de 2019 a sólo 5 en esta primera mitad de 2020. Microsoft pasa de 48 a 17.

* En total, en iPhone se han parcheado 60 CVEs en el pasado semestre, de los cuales 5 poseen la categoría de críticos y permiten la ejecución de código arbitrario. A pesar de representar un descenso en las cifras (a falta de la segunda mitad de año), 2020 no está siendo un buen año para la seguridad de iOS.

* De los datos de Bitsight se puede observar que el inquebrantable Conficker vuelve a recuperar el “trono” de las amenazas más virulentas, mientras que también observamos un dato ciertamente preocupante: en la mayoría de los sectores se aprecia un aumento sustancial de tiempo requerido para neutralizar una amenaza.

Más información: https://empresas.blogthinkbig.com/cybersecurityreport20h1-microsoft-corrige-muchas-mas-vulnerabilidades-descubre-bastantes-menos/


El problema de seguridad sufrido por Twitter es importante, pero ¿es el peor que ha sufrido? En este caso, parece ser que los atacantes usaron ingeniería social con trabajadores con acceso a paneles de control que podían modificar el contenido de la cuenta de cualquier usuario. Nada especialmente técnico (al parecer y por lo que sabemos por ahora) pero sí interesante y sobre todo, eficaz. Repasemos algunos graves problemas de seguridad que ha sufrido Twitter y que fueron noticia durante los últimos años.

* En 2010 un gusano JavaScript se apoderó de Twitter. Alguien a través de un XSS había conseguido que, con solo pasar el ratón sobre un tuit (onMouseOver) se retuiteara. La tormenta fue importante y el tuit gusano se expandió en pocos minutos.

* En 2018, se encontró un fallo en la API de Twitter que permitía ver los mensajes directos de algunos usuarios a cualquier desarrollador.

* En noviembre de 2019, se supo que desde mayo a diciembre de 2015 (cuando abandonaron la compañía) dos empleados de Twitter (Ahmad Abouammo y Ali Alzabarah), estaban realmente al servicio de Arabia Saudí para espiar a disidentes en la plataforma. Había sido reclutados en 2014.

* En 2019, un fallo en la app de Android de Twitter permitía ver tuit protegidos. A finales de ese año otro fallo en la app permitía un control total de una cuenta ajena.

* En diciembre de 2019, Ibrahim Balic encontró un problema en la app de Twitter. Subiendo 17 millones de números de teléfono aleatorios, se le devolvieron datos de sus potenciales dueños que permitían identificarlos. Consiguió así obtener el teléfono de personajes relevantes.

* También en 2019, la cuenta de Jack Dorsey fue comprometida gracias a la suplantación del número de teléfono, algo que pudo ser usado para atacar a otras personalidades.

* En 2012, Jonathan Rudenberg alertaba de un fallo en el sistema de publicación a través de SMS de Twitter que podría permitir el envío de tuits en nombre de otra persona con solo conocer su número de teléfono. En realidad, era ya entonces una vulnerabilidad conocida. En 2019 Twitter dejó de permitir el uso de SMS para la publicación.

* En 2013, gracias a fallos en Java, parece que atacantes entraron en la red interna de Twitter (y otras compañías) y tuvieron acceso a contraseñas cifradas y salteadas de 250.000 usuarios.

Más información: https://twitter.com/TwitterSupport/status/1283591844962750464


Cinco meses seguidos con más de 100 vulnerabilidades corregidas en Microsoft. 123 en este caso. 17 críticas. Sin duda el problema más grave es CVE-2020-1350, que afecta a DNS de la versión server de Windows desde 2008 a 2019 (parece que el fallo tiene 17 años). SigRed, como se ha apodado, tiene todos los ingredientes para convertirse en pesadilla (excepto que ya existe parche): ejecución de código gusanable y con máximos privilegios (SYSTEM). Aquí sí que hay ojos mirando en estos momentos cómo crear un exploit funcional en todas las versiones. Las pistas son muchas: para mitigar el problema es necesario limitar el valor TcpReceivePacketSize de 0xFFFF a 0xFF00 (255 bytes menos)… lo que allana el camino para entender la vulnerabilidad.

Existen servidores DNS de Windows de cara a Internet, pero muchos más en redes locales de compañías gracias al controlador de dominio. Las buenas noticias es que el workarraound si no se aplica el parche consiste en ese cambio mencionado en el registro y un reinicio del servicio DNS.

Otra buena tanda de parches críticos se encuentra en Hyper-V RemoteFX vGPU.

Más información:
https://support.microsoft.com/en-us/help/4569509/windows-dns-server-remote-code-execution-vulnerability


Los creadores de malware cometen fallos, por muy profesionales que sean. Incluso Trickbot. Pero esto es una obviedad. Lo que ha ocurrido es que un módulo de una versión de TrickBot, encargado de barrer con todas las credenciales, cookies e información útil que pueden alojar los navegadores, accidentalmente mostraba un mensaje en el navegador (a modo de página web en 127.0.0.1), alertando a la víctima de que si veía ese mensaje, estaba siendo víctima del malware y que “empezara a preocuparse”. Algo nada afortunado para el atacante.

Según algunas fuentes, demuestra que la industria del malware también subcontrata a personal para realizar ciertos módulos, externalizar y permitir una evolución más rápida. Incluso, que estos subcontratados crean que están realizando labores de anti-malware y de ahí el mensaje mostrado.

Pero pensamos que puede que simplemente, se tratase de un mensaje de “debug” olvidado por un programador, una muestra de prueba, etc. En cualquier caso debe alertarnos sobre el nivel de ingeniería de este tipo de malware, que lleva con nosotros de 2016 evolucionando para ser eficiente (no detectado y persistente). Esto, no lo olvidemos, se consigue basándose en los mismos principios de ingeniería del mundo del software legítimo, aunque con otros métodos.

Más información: https://threatpost.com/trickbot-sample-accidentally-warns-victims/157390/


Otro plugin con graves problemas de seguridad para Wordpress, y esta vez de pago. Adning Advertising. Con unos 8000 usuarios, es uno de los plugins de gestión de publicidad más populares en Wordpress.

La versión 1.5.6 corrige un fallo que podría permitir que un atacante tomara el control de la web. El fallo se da en la forma en la que se pueden subir banners al Wordpress, que podría permitir la subida de cualquier PHP y ejecutarlo, lo que equivale a tomar el control de la web y potencialmente el sistema.

Se encontró además otro fallo que permite borrar cualquier archivo. Este plugin es de pago, pero si se va al mercado negro a buscar plugins piratas, las posibilidades de salir malparado son mucho mayores. En la web thewordpressclub[.]org de plugins de pago “gratis”, han aparecido varios de ellos troyanizados que permiten a un atacante acceder a través de un backdoor.

Más información: https://www.wordfence.com/blog/2020/07/critical-vulnerabilities-patched-in-adning-advertising-plugin/


CVE-2020-5902 es la vulnerabilidad del momento. Por gravedad y forma en la que se ha desarrollado el problema, desde el aviso hasta la existencia de un exploit plenamente funcional muy sencillo de lanzar con solo un comando curl.

El fallo está en el TMUI de Big IP del fabricante F5. Un sistema que suele estar presentes en el perímetro de las compañías y que se utiliza con muchos fines, habitualmente críticos. Se trata de un Local Traffic Manager y tiene poder total sobre el tráfico que pasa por él. Por tanto el impacto de este problema de ejecución remota de código es más grave de lo que parece puesto que quien lo aproveche tendrá no solo acceso al sistema F5 en sí, sino al servicio que gestiona en la red. Desde un DNS hasta un gestor de certificados TLS, cualquier cosa que esté dentro de esa red.

El fallo se anunció el 1 de julio por el propio fabricante, con una gravedad de 10 pero con parche. Para el día 3 de julio ya se observaron ataques con pruebas de concepto y para el 5, la capacidad de ejecutar código puesto que se hizo público un exploit en Twitter. Horas después ya existía un módulo de Metasploit y ya proliferan las diferentes versiones del exploit por GitHub.

Por su criticidad, un F5 no es sencillo de parchear. La forma menos traumática de mitigar el problema es limitar por IP el acceso a TMUI. Y todo ha ocurrido en fin de semana.

Más información: https://support.f5.com/csp/article/K52145254


En febrero, Safari más que anuncio, realizó un tanteo de poder. Unilateralmente, haría que en Safari los certificados TLS durasen como máximo 398 días. La CAs siempre han estado en contra, y así lo han votado varias veces. Esto era, más que un ejercicio de protección al usuario, un tanteo de poder. Y ha ganado. Porque ya sabemos que Chrome y Firefox le seguirán.

Los principales actores de internet (Google, Microsoft, Apple, Mozilla…) y las CAs votaron en septiembre de 2019 si se debía reducir (aún más) el tiempo de vida de los certificados TLS/SSL obligando a que tengan un tiempo de vida máximo. El resultado fue (de nuevo) no. Un 35% votó a favor de la reducción: Entre ellos, Google, Cisco, Apple, Microsoft, Mozilla, Opera y Qihoo360. El resto (sobre todo las CAs) votaron en contra, con lo que seguimos oficialmente con los 825 días como máximo de tiempo de vida de los certificados.

Pero Safari a partir del 1 de septiembre, marcará como no confiables los certificados creados a partir de esa fecha y cuya vida sea de más de 398 días. Chrome y Firefox le seguirán. Ha pesado la cuota del 18% (gracias al iPhone). Safari sigue estando ahí.

Más información: https://www.theregister.com/2020/06/30/tls_cert_lifespan/


Microsoft ha sacado dos parches fuera de ciclo. Lo extraño no es esto, sino el canal por el que los ha distribuido. Lo ha hecho a través de la Microsoft Store. El proceso se supone automático, pero si se realiza manualmente, se podrán ver quizás actualizaciones nuevas de las aplicaciones “Extensiones de vídeo HEVC” y “Extensiones de imagen HEIF” que quizás tenga algo que ver.

Las dos vulnerabilidades CVE-2020-1425 y CVE-2020-1457 permiten ejecución de código. Son críticas puesto que no ha esperado dos semanas para los ciclos normales de actualización, aunque no parece que hayan sido aprovechadas por atacantes previamente.

Los fallos en Microsoft Windows Codecs Library se explotan abriendo una imagen o vídeo.

Más información: https://www.zdnet.com/article/microsoft-releases-emergency-security-update-to-fix-two-bugs-in-windows-codecs/


O un ThunderBird actualizado, o un sistema sólido de OpenPGP, pero las dos cosas no se pueden tener (al menos temporalmente). Así lo ha anunciado ThunderBird en un aviso al arrancar el programa. Si se necesita OpenPGP de forma crítica, mejor no actualizar a ThunderBird 78. Hacerlo, romperá Enigmail.

Aunque es cierto que la versión 78 traerá su propio sistema OpenPGP integrado... no estará listo hasta la versión 78.2 y dará problemas. Así que quien actualice a la 78, no tendrá ni Enigmail ni un sistema estable de cifrado integrado.

Parece que no se han podido coordinar todos los equipos para no dejar un “hueco” de funcionalidad. A finales de 2019 ThunderBird anunciaba que integraría la funcionalidad de cifrado sin necesidad de Enigmail (que desaparecería como tal) pero que esto ocurriría siempre que no fuese un lastre para la fundación Mozilla. Parece que han avanzado lo suficiente como para lanzarlo (a pesar de muchos problemas con las licencias), pero no han podido adaptar Enigmail a la nueva versión a tiempo para tener el sistema integrado.

Más información: https://empresas.blogthinkbig.com/fin-enigmail-descubre-realidades-del-software-que-puede-acabar-thunderbird/


Apple se une (el último) a la fiesta del DoH. Tanto iOS 14 como macOS 11 soportarán DoH y DoT (DNS over HTTPS y DNS over TLS respectivamente). Después de Android, Chrome, Microsoft y Firefox, ambos sistemas operativos permitirán peticiones DNS seguras.

Y lo hace de forma muy granular. Se podrán crear apps (extensiones de red) para cifrar las peticiones de todo el sistema o se podrá hacer uso de DoH en apps concretas en particular. Además avisará si se este tipo de tráfico está prohibido en la red para presentar alternativas, y respetará si existe una VPN o configuración de red corporativa para pasar el tráfico por ahí.

También permitirá reglas de uso. Por ejemplo elegir si se fuerza cuando se usa WiFi o conexión por datos.
Apple es el último que se une a la filosofía de proteger las peticiones DNS bajo una conexión HTTPS y que pasen totalmente desapercibidas para un potencial administrador. Una ventaja para la privacidad, pero un problema para muchas otras operaciones como por ejemplo, la búsqueda y bloqueo de dominios usados por malware.

Más información: https://developer.apple.com/videos/play/wwdc2020/10047/


Hace un año, OpenPGP sufría un problema de vandalismo en sus servidores de claves. El sistema agonizaba y necesita un cambio. Pero no llega. Un sistema crítico no puede sostenerse gracias a buenas voluntades. Hace falta uso crítico, inversión, infraestructuras y personas. Sobre todo personas. No se puede depender de, literalmente, una para una parte crítica del sistema porque pone en juego toda su funcionalidad… como ha ocurrido este mes.

Los key servers (SKS) son básicos en la infraestructura OpenPGP. Se ocupan de que podamos localizar las claves públicas de las personas. Permiten que se incorporen al sistema, jamás se pierdan y se repliquen para ofrecer disponibilidad. Para interactuar con ellos se usa el protocolo OpenPGP HTTP Keyserver protocol o HKP. A través del puerto 11371 se pueden subir y buscar claves. Los servidores públicos nunca han funcionado del todo bien y arrastran demasiadas carencias.

HKP sobre TLS se llama HKPS. El servidor hkps.pool.sks-keyservers.net se encarga del “pool” de servidores HKPS que los aglutina, dispone y “ordena” desde el punto de vista DNS para que se conozcan y coordinen. Para pertenecer al pool, los servidores deben estar validados y certificados por una CA propia que permite su comunicación cifrada que… mantiene una sola persona de forma manual desde hace más de 10 años. Kristian Fiskerstrand.

Lo que ha pasado es que a Todd Fleisher, que maneja uno de esos servidores, se le caducó ese certificado que le permitía comunicarse con el central y permanecer en el pool y por tanto, coordinado con el resto de servidores. Buscó a Kristian “desesperadamente” durante un mes. El tiempo corría en su contra. No daba señales de vida ni por correo ni por redes sociales.

Finalmente, le caducó el certificado y tuvo que sacar uno en Let’s Encrypt solo para seguir cifrando las comunicaciones pero a sabiendas de que el pool hkps.pool.sks-keyservers.net no se fiaría de él, pero al menos le permitía seguir operando sin sincronizarse. Al poco, Kristian respondió. Sin muchas explicaciones, había estado en otros asuntos en el último mes. Renovó el certificado. Si hubiera tardado algo más, habrían caducado el resto de servidores y el pool los hubiera ignorado.

Un punto crítico centralizado (que permite el uso descentralizado de OpenPGP) en manos de una sola persona que voluntariamente lo mantiene. ¿Demasiado anacrónico para esta época? ¿Otro despropósito de un proyecto tan romántico como agonizante?

Más información: https://lists.nongnu.org/archive/html/sks-devel/2020-06/msg00008.html

Показано 20 последних публикаций.

4 171

подписчиков
Статистика канала