Banner de SMTP Smuggling

Hace pocos días, investigadores de SEC Consult dieron a conocer, mediante una publicación de blog, información sobre una nueva técnica de ataque denominada SMTP Smuggling, la cual puede permitir enviar correos electrónicos falsos que eluden los mecanismos de autenticación.

Se menciona que la técnica de ataque tiene como objetivo el Protocolo SMTP, en la cual un atacante puede abusar de las diferencias en la forma en que los servidores SMTP salientes y entrantes interpretan una secuencia que indica el final de los datos del mensaje.

Sobre SMTP Smuggling

SMTP Smuggling es una nueva técnica que permite dividir un mensaje en varios mensajes diferentes cuando es transmitido por el servidor SMTP original a otro servidor SMTP, que interpreta la secuencia de manera diferente para separar letras transmitidas a través de una conexión.

Esto permite la inyección de comandos SMTP en mensajes de correo electrónico de una manera que hace que los servidores receptores los traten como dos mensajes separados, uno de los cuales tienen algunos encabezados: “Para: destinatario@dominio.com”, “De: remitente@dominio.com”, “Asunto: Asunto de ejemplo”, seguidos del cuerpo real del mensaje.

Además, debido a que el sobre del mensaje principal pasa con éxito controles de seguridad como SPF, DKIM y DMARC, el mensaje falsificado se entrega a las bandejas de entrada sin advertencias.

» SMTP Smuggling es una novedosa técnica de suplantación de correo electrónico que permite a los atacantes enviar correos electrónicos con direcciones de remitente falsas (por ejemplo, ceo@microsoft.com) para hacerse pasar por otra persona», explica Longin a Dark Reading. «Por lo general, existen algunas mitigaciones en la infraestructura de correo electrónico para limitar tales ataques, pero con el nuevo enfoque, se entregará un correo electrónico falsificado».

El nuevo ataque, denominado contrabando SMTP, fue ideado por Timo Longin, consultor senior de seguridad de SEC Consult. Longin tomó prestado el concepto principal de otra clase de ataques conocidos como HTTP request smuggling, donde los atacantes engañan a un balanceador de carga frontal o un proxy inverso para reenviar solicitudes específicamente diseñadas a un servidor de aplicaciones back-end de una manera en la que el back-end del servidor final lo procesa como dos solicitudes separadas en lugar de una.

En base a ello, SMTP Smuggling aprovecha que los servidores SMTP interpretan el final de la secuencia de datos de forma diferente, lo que puede provocar la división de una letra en varias dentro de la misma sesión en el servidor SMTP.

Esta secuencia puede ir seguida de comandos para enviar otro mensaje sin interrumpir la conexión. Algunos servidores SMTP siguen estrictamente la prescripción, pero otros, para garantizar la compatibilidad con algunos clientes de correo electrónico poco comunes.

El ataque se reduce al hecho de que se envía una carta al primer servidor, que procesa solo el delimitador «\r\n.\r\n», en cuyo cuerpo hay un delimitador alternativo, por ejemplo, «\ r.\r», seguido de comandos que envían un segundo mensaje. Dado que el primer servidor sigue estrictamente la especificación, procesa la secuencia recibida como una sola letra.

Si luego la carta se envía a un servidor de tránsito o a un servidor de destinatario que además acepta la secuencia «\r.\r» como separador, se procesará como dos cartas enviadas por separado (la segunda carta puede enviarse en nombre de un usuario no autenticado a través de «AUTH LOGIN», pero aparece correcto en el lado del destinatario).

Se menciona que el problema ya fue solucionado en las últimas versiones de Postfix en las cuales se añadió la configuración «smtpd_forbid_unauth_pipelining«, que hace que la conexión falle si los delimitadores que no cumplen con RFC 2920 y RFC 5321.  Esta configuración está deshabilitada de forma predeterminada, pero planean habilitarla de forma predeterminada en la rama Postfix 3.9, que se espera para 2024.

