Tecnología, Internet y juegos
36 meneos
444 clics
Este envío tiene varios votos negativos. Asegúrate antes de menear

RansomEXX, un ransomware que también afecta a Linux

La empresa de seguridad Kaspersky dio a conocer hace poco, que ha descubierto una variante para Linux del ransomware RansomEXX, lo que marca la primera vez que una cepa importante del ransomware de Windows se ha trasladado a Linux para ayudar con intrusiones específicas. Anteriormente, se informó que este ransomware se utilizó en ataques contra el Departamento de Transportede Texas, Konica Minolta, el contratista del gobierno estadounidense Tyler Technologies, el sistema de tránsito de Montreal y, más recientemente, contra el Sistema Judicial

| etiquetas: ransomexx , ransomware , afecta , linux
23 13 10 K 13
23 13 10 K 13
12»
  1. #27 Porque nunca han atacado un repositorio de una distribución. En Linux Mint cambiaron hasta la imagen de descarga e instalación y sacaron el MD5 por si querías comprobarla, por ejemplo.

    Porque a Alan Cox nunca le hackearon la cuenta con la que aporta código al kernel de Linux para subir una backdoor en su nombre.

    Porque en tu repositorio solo hay software sin precompilar y lo auditas todo e instalas desde las fuentes.

    Porque nunca van a sobornar a un desarrollador para que meta un backdoor.

    Porque en 2020 no siguen saliendo errores de seguridad en librerías de lo la más anodino pero ampliamente utilizadas, como libjpg o libpng que parecen de lo más inocente.

    Porque la critpgrafía asimétrica de llave pública se basa en software privativo. Espera, que no lo hace. Lo que se mantiene privado es la clave privada. El algortimo es público y lo bastante robusto para que conocerlo no sirva de mucho sin las claves secretas. El ramsomware utiliza librerías públicas. El criminal no desarrolla algoritmos propios para cifrar.

    En cuanto a las vulnerabilidades que utiliza para difundirse... bueno, las que se utilizan en windows que se filtraron de la NSA seguramente se consideran software abierto.

    La seguridad no tiene que ver con el software libre o no libre. No hay pares de ojos para auditar todo el software que se necesita en un servidor o una estación de trabajo. Partimos de la confianza de que el software abierto (no necesariamente libre) está auditado porque su código es disponible y que nuestros suministradores de software de confianza tienen procesos internos de seguridad lo suficientemente robustos. Igual que confiamos en que las redes de anuncios que insertamos en nuestras páginas web vienen de una empresa de confianza que tiene un proceso de seguridad robusto.

    Pero el día que en un paquete de lo más anodino de nuestra distribución de software o que un módulo del kernel de linux que necesitamos nosotros y mucha otra gente para un dispositivo concreto o la empresa que distribuye los anuncios en la web es vulnerada las consecuencias son graves. Por supuesto te joden antes si instalas paquetes de sitios que no se toman en serio la seguridad, o insertas anuncios en tu web de una empresa de dudosa reputación, pero no va de software libre vs software privativo la seguridad.

    Va de buenas prácticas sobre malas prácticas. El software libre puede ser mejor auditado por los propios usuarios finales o por gente más cercana a estos últimos y tener hábitos más "sanos" te evita algunos problemas, pero sigue sin ser una garantía.
  2. #132 Prácticamente nadie se descarga un software binario y valida la descarga. El MD5 no se proporciona para revisar si se ha modificado el software, sino si la descarga es correcta, aunque casi nadie lo hace. Si un hacker malicioso es capaz de atacar a un repositorio puede cambiar los hashes.

    Los CVE se publican cuando los fallos son descubiertos. Un hacker malicioso no reporta las vulnerabilidades que encuentra. ¿Cuántos años ha vivido shellshock entre nosotros? ¿Era software malicioso per sé? No, aparentemente era un bug, pero podría estar ahí intencionadamente.

    ¿Cuántos servidores quedan aún por parchear con esa vulnerabilidad?

    El software libre no es garantía de seguridad por si misma. Nadie vive al día en la última versión y el software libre no es garantía de seguridad. Si. Es más difícil que te la cuelen usando software libre que tiene un desarrollo activo y es debidamente auditado. si además sigues buenas prácticas de seguridad es más difícil que te la cueles tu mismo. El problema es que también existe software libre que está abandonado o que es relativamente poco importante y no nadie se molesta en auditarlo. El software tiene fallos. Tanto el libre como el otro.

    Y que no se puede vivir 100% usando software libre. Si para muchos usuarios, pero otros tenemos ciertas necesidades que no están cubiertas por el software libre, aunque siempre que podamos utilizamos la opción libre. Puestos a utilizar software propietario hay que usar el que te de más garantías. Y no, la versión "thepiratebay" de tu software favorito es menos segura.
  3. #134 ¿Te has leído la GPL? Tampoco da ninguna garantía. Te da una serie de libertades e impide que te las arrebaten. Y ya está.

    Hay proyectos en los que se auditan y hay otros en los que no se hace. También hay software privativo en el que contratan a terceros para auditar (aunque luego un responsable pueda pedir que se meta una puerta de atrás). Eso si, incluso aunque fuese muy seguro se limpian el culo con las libertades del usuario.

    La seguridad no tiene que ver con que el software sea libre sino con que se cumplan ciertos procesos de auditoría. Que el software sea libre ayuda a que se cumplan y se revise su cumplimiento.
  4. #22 Si el script lo has escrito tú, no hace falta darle ningún permiso, pero si te lo has descargado de la red, no tiene permisos de ejecución hasta que se los das. No es como pulsar en el enlace de un archivo adjunto en Outlook, que ya se ejecuta sin ninguna intervención más.
  5. #137 Si descargas algo de Internet, dependerá también un poco de que umask tengas configurado. Pero por defecto, los permisos del script serán los siguientes: rwrw-r-- (no hay ejecución). Si lo ejecutas con bash script.sh se ejecutará sin tener permisos de ejecución. Básicamente porque bash solo necesita permisos de lectura, como lo explican aquí: unix.stackexchange.com/questions/203371/run-script-sh-vs-bash-script-s
  6. #138 El umask que tengo, es el que viene configurado por la distro. De todas formas en ese caso serás responsable de lo que haga el script, no es responsabilidad del que portó el ransomware para GNU/Linux.
  7. #139 Yo no he dicho nunca eso.
  8. #140 Supongo. A lo que voy es que más que un ransomware que afecta a GNU/Linux, es un ransmware que se puede ejecutar en GNU/Linux, pero alguien tiene que ejecutarlo antes, no ocurre por el programa mismo sin intervención humana previa.
  9. #136 No. Estoy reconociendo para que un software sea razonablemente seguro tiene que ser auditado, y que sea libre no es garantía de que esté auditado.

    Y que a efectos prácticos salvo que lo audites y lo compiles tu mismo te va a dar un poco igual. Creer que algo es seguro es una prueba de fe. Simplemente hay organizaciones más fiables que otras.
12»
comentarios cerrados

menéame