13.09.2017 | 06:30

Adam Haertle

Testy penetracyjne aplikacji WWW – przykład ciekawego raportu

Choć na świecie codziennie przeprowadzane pewnie są dziesiątki, jak nie setki pentestów, to raporty z nich lądują najczęściej w zamkniętych szufladach, by nie ujrzeć nigdy światła dziennego. Na szczęście czasem można je jednak poczytać.

Firma Securitum opublikowała własnie pełny raport z testów bezpieczeństwa rozbudowanej aplikacji WWW – systemu CRM YetiForce. Warto tutaj podziękować klientowi za zgodę na publikację – mało kto decyduje się na taką transparentność, najczęściej chcąc zataić popełnione błędy. Można także podziękować firmie Securitum, która przeprowadza audyty bezpieczeństwa, za udostępnienie wyników prac. Spójrzmy zatem, co w raporcie można znaleźć – bo jest kilka ciekawostek (wszystkie błędy zostały usunięte).

Najciekawsze odkrycia

Zacznijmy od ważnej informacji – w raporcie znaleźć możemy informację, że zakres prac ograniczony był do siedmiu pentesterskich dniówek, zatem istnieje możliwość, że dłuższe poszukiwania mogły przynieść więcej rezultatów. Niemniej błędów znalezionych w aplikacji nie brakuje.

Najciekawszym, bo dającym zalogowanemu użytkownikowi z prawem wgrywania plików możliwość zdalnego wykonania kodu, jest błąd w mechanizmach importu danych. Po pierwsze, aplikacja umożliwia przesłanie w ramach archiwum ZIP plików PHP. Po drugie, rozpakowuje je do katalogu o przewidywalnej nazwie. Po trzecie, katalog ten dostępny jest dla użytkownika. Pozwala to na wgranie dowolnego pliku PHP i wykonanie go na serwerze, czyli oddanie atakującemu kontroli nad tym, co stanie się na maszynie. Co więcej, dzięki brakowi kontroli nad ścieżką zawartą w pliku ZIP, możliwe było wgranie pliku do dowolnego katalogu serwera dostępnego dla serwera WWW. Warto przeczytać szczegółowy opis błędu i sprawdzić swoje aplikacje pod kątem tej podatności.

Drugim ciekawym sposobem zdalnego uruchomienia kodu odkrytym przez załogę Securitum okazała się funkcja połączenia skrzynki poczty elektronicznej z kontem w aplikacji. Możliwość wysłania wiadomości z kodem HTML (a przy okazji JavaScript) połączona z przewidywalną ścieżką zapisywania załączników wiadomości na serwerze dała zdalne wykonanie kodu przesłanego w załączniku i wywołanego z poziomu emaila. Dzięki błędowi XSS możliwe okazało się uruchomienie złośliwego kodu po kliknięciu w wiadomość przez użytkownika – metoda ta może okazać się przydatna, gdy serwer aplikacji znajduje się w sieci lokalnej. Gdy jest dostępny publicznie, to można po prostu odwołać się do przewidywalnej ścieżki, w której został zapisany załącznik.

Fragment raportu

W raporcie znajdziecie także opis wielu błędów XSS, błąd SQLi (dostępny dla zalogowanego użytkownika z dostępem do konkretnego modułu), możliwość ataków MiTM na zewnętrzne zasoby aplikacji oraz dwie metody ominięcia zabezpieczenia przed atakami typu brute force w panelu logowania (w tym jeden przez manipulację strefą czasową – bardzo ciekawe).

Wymiar edukacyjny

Oprócz opisu błędów w raporcie znajdziecie także dokładne instrukcje, jak błędy usunąć (oraz historię tego, jak autorzy błędy usunąć próbowali, czasem w kilku iteracjach). Oprócz tego Securitum udostępniło maszynę wirtualną z podatną wersją systemu, by każdy mógł sam podobny test przeprowadzić. Instrukcja instalacji wygląda tak:

mkdir yetipentest
cd yetipentest
wget https://www.sekurak.pl/vagrant/yeti/Vagrantfile
vagrant up
curl 127.0.0.1:8080

Dla pełnej przejrzystości – za publikację tego artykułu pobieramy wynagrodzenie.

Powrót

Komentarze

  • 2017.09.13 14:30 skirge

    Czy czas trwania pentestów (7 dni) jest wystarczający? Wydawało mi się, że może wystarcza to dla wyjątkowo prostych aplikacji.

    Odpowiedz
    • 2017.09.14 13:08 Michał Sajdak

      Czy tyle dni wystarcza? Raczej do pełnych testów nie, ale ćwiczenie było dokładnie takie jak opisane w raporcie – czyli znaleźć tyle grubych rzeczy, ile się da – przez maksymaklnie 7 osobodni, łącznie ze spisaniem całości.

      A wynik może posłużyć do decyzji co dalej – czy kontynuować testy, a może jeśli nic by się nie znalazło to nie ma sensu?

      Odpowiedz
    • 2017.09.14 14:18 xylaz

      To zdecydowanie za mało.

      Odpowiedz
    • 2017.09.16 00:17 CSO

      Kolego musisz rozróżnić dwa terminy… dni robocze i tzw. MD… 7 dni to jest całkiem dużo jeśli aplikację testuje kilka osób, zwykle starczą 2-3… wtedy jeśli te 3 osoby pomnożysz przez 7 dni wyjdzie ci aż 21 dni jakie musiałaby poświęcić 1 osoba

      Odpowiedz
    • 2017.09.25 11:36 Piotr

      Pracuje jako pentester i 7 dni to bardzo duzo na web applikacje, zwykle to jakies 3 do 4 dni maks. Przy legalnych testach mozesz byc 'bardzo glosny’ wiec nie musisz sie czajic by haxowac.

      Odpowiedz
  • 2017.09.13 16:00 Tomek

    A ja bylem przekonany ze firmy pracujace w tej samej branzy nie placa sobie za reklamowanie konkurencji, jak to jest Z3S?

    Odpowiedz
    • 2017.09.14 09:14 Robert

      Jedna wielka rodzina, a nie konkurenci ;)

      Odpowiedz
      • 2017.09.14 13:50 Tomek

        Dokladnie tak jest / powinno byc. Po co robic sobie wrogow w 'rodzinie’ jak to tylko utrudnia zycie. ;)

        Odpowiedz
  • 2017.09.14 08:01 Fan

    Sekurak jak zwykle na poziomie. :)

    Odpowiedz
  • 2017.09.15 03:00 laksdkasjd

    na tegorocznych SCSach mozna bylo 'spotkac’ oba teamy (z3s i sekuraki). warto bylo odwiedzic i prezentacje i expo. po raz kolejny rewelacyjna robota. dziekuje.

    Odpowiedz

Zostaw odpowiedź

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

Testy penetracyjne aplikacji WWW – przykład ciekawego raportu

Komentarze