Esta semana en seguridad: puertas traseras en conmutadores Cisco, suplantación de PGP en correos electrónicos, Git ransomware

Algunos conmutadores de la serie Cisco 9000 son sensibles a la vulnerabilidad remota, con el número CVE-2019-1804. Es un poco extraño llamarlo vulnerable, de hecho, porque el software funciona a propósito. Cisco envió estos conmutadores con la misma clave privada poco cifrada en el software para todos los inicios de sesión SSH raíz. Cualquiera que tenga la clave puede iniciar sesión como root en cualquiera de estos conmutadores.

Cisco hace una afirmación extraña en su consejo de que esto solo puede ser explotado por IPv6. Esto parece muy extraño, ya que no hay nada sobre SSH o el proceso de autenticación de clave que sea específico de IPv6. Esto sugiere que puede haber otra falla: accidentalmente dejaron el puerto SSH abierto al mundo a través de IPv6. Otra posibilidad es que asumen que todos estos conmutadores están detrás de enrutadores NAT de forma segura y, por lo tanto, inaccesibles a través de IPv4. Una de las ventajas / desventajas de IPv6 es que no hay NAT y todos los dispositivos de red son accesibles desde la red externa. (Accesible en el sentido de que existe una ruta. La protección contra incendios todavía es posible, por supuesto).

Es sorprendente cuántos dispositivos, incluso dispositivos comerciales de alta gama, se envían con puertas traseras involuntarias pero efectivas, como este.

Repositorio de Git ransomware

El primer ransomware se dirigió a los repositorios de Git. Cientos de depósitos a través de GitHub, Gitlab y otros servicios fueron reemplazados por una nota de rescate, que requiere 0.1 bitmon para su recuperación. Curiosamente, la nota de rescate amenaza con liberar el código. Este es un problema que el código abierto ciertamente resuelve.

¿Cómo alguien rompió tantas cuentas a la vez? Badpackets.net, una firma de investigación de seguridad, tiene la desventaja.

Maldita sea, pensé que todos esos escaneos "/.git/config" que detectamos eran inofensivos. Supongo que ahora sabemos cuál era el objetivo.

- Informe sobre paquetes defectuosos (@bad_packets) 3 de mayo de 2019

Maldita sea, pensé que todos esos escaneos "/.git/config" que detectamos eran inofensivos. Supongo que ahora sabemos cuál era el objetivo.

Sí, parece que las cuentas comprometidas filtraron sus certificados al alojar accidentalmente sus carpetas .git en línea. Alguien notó que se trataba de un error común y quitó los certificados de estas carpetas a través de Internet. Después de recopilar las credenciales disponibles, se lanzó el ataque. Una mirada a la dirección de bitcoin especificada parece indicar que nadie pagó el rescate, y varios de los afectados descubrieron que el código suscrito aún era accesible, dado el git-fu correcto.

En un hilo de Reddit, un usuario que afirma ser el atacante se vincula a una entrada de 2015 que detalla exactamente cómo puede ocurrir el directorio .git.

Parodia de la firma PGP

Las firmas PGP son una forma útil de saber absolutamente que un mensaje es auténtico, ¿verdad? Según un periódico reciente, no siempre. Puede recordar cómo Efail permitió a un atacante aprovechar una debilidad en los clientes de correo electrónico y enviar el mensaje descifrado al atacante. Un nuevo conjunto de ataques utiliza las debilidades del cliente para romper el control de los mensajes. Imagínese lo que sucede cuando alguien reenvía un mensaje correctamente firmado de alguien en quien confía, pero agrega su propia nota en la parte superior del correo electrónico reenviado. El cliente de correo electrónico muestra la nota sin firmar y luego también muestra el bloque firmado. El periódico señala que la parte sin nombre del correo electrónico podría incluir código HTML y CSS que oculta el resto del mensaje. El correo electrónico mostraría una firma válida y confiable y, sin inspeccionar el texto del mensaje sin procesar, es una falsificación bastante convincente.

El documento describe varias otras técnicas similares. Al igual que en el ataque Efail, estos investigadores no encontraron vulnerabilidades en la propia firma PGP, sino en cómo se procesan y presentan los mensajes firmados al usuario final. De esa manera, no todos los clientes de correo electrónico se ven afectados, pero muchos de los grandes nombres estaban en la lista.

