Zdalne wykonanie kodu przez fail2ban

W tym artykule omówimy niedawno opublikowaną podatność w całkiem popularnym oprogramowaniu – fail2ban (CVE-2021-32749). Przy odpowiednich warunkach ten błąd można by wykorzystać, aby masowo osiągnąć wykonanie kodu z uprawnieniami roota, jednak jest to trudne do osiągnięcia przez “zwykłego” napastnika. Korzenie tej podatności wynikają ze sposobu działania komendy mail z pakietu mailutils i przyznam szczerze – trafiłem na to przez totalny przypadek! 

fail2ban analizuje logi (lub inne źródła danych) w poszukiwaniu prób ataków typu brute-force, a w razie ich wykrycia, blokuje źródłowe adresy IP. Istnieje szereg reguł dla konkretnych usług (SSH, SMTP, HTTP, itd). Istnieją także konkretne akcje, które mają być wykonane po wykryciu ataku – jedną z nich jest wysłanie maila do administratora z powiadomieniem, że dany adres IP został zablokowany. Jeżeli poszukamy w Internecie sposobu, żeby wysłać maila z linii komend możemy często trafić na takie rozwiązanie:

$ echo "test e-mail" | mail -s "subject" user@example.org

Dokładnie w taki sposób zdefiniowana jest akcja wysłania maila w fail2ban – poniżej fragment pliku ./config/action.d/mail-whois.conf:

actionban = printf %%b "Hi,\n
            The IP <ip> has just been banned by Fail2Ban after
            <failures> attempts against <name>.\n\n
            Here is more information about <ip> :\n
            `%(_whois_command)s`\n
            Regards,\n
            Fail2Ban"|mail -s "[Fail2Ban] <name>: banned <ip> from <fq-hostname>" <dest>

W powyższym fragmencie nie ma nic podejrzanego, co mogłoby zwrócić naszą uwagę. Jednak jeżeli spojrzymy na dokumentację mailutils możemy trafić na informacje na temat tzw. tilde escape sequences: 

The ‘~!’ escape executes specified command and returns you to mail compose mode without altering your message. When used without arguments, it starts your login shell. The ‘~|’ escape pipes the message composed so far through the given shell command and replaces the message with the output the command produced. If the command produced no output, mail assumes that something went wrong and retains the old contents of your message.

Oto powyższe w akcji: 

jz@fail2ban:~$ cat -n pwn.txt
 	1  Next line will execute command :)
 	2  ~! uname -a
 	3
 	4  Best,
 	5  JZ
jz@fail2ban:~$ cat pwn.txt | mail -s "whatever" whatever@whatever.com
Linux fail2ban 4.19.0-16-cloud-amd64 #1 SMP Debian 4.19.181-1 (2021-03-19) x86_64 GNU/Linux
jz@fail2ban:~$

Jeżeli spojrzymy ponownie w definicje akcji w fail2ban, możemy zauważyć, że do maila dołączany jest wynik komendy whois. Jeżeli atakujący byłby w stanie dodać tilde escape sequence jako część odpowiedzi whois dla wybranego przez siebie adresu IP – po wysłaniu maila do administratora skończyłoby się to wykonaniem kodu – najpewniej jako administrator (root). 

Jakie są nasze opcje z perspektywy atakujących?

Pierwsze, co przyszło mi do głowy to próba zapytania mojego ISP, aby skontaktował się z RIPE i dodał po prostu konkretny wpis dla mojego adresu IP ;-) Niestety – to tak nie działa. RIPE/ARIAN/APNIC oraz inni modyfikują wpisy dla całych klas adresów IP. Dodatkowo, mało prawdopodobne żeby ktokolwiek wyraził zgodę na dodanie jakiegoś podejrzanego ciągu znaków do odpowiedzi WHOIS bez zadawania pytań.

