¿Creías que después del fallo de Kamisnky en 2008 se solucionó todo? DNS sigue siendo uno de los protocolos más débiles sobre el que se sustenta (demasiado) internet. Varias universidades han podido envenenar las cachés DNS como ya se hizo entonces. Se llama SAD DNS. Es complejo de explicar, pero vamos por partes.

Para poder falsear una petición DNS y devolverle al cliente una mentira, el atacante debe saber el TxID (transaction ID) y el puerto origen UDP. Esto suponía una entropía de 32 bits (adivinar dos campos de 16 bits). SAD DNS consiste (básicamente, porque el paper es muy complejo) en inferir el puerto UDP a través de un ingenioso método que se vale de los mensajes de vuelta de error ICMP. Esto deja de nuevo una entropía de 16 bits, asumible para un ataque.

¿Cómo deducir el puerto abierto del resolvedor (la víctima a la que se le va a envenenar la caché)? Lo más sencillo es escanear todos los puertos UDP y ver cuál está abierto, pero esto lleva demasiado tiempo. Pero cuando hayas terminado, ya se ha realizado la transacción y el puerto que querías estará obsoleto. Además, si se machaca un servidor consultando puertos UDP él mismo limitará las respuestas ICMP de “error puerto cerrado” para no saturar. Todos los OS implementan este límite global. Y este límite para proteger, paradójicamente, es lo que aprovecha el ataque. El límite global es de 1000 respuestas por segundo en Linux (200 en Windows). Se trata de un contador global compartido por cualquiera que le esté preguntado. Por tanto el atacante debe:

* Enviar 1000 sondas UDP al resolvedor víctima con IPs de origen falseadas probando 1000 puertos (en realidad son lotes de 50 cada 20 ms para superar otro límite de respuestas por IP).

* Si los 1000 puertos están cerrados, la víctima devolverá (a las IPs falseadas) 1000 paquetes ICMP de error indicando que no está abierto el puerto. Si está abierto, no pasa nada, lo descarta la aplicación correspondiente en ese puerto.

* No importa que el atacante no vea los ICMP respuesta (llegan a las IPs falseada). Lo que importa es ver cuánto del límite global de 1000 respuestas por segundo “se gasta” en esa tanda.

* Antes de dejar pasar ese segundo, el atacante consulta un puerto cualquiera cerrado y si el servidor le devuelve un ICMP de “puerto cerrado”… es que no se había gastado los 1000 ICPM de “error puerto cerrado” y por tanto… en ese rango de 1000 había al menos un puerto abierto. Bingo. Como el límite es global, una respuesta de puerto cerrado significa que no se gastó el límite de 1000 repuestas de “puerto cerrado” por segundo.

* De esta forma, en tandas de 1000 consultas por segundo y comprobando si gasta o no el límite de paquetes de error “puerto cerrado”, el atacante puede ir deduciendo qué puertos están abiertos. En algo más de 65 segundos (para cubrir 65.536) tendrá mapeados los puertos abiertos del servidor. Ahora adivina el TrID por fuerza bruta, y lanza varios paquetes que confundan al resolvedor.

Hay más variantes del ataque dependiendo de cómo implemente UDP la víctima, de si es un simple forwarder o un resolvedor.

Más información: https://dl.acm.org/doi/pdf/10.1145/3372297.3417280

Si macOS no respeta la privacidad, no parece que sea precisamente por la polémica alrededor del envío OCSP y de qué programas se tienen abiertos. El informe original de Jeffrey Paul, a nuestro criterio, especula en exceso. Muestra hechos, pero la interpretación (más o menos dramática de las consecuencias) está abierta y la polémica, servida. Algunas consideraciones sobre el “descubrimiento”:

* OCSP sirve para saber si un certificado que firma un programa está revocado. Esto es una protección adicional para MacOS que ya de por sí resulta bastante estricta en seguridad con lo que se ejecuta: tenemos a gatekeeper y la notarización. Mejorable, pero es una opción de seguridad añadida.

