Patcha Exim — patcha igen. Nyligen upptäckte Remote Command Execution i Exim 4.92 i ett enda anrop

Nyligen, i början av sommaren, fanns det en massiv uppmaning att uppgradera Exim till version 4.92 på grund av sårbarheten CVE-2019-10149 (Uppdatera exim till 4.92 omgående – aktiv infektion pågår / Habr). Och nyligen upptäcktes det att den skadliga Sustes utnyttjade den här sårbarheten.

Nu kan alla som hastigt uppgrupperat sig återigen "glädjas": Den 21 juli 2019 upptäckte forskaren Zerons en kritisk sårbarhet i Exim Mail Transfer agent (MTA) vid användning av TLS för versioner från 4.80 till 4.92.1 inklusive, vilket möjliggör fjärrkontroll att köra kod med privilegierade rättigheter (CVE-2019-15846).

Sårbarhet

Sårbarheten förekommer vid användning av bibliotek som GnuTLS och OpenSSL vid installation av en säker TLS-anslutning.

Enligt utvecklaren Heiko Schlittermann använder Exims konfigurationsfil som standard inte TLS, men många distributioner skapar nödvändiga certifikat och inkluderar en säker anslutning vid installation. Dessutom installerar nyare versioner av Exim alternativet tls_advertise_hosts=* och genererar nödvändiga certifikat.

beroende på konfigurationen. De flesta distributionerna aktiverar det som standard, men Exim behöver ett certifikat + nyckel för att fungera som en TLS-server. Förmodligen skapar distributionerna ett certifikat under installationen. Nyare Exim-versioner har tls_advertise_hosts-alternativet som standard inställt på "*" och skapar ett självsignerat certifikat om inget anges.

Sårbarheten i sig ligger i felaktig hantering av SNI (Server Name Indication, en teknik som introducerades 2003 i RFC 3546 för att låta klienten begära ett korrekt certifikat för domännamnet, Spridning av standarden TLS SNI / Blogg av WEBO Group / Habr) under TLS-handshake. En angripare behöver bara skicka SNI som slutar med en bakåtsnedsträck («») och en null-tecken (»«).

Forskare från Qualys har upptäckt en bugg i funktionen string_printing(tls_in.sni), som består av felaktig escaping av «». Som ett resultat skrivs bakåtsnedsträcket utan escaping i filen för headern print spool. Denna fil läses sedan av funktionen spool_read_header() med privilegierade rättigheter, vilket leder till en heap overflow.

Det är värt att notera att Exims utvecklare för närvarande har skapat en PoC för sårbarheten för att köra kommandon på en extern sårbar server, men den är för närvarande inte offentligt tillgänglig. På grund av enkelheten i att utnyttja buggen är det bara en tidsfråga, och ganska kort tid dessutom.

För mer detaljerad forskning från Qualys kan du läsa här.

Användning av SNI i TLS

Antal potentiellt sårbara offentliga servrar

Enligt statistik från en stor hostingleverantör E-Soft Inc den 1 september används version 4.92 på mer än 70 % av de hyrestjänster som finns.

Version
Antal servrar
Procent

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%

Andra versioner
25568
5.04%

Statistik från E-Soft Inc

Om man söker i sökmotorn Shodan, så av 5 250 000 i databasen av servrar:

• ungefär 3 500 000 använder Exim 4.92 (ungefär 1 380 000 med SSL/TLS);
• över 74 000 använder 4.92.1 (ungefär 25 000 med SSL/TLS).

Därför finns det cirka 1.5 miljoner.

Sökning av Exim-servrar i Shodan

Skydd

• Det enklaste, men inte rekommenderade alternativet är att inte använda TLS, vilket leder till att e-postmeddelanden skickas i klartext.
• Mer att föredra för att undvika utnyttjande av sårbarheten är att uppgradera till version Exim Internet Mailer 4.92.2.
• Om uppgradering eller installation av en patchad version inte är möjligt kan du ställa in ACL i Exim-konfigurationen för alternativet acl_smtp_mail med följande regler:

  # 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}}}}

Källa: habr.com