Máis recentemente, a principios do verán, houbo solicitudes xeneralizadas para que Exim se actualizase á versión 4.92 debido á vulnerabilidade CVE-2019-10149 (). E recentemente resultou que o malware Sustes decidiu aproveitar esta vulnerabilidade.
Agora todos aqueles que actualizaron con urxencia poden "alegrarse" de novo: o 21 de xullo de 2019, o investigador Zerons descubriu unha vulnerabilidade crítica en Axente de transferencia de correo (MTA) Exim ao usar TLS para versións de 4.80 4.92.1 se inclusive, permitindo remoto executar código con dereitos privilexiados ().
Vulnerabilidade
A vulnerabilidade está presente ao usar as bibliotecas GnuTLS e OpenSSL ao establecer unha conexión TLS segura.
Segundo o desarrollador Heiko Schlittermann, o ficheiro de configuración en Exim non usa TLS por defecto, pero moitas distribucións crean os certificados necesarios durante a instalación e permiten unha conexión segura. Tamén as versións máis novas de Exim instalan a opción tls_advertise_hosts=* e xerar os certificados necesarios.
depende da configuración. A maioría das distribucións habilitano de forma predeterminada, pero Exim necesita un certificado+clave para funcionar como servidor TLS. Probablemente, as distribucións crean un certificado durante a configuración. Os Exim máis novos teñen a opción tls_advertise_hosts por defecto "*" e crean un certificado auto asinado, se non se proporciona ningún.
A propia vulnerabilidade reside no procesamento incorrecto do SNI (Server Name Indication, unha tecnoloxía introducida en 2003 na RFC 3546 para que un cliente solicite o certificado correcto para un nome de dominio, ) durante un apretón de contactos TLS. Un atacante só ten que enviar un SNI rematado cunha barra invertida ("") e un carácter nulo (" ").
Os investigadores de Qualys descubriron un erro na función string_printing(tls_in.sni), que implica un escape incorrecto de "". Como resultado, a barra invertida escríbese sen escape no ficheiro de cabeceira da cola de impresión. Este ficheiro é entón lido con dereitos privilexiados pola función spool_read_header(), o que provoca un desbordamento do montón.
Cabe sinalar que, polo momento, os desenvolvedores de Exim crearon un PoC de vulnerabilidades coa execución de comandos nun servidor remoto vulnerable, pero aínda non está dispoñible publicamente. Debido á facilidade de explotación do erro, é só cuestión de tempo, e bastante curto.
Pódese atopar un estudo máis detallado de Qualys .
Usando SNI en TLS
Número de servidores públicos potencialmente vulnerables
Segundo as estatísticas dun gran provedor de hospedaxe E-Soft Inc a partir do 1 de setembro, en servidores alugados, a versión 4.92 utilízase en máis do 70 % dos hosts.
versión
Número de Servidores
Por cento
4.92.1
6471
1.28%
4.92
376436
74.22%
4.91
58179
11.47%
4.9
5732
1.13%
4.89
10700
2.11%
4.87
14177
2.80%
4.84
9937
1.96%
Outras versións
25568
5.04%
Estatísticas da empresa E-Soft Inc
Se usas un buscador , despois de 5,250,000 na base de datos do servidor:
- uns 3,500,000 usan Exim 4.92 (uns 1,380,000 usan SSL/TLS);
- máis de 74,000 usando 4.92.1 (uns 25,000 usando SSL/TLS).
Así, os servidores Exim potencialmente vulnerables, coñecidos e accesibles publicamente, son uns 1.5M.
Busca servidores Exim en Shodan
protección
- A opción máis sinxela, pero non recomendada, é non usar TLS, o que fará que as mensaxes de correo electrónico se reenvíen con claridade.
- Para evitar a explotación da vulnerabilidade, sería máis preferible actualizar á versión .
- Se é imposible actualizar ou instalar unha versión parcheada, pode establecer unha ACL na configuración de Exim para a opción acl_smtp_mail coas seguintes regras:
# to be prepended to your mail acl (the ACL referenced # by the acl_smtp_mail main config option) deny condition = ${if eq{}{${substr{-1}{1}{$tls_in_sni}}}} deny condition = ${if eq{}{${substr{-1}{1}{$tls_in_peerdn}}}}
Fonte: www.habr.com