* El envío OCSP es en texto claro, y englobaría básicamente la IP y un hash del certificado relacionable con la aplicación. También puede que Akamai, que sirve de infraestructura a Apple, pueda verlo, además de alguien en la red. Pero ya ven los dominios en peticiones DNS en claro, puertos de conexión… ¿De verdad es tan dramático que alguien con acceso a la red pueda acceder, además, hashes asociados a programas ejecutados? Es más probables que la llamada a casa de cada programa aporte más información que la comprobación OCSP.

* Se suponía que la imposibilidad de bloquear el acceso al dominio de comprobación OCSP resultaba en un signo de la intencionalidad de Apple. En realidad puede interpretarse como un intento de mejorar la seguridad, para que ningún malware pueda evitar la comprobación.

En resumen, ¿un grave problema de privacidad? No tanto. Y en todo caso, es habitual sacrificar algo de privacidad por una mayor seguridad. En este caso, una pequeña parte, pensamos. Microsoft con su SmartScreen recolecta una enorme telemetría sobre el uso de los programas que ejecuta el usuario. A cambio ofrece una seguridad adicional que para muchos merece la pena. Aun así, después de todo, Apple no recogerá más las IPs, entre otras mejoras en el futuro.

Más información: https://sneak.berlin/20201112/your-computer-isnt-yours/

Se han hecho públicas casi 50.000 direcciones IP de dispositivos VPN de Fortinet vulnerables al fallo CVE-2018-13379, que como indica su CVE, tiene ya dos años aunque se hizo pública en 2019. El problema es que el trabajo está ya totalmente hecho para los atacantes. Por un lado existe un exploit público funcional, y por otro ya alguien se ha encargado de hacer el filtrado de potenciales candidatos a ser atacados (que habitualmente implica una búsqueda en Shodan). Esto implica una presión adicional para aquellos que todavía no hayan aplicado el parche. No se sabe si absolutamente todos las IPs son verdaderas y atacables (hay algunos honeypots), aunque parece que el atacante ya hizo el ejercicio de atacarlas para estar seguro de poder recuperar la información.

El atacante tendría acceso con este fallo a archivos del sistema habitualmente no accesibles. En concreto sslvpn_websession, permitiría facilitar el acceso remoto. Los afectados son: FortiOS de 6.0.0 a 6.0.4; FortiOS de 5.6.3 a 5.6.7; FortiOS de 5.4.6 a 5.4.12.

Desde esta web se puede comprobar si una determinada dirección IP se encuentra en esa lista: https://www.segu-info.com.ar/find-ip-FG-IR-18-384

Más información: https://www.bleepingcomputer.com/news/security/hacker-posts-exploits-for-over-49-000-vulnerable-fortinet-vpns/amp/

Usar un segundo factor de autenticación siempre es buena idea. Aunque no siempre son del todo efectivos. Un ejemplo son los códigos por SMS, un método en extinción que se sabe obsoleto y que es mucho menos robusto que otras soluciones. Pero también puede que el sistema de 2FA esté mal implementado, como ha ocurrido con cPanel, al que se le ha encontrado un fallo importante en este aspecto.

Se podía adivinar por fuerza bruta, en cuestión de minutos, unos parámetros que eludían el 2FA. Si el atacante disponía de la contraseña de la víctima por cualquier motivo, en este caso el segundo factor no cumplía su misión.

Dada la popularidad de cPanel y la cantidad de sitios web que lo usan como sistema de gestión de hostings, el fallo es relevante. Ha sido solucionado en las últimas versiones del programa.

Más información: https://www.digitaldefense.com/news/zero-day-cpanel-and-webhost-manager/

El navegador es el nuevo campo de batalla del malware y el interés por los atacantes en las extensiones así lo confirma. No es nuevo que se cuelen extensiones maliciosas en un Web Store (en especial el de Chrome) pero sí que es noticia que lo hagan para Edge… aunque ahora es más sencillo porque al estar basado en Chromium, las extensiones son compatibles.