Además de ello se agregó la configuración smtpd_forbid_bare_newline, deshabilitada de forma predeterminada, que prohíbe el uso del carácter de avance de línea («\n») para separar líneas sin retorno. También se agregó el parámetro smtpd_forbid_bare_newline_exclusions, que permite deshabilitar la restricción del soporte «\n» para clientes de la red local.

Por la parte de Sendmail, este proporciona una opción ‘o’ para proteger contra ataques en srv_features, que permite procesar solo la secuencia «\r\n.\r\n».

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/nHPca8q
via IFTTT

SSH3: shell seguro más rápido y rico usando HTTP/3

Hace poco se dio a conocer el lanzamiento oficial de la primera versión experimental del servidor y cliente para el protocolo SSH3 diseñado como complemento del protocolo HTTP3 y que utiliza QUIC (basado en UDP), TLS 1.3 que y aprovecha los mecanismos HTTP para la autenticación de usuarios, asi como tambien para establecer un canal de comunicación seguro

SSH3 utiliza mecanismos de autorización basados ​​en el protocolo HTTP, que permiten nuevos métodos de autenticación, además de la autenticación clásica mediante una contraseña y un par de claves, además de que en SSH3 se puede configurar el acceso a un servidor remoto a través del proveedor de identidad una organización o con una cuenta de Google o GitHub. SSH3 se basa en HTTP/3 y QUIC y, además del reenvío TCP normal, también ofrece reenvío de puertos UDP y un establecimiento de sesión más rápido y seguro.

Sobre SSH3

Los desarrolladores del proyecto mencionan que la creación de SSH3 surgió como resultado de una revisión completa del protocolo SSH, llevada a cabo por un grupo independiente de investigadores separados de los equipos que trabajan en proyectos como OpenSSH y otras implementaciones del protocolo SSH clásico. En SSH3, la semántica del protocolo SSH clásico se implementa a través de mecanismos HTTP, lo que no solo permite capacidades adicionales, sino que también asegura que las actividades relacionadas con SSH estén ocultas entre el resto del tráfico, entre otras cosas, SSH3 permite las siguientes mejoras que el protocolo SSH2 no podría proporcionar, asi como también muchas de las características populares de OpenSSH:

• Establecimiento de sesión significativamente más rápido
• Nuevos métodos de autenticación HTTP, como OAuth 2.0 y OpenID Connect, además de la autenticación SSH clásica.
• Análisis ~/.ssh/authorized_keys en el servidor.
  Analiza ~/.ssh/config en el cliente y maneja las opciones Hostname, Usery Portconfig IdentityFile(las otras opciones se ignoran actualmente)
  Autenticación de servidor basada en certificados
• Robustez ante ataques de escaneo de puertos: su servidor SSH3 puede volverse invisible para otros usuarios de Internet
• Reenvío de puertos UDP: ahora puede acceder a su QUIC, DNS, RTP o cualquier servidor basado en UDP al que solo se pueda acceder desde su host SSH3.
• Certificados X.509: ahora puede utilizar sus certificados HTTPS clásicos para autenticar su servidor SSH3. Este mecanismo es más seguro que el clásico mecanismo de clave de host SSHv2.
• Capacidad de ocultar el servidor detrás de un enlace secreto.
• Todas las funciones permitidas por el protocolo QUIC moderno: incluida la migración de conexiones y conexiones multiruta
• Usar automáticamente la autenticación ssh-agent  de clave pública
• Reenvío de agente SSH para usar sus claves locales en su servidor remoto
• Autenticación de usuario segura sin llave mediante OpenID Connect.

Para cifrar el canal de comunicación, SSH3 utiliza el protocolo TLS 1.3 y se pueden emplear métodos tradicionales basados en contraseñas y claves públicas (RSA y EdDSA/ed25519). Adicionalmente, SSH3 ofrece la opción de utilizar métodos basados en el protocolo OAuth 2.0, permitiendo transferir la autenticación a proveedores externos.

