Si se explotan, estas fallas pueden permitir a los atacantes obtener acceso no autorizado a información confidencial o, en general, causar problemas

Hace poco, un grupo de científicos de la Universidad Ruhr de Bochum, Alemania, presentaron los detalles de una nueva técnica de ataque MITM sobre SSH, la cual han bautizado como «Terrapin» y la cual mencionan que podría permitir a un atacante degradar la seguridad de una conexión SSH cuando utiliza la negociación de extensión SSH. El impacto en la práctica dependería en gran medida de las extensiones admitidas, pero «casi todos» son vulnerables.

Terrapin, explota una vulnerabilidad (ya catalogada bajo CVE-2023-48795) la cual un atacante puede aprovechar para organizar un ataque MITM cuando se usa OpenSSH, la vulnerabilidad le permite revertir la conexión para usar algoritmos de autenticación menos seguros o deshabilitar la protección contra ataques de canal lateral que recrean la entrada analizando los retrasos entre las pulsaciones de teclas en el teclado.

«Al ajustar cuidadosamente los números de secuencia durante el protocolo de enlace, un atacante puede eliminar una cantidad arbitraria de mensajes enviados por el cliente o el servidor al comienzo del canal seguro sin que el cliente o el servidor se dé cuenta», mencionan los investigadores

Sobre la vulnerabilidad, se menciona que esta afecta a todas las implementaciones SSH que admiten cifrados en modo ChaCha20-Poly1305 o CBC en combinación con el modo ETM (Encrypt-then-MAC). Por ejemplo, capacidades similares han estado disponibles en OpenSSH durante más de 10 años.

“Lo más común es que esto afecte la seguridad de la autenticación del cliente cuando se utiliza una clave pública RSA. Cuando se utiliza OpenSSH 9.5, también se puede utilizar para desactivar ciertas contramedidas a los ataques de sincronización de pulsaciones de teclas”, escriben los investigadores.

La vulnerabilidad se debe al hecho de que un atacante que controla el tráfico de la conexión (por ejemplo, el propietario de un punto inalámbrico malicioso) puede ajustar los números de secuencia de los paquetes durante el proceso de negociación de la conexión y lograr la eliminación silenciosa de un número arbitrario de mensajes del servicio SSH enviado por el cliente o servidor.

Entre otras cosas, un atacante podría eliminar los mensajes SSH_MSG_EXT_INFO utilizados para configurar las extensiones de protocolo que se utilizan. Para evitar que la otra parte detecte una pérdida de paquete debido a una brecha en los números de secuencia, el atacante inicia el envío de un paquete ficticio con el mismo número de secuencia que el paquete remoto para cambiar el número de secuencia. El paquete ficticio contiene un mensaje con el indicador SSH_MSG_IGNORE, que se ignora durante el procesamiento.

Para realizar un ataque Terrapin en la práctica, los atacantes requieren capacidades de intermediario en la capa de red para interceptar y modificar el tráfico. Asimismo, se deberán acordar métodos de cifrado específicos para garantizar la transmisión segura de los datos durante la conexión.

El ataque no se puede llevar a cabo utilizando cifrados de flujo y CTR, ya que la violación de integridad se detectará en el nivel de la aplicación. En la práctica, solo se utiliza el cifrado ChaCha20-Poly1305 en el que el estado se rastrea únicamente mediante números de secuencia de mensajes, y una combinación del modo Encrypt-Then-MAC (*-etm@openssh.com). ) y los cifrados CBC están sujetos a ataques.

Se menciona que también se detectó en la biblioteca Python AsyncSSH, en combinación con una vulnerabilidad (CVE-2023-46446) en la implementación de la máquina de estado interna, el ataque Terrapin nos permite meternos en una sesión SSH.

La vulnerabilidad se solucionó en la versión de OpenSSH 9.6 y en esta versión de OpenSSH y otras implementaciones, se implementa una extensión del protocolo «estricto KEX» para bloquear el ataque, que se habilita automáticamente si hay soporte en el lado del servidor y del cliente. La extensión finaliza la conexión al recibir cualquier mensaje anormal o innecesario (por ejemplo, con el indicador SSH_MSG_IGNORE o SSH2_MSG_DEBUG) recibido durante el proceso de negociación de la conexión, y también restablece el contador MAC (Código de autenticación de mensajes) después de completar cada intercambio de claves.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.

from Linux Adictos https://ift.tt/uaN8YJz
via IFTTT

OpenSSH es un conjunto de aplicaciones que permiten realizar comunicaciones cifradas a través de una red, usando el protocolo SSH