Se han encontrado 18 extensiones maliciosas que en esta ocasión, inyectaban publicidad. Se hacían pasar por VPNs que ni siquiera tenían versiones oficiales. En otra tanda, los atacantes simulaban versiones de extensiones oficiales, pero a las que habían añadido contenido malicioso.

Más información: www.zdnet.com/article/microsoft-removes-18-malicious-edge-extensions-for-injecting-ads-into-web-pages

Microsoft cierra el año con 58 vulnerabilidades corregidas el segundo martes de diciembre. 9 de ellas críticas y un CVSS máximo de 8.8 en Microsoft Dynamics. Exchange y Excel son especialmente castigados con seis y ocho fallos respectivamente , cinco de ellos con ejecución de código en el caso de Exchange.

Se ha hecho público además una alerta de spoofing de DNS. En principio relacionado con la fragmentación pero no explícitamente con SAD DNS. Microsoft recomienda limitar el tamaño del búfer para evitar fragmentación, lo que se traducirá en más conexiones más pequeñas al puerto 53.

Más información: https://msrc.microsoft.com/update-guide

Ya se conocen los detalles dl ataque a FireEye, del que publicaron muchos detalles, entre ellos, las reglas Yara para detectar potenciales ataques que se pudieran derivar del robo de sus propias herramientas. Lo más interesante es que desvela una operación encubierta muy sofisticada a la cadena de suministro.

Y es sofisticada porque han troyanizado una herramienta muy habitual de gestión de red, llamada Orion de la compañía SolarWinds, la han vuelto a firmar con el certificado legítimo de la compañía y la han subido para su descarga. Esto implica que puede haber muchos otros afectados.

A pesar de haberse hecho público estos detalles este mismo lunes (lo que implica que se conocía desde hace más tiempo) resulta llamativo que la DLL troyanizada no era detectada en masa por los antivirus a la hora de hacer el anuncio. Incluso seguía colgada en el repositorio oficial. El certificado tampoco estaba revocado.
Si la gestión de FireEye ha sido ejemplar en otros aspectos de esta crisis. ¿Se podía haber mejorado la coordinación con todos los actores para dejar atados los aspectos "reactivos" antes de la publicación de los detalles? ¿Desvelarlo así haya sido, quizás, una maniobra de presión sobre SolarWinds?

Más información: https://www.fireeye.com/blog/threat-research/2020/12/evasive-attacker-leverages-solarwinds-supply-chain-compromises-with-sunburst-backdoor.html

El Consejo Europeo adoptó el pasado 14 de diciembre una Resolución sobre el cifrado en la que destaca la necesidad de que se garantice la seguridad a pesar del cifrado. Lo interesante es que el Consejo observa la necesidad de que se vele por que las fuerzas o cuerpos de seguridad y las autoridades judiciales competentes puedan ejercer sus facultades legítimas, tanto en línea como fuera de línea, para proteger nuestras sociedades y a nuestra ciudadanía.

Sin embargo, se dan casos en los que el cifrado hace extremadamente difícil o prácticamente imposible el acceso a las pruebas electrónicas y su análisis. Según la Resolución, la UE buscará un equilibrio adecuado a la hora de velar, por un lado, por la aplicación y el uso continuados de una sólida tecnología de cifrado, y por otro, por que las fuerzas o cuerpos de seguridad y el poder judicial puedan ejercer sus facultades en las mismas condiciones que en el mundo fuera de línea.

La Resolución no dice más, pero abre la puerta a la custodia de claves y a las puertas traseras en el software y hardware de cifrado.

Más información: https://www.consilium.europa.eu/en/press/press-releases/2020/12/14/encryption-council-adopts-resolution-on-security-through-encryption-and-security-despite-encryption/

