CVE-2022-3602 y CVE-2022-3768
El 1 de noviembre de 2022, después de anunciar el programa principal la semana anterior, OpenSSL publicó su aviso describiendo dos riesgos para OpenSSL 3.0.0 - 3.0.6. Originalmente se había anunciado como una alerta de nivel Crítico, que habría sido el primer nivel Crítico desde 2015, pero se rebajó a Alto debido a lo que OpenSSL describe como "factores atenuantes".
Las dos vulnerabilidades se basan en desbordamientos de búfer en el campo Dirección de correo electrónico de un certificado X509. Mediante la elaboración específica de la dirección de correo electrónico, un atacante podría desbordarse y controlar 4 bytes en la pila del sistema de destino CVE-2022-3602, o rellenando la dirección de correo electrónico con un carácter específico el atacante podría desbordar el búfer y bloquear el sistema CVE-2022-3768. Estas dos vulnerabilidades podrían, por sí solas, parecer que romperían todo en todas partes a la vez, sin embargo esos factores mitigantes son bastante importantes.
El primer factor atenuante es que estas dos vulnerabilidades requieren cierto nivel de interacción por parte del cliente o del servidor atacado. En ambas vulnerabilidades, un cliente que ejecute OpenSSL3.0 tendría que visitar un servidor malicioso que aloje un certificado x509 malicioso. Aunque esto no está fuera de lo posible en las operaciones cotidianas, todavía tendría que haber un usuario que hiciera clic en un enlace o abriera un documento para verse comprometido. Aunque esto es bastante común, hay formas más sencillas que utilizar una vulnerabilidad OpenSSL para ejecutar un código remoto.
Desde el lado del servidor, el servidor atacado tendría que solicitar un certificado de autenticación de cliente a un cliente malicioso. Esta no es una configuración normal para servidores orientados a Internet y es más probable que se utilice en dispositivos locales. En este caso, sería necesario que un tercero malintencionado estuviera lo suficientemente cerca como para atacar una red.
Otro gran factor mitigante de estas vulnerabilidades es que los certificados utilizados tendrían que estar firmados por una autoridad de certificación (CA) de confianza, o la aplicación tendría que continuar sin poder establecer una ruta a una CA de confianza para desencadenar estos desbordamientos. Esta es una tarea no trivial para la mayoría de los atacantes, aunque puede haber maneras de utilizar autoridades de firma más abiertas, hay una alta probabilidad de que estos proveedores van a auditar las solicitudes de firma de certificados con el fin de encontrar estos campos de dirección de correo electrónico que pueden ser maliciosos.
Tampoco hay un gran número de sistemas que ejecuten OpenSSL3.0. El número definitivamente no es cero, pero para ponerlo en perspectiva, dos de los principales sistemas operativos de servidor no Windows, RHEL y Ubuntu, acaban de incorporar OpenSSL3.0 a sus plataformas este año. RHEL 9 se lanzó en mayo de 2022, y Ubuntu 22.04 en agosto del mismo año. Esto significa que muchos administradores de sistemas pueden no haber tenido la oportunidad de actualizar a estas ramas, y estas son sólo las versiones LTS más recientes, por lo que puede que no haya necesidad de actualizar. Sin embargo, debe tenerse en cuenta que estas versiones pueden estar siendo utilizadas para construir contenedores Docker, y otras aplicaciones en contenedores.
Por último, OpenSSL no ha detectado que estas vulnerabilidades se estén explotando en la naturaleza, por lo que no se trata de un parche fuera de banda en el que haya una campaña de ataque activa. A pesar de ello, se recomienda parchear los sistemas que ejecuten OpenSSL3.0.0-3.0.6 hasta 3.0.7.
Vectra no tiene una detección específica, o búsqueda guardada desplegada para encontrar usos potenciales de estas vulnerabilidades específicas, sin embargo, como con todas las vulnerabilidades dirigidas a infraestructura o clientes, la vulnerabilidad es sólo el primer vector de infección en un compromiso en curso. Si se comprometiera un cliente o servidor utilizando las técnicas anteriores, es probable que se desplegara un implante o troyano. En estos casos, los clientes podrían esperar ver las siguientes detecciones:
- Túnel DNS oculto
- Túnel HTTP oculto
- Túnel HTTPS oculto
- Acceso remoto externo
- Vectra Inteligencia sobre amenazas Match
- Túnel con fachada múltiple
Estos cubrirían las herramientas maliciosas y los implantes de comportamiento C2, independientemente de la vulnerabilidad utilizada para desplegarlos.
Como esto formaría parte de una campaña en curso, cabe esperar que también se produzcan movimientos laterales, en cuyo caso Vectra ofrece cobertura para las siguientes técnicas:
- Ejecución remota sospechosa
- Anomalía de privilegio: Servicio inusual
- Anomalía de privilegios: cuenta inusual en el host
- Escritorio remoto sospechoso
- Anomalía de privilegios: servicio inusual - Insider
- Anomalía de privilegio: Trío inusual, Anomalía de privilegio: Anfitrión inusual
- Anomalía de privilegios: servicio inusual del host
- Administrador sospechoso
Independientemente de la herramienta que se utilice, estas detecciones están diseñadas para proporcionar cobertura a los comportamientos que los atacantes utilizan después de la vulneración para lograr sus objetivos finales dentro de su entorno.