Przepatchowano Exim – przepatchuj jeszcze raz. Nowe zdalne wykonanie polecenia w Exim 4.92 w jednym żądaniu

Niedawno, na początku lata, zaczęły się masowe wezwania do aktualizacji Exim do wersji 4.92 z powodu luki CVE-2019-10149 (Pilnie aktualizuj exim do 4.92 — trwa aktywne zarażenie / Habr). A kilka dni temu okazało się, że złośliwe oprogramowanie Sustes postanowiło wykorzystać tę lukę.

Teraz wszyscy, którzy nagle zaktualizowali, mogą znów "cieszyć się": 21 lipca 2019 r. badacz Zerons odkrył krytyczną lukę w Exim Mail Transfer agent (MTA) przy użyciu TLS dla wersji od 4.80 do 4.92.1 włącznie, pozwalającą na zdalne wykonywanie kodu z uprawnieniami administratora. (CVE-2019-15846).

Luka

Luka występuje przy użyciu zarówno bibliotek GnuTLS, jak i OpenSSL podczas nawiązywania zabezpieczonego połączenia TLS.

Według słów dewelopera Heiko Schlittermanna, plik konfiguracyjny w Exim domyślnie nie korzysta z TLS, jednak wiele dystrybucji podczas instalacji tworzy niezbędne certyfikaty i włącza zabezpieczone połączenie. Ponadto nowsze wersje Exim ustalają opcję tls_advertise_hosts=* i generują niezbędne certyfikaty.

zależy od konfiguracji. Większość dystrybucji włącza to domyślnie, ale Exim potrzebuje certyfikatu + klucza, aby działać jako serwer TLS. Prawdopodobnie dystrybucje tworzą certyfikat podczas instalacji. Nowsze wersje Exim mają opcję tls_advertise_hosts domyślnie ustawioną na «*» i tworzą certyfikat samopodpisany, jeśli żaden nie jest dostarczony.

Sama luka polega na niepoprawnym przetwarzaniu SNI (Server Name Indication, technologia wprowadzona w 2003 roku w RFC 3546, umożliwiająca klientowi żądanie poprawnego certyfikatu dla nazwy domeny, Rozprzestrzenianie standardu TLS SNI / Blog firmy WEBO Group / Habr) podczas handshake TLS. Atakującemu wystarczy wysłać SNI kończące się znakiem backslash („”) i znakiem null („”).

Badacze z firmy Qualys odkryli błąd w funkcji string_printing(tls_in.sni), który polega na niepoprawnym escape'owaniu „”. W rezultacie zapisuje się znak backslash w nieescape'owanej formie w pliku nagłówków print spool. Następnie ten plik z uprawnieniami administratora jest odczytywany przez funkcję spool_read_header(), co prowadzi do przekroczenia bufora (heap overflow).

Warto zauważyć, że w tej chwili deweloperzy Exim stworzyli PoC luki z wykonaniem poleceń na zdalnym, podatnym serwerze, ale publicznie nie jest ona jeszcze dostępna. Z powodu prostoty wykorzystania błędu to tylko kwestia czasu, a ponadto wcale nie długiego.

Szczegółowe badania firmy Qualys można znaleźć tutaj.

użycie SNI w TLS

Liczba potencjalnie podatnych publicznych serwerów

Według statystyk dużego dostawcy hostingu E-Soft Inc na 1 września, na wynajmowanych serwerach wersja 4.92 jest używana w ponad 70% hostów.

Wersja
Liczba serwerów
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%

Inne wersje
25568
5.04%

Statystyki firmy E-Soft Inc

Jeżeli zwrócisz się do wyszukiwarki Shodan, spośród 5 250 000 serwerów w bazie:

• około 3 500 000 używa Exim 4.92 (około 1 380 000 z wykorzystaniem SSL/TLS);
• ponad 74 000 używa 4.92.1 (około 25 000 z wykorzystaniem SSL/TLS).

W ten sposób, publicznie znanych i dostępnych potencjalnie podatnych serwerów Exim jest około 1,5 mln.

Wyszukiwanie serwerów Exim w Shodan

Ochrona

• Najprostszą, ale niezalecaną opcją jest nieużywanie TLS, co prowadzi do przesyłania wiadomości e-mail w otwartym formacie.
• Bardziej preferowanym rozwiązaniem, aby uniknąć wykorzystania luki, będzie aktualizacja do wersji Exim Internet Mailer 4.92.2.
• W przypadku braku możliwości aktualizacji lub zainstalowania wersji z poprawkami, można ustawić ACL w konfiguracji Exim dla opcji acl_smtp_mail z następującymi zasadami:

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

Źródło: habr.com