Otro de los puntos fuertes de SSH3 es que ofrece un establecimiento de sesión significativamente más rápido que SSH2, por ejemplo, establecer una nueva sesión con SSH2 puede tardar de 5 a 7 iteraciones de red (ida y vuelta), lo que el usuario puede notar fácilmente ya que SSH3 solo necesita 3 iteraciones.

Si estás interesado en poder conocer más al respecto, debes saber que el cliente y del servidor está escrito en Go y distribuido bajo la licencia Apache 2.0, puedes consultar los detalles en el siguiente enlace.

Además de ello, cabe mencionar que SSH3 aún es experimental y su uso no es recomendable para la producción o entornos críticos y como tal solo se recomienda su instalación para conocer sus funcionalidades o poder testear.

Descargar e instalar SSH3

Para los interesados en poder implementar un servidor SSH3 para pruebas, pueden hacerlo compilando con Go el código fuente siguiendo las instrucciones que compartimos a continuación.

git clone https://github.com/francoismichel/ssh3
cd ssh3
go build -o ssh3 cmd/ssh3/main.go
CGO_ENABLED=1 go build -o ssh3-server cmd/ssh3-server/main.go

Hecho esto, ahora procedemos a añadir nuestra variable de entorno en .bashrc con:

export PATH=$PATH:/path/to/the/ssh3/directory

En cuanto a la implementación del servidor, ya que como SSH3 se ejecuta sobre HTTP3 es necesario un certificado y se puede generar uno con el script:

sh ./generate_openssl_selfsigned_certificate.sh

Finalmente, te invito a que consultes la documentación sobre el uso e implementación de funciones adicionales en el siguiente enlace.

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

Calamares es un framework de instalación gráfica para sistemas operativos Linux.

La nueva versión de Calamares 3.3 ya fue liberada y llega poco después de un año y medio de trabajo y cinco años y medio después de la formación de la rama 3.2.x (lo cual representa un largo trabajo sobre una rama en especifico). La nueva versión cuenta con una gran cantidad de cambios importantes, asi como mejoras y correcciones de errores.

Para quienes desconocen de calamares, deben saber que es una herramienta que te permite instalar fácilmente diferentes distribuciones de Linux, proporciona características tales como modos manuales y automáticos de particiones de disco, sistema flexible de adaptación de apariencia, arquitectura modular, una gran selección de módulos listos para usar (desde la administración del cargador de arranque hasta la administración de usuarios).

Calamares incluye una función de partición avanzada, con soporte para operaciones de partición tanto manuales como automatizadas. Es el primer instalador con una opción automatizada «Reemplazar partición», que facilita la reutilización de una partición una y otra vez para pruebas de distribución.

Principales novedades de Calamares 3.3

Esta nueva versión que se presenta de Calamares 3.3 llega con la actualización de diversos módulos, y es que ahora Calamares es totalmente compatible con las bibliotecas Qt 6 y KDE Frameworks 6, además de que cuenta con un conjunto de archivos QML compatibles con Qt6 para todos los módulos QML. Cabe mencionar que se conserva la capacidad de compilar con Qt5 y KDE Frameworks 5.

Los requisitos de estilo de codificación en Calamares 3.3 han experimentado actualizaciones significativas, pues ahora, el formato del código se ajusta al formato de Clang 15 o 16. Asimismo, los espacios de nombres utilizados en el código C++ han sido reelaborados, pues ahora todas las llamadas se han movido al espacio de nombres Calamares y se han eliminado las referencias al espacio de nombres CalamaresUtils.

Una modificación adicional incluye la eliminación de la dependencia de la biblioteca Boost::Python. En su lugar, el desarrollo en Python ahora se basa en el conjunto integrado de enlaces pybind11. Para desactivar este cambio y volver a compilar desde Boost::Python, se puede configurar la variable CON_PYBIND11=OFF.

Además, Calamares 3.3 incorpora un nuevo módulo denominado «zfshostid», diseñado específicamente para copiar archivos generados por ZFS en /etc/hostid. Otra mejora notable es la introducción de la capacidad de configurar la personalización del nombre del kernel en el módulo Dracut y que se ha llevado a cabo una modernización de la interfaz de usuario para los módulos de «keyboardq» y «localeq» se ha movido del ComboBox al widget Drawer, brindando una experiencia más intuitiva y actualizada.

