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ź do CSO

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