De las 83 vulnerabilidades publicadas por Microsoft, 10 son críticas. Al menos durante dos meses se ha bajado de 100 fallos por mes, algo que fue la tónica durante la mayor parte de 2020.

Una de las más graves es el fallo en Microsoft defender, CVE-2021-1647, que ya está siendo aprovechada por atacantes y permite ejecución de código. Probablemente se explote al analizar un fichero especialmente manipulado.

El RPC Runtime de Windows también sufre un fallo grave que parece sencillo de explotar. CVE-2021-1658.

No se tienen muchos más detalles de la mayoría de las vulnerabilidades puesto que si bien Microsoft introdujo no hace mucho el estándar CVSS en sus alertas para valorar su criticidad, eliminó el párrafo con las explicaciones necesarias para entender mejor en qué consistían los fallos.

Más información: https://msrc.microsoft.com/update-guide/vulnerability

¿Parchear o no parchear los sistemas que han llegado a su fin de ciclo (EOL), pero que todavía siguen siendo populares? Ya se discutió el asunto cuando XP, tras trece años siendo soportado por Microsoft, terminó recibiendo un parche en 2017 (mucho después de su fin) para intentar detener Wannacry.

Cisco no quiere parchear las últimas 74 vulnerabilidades en varios de sus dispositivos populares, porque han terminado su ciclo de vida, e invita a los usuarios a adquirir las versiones más recientes. Por ahora, ninguno de los fallos parece crítico. La decisión, aunque no guste a los usuarios, debe ser respetada. Los fabricantes deben avanzar, soltar lastre de versiones antiguas para enfocarse en las más recientes y (supuestamente) robustas. Aunque no hay duda de que hay un componente de negocio, puede llegar a entender esa decisión. Abrir la veda a un soporte infinito, no beneficia el progreso hacia sistemas más seguros. ¿Lo hizo bien Microsoft entonces? En el caso de Wannacry, la gravedad del problema lo requería. El fallo era “gusanable” y el parque de XP todavía existente prometía perpetuar la difusión. Puntualmente, realizó un ejercicio de responsabilidad para también cuidar del resto de sus productos.

Más información: https://www.zdnet.com/article/cisco-says-it-wont-patch-74-security-bugs-in-older-rv-routers-that-reached-eol/

Ya lo hemos dicho en muchas ocasiones, el malware para Android no para de evolucionar hacia técnicas cada vez más parecidas al mundo más “maduro” del malware para PC. En este caso se ha encontrado un APK fraudulento capaz de enviar mensajes a través de WhatsApp a los contactos de la víctima. Aprovecha las notificaciones recibidas en el teléfono para responderlas rápidamente con un enlace que parece ser de la Play Store, pero que en realidad redirige otra URL desde donde descargar el malware. La víctima se convierte así en prescriptora del malware a sus contactos.

Si bien esto es relativamente habitual en malware para Android a través de SMS, no lo es tanto esta fórmula a través de mensajería instantánea que puede resultar más creíble y por tanto derivar en más infecciones.

La página a la que redirige (que toma de un servidor, no es siempre la misma) se parece mucho a una app de Huawei supuestamente en Google Play. En realidad se trata de estafas relacionadas con el adware.

Más información: https://thehackernews.com/2021/01/beware-new-wormable-android-malware.html

¿Pueden ser los expertos en seguridad, víctimas a su vez de otros supuestos expertos? Google ha destapado una operación que supera cualquier otra actividad delictiva que hubiera tenido en su objetivo a expertos en ciberseguridad por su elaborada maquinaria para llegar a ellos.

La campaña parece orquestada por el gobierno norcoreano. Se han tomado la molestia de construir perfiles de supuestos investigadores de vulnerabilidades y exploits en Twitter, que apoyaban la labor de los otros, se daban a conocer en la comunidad y alardeaban de sus habilidades (de nuevo, respaldadas entre ellos). Como por ejemplo un supuesto exploit para un fallo en Defender solo apoyado por un vídeo falso, que fue descubierto por la comunidad de investigadores reales pero respaldada por los perfiles falsos. También crearon blogs falsos con investigaciones, algunas plagiadas.
Y una vez ganada la confianza, ahora el ataque. Contactaban por privado con conocidos investigadores y le pasaban un proyecto en Visual Studio con el que pedían su ayuda. Este cargaba una DLL maliciosa en el sistema del verdadero experto.

