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