Prowadzenie testów penetracyjnych jest trudnym zadaniem a napisanie raportu z ich przebiegu nie jest łatwiejsze. Kiedy jednak otrzymujemy raport podobny do opisanego poniżej, to nie wiadomo, czy śmiać się, czy płakać. A może śmiać przez łzy?
Pewna amerykańska firma miała obowiązek co roku zamawiać testy penetracyjne u innego dostawcy. Najwyraźniej analiza ofert nie była wystarczająco dokładna, ponieważ to, co otrzymali w wyniku przeprowadzonych prac, woła o pomstę do nieba. Polecamy lekturę angielskiego oryginału, a my postaramy się przetłumaczyć najlepiej, jak potrafimy.
Szef pentesterów pracuje z Indii
Z tajemniczego powodu szef wynajętego zespołu pentesterów nie mógł dotrzeć do USA i prowadził projekt zdalnie. Osoby, wykonujące zadania na miejscu, przeprowadziły swoje prace, a przez cały czas trwania projektu szef z Indii nawet nie wdzwonił się na żadne spotkanie. Swój talent objawił dopiero w raporcie końcowym.
Raport miał trzy sekcje – dwie dość standardowe, czyli podsumowanie dla kierownictwa oraz szczegółową listę odkrytych problemów oraz część trzecią, czyli ofertę cenową załatania wykrytych błędów. Może nie znamy tak dobrze standardów rynkowych, ale ten trzeci rozdział wydaje się być nie na miejscu.
Podsumowanie dla kierownictwa było kolejnym sygnałem, ze coś jest nie tak. Sprawiało wrażenie, jakby było zlepkiem róznych dokumentów:
- pojawiała się nazwa innego klienta,
- pisane było na zmianę w pierwszej i trzeciej osobie,
- wymieniało błędy, które nie pojawiły się w drugim rozdziale,
- paragrafy napisane były rożnymi czcionkami.
To było jednak dopiero preludium do właściwego dzieła.
Najlepsze z najlepszych
Poniżej znajdziecie najciekawsze cytaty z głównej części raportu.
Ktoś własnie odkrył podatność Schrödingera.
…
Twierdzenia ma sens, jednak wszystkie problemy opisane w raporcie posiadają priorytet „wysoki”. Łącznie z „serwer FTP działa na porcie 21” z rekomendacją „Należy przenieść usługę na port 2121”.
Co prawda widzieliśmy zlecenie, ale postanowiliśmy je zignorować.
Mogło to być ciekawe odkrycie, gdyby nie fakt, że według notatek testera z załącznika do raportu aplikacja X przechowuje hasła otwartym tekstem. Czy to oznacza, że hasła zostały zahaszowane a następnie złamane przez testera?
Pentester poprawia samodzielnie kod w środowisku produkcyjnym klienta w celu REDUKCJI ryzyka? (okazało się, że to zwykłe kłamstwo a nie nadużycie, nikt nie modyfikował kodu)
…
Rekomendacja, której zadaniem jest sprawdzenie, czy ktoś w ogóle czyta raport.
Wszystko OK, tylko ten serwer działa pod kontrolą RHEL 5.x. Jak oni tam IISa uruchomili…
Na deser jeszcze dwie przykładowe pozycje z „cennika naprawy”:
- Załatanie podatności IIS CVE-xxxxx $500 (1 serwer)
- Skonfigurowanie bezpiecznych ustawień PHP.INI $390 (1 serwer)
Wasze przykłady
Oczywiście nie wierzymy, że powyższe to najlepsze cytaty, na jakie można było trafić – bez wątpienia widzieliście coś podobnego w innych raportach. Zapraszamy zatem do podzielenia się w komentarzach.
Komentarze
„Audytor” odpalił Acunetixa i przepisał jego znaleziska do swojego raportu. Pomijając fakt, że w dwóch różncy webserwisach na tym samym serwerze potrafił jednocześnie znaleźć i nie znaleźć jakiegoś wydumanego błędu ściśle związanego z wersją serwera, to najlepszy był zaraportowany jako krytyczny w finalnym raporcie błąd blind SQLi. W parametrze nagłówka HTTP. W ścieżce http://server.pl/nazwafolderu/images/. Które to wywołanie odpowiadało 403.
Trzeba koniecznie zeswatać rzeczonych pentesterów z Hakin9, na pewno zaczną współpracować. Mają podobne podejscie :D Aż się chce przytrollowować :D Pozdro dla Redaktora za kawał dobrej roboty!
Dziękuje, poprawiliście mi humor ;D
Przypomnialy mi sie czasy, gdy dzieciakom pretendujacym do miana hakerow polecalo sie atakowac adres 127.0.0.1. ;-)
Mnie kiedyś wkurzyli pacjenci którzy w raporcie podali numerki wersji z bannerów różnych usług wraz z teoretycznie występującymi podatnościami – zapominając o tym, że Debian backportuje łatki security nie zmieniając numeru wersji…