Blockchain!

Parece que no pasa un día sin que algo relacionado con una cadena de bloques no cruce mi radar. Ethercombing es una ilustración interesante y buena de un problema criptográfico común. Los investigadores de ISE observaron la cadena de bloques Ethereum, especialmente la posibilidad de claves privadas. Ethereum tiene un espacio clave de 256 bits. Un buen generador de números aleatorios podría generar billones de claves únicas y nunca repetir la misma clave. Tratar de encontrar la clave privada de alguien en ese mar aleatorio sería un ejercicio inútil, asumiendo, por supuesto, que todo el mundo utiliza una buena generación de números aleatorios.

Como tenían que empezar en alguna parte, los investigadores de ISE empezaron con una clave privada 0x01. Las probabilidades de que se utilice esta o cualquier otra clave privada dada son extremadamente bajas (1 en 2 ^ 256). Se utilizó la clave 0x01 y tuvo 592 transacciones en su historial. Esto sugiere dos opciones. Los humanos somos raros porque solo nos gustan ciertos números. Quizás alguien haya usado deliberadamente esta clave en el pasado, eligiéndola de la misma manera no aleatoria que lo hicieron los investigadores. La otra posibilidad es que un cliente de Ethereum mal escrito haya usado accidentalmente un valor de clave privada de 1.

Luego, los investigadores consideraron otros errores de software que podrían resultar en claves débiles, como truncar 256 bits a 32 bits. Otra suposición ilustrada resultó en el éxito. En total, fueron capaces de "crackear" 732 claves privadas de Ethereum. Al menos una clave se vio comprometida previamente. Entregaron un dólar de Ethereum a esta cuenta comprometida y vieron cómo los fondos se desvían rápidamente a otra cuenta. Ahora que se ha publicado esta investigación, muchas de estas cuentas débiles ciertamente serán controladas de manera similar, así que tenga cuidado.

  • asdf dice:

    En el problema de Cisco IPv6, supongo que los dispositivos tienen un firewall que bloquea las conexiones entrantes, pero solo filtra IPv4. Error sorprendentemente común al usar, por ejemplo, iptables.

  • un solo pensamiento dice:

    ¡Hecho! = Afectado. Solo para que sepas. Gracias

    • Elliot Williams dice:

      TY.

  • tekkieneet dice:

    Ni siquiera estoy seguro de por qué alguien pagaría el rescate de git. Si el proyecto está activo, sus datos se distribuyen allí; de lo contrario, no se pierde nada. Causará algo de dolor organizar una aventura, etc.

    Realmente es un problema con el alojamiento, es decir, administrar la seguridad, hacer copias de seguridad. Microsoft puede restaurar fácilmente los cambios de la copia de seguridad. Si no cuentan con las copias de seguridad adecuadas, los proyectos se trasladarán a otro lugar.

    Los hackers estúpidos enfurecen a MS. La EM es lo suficientemente poderosa como para aprovechar la ayuda a nivel gubernamental para atrapar a estos sinvergüenzas.

    • Dr. Memals dice:

      Según el enlace, estos son repositorios privados donde el .git / config se ha implementado en un servidor web en vivo. El código se almacena felizmente en las máquinas de software para que pueda recuperarse. El problema es que estos no son proyectos de código abierto sino repositorios privados, tal vez con información confidencial, por ejemplo, claves ssh, etc.

  • Un dron dice:

    "Cisco hace una afirmación extraña en su consejo de que esto solo puede ser explotado por IPv6. Esto parece muy extraño, porque no se trata de SSH o del proceso de autenticación de claves que especifica IPv6".

    Sí, lo hay, si dice que es específico de IPv6. Por ejemplo, en el archivo OpenSSH sshd_config:

    DirecciónFamilia

    Indica qué familia de direcciones IP debe usar sshd. Los argumentos válidos son: cualquiera, inet (solo IPv4), inet6 (solo IPv6).

  • tomás zerolo dice:

    Efail. Si claro.

    De todos modos, ¿quién confiaría en el correo HTML? Más aún si llevan enlaces a cosas o (¡sin aliento!) Javascript.

    Solo Microsoft y otros actores en la sombra hacen eso, ¿verdad?

Alana Herrero
Alana Herrero

Deja una respuesta

Tu dirección de correo electrónico no será publicada.