Se dio a conocer el lanzamiento de la nueva versión de OpenSSH 9.6 y esta versión incluye varias correcciones de errores y también incluye algunas funciones nuevas, varias mejoras de rendimiento y más.

Para quienes desconocen de OpenSSH (Open Secure Shell) deben saber que este es un conjunto de aplicaciones que permiten realizar comunicaciones cifradas a través de una red, usando el protocolo SSH. Fue creado como una alternativa libre y abierta al programa Secure Shell, que es software propietario.

Principales novedades de OpenSSH 9.6

En esta nueva versión que se presenta de OpenSSH 9.6 se destaca el ProxyJump simplificado, pues se agregó la sustitución «%j» a ssh, expandiéndose al nombre de host especificado, asi como también la detección mejorada de indicadores de compilador inestables o no compatibles, como «-fzero-call-used-regs» en clang.

Otro de los cambios que presenta la nueva versión, es que en ssh se ha agregado el soporte para configurar ChannelTimeout en el lado del cliente, que puede usarse para terminar canales inactivos.

Además de ello, en OpenSSH 9.6 se presenta el control granular de algoritmos de firma, pues se agregó una extensión de protocolo a ssh y sshd para renegociar los algoritmos de firma digital para la autenticación de clave pública después de recibir el nombre de usuario. Por ejemplo, al utilizar la extensión, puede utilizar selectivamente otros algoritmos en relación con los usuarios especificando.

También se destaca que se agregó una extensión de protocolo a ssh-add y ssh-agent para configurar certificados al cargar claves PKCS#11, lo que permite utilizar certificados asociados con claves privadas PKCS#11 en todas las utilidades OpenSSH que admiten ssh-agent, no solo ssh.

Por la parte de las soluciones de errores, se menciona que se incluyen las siguientes correcciones:

1. Solucion a la vulnerabilidad en el protocolo SSH (CVE-2023-48795, ataque Terrapin), que permite que un ataque MITM revierta la conexión para utilizar algoritmos de autenticación menos seguros y desactivar la protección contra ataques de canal lateral que recrean la entrada analizando los retrasos entre pulsaciones de teclas en el teclado. El método de ataque se describe en un artículo de noticias separado.
2. Solucion a la vulnerabilidad en la utilidad ssh que permite la sustitución de comandos de shell arbitrarios mediante la manipulación de valores de inicio de sesión y host que contienen caracteres especiales. La vulnerabilidad puede explotarse si un atacante controla los valores de inicio de sesión y nombre de host pasados ​​a ssh, las directivas ProxyCommand y LocalCommand, o los bloques «match exec» que contienen caracteres comodín como %u y %h. Por ejemplo, el inicio de sesión y el host incorrectos se pueden sustituir en sistemas que usan submódulos en Git, ya que Git no prohíbe especificar caracteres especiales en los nombres de host y de usuario. También aparece una vulnerabilidad similar en libssh.
3. Solucion al error en ssh-agent donde, al agregar claves privadas PKCS#11, se aplicaron restricciones solo a la primera clave devuelta por el token PKCS#11. El problema no afecta a las claves privadas normales, los tokens FIDO ni las claves sin restricciones.

De los demás cambios que se destacan de esta nueva versión:

• PubkeyAcceptedAlgorithms en el bloque «Coincidir usuario».
• Para limitar los privilegios del proceso sshd, las versiones de OpenSolaris que admiten la interfaz getpflags() utilizan el modo PRIV_XPOLICY en lugar de PRIV_LIMIT.
• Se agregó soporte para leer claves privadas ED25519 en formato PEM PKCS8 para ssh, sshd, ssh-add y ssh-keygen (anteriormente solo se admitía el formato OpenSSH).

Finalmente si estás interesado en conocer más al respecto sobre esta nueva versión, puedes consultar los detalles dirigiéndote al siguiente enlace.

¿Como instalar OpenSSH 9.6 en Linux?

Para quienes estén interesados en poder instalar esta nueva versión de OpenSSH en sus sistemas, de momento podrán hacerlo descargando el código fuente de este y realizando la compilación en sus equipos.

Esto es debido a que la nueva versión aún no se ha incluido dentro de los repositorios de las principales distribuciones de Linux. Para obtener el código fuente, puedes hacer desde el siguiente enlace.

Hecha la descarga, ahora vamos a descomprimir el paquete con el siguiente comando:

tar -xvf openssh-9.6.tar.gz

Entramos al directorio creado:

cd openssh-9.6

Y podremos realizar la compilación con los siguientes comandos:

./configure --prefix=/opt --sysconfdir=/etc/ssh
make
make install