El módulo «bootloader» presenta opciones ampliadas para su uso en la línea de comandos del kernel. En el módulo «fstab», el trabajo con la configuración /etc/fstab ha sido completamente rediseñado. Muchas configuraciones se han movido al módulo «mount».

También sé destaca que se ha implementado soporte para el cifrado de disco LUKS o LUKS2 en el módulo «partition» ofreciendo una capa adicional de seguridad, ya que ahora es posible omitir la instalación del gestor de arranque. Se utiliza la funcionalidad de la biblioteca KPMCore 21.12 (KDE Partition Manager).

En cuanto al módulo Netinstall, se ha añadido una nueva opción «non-checkable» para grupos, lo que impide que un grupo sea marcado o desmarcado en su totalidad. Es importante señalar que, a pesar de esta restricción, los usuarios aún conservan la capacidad de verificar elementos individuales dentro del grupo, según lo señalado por los desarrolladores.

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

• Se agregó soporte para metadatos de AppStream 1.0 en la interfaz de selección de paquetes «packagechooser» .
• El módulo «keyboard» permite elegir si desea utilizar la configuración X11 o el servicio DBus FreeDesktop locale1. Garantiza que la configuración de distribución del teclado se guarde para todos los diseños que no sean ASCII.
• El módulo «displaymanager» ya no es compatible con el administrador de pantalla kdm.
• ${var} se utiliza como máscara de sustitución en lugar de @{var}.
  El módulo machineid se ha actualizado con soporte para varias variaciones de escritura del archivo /etc/machine-id
• unpackfs ahora usa la opción -S de rsync para soporte de archivos dispersos

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/i2EBgFD
via IFTTT

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

WineHQ continúa con el trabajo de preparar la próxima versión estable de su software. Hace escasos minutos, y una semana después de la anterior v9.0-rc2,  han anunciado el lanzamiento de WINE 9-0.rc3, lo que es la tercera «candidata» a la v9.0 del programa para ejecutar programas de Windows en otros sistemas operativos, que a su vez es la base de otro software como Bottles o PlayOnLinux (muy parado o totalmente abandonado este último). Como se espera en esta fase del desarrollo, no hay nada destacado, ya que el código ya ha entrado en congelación.

WINE 9.0-rc3 ha corregido 35 bugs, con 44 cambios en total. No es habitual que se añada esta segunda parte con los cambios realizados, pero parece que será la tónica de este año. O no, pero para despejar las dudas habrá que ir viendo lo que nos van entregando semana tras semana hasta el lanzamiento de la versión estable.

Bugs corregidos en WINE 9.0-rc3