Existe otra vía de ataque a los investigadores reales. Parece que tras visitar con Chrome los blogs de los atacantes (investigadores falsos) algunos se han infectado con malware, aunque este punto no está claro aún porque parece que implicaría el uso de un 0day.

Han usado Twitter, LinkedIn, Telegram, Discord, Keybase y el correo. Se conocen más de 10 perfiles de investigadores falsos por ahora.

Más información: https://blog.google/threat-analysis-group/new-campaign-targeting-security-researchers/

A partir de la inminente versión 90, Chrome mostrará un error de certificado cuando un usuario intente acceder a cualquier web con un certificado firmado por Camerfirma. Aunque quizás no sea la CA más popular, está muy presente en España en muchas organizaciones públicas.

En Bugzilla se exponen las 26 razones por las que ha sido expulsada. Por ejemplo, decenas de fallos técnicos en otros campos de certificados que no eran capaces de revocar a tiempo. Y para ello las excusas eran variadas. Desde que la legislación local les obligaba a ciertas fórmulas que no cumplían los estándares (cosas que no demostraban)… hasta que su sistema había funcionado bien 17 años, pero que luego al crecer mucho, fallaron algunos controles internos. A veces no había ni excusas. Simplemente no contestaban a los requerimientos.

En uno de los incidentes, se supone que debían dar a conocer la existencia de una sub-CA máximo una semana después de su creación pero no lo hacían. Lo que ocurría según ellos es que “la persona encargada no estaba disponible”. Tampoco el respaldo de esa persona. Camerfirma lo intentó solucionar diciendo que pondría “un respaldo para la persona de respaldo encargada de esta comunicación”. Su personal estaba completamente “desbordado”, o “de vacaciones”. Básicamente, de todos los fallos comunes en muchos certificados (insuficiente entropía, extensiones incorrectas…), Camerfirma siempre fallaba al revocar en tiempo y forma en los certificados.

El mundo de los certificados es exigente. Pero es que así debe ser. Del buen hacer de las CA depende, literalmente, el internet que se ha construido.

Más información: https://empresas.blogthinkbig.com/26-razones-chrome-no-confia-ca-espanola-camerfirma/

Chrome, tan difícil de explotar como suculento para los atacantes. Tras el fallo en FreeType descubierto a finales de 2020 y que en realidad comprendía dos problemas (uno para explotar y otro para escapar de su sandbox), vuelve a conocerse otro 0day de verdad (del que se encuentra siendo aprovechado por atacantes) en este navegador. Es el sexto en apenas unos meses.

Se trata de un nuevo fallo parcheado en la última versión. CVE-2021-21148 es un problema de desbordamiento de heap en el motor V8 (el que procesa JavaScript). Al parecer estaba siendo usado por atacantes coreanos (y pagados por su gobierno) para atacar a reputados investigadores de seguridad. Recordemos que hace poco algunos atacantes se hicieron pasar por investigadores de seguridad para ganarse la confianza de otros legítimos, pasarles supuestos exploits e infectarlos. En aquel momento se barajó que posiblemente existía otra vía de ataque en esta campaña. Parecía que tras visitar con Chrome los blogs de los atacantes (investigadores falsos) algunos se habían infectado con malware, aunque este punto no estaba claro porque implicaría el uso de un 0day. Pues efectivamente lo había.

Y aplicamos la misma lógica ahora que cuando apareció el fallo en FreeType. ¿Es posible que esos mismos atacantes aprovecharan otro fallo en el sistema operativo para rematar su ataque?

Más información: https://chromereleases.googleblog.com/2021/02/stable-channel-update-for-desktop_4.html

