Przykładowy raport z rzeczywistego testu penetracyjnego

W ramach swojej pracy magisterskiej miałem okazję przeprowadzić pełny test penetracyjny komercyjnej aplikacji webowej napisanej z użyciem ASP.NET. Wynikiem moich badań jest raport, którym postanowiłem podzielić się w „zaciemnionej” formie z szerszym gronem osób. Materiały tego typu w naszym ojczystym języku są towarem deficytowym. W zasadzie jedyny, który znam z tych dostępnych publicznie pochodzi od ekipy sekuraka – SEKURAK
Sam również zdecydowanie wolę pisać raporty w języku angielskim, z powodu fachowego nazewnictwa i problemów związanych z jego tłumaczeniem.

Aplikacja testowana była z użyciem dwóch ról o różnych uprawnieniach – klasycznego administratora i zwykłego użytkownika. W aplikacji wykryto podatności pozwalające między innymi na:
• Przejęcie kontroli nad serwerem;
• Przejęcie kontroli nad dowolnym kontem użytkownika;
• Odczyt wrażliwych danych użytkowników;
• Wykorzystanie aplikacji do przeprowadzania ataków phishingowych;

wykryte podatności

Oprócz klasycznego shella zdobytego za pomocą wykorzystania luki polegającej na braku walidacji przesyłanych plików do serwera, szczególną „sympatią” darzę błąd związany z mechanizmem resetu hasła użytkowników. Aplikacja generowała token zabezpieczający, którego poprawność nie była weryfikowana na późniejszym etapie tegoż procesu po stronie serwera. Skutkowało to możliwością zresetowania hasła dowolnego użytkownika i tym samym przejęciem jego konta.

Pełny raport do pobrania pod poniższym linkiem RAPORT

Chcesz wiedzieć więcej?

Zapisz się i bądź informowany o nowych postach (zero spamu!).
Dodatkowo otrzymasz, moją prywatną listę 15 najbardziej przydatnych narzędzi (wraz z krótkim opisem), których używam przy testach penetracyjnych.

Nigdy nie podam, nie wymienię ani nie sprzedam Twojego adresu e-mail. W każdej chwili możesz zrezygnować z subskrypcji.

Otagowano , , , , , , , , , , , , , , , , , , .Dodaj do zakładek Link.