• vulkan-1:vulkan falla en Windows con controladores Radeon recientes.
• dinput:device8 rompe test_keyboard_layout_name() de user32:input en algunas localizaciones ().
• HardWest 2 (playtest) se rompe con OpenGL/Vulkan backend.
• Star Wars : Fallen Order se bloquea en el lanzamiento.
• Silent Hill 4: The Room no reproduce vídeos de baja resolución (necesita CLSID_CMpegVideoCodec).
• tightvnc viewer se bloquea en la conexión.
• WinSCP 5.21.1.12643 no lista los archivos cuando la versión de Windows es 10.
• Programa Treecomp: algunos widgets no se dibujan.
• Starcraft Remastered: gráficos borrosos / baja resolución.
• El modo de pantalla completa de IrfanView crea un panel superpuesto permanente innecesario.
• advapi32:registry & ntdll:reg – El test_redirection() de 32 bits falla si se ejecuta después del WineTest de 64.
• No se puede hacer doble clic en el navegador del servidor en Worms Armageddon.
• user32:input – test_ActivateKeyboardLayout() falla en Windows 7 para la configuración regional española.
• user32:input – test_keyboard_layout_name() falla en Windows 7 para la configuración regional española.
• comctl32:listbox – test_LBS_NODATA() falla en Wine para la configuración regional hindi.
• El juego RPG Maker se bloquea.
• El uso de C en tiempo de ejecución para la comparación de cadenas unicode rompe LB_FINDSTRING insensible a mayúsculas y minúsculas.
• kernel32:loader – test_section_access() falla a veces en Windows 8.
• Civilization 2 se bloquea al configurar una nueva partida.
• user32:dialog – test_IsDialogMessageA_proc() falla en la configuración regional hindi en Wine.
• kernel32:file – test_MapFile() falla en macOS.
• Railroad Tycoon 2 Platinum (Steam, GOG) se bloquea al cambiar a una resolución de 800X600.
• Falcon BMS 4.37u3: el juego falla aleatoriamente al cargar modelos 3D.
• Crazy Chicken Approaching – Nebula Assertion y Visual C++ Runtime Library Errores.
• Programa que mezcla typelibs de 32 y 64 bits falla al encontrar una typelib referenciada.
• Regresión de la aplicación; SWATH deja de funcionar en absoluto a partir de 8.18.
• Algunos atajos de teclado no funcionan con winewayland cuando se pierde y se recupera el foco.
• SysTray no funciona (y se bloquea) con WiseReminder.
• Wine 9.0-rc1 wayland: El cursor no se mueve en algunas superficies.
• Wine 9.0-rc1 Wayland: Los botones 3-6 del ratón no funcionan.
• winewayland.drv: Alt-shift para cambiar el idioma de entrada aparece como si Shift estuviera pulsado todo el tiempo.
• winecfg ya no se ejecuta después de exportar WINEARCH=win32.
• Regresión de Pegasus Mail 4.80: El puntero no cambia.
• winedbg –auto: muestra la lista de módulos incompleta.
• Regresión en fallout 3 en el nuevo modo wow64.

WINE 9.0-rc3 ya se puede descargar desde el siguiente botón. En la página de descargas del proyecto hay instrucciones sobre cómo instalar esta y otras versiones en Linux, y también en otros sistemas como macOS y hasta Android. La próxima semana, si no se toman un respiro por las vacaciones navideñas, debería llegar WINE 9.0-rc4 también puliendo el software para preparar la versión estable.

.boton {color: white; background-color: grey; padding: 20px; font-size: 2rem; text-decoration: none; border-radius: 10px; position: relative; top: 15px; border: 4px solid #555;}.boton:hover {box-shadow:1px 1px 2.5px black !important;}

WINE 9.0 llegará a principios de 2024, o bien a finales de enero o a principios de febrero. Mucho se tendrían que torcer las cosas para que superara esas fechas. Tras el lanzamiento de la versión estable llegarán las versiones de punto de las estables y volverá a empecer el ciclo, lanzando una versión de desarrollo cada dos semanas hasta finales de 2024, luego Release Candidates, luego estables… Pero ya estamos mirando muy lejos en el futuro. Lo que tenemos más cerca es una felicitación: ¡Feliz navidad a todos nuestros lectores!… aunque uséis Windows.

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

Alpine Linux es una distribución Linux basada en musl y BusyBox, que tiene como objetivo ser ligera y segura por defecto sin dejar de ser útil para tareas de propósito general

Se dio a conocer el lanzamiento de la nueva versión de Alpine Linux 3.19, versión en la cual se incluyen una gran cantidad de actualizaciones, asi como también la integración del soporte para RPi 5, mejoras y más.

Para quienes desconocen de la distribución, deben saber que esta se distingue por mayores requisitos de seguridad y está construida con protección SSP (Stack Smashing Protection). OpenRC se utiliza como sistema de inicialización y su propio administrador de paquetes apk se utiliza para la gestión de paquetes. Alpine se utiliza para crear imágenes de contenedores Docker oficiales.

Principales novedades de Alpine Linux 3.19

En esta nueva versión que se presenta de Alpine Linux 3.19 se destaca la actualización del kernel de Linux a la versión 6.6 LTS junto con la cual se añade el soporte para la Raspberry Pi 5 y se reemplazan los Kernels linux-rpi4 y linux-rpi2 por un solo un Kernel «linux-rpi».

Además de ello, también podremos encontrar las actualizaciones de los entornos de escritorio GNOME 45, LXQt 1.4 y para el entorno de escritorio KDE se incluyen los paquetes de KDE Gear 23.08 junto con KDE Frameworks 5.112.

Otro de los cambios que se destaca de la nueva versión de Alpine Linux 3.19 es que el directorio de paquetes de Python ahora está marcado como administrado por una herramienta externa. Este cambio impide que pip ya no instale paquetes en el directorio del sistema, cuyo contenido es administrado por el administrador de paquetes apk), se menciona que ahora se debera usar pipx en lugar de pip.

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