Las extensiones del navegador Chrome son uno de los huecos que mejor aprovechan los atacantes en estos momentos. Un reciente caso encontrado en el que se usa la capacidad de sincronización de cuentas entre el navegador, es un buen ejemplo.

Los atacantes comprometieron un sistema. En vez plantar binarios, consiguieron meter una extensión en modo desarrollador (no está en el Store) con permisos para incrustar JavaScript en cada página. Así conseguían robar información de una web muy concreta que operaba la víctima. Pero iban más allá. Para conseguir exfiltrar información de una manera sencilla, elegante y sobre todo, discreta. Aprovechaban la infraestructura de Google como Command and Control. El navegador sincroniza cierta información entre cuentas, para que el usuario tenga la misma experiencia cuando se registra con su cuenta en Chrome en diferentes sistemas. Para conseguirlo envía cierta información a servidores de Google cada cierto tiempo.

El atacante conseguía así, a través de la extensión, enviar información al servidor de Google. Después solo tenía que loguearse con la cuenta de la víctima y recuperar la información gracias a ese diálogo establecido entre los navegadores y con los servidores de Google de por medio. Y todo sin binarios de por medio, solo una sencilla extensión del navegador.

Más información: https://isc.sans.edu/diary/27066

Este segundo martes del mes, Microsoft soluciona 56 fallos de seguridad. Seis de ellos ya se conocían (en .NET principalmente), y uno está siendo aprovechado por atacantes (una elevación de privilegios). Lo más destacado:

* Vuelven los fallos en el servidor DNS. Una ejecución de código.

* Otra vez la pila TCP/IP. Dos fallos de ejecución de código y una DoS. En la práctica, son desde ya tres "ping de la muerte". Afecta tanto a ipv4 como ipv6.

En el caso de la implementación de la pila TC/IP, para ipv4, la ejecución se consigue atacando a la función de “source routing” que, aunque está deshabilitado, responde con un paquete ICMP para informar sobre ello. Y en este proceso se podría aprovechar el fallo. Aunque Microsoft avisa de que es poco probable que estos fallos en la pila sean aprovechados para ejecutar código (la opinión de Microsoft suele estar sesgada) lo que sí es seguro que permiten una denegación de servicio sencilla (provocar un pantallazo azul desde la red).

Más información: https://msrc.microsoft.com/update-guide

"Cellebrite ha crackeado la aplicación Signal: han roto su cifrado extremo-a-extremo". Con este lapidario anuncio despedía el 2020 la BBC. Otros muchos periódicos y blogs se hicieron eco y cundió el pánico entre los usuarios de Signal y la curiosidad agitó a los investigadores. Romper el cifrado extremo-a-extremo de Signal serçoa una proeza. Los ingenieros de Signal, (encabezados por el carismático Moxie), investigaron el asunto y, sorpresa, todo era un malentendido. La aplicación Cellebrite Physical Analyzer puede leer los mensajes de Signal si tiene acceso físico al dispositivo y está desbloqueado. Cualquiera puede hacer eso.

Recientemente, la empresa suiza Terra Quantum acaba de anunciar que ha roto la criptografía post-cuántica. Sí, has leído bien. Por supuesto, no han publicado ningún artículo en una revista científica de prestigio donde detallen su ataque. De momento, solo contamos con su palabra y un reguero de artículos en blogs y prensa especializada que comentan el sorprendente anuncio, haciendo mucho ruido. ¿Habrá llegado el fin de nuestra esperanza en un futuro post-cuántico o se trata de otra campaña de publicidad gratuita? Vender aceite de serpiente sigue estando de moda.

Más información: https://www.bloomberg.com/news/articles/2021-02-07/a-swiss-company-says-it-found-weakness-that-imperils-encryption?srnd=technology-vp

