Narzędzia automatyczne nie myślą, robią tylko to, do czego zostały napisane (oraz to, co kazał im robić ich operator). Korzystanie z narzędzi automatycznych nie zwalnia z myślenia.Trzeba zrozumieć co tak naprawdę sprawdza wykorzystywane narzędzie i co mówią otrzymane wyniki. Bez tego wnioski, komentarze i zalecenia wynikające z rezultatów pracy narzędzia mogą być... dziwne.
Dać małpie brzytwę czyli o co chodzi w tych wynikach
Dla przykładu proponuję zacząć od lektury artykułu Jak ufać podatnej na atak bankowości online? Czyli znów o cache poisoning w .PL. Drugim krokiem powinno być zapoznanie się ze szczegółami ataku na bank Bradesco, na przykład po to, by dowiedzieć się, że zaatakowany serwer DNS należał nie do banku, a do ISP (na przykład tu: Cache-poisoning attack snares top Brazilian bank, choć szczegółów technicznych jest dość niewiele). Czyli przez analogię testom powinny zostać poddane serwery DNS używane przez działających w Polsce ISP, przynajmniej tych największych.
Protokół DNS nie jest protokołem bezpiecznym, być może w końcu zostanie zastąpiony przez DNSSEC. Na razie jednak potencjał cache poisoningu jest spory, można go wykonać w wielu miejscach. W zasadzie jedynym zabezpieczeniem przed nim są dwa szesnastobitowe pola - port źródłowy oraz identyfikator transakcji. Teoretycznie daje to dość dużo możliwości, bo 65536^2, ale różne słabości w wyborze portu źródłowego oraz podczas generowania identyfikatora transakcji powodowały, że atak cache poisoning jest/był w rzeczywistości dużo prostszy do przeprowadzenia. O ostatnio (2008 rok) głośnym problemem można poczytać ze szczegółami tu: An Illustrated Guide to the Kaminsky DNS Vulnerability, w szczególności w sekcji Dan's Shenanigans.
W "testach" opisanych w artykule posłużono się narzędziem Cross-Pollination Check, które sprawdza autorytatywne serwery nazw czy:
- pozwalają na zapytania rekursywne,
- czy porty źródłowe wybierane są w sposób losowy,
Status Vulnerable otrzymują te serwery, na których dostępna są zapytania rekursywne, status Highly vulnerable te, które dodatkowo nie stosują randomizacji portów źródłowych. Tylko, że idąc tym tropem wszystkie serwery typu dns cache powinny również uzyskać status vulnerable.
Rozdzielenie serwerów autorytatywnych i tych pełniących rolę cache (obsługujących klientów) jest dobrą (prawidłową) praktyką, taki model jest stosowany przymusowo w djbdns poprzez rozdzielenie tych funkcji między dnscache i tinydns. Łączenie tych funkcji można uznać za błąd konfiguracyjny (nieprzestrzeganie zasad dobrej praktyki), jednak z przesłaniem wynikającym z artykułu, że rekursja na serwerze autorytatywnym oznacza wprost cache poisoning i sam fakt jej istnienia naraża klientów banku na jakieś wielkie ryzyko, zgodzić się nie można.
Powtarzam: DNS nie jest bezpiecznym protokołem, nigdy nie można ufać, że otrzymany adres IP jest adresem IP "prawdziwego" serwera. Klienci "pochwalonych" w tym artykule banków wcale nie powinni czuć się bezpiecznie i wierzyć, że skoro jakieś narzędzie pokazało ich bank "na zielono" to automatycznie nie mogą się oni stać ofiarami ataku cache poisoning. Mogą.
Przykład: jestem klientem banku fajnybank.pl i chcę skorzystać z jego serwisu. W przeglądarce wpisuję więc jego adres: https://fajnybank.pl. Przeglądarka chce się dowiedzieć z jakim adresem IP powinna się połączyć, mój system wysyła więc zapytanie o adres IP dla fajnybank.pl do mojego serwera DNS (dns cache). Atakujący może przesłać do mnie sfałszowaną odpowiedź i nawet może mu się to udać. Jeśli atakujący ma wgląd w ruch sieciowy, szanse powodzenia takiego ataku są naprawdę spore - proponuję bliższe zapoznanie się z narzędziem Cain & Abel. Moje zapytanie trafia do serwera, który w celu udzielenia mi odpowiedzi, również musi wysłać zapytanie "gdzieś dalej". Odpowiedź na to zapytanie może zostać sfałszowana, w związku z czym do mnie trafi nieprawidłowy adres IP (właściwie cache poisoning wykonywany jest wcześniej by fałszywy adres IP znajdował się już w cache serwera). Znów szanse powodzenia tego ataku zależą od tego, czy atakujący zna prawidłowe wartości portu źródłowego i identyfikatora transakcji, czy musi je zgadnąć. Jeśli je zna, to w zasadzie jest już po zabawie, jeśli natomiast musi zgadnąć to prawdopodobieństwo sukcesu zależy od losowości identyfikatorów transakcji i portów źródłowych. I tak tym łańcuszkiem podążamy dalej aż do tego serwera NS banku, który jest vulnerable, ale w praktyce atak na niego/za jego pośrednictwem wcale nie jest łatwiejszy, niż w dowolnym miejscu opisanego łańcuszka.
Wniosek: jako klient nie mogę być pewny, że po wpisaniu adresu https://fajnybank.pl trafiłem rzeczywiście na stronę, na którą chciałem trafić, a konfiguracja serwera DNS owego banku ma tu w zasadzie pomijalne znaczenie. Klienci otrzymują inną możliwość weryfikacji autentyczności serwera WWW - certyfikat serwera. Oczywiście certyfikat serwera jest dostępny tylko wówczas, gdy dostępny jest SSL (https). W przypadku systemów bankowości internetowej jest to standard, w wielu innych przypadkach niestety nie.
A o co chodzi z małpą i brzytwą? Na wyniki narzędzi automatycznych trzeba popatrzeć krytycznym okiem, zweryfikować je. Nawet we wspominanym przeze mnie wcześniej OWASP Application Security Verification Standard dla Automated Verification (narzędzia automatyczne) wymagana jest weryfikacja rezultatów. Bez weryfikacji może się okazać na przykład, że na Solarisie zainstalowany jest stary Exchange (typowy błąd Nessusa) albo inne, temu podobne kwiatki. Może się również okazać, że ryzyko związane z daną podatnością zostanie nieprawidłowo wycenione, przez co klient, opierając się na rezultatach narzędzia "wiodącego dostawcy", będzie za duże pieniądze rozwiązywał nie ten problem.
Swoją drogą trzeba sobie uświadomić, że szeroko pojęty Internet opiera się na protokołach stworzonych wiele lat temu, przy których projektowaniu kwestie bezpieczeństwa nie były uwzględnione wystarczająco, a i zmiana stanu wiedzy czy zwiększenie się wydajności pospolitych komputerów powoduje, że kiedyś jedynie teoretycznie rozważane ataki, stają się codziennością. Trochę dziwi mnie to, że "nowe" wchodzi tak przeraźliwie wolno, choć logistyka potrzebna do realizacji takich zmian jest spora.
PS
Będziesz może na OWASP/CONFidence?