• Se han actualizado las versiones de paquetes, entre otros, GCC 13.2, LLVM 17, Perl 5.38, Xen 4.18, PostgreSQL 16, Node.js 20.10, Ceph 18.2, Go 1.21, la última versión de LTS Java, openjdk21, PHP 8.3, Erlang 26, Rust 1.72, yggdrasil 0.5, PipeWire 1.0.0,
• El backend predeterminado de iptables es el paquete iptables-nft.
• El paquete OpenRC contiene un parche que permite iniciar la mayoría de los servicios en espacios de nombres netns.
• Debido a un cambio de licencia a una no gratuita, se eliminaron los paquetes de HashiCorp: Consul, Nomad, Packer, Terraform y Vault.
• openrc ha eliminado/sbin/rc el binario obsoleto
• EFI_ZBOOT estaba habilitado para los núcleos aarch64. Este cambio requiere que grub sea reinstalado con grub-install –bootloader-id=alpine –efi-directory=/boot (o /boot/efi)
• yggdrasilse actualizó a 0.5 y el nuevo esquema de enrutamiento es incompatible con versiones anteriores.

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

Descarga de Alpine Linux 3.19

Si quieres descargar esta nueva actualización de Alpine Linux, deberás de dirigirte a la página web oficial del proyecto en donde podrás obtener la imagen del sistema acorde a la arquitectura del equipo donde lo utilizaras.

Las imágenes iso están preparados en seis versiones: estándar (207 MB), con kernel sin parches (204 MB), extendida (957 MB), para máquinas virtuales ( 60 MB) y para el hipervisor Xen (239 MB). El enlace de descarga es este.

Por último, y no menos importante, debes también saber que esta distribución cuenta con una imagen para usar en Raspberry Pi.

¿Cómo instalar Alpine Linux en Raspberry Pi?

Si planeas utilizar este sistema en tu pequeño ordenador de bolsillo, puedes hacerlo siguiendo estas instrucciones que detallo a continuación.

• Hecha la descarga, debemos de formatear nuestra tarjeta SD, podemos apoyar de Gparted, la tarjeta SD debe de quedar con el formato fat32.
• Hecho esto debemos ahora grabar la imagen de Alpine Linux 3.18 en nuestra SD, para ello solamente debemos de descomprimir el archivo que contiene los archivos de Alpine.
• Hecha la descarga, solamente debemos de copiar el contenido dentro de nuestra tarjeta SD.
• Al finalizar solamente debemos de insertar la tarjeta SD en nuestra Raspberry Pi y conectarla a la corriente y el sistema deberá comenzar a ejecutarse.
• Nos daremos cuenta de ello porque debe de parpadear el led de color verde indicándonos que sí reconoció el sistema.
• Y listo con ello podemos comenzar a utilizar Alpine Linux en nuestra Raspberry Pi.

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

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

Hace pocos días Marc Newlin, quien descubrió la vulnerabilidad MouseJack hace siete años, dio a conocer los detalles de una vulnerabilidad de omisión de autenticación Bluetooth que está presente desde hace años que afecta a las pilas Bluetooth de Android, Linux, macOS e iOS y permite la sustitución de pulsaciones de teclas simulando la actividad del dispositivo de entrada conectado a través de Bluetooth.