10 odpowiedzi na „Przykładowy raport z rzeczywistego testu penetracyjnego

  1. gregor komentarz:

    Fajny raport. Jednak w punkcie 3.2.4 w czerwonej ramce jest z tego co widzę [cut]

  2. k4 komentarz:

    Jak rozumiecie „zagrożenie” opisane w tym raporcie? Jako coś tożsamego z ryzykiem?

    • Michał Kędzior komentarz:

      Ciekawe pytanie. Rzeczywiście używanie nomenklatury typu „wpływ podatności” albo „krytyczność podatności” byłaby bardziej adekwatna. Dla mnie ryzyko jest już czymś głębszym, wymagającym często wiedzy na przykład na temat kontekstu biznesowego. Swoje „znaleziska” staram się oceniać bardziej pod kątem technicznym. Nie raz spotkałem się z sytuacją gdy „właściciel aplikacji” albo ktoś ala „security officer” obniżał lub podwyższał ocenę danej podatności posiadając szerszy obraz sytuacji. Ważnym zaznaczenia jest aby widzieć różnicę pomiędzy testami penetracyjnymi a oceną ryzyka czy też audytami. Audytor pyta – „czy mają państwo backupy?”, pentester natomiast informuje – „mamy wasze backupy” ????.

  3. k4 komentarz:

    BTW. Zastanawiałeś się dlaczego np. Facebook ustawia w nagłówkach HTTP pole XSS-Protection na 0 ? 🙂

    W kontekście tego czy dalej uważasz że takie powinny być zgłaszane w raporatch? 🙂

    • Michał Kędzior komentarz:

      Wiem dlaczego to robią. Ja jednak spotkałem się jedynie z sytuacjami, gdy ten nagłówek w jakiś sposób uniemożliwiał lub utrudniał atak, a nie go ułatwiał. Jest to jedynie dodatek, a nie jedyna linia obrony. Jeżeli nie ma przeciwwskazań to zalecam jego wartość ustawiać na 1. Pewnie sam spotkałeś się z sytuacją gdzie błędy bezpieczeństwa naprawia się jedynie WAFem 😉

  4. pentest komentarz:

    Cześć, przejrzałem Twój raport i mam kilka uwag.
    1.1 – „Przesyłanie dowolnego pliku na serwer” nie zawsze daje możliwość uploadu bezpośrednio do webroota, czy też wykonania uploadowanego kodu przez serwer – w Twoim przypadku daje, co prowadzi do zdalnego wykonania kodu i właśnie w taki nagłówek bym celował. Podatność dotyczy możliwości wykonania własnego kodu na serwerze poprzez upload pliku.
    1.2, 1.3 – brak spójności oszacowania zagrożenia. Stored XSS oznaczasz jako krytyczny, bo pozwala na „wykradniecie sesji”, z kolei vuln pozwalający na przejęcie dowolnego konta – jako wysoki. Btw, czy zweryfikowałeś, czy rzeczywiście XSS jest w stanie wykraść cookie sesyjne? Jeśli tak, dlaczego brak httpOnly nie zostało osobno zaznaczone w raporcie? W tym przypadku nie zgodzę się, że Stored jest bardziej niebezpieczny od Reflected – bo payload ustawiany jest przez konto admina. To nie jest scenariusz, w którym użytkownik wprowadza payload (stored), a następnie wykonuje się on na koncie admina – tutaj nadal musisz zmusić administratora do interakcji (chociażby przez CSRF), aby ten payload sam sobie ustawił.
    2.2 – Oprócz CSRF, podatna jest również sama funkcjonalność formularza resetu hasła, jeśli nie wymaga on wprowadzenia starego hasła.
    3.4 – leakowanie wersji oprogramowania w headerach to zupełnie inna klasa podatności niż „przewidywalne nazwy pozwalające na” enumerowanie faktur. To drugie to błąd logiczny – z dużo większym stopniem zagrożenia (i powinien zostać zaraportowany jako osobna podatność).
    4.1 – czy aplikacja posiada miejsce, w którym ten nagłówek będzie istotny, np. miejsce, w którym atakujący kontroluje zawartość, ale Content-Type nie pozwala na XSS’a? Jeśli nie, przeniósłbym to do działu „dodatowe informacje i rekomendacje”
    4.2 – jw., z czego bardziej istotnym mechanizmem bezpieczeństwa jest brak request validation (zakładam, ze go nie ma, skoro udało się wykonać xssa). Poza tym wpis wprowadza w błąd – bo nie każda przeglądarka respektuje ten nagłówek (np. Firefox). Juz lepszym rozwiązaniem byłaby rekomendacja poprawnej polityki CSP.
    4.3 – tutaj po numerze portu (8172) + poprzednim wpisie o braku HTTPS widze, że wyskoczyłeś poza zakres testu aplikacji webowej. + BEAST jest już często pomijany (wyguglaj artykuł is BEAST still a threat)
    5.1 – tutaj znowu wyskoczyłeś poza zakres testując infrastrukturę

    Widzę równiez, ze w zakresie testów znajdowały się dwie role: user i admin, z czego większość podatności zgłoszonych zostało z konta administratora – co również (w niewielkim stopniu) obniża krytyczność zagrożenia (i powinno zostać odnotowane przy szacowaniu krytyczności podatności).

    • Michał Kędzior komentarz:

      Cześć, dziękuję za obszerny i wartościowy komentarz. Spróbuję odnieść się merytorycznie do Twoich uwag.

      1.1 To o czym mówisz jest następstwem opisanej podatności. W przypadku gdy nie byłoby możliwości za jej pomocą wykonania kodu – po prostu zostałby obniżony rating. Wyobraź sobie sytuację gdy za pomocą mechanizmu uploadu pliku służącego do obrazków, wrzucasz na serwer plik excela z malwarem. Więcej do poczytania na ten temat tutaj – https://www.owasp.org/index.php/Unrestricted_File_Upload
      1.2, 1.3 W przypadku XSSa nagłówek HTTPOnly nie chroni użytkownika w 100% przed skradzeniem sesji. Niemniej wykradzenie sesji użytkownika to jedynie jeden z wielu scenariuszy do czego można użyć XSSa – podpowiedź wołowina ;). CSRF został znaleziony w aplikacji, tak samo jak możliwość przejęcia konta administratora.
      2.2 Gdyby babcia miała wąsy to by dziadkiem była, ale wąsy ogoliła i ich nie widać 😉
      3.4 Nie poznałem nigdy klasy podatności – 'przewidywalne nazwy pozwalające na” enumerowanie faktur’
      4.1 Odsyłam – https://www.owasp.org/index.php/Security_Headers
      4.2 Chciałeś chyba napisać, że tylko Firefox. Pewnych rzeczy nie jesteś w stanie stwierdzić bez dostępu do kodu źródłowego. Odsyłam – https://www.owasp.org/index.php/Security_Headers
      4.3 Załamałem się to czytając i pozwolę się nie odnieść.
      5.1 Lubisz snuć wnioski bez posiadania wymaganych informacji.

      Odpowiedź na ten zarzut znajduje się już wyżej.

Podziel się swoją opinią na temat artykułu