from Linux Adictos https://ift.tt/a1z0cp5
via IFTTT

Qubes OS es una distribución de Linux centrada en ser «un sistema operativo razonablemente seguro»

La nueva versión de Qubes OS 4.2 llega poco después de dos años de desarrollo (desde el lanzamiento de la anterior rama 4.1.x) y presenta una gran cantidad de actualizaciones importantes, tales como Xen 4.17, Debian 12, cambio de Gnome por XFCE, soporte de PipeWire entre otras cosas más.

Para quienes desconocen de Qubes OS, deben saber que este es un sistema operativo que implementa la idea de usar un hipervisor para el aislamiento estricto de aplicaciones y componentes del sistema operativo (cada clase de aplicaciones y servicios del sistema se ejecutan en máquinas virtuales separadas).

Las aplicaciones en Qubes se dividen en clases según la importancia de los datos que se procesan y las tareas que se resuelven. Cada clase de aplicación (por ejemplo, trabajo, entretenimiento, banca), así como los servicios del sistema (subsistema de red, firewall, almacenamiento, pila USB, etc.) se ejecutan en máquinas virtuales separadas que se ejecutan con el hipervisor Xen.

Principales novedades de Qubes OS 4.2

Esta nueva versión, que se presenta de Qubes OS 4.2 la base del sistema, se ha actualizado a la nueva versión hipervisor Xen 4.17 (anteriormente se usaba Xen 4.14), además de ello la base de Dom0 ha sido actualizado a Fedora 37 (cabe mencionar que la plantilla para entornos virtuales basados ​​en Fedora 37 fue propuesta en la última actualización de Qubes 4.1.2), también se destaca la actualización de los entornos virtuales basados ​​en Debian se ha actualizado a la rama Debian 12.

Otro de los cambios es el soporte SELinux en las plantillas de Fedora, lo que aumenta la solidez de las políticas de seguridad, ademas de ello en las plantillas para crear entornos virtuales basados ​​en Fedora y Debian se han cambiado para utilizar el entorno de usuario Xfce en lugar de GNOME de forma predeterminada.

Además de ello, se destaca que se ha reescrito por completo la implementación del menú de la aplicación, así como las interfaces gráficas para la configuración (Qubes Global Settings), la creación de nuevos entornos (Create New Qube) y la actualización de plantillas de máquinas virtuales (Qubes Update).

Por otra parte, se destaca la nueva política que presenta Qrexec que se utilizan de forma predeterminada un formato nuevo y más flexible de reglas Qrexec que definen quién puede hacer qué y dónde en Qubes. La nueva versión de las reglas presenta un aumento significativo en el rendimiento y un sistema de notificación que facilita el diagnóstico de problemas.

De los demás cambios que se destacan de esta nueva versión:

• La ubicación del archivo de configuración de GRUB (grub.cfg) está unificada para UEFI y BIOS clásico.
• Se agregó soporte para el servidor de medios PipeWire
• Ahora fwupd se utiliza para actualizar el firmware
• Se agregó una opción para borrar automáticamente el portapapeles un minuto después de la última operación de pegado. Para habilitar la limpieza automática, use el comando qvm-service –enable VMNAME gui-agent-clipboard-wipe
• Para construir paquetes oficiales se utilizan las nuevas herramientas de compilación Qubes Builder v2, que mejora el aislamiento de los procesos de ensamblaje.
• El configurador ofrece una sección separada para administrar GPG.

Finalmente si quieres conocer un poco más al respecto de esta nueva versión, puedes leer los detalles en la nota del lanzamiento de Qubes OS 4.2 en el siguiente enlace.

Descargar Qubes OS

Si quieres probar este Qubes OS puedes hacerlo descargando la imagen del sistema desde su página web oficial y en su sección de descargas la obtendrás, lo puedes hacer en el siguiente enlace.

Se requiere un sistema con 6 GB de RAM y una CPU Intel o AMD de 64 bits con soporte para las tecnologías VT-x c EPT/AMD-v c RVI y VT-d / AMD IOMMU, es deseable una GPU Intel (GPU NVIDIA y AMD no están bien probados). El tamaño de la imagen de instalación es de 6 GB. Es importante recalcar que Qubes OS no solamente puede ser instalado como sistema operativo principal, sino que también brinda la posibilidad de poder probarlo en su versión Live.

from Linux Adictos https://ift.tt/zA6wGoM
via IFTTT

LibrePGP es una especificación alternativa actualizada del estándar de cifrado OpenPGP

El principal desarrollador y mantenedor de la herramienta de cifrado y firma El principal desarrollador y mantenedor de, Werner Koch dio a conocer hace pocos la noticia de la creación del proyecto LibrePGP, la cual es una bifurcación centrada en desarrollar una especificación alternativa actualizada al estándar OpenPGP.