El error, identificado como CVE-2023-45866, no requiere ningún hardware especial para explotarlo y el ataque da acceso a la entrada del teclado, con lo cual un atacante puede realizar acciones como ejecutar comandos en el sistema, instalar aplicaciones y redirigir mensajes.

«Varias pilas de Bluetooth tienen vulnerabilidades de omisión de autenticación que permiten a un atacante conectarse a un host reconocible sin la confirmación del usuario e inyectar pulsaciones de teclas», dijo el investigador de seguridad Marc Newlin , quien reveló las fallas a los proveedores de software en agosto de 2023.

Sobre la vulnerabilidad se informa que está, específicamente, engaña al dispositivo objetivo, haciéndole creer que está conectado a un teclado Bluetooth aprovechando un «mecanismo de emparejamiento no autenticado» definido en la especificación Bluetooth.

La vulnerabilidad surge debido a que los controladores HID para Bluetooth poseen un modo que facilita la creación y establecimiento de conexiones cifradas por parte de un dispositivo periférico remoto, sin necesidad de autenticación, con lo cual se posibilita la transmisión de mensajes de teclado por parte de los dispositivos conectados, siendo procesados por la pila HID. Este escenario propicia la ejecución de un ataque remoto de sustitución de mensajes HID, sin requerir intervención por parte del usuario. Este tipo de ataque puede ser llevado a cabo cuando el atacante se encuentra a una distancia de hasta 100 metros de la víctima.

Comencé con una investigación sobre los teclados inalámbricos para juegos, pero resultaron ser el tipo equivocado de incendio en un contenedor de basura, así que busqué un desafío en el Magic Keyboard de Apple. Tenía dos cosas notablemente ausentes en mi investigación periférica anterior: Bluetooth y Apple.

La investigación tuvo un comienzo humilde cuando me di cuenta de que no sabía casi nada sobre Bluetooth, macOS o iOS. Tenía mucho que aprender, pero una pregunta llevó a la otra, y pronto estaba informando sobre vulnerabilidades de inyección de pulsaciones de teclas Bluetooth no autenticadas en macOS e iOS, ambas explotables en modo de bloqueo. En este punto, todavía pensaba que Bluetooth probablemente estaba bien, pero el espejismo de la seguridad de Apple estaba comenzando a desvanecerse.

El procedimiento para emparejar dispositivos sin autenticación está definido en las especificaciones de Bluetooth y, dependiendo de la configuración de la pila de Bluetooth, posibilita la conexión de un dispositivo sin requerir la confirmación del usuario (víctima).

Como ya se mencionó al inicio, el ataque no requiere ningún hardware especializado y se puede realizar desde una computadora con Linux usando un adaptador Bluetooth normal. Se espera que en el futuro se publiquen detalles técnicos adicionales sobre la falla.

Los dispositivos sin parches son vulnerables en las siguientes condiciones:

• Los dispositivos Android son vulnerables cuando Bluetooth está habilitado
• Linux/BlueZ requiere que Bluetooth sea reconocible/conectable
• iOS y macOS son vulnerables cuando Bluetooth está habilitado y se ha emparejado un Magic Keyboard con el teléfono o la computadora

En Linux, la vulnerabilidad fue abordada en el código base de Bluez mediante la configuración «ClassicBondedOnly», la cual se ajustó a «true». Esta modificación habilita un modo seguro que permite establecer conexiones únicamente después del emparejamiento, ya que anteriormente dicha configuración estaba establecida en «false», comprometiendo la seguridad en aras de resolver problemas de compatibilidad con ciertos dispositivos de entrada

La pila Bluetooth empleada en las versiones más recientes de Android solucionó la vulnerabilidad al requerir autenticación para todas las conexiones cifradas. Las correcciones para Android están disponibles únicamente en las ramas 11 a 14. Para los dispositivos Pixel, la vulnerabilidad se abordó mediante una actualización de firmware lanzada en diciembre. Sin embargo, para las versiones de Android comprendidas entre la 4.2.2 y la 10, la vulnerabilidad aún esta presente.

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/TwjpLoQ
via IFTTT