Una vulnerabilidad siempre se puede considerar un fallo, y un fallo es un riesgo que puede, o no, suponer una amenaza. En este sentido, intuimos ya que no todas las vulnerabilidades son igual de importantes. No solo por su gravedad sino porque puedan llegar a ser realmente aprovechadas para atacar.

Kenna Security ha estudiado 18.000 vulnerabilidades catalogadas con su CVE y concluye que solo 473 fueron explotadas en 2019 de forma que supusieran una amenaza real para las compañías. Esto supone un 2,6%. De estas, a su vez, apenas un 6% han llegado a ser populares en su explotación. Un detalle interesante es que para la mitad de las vulnerabilidades, el código para explotarlas ya estaba disponible públicamente cuando se les asignó CVE y por tanto, la inmensa mayoría ya estaban corregidas para entonces.

En resumen, concluimos que hay vulnerabilidades especiales a las que prestar una particular atención. E incluso entre ellas, las hay que son aprovechadas masivamente (vulnerabilidades “estrella”) por atacantes gracias a los exploits disponibles. Con mitigar esas vulnerabilidades, se reduce mucho un riesgo muy real. ¿Por qué siguen suponiendo un problema incluso cuando existen parches? Entramos entonces en el terreno de la planificación, despliegues… Nada es tan sencillo como parece. Pero en realidad, tampoco debería ser tan complicado… por nuestro propio bien.

Más información: https://www.kennasecurity.com/resources/prioritization-to-prediction-reports/

En tiempos de pandemia, ¿qué pasa con el malware destinado a Linux? En el 2021 X-Force Threat Intelligence Index creado por IBM y Intezer se sacan interesantes conclusiones. En 2020 hubo 56 familias nuevas de malware para Linux. Por comparar, en 2015 hubo 14 y en 2010, solo 9 nuevas. Una familia debe entenderse como un conjunto de muestras similares en técnicas, código o procedimientos, aunque cambie cada archivo. ¿Por qué este interés en crear nuevo malware para Linux? Cada vez con mayor frecuencia, lo más interesante de una compañía (datos o procesamiento) se encuentra en la nube y estos servidores suelen basarse en Linux.

Y a ello se dedican los profesionales del malware como Carbanak, APT28 y APT29 o los ransomware RansomEXX y SFile, que ya han adaptado su malware a estos entornos. También aumenta el malware que intenta minar criptomonedas en servidores Linux. Todo ello, al amparo del lenguaje Go, para poder ser multiplataforma y por facilidad de programación.

Pero no olvidemos que independientemente de estas tendencias, los atacantes seguirán explotando la “fruta más al alcance” a través del malware en estaciones Windows.

Más información: https://www.intezer.com/blog/cloud-security/2020-set-record-for-new-linux-malware-families/

La NASA sorprende y deleita a todos los amantes de los viajes espaciales con la revelación de un código secreto oculto en el paracaídas del rover Perserverance. Un joven estudiante francés de informática, Maxence Abela, publicó seis horas después del “amartizaje” un tweet con el criptograma ingeniosamente resuelto.

Utilizando código binario escondido en el patrón de colores del paracaídas, los ingenieros habían codificado el famoso lema del Jet Propulsion Laboratory (JPL) de la NASA: “DARE MIGHTY THINGS”, palabras tomadas de un discurso del presidente Teodoro Roosevelt en 1899: atreverse a cosas poderosas. El código binario correspondía a diferentes valores numéricos, los cuales codificaban a su vez las letras: (1, A), (2, B), (3, C), y así sucesivamente.

Posteriormente, la NASA desveló que el anillo exterior del paracaídas codificaba las coordenadas GPS de la ubicación del JPL: 34°11’58” N 118°10’31” W. Ambos códigos pueden apreciarse en una imagen publicada por el propio laboratorio.

Los ingenieros del JPL ciertamente viven a la altura de su lema.

Más información: https://www.20minutos.es/noticia/4597119/0/la-nasa-escondio-un-mensaje-secreto-en-el-paracaidas-del-rover-perseverance/