Se menciona que dentro de los motivos de la creación de esta bifurcación es en respuesta aparentemente a una disputa dentro del Internet Engineering Task Force (IETF) sobre el futuro desarrollo del estándar OpenPGP, ya que Koch lo percibió como cuestionable la próxima actualización de la especificación OpenPGP desde una perspectiva de compatibilidad y seguridad.

Según Koch:

El punto de partida para la separación del trabajo dentro del IETF y para el inicio de LibrePGP es que las actualizaciones previstas del estándar OpenPGP (RFC 4880) son «perjudiciales para el uso actual del software OpenPGP «, según afirmó. en el Anuncio escribe. Sin entrar en detalles técnicos específicos, la disputa se remonta a la cuestión de cómo adaptar el actual estándar OpenPGP para el futuro.

Y es que el IETF, en lugar de actualizar gradualmente la especificación, intentó reinventar el estándar y realizarle cambios significativos que violaban la interoperabilidad, además de imponer soporte para el modo de cifrado simétrico GCM, que es difícil de implementar correctamente, ignorando el OCB (Offset codebook mode), cuyas patentes expiraron hace varios años.

Los desarrolladores de los proyectos GnuPG, RNP (implementación OpenPGP de Thunderbird) y Gpg4win que apoyaron la bifurcación, temen que los cambios planificados vayan en detrimento de las implementaciones existentes de aplicaciones basadas en OpenPGP, cuyos usuarios esperan que la especificación sea estable a largo plazo y no están listos para soportar cambios que rompan la compatibilidad.

Además de ello, los creadores de LibrePGP cuestionan la adición de paquetes opcionales con relleno aleatorio para proteger contra el análisis de tráfico. Según ellos, estos paquetes con un llenado aleatorio inicial no verificable representan una amenaza de ser utilizados para crear canales de transmisión de datos ocultos y eludir los sistemas de prevención de fuga de datos. Anteriormente, la idea de incluir relleno se rechazaba por ser un problema a nivel de aplicación en lugar de un problema a nivel de cifrado.

Por otra parte, también cuestionan el uso de un esquema de cifrado ECDH modificado, en lugar de utilizar la opción ya descrita en RFC-6637 e implementada en PGP y GnuPG, asi como tambien la eliminacion de algunas características prácticas, como el método clásico de revocación de clave, el indicador «m» para marcar datos MIME y el indicador «t» para separar texto de datos binarios (el indicador «t» fue reemplazado por el indicador «u» para texto codificado UTF-8).

Ante esto y otras cuestiones más, fueron los motivos de la creación de LibrePGP, el cual se menciona que incorpora mejoras útiles que se han desarrollado en los últimos años para una versión futura de la especificación OpenPGP, pero evita cambios que afectarían negativamente a la compatibilidad. Por ejemplo, en comparación con el estándar RFC-4880 actual, LibrePGP ha adoptado las siguientes características:

• Compatibilidad con el algoritmo de cifrado Camellia ( RFC-5581 ),
• Extensiones ECC (criptografía de curva elíptica) para OpenPGP ( RFC-6637 ).
• Soporte obligatorio para hashes SHA2-256 (SHA-1 y MD5 se clasifican como no recomendados, y la capacidad de descifrar datos sin verificación de integridad se clasifica como completamente obsoleta).
• Aumentando el tamaño de la huella digital a 256 bits.
• Admite el esquema de firma digital EdDSA y los esquemas de firma de curva elíptica BrainpoolP256r1, BrainpoolP384r1, BrainpoolP512r1, Ed25519, Curve25519, Ed488 y X448.
• Soporte para el algoritmo CRYSTALS-Kyber, que es resistente a la selección en computadoras cuánticas.
• Compatibilidad con modos de cifrado autenticados OCB (modo de libro de códigos compensado).
• Implementación de la quinta versión del formato de firma digital con protección de metadatos.
• Soporte para subpaquetes extendidos con firmas digitales.

Finalmente, cabe mencionar que los partidarios de OpenPGP ya han publicado críticas tras críticas. Como resultado, si no se puede encontrar un compromiso, la división puede conducir a crecientes incompatibilidades en las implementaciones de OpenPGP/LibrePGP. Para resolver parcialmente este problema, los desarrolladores de OpenPGP arreglaron la quinta versión del formato de firma como compatible con LibrePGP y pasaron a trabajar en la sexta versión.

Si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.

from Linux Adictos https://ift.tt/LK6srXl
via IFTTT