Testy penetracyjne aplikacji desktopowych
Aplikacja desktopowa działa na komputerze, nad którym nie masz często pełnej kontroli, z uprawnieniami zalogowanego użytkownika, a często administratora. Czasem wszystkie aplikacje współdzielą jedno konto bazodanowe, które może na bazie wykonać każdą operację. Atakujący ma ją u siebie: może rozłożyć plik wykonywalny na części, podejrzeć pamięć procesu, podmienić bibliotekę i przechwycić każde żądanie do serwera. W sieci korporacyjnej taka aplikacja może stanowić istotną powierzchnię ataku. Testujemy dokładnie z tej pozycji.
Sprawdzamy aplikację razem z jej zapleczem: plik wykonywalny i biblioteki, dane pozostawiane na dysku i w rejestrze, komunikację z backendem, uprawnienia procesu, mechanizm aktualizacji i odporność na modyfikację w trakcie działania. Dla systemów Windows, macOS i Linux.
Pracowaliśmy m.in. dla: banków, domów maklerskich, firm leasingowych, energetycznych, telekomunikacyjnych, produkcyjnych i e-commerce.
Dowiedz się więcejDlaczego gruby klienta (thick client) wymaga innego podejścia niż aplikacja webowa?
W aplikacji webowej większość istotnej logiki wykonuje się na Waszym serwerze, a przeglądarka wyświetla wynik. W aplikacji desktopowej duża część systemu trafia na komputer użytkownika i przestaje być pod Waszą kontrolą. Wynikają z tego cztery różnice, które zmieniają zakres testu:
Kod jest dostępny lokalnie. Plik wykonywalny można zdekompilować, zwłaszcza gdy aplikacja powstała w .NET lub Javie. Zaszyte poświadczenia, klucze API, adresy środowisk testowych i ustawienia połączeń do bazy danych – w tym często loginy i hasła – zostają w pliku, który leży na dysku każdego użytkownika.
Aplikacja działa z uprawnieniami systemowymi. Przejęcie kontroli nad procesem to nie tylko dostęp do danych aplikacji. To punkt wyjścia do eskalacji uprawnień na stacji roboczej, przejęcia poświadczeń domenowych i ruchu bocznego w sieci firmowej. Aplikacja desktopowa bywa najkrótszą drogą od jednego pracownika do kontrolera domeny.
Zabezpieczenia po stronie klienta da się wyłączyć. Ograniczenia w interfejsie, walidacja kwot, blokady przycisków, kontrola ról – wszystko to działa, dopóki nikt nie zmodyfikuje procesu w pamięci albo nie wyśle żądania z pominięciem interfejsu.
Backend często ufa aplikacji. Jeżeli serwer zakłada, że żądanie przyszło z Waszego klienta i dlatego jest poprawne, wystarczy to żądanie podrobić. To najczęstsze poważne znalezisko w pentestach aplikacji desktopowych i zawsze wynika z tego samego założenia: że klient desktopowy jest zaufany.
Skontaktuj się z nami
Co obejmuje test penetracyjny aplikacji desktopowej
Analiza pliku wykonywalnego
Rozpoznanie technologii i frameworka, dekompilacja aplikacji .NET i Java, przegląd zasobów i plików konfiguracyjnych, wyszukiwanie zaszytych poświadczeń, kluczy i ciągów połączeń. Ocena skuteczności obfuskacji oraz mechanizmów utrudniających modyfikację pliku. Weryfikacja podpisu cyfrowego i zabezpieczeń kompilatora.
Dane na dysku i w rejestrze
Co aplikacja zostawia po sobie: pliki konfiguracyjne, lokalne bazy danych, loginy i hasła do zewnętrznych baz, cache, logi, wpisy w rejestrze, pliki tymczasowe. Sprawdzamy, czy dane wrażliwe są szyfrowane, gdzie trzymane są klucze i czy po wylogowaniu coś zostaje.
Pamięć procesu
Dane, które w pliku są zaszyfrowane, w pamięci działającego procesu zwykle już nie są. Sprawdzamy, co da się z niej odczytać: hasła, tokeny sesji, klucze, dane klientów.
Komunikacja z backendem
Przechwytywanie ruchu, w tym protokołów innych niż HTTP, próby ataku Man-in-the-Middle, weryfikacja szyfrowania i sprawdzania certyfikatów. Testujemy też samo API: manipulację żądaniami, dostęp do danych innych użytkowników, uprawnienia po stronie serwera.
Uprawnienia i integracja z systemem
Uprawnienia, z jakimi działa proces i usługa, uprawnienia katalogu instalacyjnego, przejmowanie ładowanych bibliotek (DLL hijacking), niebezpieczne ścieżki do plików wykonywalnych, komunikacja międzyprocesowa (IPC), obsługa protokołów i skojarzeń plików rejestrowanych w systemie.
Mechanizm aktualizacji
Obszar pomijany najczęściej, a konsekwencje jego przełamania są największe. Sprawdzamy integralność pakietu aktualizacji, weryfikację podpisu, odporność na podstawienie własnej paczki i na wymuszenie instalacji starszej, podatnej wersji. Aplikacja z zaufanym podpisem, która sama pobiera i uruchamia kod, jest gotowym kanałem dystrybucji.
Kontrola dostępu i logika biznesowa
Obejście ról i uprawnień, wykonywanie operacji poza przewidzianą kolejnością, manipulacja kwotami, limitami i procesem akceptacji. Spójność między tym, co blokuje interfejs, a tym, co dopuszcza serwer.
Aplikacje oparte o technologie webowe
Osobne podejście dla klientów zbudowanych w Electronie i podobnych rozwiązaniach: izolacja komponentów, dostęp kodu strony do funkcji systemowych, obsługa treści zewnętrznych, konfiguracja zabezpieczeń frameworka.
Krytyczność każdej potwierdzonej podatności wyceniamy według CVSS lub OWASP Risk Rating Methodology.
Warianty testów bezpieczeństwa aplikacji desktopowych
Black-box – pracujemy wyłącznie z zainstalowaną aplikacją, bez dokumentacji i kodu. Najbliżej realnego scenariusza, w którym atakujący ma tę samą aplikację co każdy użytkownik.
Grey-box – najczęściej wybierany wariant. Dostajemy konta testowe dla różnych ról, opis architektury i informacje o technologiach. Przy tym samym budżecie schodzimy głębiej w logikę i komunikację z backendem.
White-box – z dostępem do kodu źródłowego i konfiguracji. Najwyższe pokrycie, wychwytuje błędy niewidoczne z zewnątrz, zwłaszcza w implementacji kryptografii.
Testujemy aplikacje komunikujące się z serwerami w Internecie i takie, które działają wyłącznie wewnątrz sieci firmowej. Pracujemy zdalnie lub w siedzibie Klienta, jeżeli wymaga tego polityka bezpieczeństwa albo aplikacja nie może opuścić Waszej infrastruktury.
Jeżeli zależy Wam na pełnym przeglądzie implementacji, zobaczcie audyt kodu źródłowego. Przy aplikacji mocno opartej na integracjach warto rozszerzyć zakres o testy bezpieczeństwa API, a przy sprawdzeniu całej stacji roboczej o testy infrastruktury IT. Jeżeli chcesz połączyć testy z warstwą formalną, zobacz audyt zgodności z NIS2 i UoKSC.
Kiedy zamówić pentest aplikacji desktopowej?
- Przed wdrożeniem nowej aplikacji albo dużej aktualizacji u użytkowników.
- Przed odbiorem systemu od zewnętrznego dostawcy, zanim podpiszecie protokół.
- Po dodaniu funkcji związanych z przepływami finansowymi, danymi osobowymi lub uwierzytelnianiem.
- Po zmianie mechanizmu aktualizacji albo dostawcy podpisu kodu.
- Gdy aplikacja jest starsza niż zespół, który ją utrzymuje, i nikt nie wie, jak i dlaczego w ogóle działa i co dokładnie robi w tle.
- Cyklicznie, co 3 do 24 miesięcy, zależnie od wrażliwości danych i tempa zmian.
Aplikacje desktopowe a DORA, NIS2 i UoKSC
Rozporządzenie DORA wymaga od instytucji finansowych regularnego testowania systemów ICT wspierających funkcje krytyczne lub istotne. Aplikacja desktopowa obsługująca rozliczenia, obieg dokumentów czy pracę back-office zwykle takie funkcje wspiera, a mimo to w programach testów bywa pomijana na rzecz systemów webowych.
Dla podmiotów objętych NIS2 obowiązuje odrębny harmonogram: nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa weszła w życie 3 kwietnia 2026 r., okres dostosowawczy mija 3 kwietnia 2027 r., a podmioty kluczowe muszą przeprowadzić pierwszy audyt bezpieczeństwa do 3 kwietnia 2028 r. i powtarzać go nie rzadziej niż co trzy lata. Jeżeli chcecie uporządkować warstwę formalną, zobacz audyt zgodności z NIS2 i UoKSC.
Dodatkowo producenci oprogramowania wprowadzanego na rynek unijny podlegają rozporządzeniu Cyber Resilience Act (CRA). Od 11 września 2026 r. obowiązuje ich zgłaszanie aktywnie wykorzystywanych podatności i poważnych incydentów, a pełne stosowanie przepisów nastąpi 11 grudnia 2027 r. Aplikacje desktopowe mogą podlegać obowiązkom związanym z CRA.
Korzyści
Podatności potwierdzone, z dowodem
Każde znalezisko ma proof of concept: kroki odtworzenia, zrzuty ekranu, przechwycone żądania, fragmenty logów. Zespół nie traci czasu na sprawdzanie, czy błąd istnieje.
Materiał dla Zarządu
Streszczenie bez terminologii technicznej, z opisem możliwych skutków.
Obszar, którego zwykle nikt nie testował
Aplikacje desktopowe zwykle wypadają z programów testów, bo „nie są wystawione do Internetu". Lub nikt nie wie, jak je testować. Tymczasem to one działają z najwyższymi uprawnieniami na stacjach roboczych.
Dowód dla regulatora i kontrahenta
Niezależna ocena według uznanych standardów, którą możecie pokazać audytorowi, klientowi korporacyjnemu lub ubezpieczycielowi.
Kolejność napraw według ryzyka
Rekomendacje uszeregowane od tych, które mogą realnie kosztować pieniądze, po informacyjne.
Weryfikacja po naprawie
Re-testy potwierdzają, że poprawki działają i że przy okazji nie powstał nowy błąd.
Czym testujemy aplikacje desktopowe
Aplikacje desktopowe wymagają innego warsztatu niż web i mobile. Nasz zestaw obejmuje m.in.:
Analiza binarna i dekompilacja: dnSpy, dotPeek i .NET Reflector dla aplikacji .NET, IDA i OllyDbg dla kodu natywnego, CFF Explorer, Dependency Walker, BinScope, JavaSnoop.
Obserwacja zachowania w systemie: Process Monitor, Process Explorer i pozostałe narzędzia Sysinternals, TCPView, Spy++.
Analiza i modyfikacja ruchu: Burp Suite Pro, Fiddler, Echo Mirage do protokołów innych niż HTTP, Wireshark.
Aplikacje oparte o Electron: Electronegativity.
Pozostałe: ffuf z własnymi słownikami oraz autorskie narzędzia pisane pod konkretne przypadki, których gotowe rozwiązania nie obsługują.
Skontaktuj się z nami
Masz pytania?
Skorzystaj z BEZPŁATNEJ KONSULTACJI
Na rozmowie przejrzymy technologię i funkcje aplikacji, wskażemy obszary o najwyższym ryzyku i podamy realny zakres oraz czas testów. Bez zobowiązań.
Raport z testów penetracyjnych aplikacji desktopowej
Raport pisany jest dla dwóch odbiorców i tak też jest podzielony.
Część dla Zarządu i osób decyzyjnych:
- cel i zakres wykonanych prac,
- zastosowane podejście,
- podsumowanie wyników językiem biznesowym, bez terminologii technicznej,
- ogólna ocena poziomu bezpieczeństwa aplikacji.
Część techniczna, dla każdej podatności:
- tytuł i szczegółowy opis,
- proof of concept: sposób wywołania podatności wraz z dowodami (zrzuty ekranu, zmanipulowane zapytania, listingi poleceń, fragmenty logów),
- opis możliwych skutków wykorzystania,
- poziom krytyczności według CVSS lub OWASP RRM w skali: krytyczny, wysoki, średni, niski, informacyjny,
- odniesienie do publicznych baz podatności,
- rekomendacja naprawcza z opisem sposobu wdrożenia, dopasowana do Waszej technologii.
Raport zawiera też zakres i datę testów, listę zastosowanych metodyk i technik oraz wykorzystane narzędzia.
Najczęściej zadawane pytania
Wycena zależy od technologii, liczby platform i ról, złożoności logiki oraz tego, czy zakres obejmuje backend. Podajemy ją po wstępnej rozmowie i przejrzeniu aplikacji, zawsze jako konkretną pracochłonność, koszt i termin realizacji.
Od 1 do 4 tygodni, zależnie od złożoności aplikacji. Termin i pracochłonność ustalamy przed startem.
Instalatora lub pakietu aplikacji, kont testowych dla każdej roli oraz zgody na testy. Przy wariancie grey-box dodatkowo opisu architektury, użytych technologii i dokumentacji API. Przy white-box także dostępu do kodu.
Aplikacje natywne dla Windows, macOS i Linux, aplikacje .NET i Java oraz aplikacje klienckie zbudowane na technologiach webowych, takie jak Electron. Przy nietypowych lub starszych technologiach potwierdzamy dostępność odpowiedniego specjalisty przed złożeniem oferty.
Preferujemy środowisko testowe odwzorowujące produkcję. Jeżeli test musi objąć produkcję, ustalamy okno czasowe i zakres dopuszczalnych operacji, a w trakcie prac utrzymujemy stały kontakt z Waszym zespołem.
Zależnie od uzgodnionego zakresu. Rekomendujemy objęcie backendu testami, bo w aplikacjach desktopowych większość poważnych podatności ujawnia się po stronie serwera, który zbyt mocno ufa klientowi.
Nie musi. Przy aplikacjach objętych szczególnymi ograniczeniami pracujemy w siedzibie Klienta, na Waszym sprzęcie i w Waszej sieci.
Skaner porówna wersje komponentów z bazą znanych błędów. Nie zdekompiluje pliku wykonywalnego, nie przejrzy pamięci procesu, nie sprawdzi, czy da się podstawić własną aktualizację. W przypadku aplikacji desktopowych różnica między skanem a pentestem jest większa niż gdziekolwiek indziej.
Tak. Wspieramy zespół przy naprawie, prowadzimy szkolenia z usuwania podatności i wykonujemy re-testy potwierdzające skuteczność poprawek.
Zwykle co 3 do 24 miesięcy, zależnie od wrażliwości danych, poziomu ryzyka i liczby zmian. Instytucje finansowe objęte DORA testują systemy wspierające funkcje krytyczne lub istotne regularnie, zgodnie z własnym programem testowania odporności cyfrowej. Pomagamy zbudować plan ciągłego monitorowania bezpieczeństwa.
Tak, przy współpracy długoterminowej warunki są korzystniejsze niż przy pojedynczym projekcie.
Zgodnie z ISO 27001: kontrola dostępu do serwerowni i zasobów sieciowych, szyfrowanie dysków, szyfrowanie plików i załączników PGP, szyfrowanie treści wiadomości, ciągłe monitorowanie dostępu.
Dlaczego warto powierzyć nam testy aplikacji desktopowych?
Kompetencja, której rynek prawie nie ma. Pentest thick clienta wymaga umiejętności analizy binarnej i pracy z pamięcią procesu, a nie tylko znajomości OWASP Top 10. W Polsce niewielu dostawców ma tę usługę w ofercie jako osobną pozycję.
Zespół i doświadczenie. Ponad 20 inżynierów bezpieczeństwa z certyfikatami OSCP, OSCE, OSWE, OSEE, CEH, CISSP i CISA, w tym AWE (Advanced Windows Exploitation), z doświadczeniem w programowaniu i administracji systemami. Ponad 500 testów penetracyjnych rocznie.
Jakość i niezależny przegląd. Dostajesz raport, a nie wynika pracy narzędzi. Raport jest wynikiem pracy przynajmniej dwóch niezależnych pentesterów lub zespołów – jeden wykonuje prace, drugi niezależnie weryfikuje ich wyniki i raport.
Testy manualne jako podstawa. Skaner nie zdekompiluje aplikacji, nie przejrzy pamięci procesu i nie sprawdzi mechanizmu aktualizacji. Automat stosujemy pomocniczo i przy cyklicznych przeglądach.
Dwie osoby kontaktowe. Pentester Wiodący odpowiada na pytania techniczne w trakcie testów, Project Manager pilnuje terminów i ustaleń.
Ochrona materiałów z testów. Zgodnie z ISO 27001: szyfrowanie dysków, szyfrowanie plików i załączników PGP, kontrola i monitorowanie dostępu do danych oraz raportów. Przy aplikacjach, których instalator nie może opuścić Waszej infrastruktury, pracujemy na miejscu.