31.01.2014 | 13:40

Adam Haertle

Najgorszy w historii raport z testów penetracyjnych

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.

Co prawda w tej części sieci nie odnaleziono żadnych problemów, ale mogą one występować lub nie występować do momentu ich odkrycia.

Ktoś własnie odkrył podatność Schrödingera.

Skutki przeprowadzenia testu na tej bazie danych mogą mieć poważne skutki.

Zaleca się, aby odkryte błędy zostały usunięte zgodnie z priorytetami określonymi w raporcie.

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”.

Zakres zlecenia przewidywał testowanie w modelu „white box”. Testy DMZ zostały przeprowadzone w modelu „black box”.

Co prawda widzieliśmy zlecenie, ale postanowiliśmy je zignorować.

Wszystkie hasze haseł w aplikacji X zostały zidentyfikowane oraz złamane, ujawniając słabość zastosowanych mechanizmów kryptograficznych.

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?

Aplikacja Y podatna na atak XSS na stronie logowania. Kod odpowiedzialny za wystąpienie błędu został poprawiony w celu redukcji ryzyka w środowisku produkcyjnym.

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)

Zastosowanie NMAPa spowodowało awarię klastra Z. Po przywróceniu działania klastra przez klienta NMAP wielokrotnie powodował kolejne awarie, w związku z czym postanowiono zastosować Nessusa.

MySQL pozwala na połączenia z adresu 127.0.0.1. Rekomendujemy zmianę konfiguracji na zabraniającą zdalnych połączeń.

Rekomendacja, której zadaniem jest sprawdzenie, czy ktoś w ogóle czyta raport.

Microsoft IIS podatny na atak CVE-xxxxx. Rekomendujemy zastosowanie odpowiedniej łaty.

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.

Powrót

Komentarze

  • 2014.01.31 13:46 r

    „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.

    Odpowiedz
  • 2014.01.31 16:24 Frędzel

    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!

    Odpowiedz
  • 2014.01.31 18:23 Pendzel

    Dziękuje, poprawiliście mi humor ;D

    Odpowiedz
  • 2014.01.31 21:20 BGP Admin

    Przypomnialy mi sie czasy, gdy dzieciakom pretendujacym do miana hakerow polecalo sie atakowac adres 127.0.0.1. ;-)

    Odpowiedz
  • 2014.02.19 20:34 xyz

    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…

    Odpowiedz

Zostaw odpowiedź do BGP Admin

Jeśli chcesz zwrócić uwagę na literówkę lub inny błąd techniczny, zapraszamy do formularza kontaktowego. Reagujemy równie szybko.

Najgorszy w historii raport z testów penetracyjnych

Komentarze