Może w takim razie opcją byłoby uruchomienie własnego serwera WHOIS? O dziwo – jest taka możliwość i można się natknąć na kilka “prywatnych” serwerów WHOIS. Wszystko dzięki mechanizmowi, który zostało dokładniej opisany w RFC: mianowicie, jeżeli w odpowiedzi WHOIS znajdziemy atrybut ReferralServer, klient spróbuje połączyć się z serwerem ustawionym jako wartość tego atrybutu. Przykładowe działanie możemy zauważyć weryfikując odpowiedź WHOIS dla adresu IP 157.5.7.5:

$ whois 157.5.7.5

#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/resources/registry/whois/tou/
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/resources/registry/whois/inaccuracy_reporting/
#
# Copyright 1997-2021, American Registry for Internet Numbers, Ltd.
#


NetRange:       157.1.0.0 - 157.14.255.255
CIDR:           157.4.0.0/14, 157.14.0.0/16, 157.1.0.0/16, 157.12.0.0/15, 157.2.0.0/15, 157.8.0.0/14
NetName:        APNIC-ERX-157-1-0-0
NetHandle:      NET-157-1-0-0-1
Parent:         NET157 (NET-157-0-0-0-0)
NetType:        Early Registrations, Transferred to APNIC
OriginAS:
Organization:   Asia Pacific Network Information Centre (APNIC)

[… cut …]

ReferralServer:  whois://whois.apnic.net
ResourceLink:  http://wq.apnic.net/whois-search/static/search.html

OrgTechHandle: AWC12-ARIN
OrgTechName:   APNIC Whois Contact
OrgTechPhone:  +61 7 3858 3188
OrgTechEmail:  search-apnic-not-arin@apnic.net

[… cut …]

Found a referral to whois.apnic.net.

% [whois.apnic.net]
% Whois data copyright terms    http://www.apnic.net/db/dbcopyright.html

% Information related to '157.0.0.0 - 157.255.255.255'

% Abuse contact for '157.0.0.0 - 157.255.255.255' is 'helpdesk@apnic.net'

inetnum:        157.0.0.0 - 157.255.255.255
netname:        ERX-NETBLOCK
descr:          Early registration addresses

[… cut …]

Teoretycznie więc gdybyśmy byli posiadaczami wystarczająco dużej sieci – można by spróbować poprosić naszego Regional Internet Registries o dodanie stosownego wpisu. Następnie z poziomu własnego serwera RWhois możemy dowolnie kontrolować wysyłane odpowiedzi. 

Jednak z drugiej strony – dość łatwo wyobrazić sobie scenariusz, w którym atakujący / black hat – po prostu kompromituje sieć lub serwer, na którym uruchomiona jest usługa RWHOIS, a następnie przeprowadza atak właśnie z tej sieci. Wydaje się to być zadanie łatwiejsze i tańsze niż przekształcenie się w na tyle dużą firmę, aby legalnie uruchomić własny, działający serwer whois. 

Oczywiście możesz być też rządem dużego kraju i najzwyczajniej w świecie kontrolować ruch sieciowy tego kraju. Jeżeli przyjrzymy się dokładnie protokołowi WHOIS możemy zauważyć kilka rzeczy:

• to szalenie stary protokół (początki sięgają roku 1977)
• bardzo prosty w implementacji (pytanie/odpowiedź)
• absolutnie nieszyfrowany ;)

Biorąc pod uwagę powyższe – poprzez przeprowadzenie ataku typu MITM na tym nieszyfrowanym protokole – atakujący (w tym wypadku – rząd) mógłby po prostu umieścić stosowny, złośliwy ciąg znaków w odpowiedziach. 

To o czym warto pamiętać, to że problem nie tyle dotyczy samego fail2ban, ale mailutils – gdzie wspomniana funkcjonalność nie jest błędem, a zaplanowanym sposobem działania. Warto zacząć zwracać uwagę na własne, autorskie skrypty, które wykorzystują komendę mail oraz na inne oprogramowanie, które również mogłoby okazać się podatne. 

Historia pokazała wielokrotnie, że bezpieczeństwo jest trudne oraz złożone. Czasami niewinna, z pozoru niegroźna funkcjonalność może okazać się sporym zagrożeniem.

— Jakub Żoczek – haker w Securitum