Bezpieczeństwo systemu

Testy podatności

Mając na uwadze bardzo szerokie zastosowanie systemu eAuditor we wszystkich sektorach gospodarki oraz możliwy duży wpływ działania systemu na infrastrukturę IT przeprowadzono testy bezpieczeństwa systemu. Testy będą w przyszłości powtarzane i dotyczą wszystkich linii produktowych BTC.

Testy penetracyjne aplikacji web oraz REST API

Testy penetracyjne są podstawowym procesem oceny bezpieczeństwa, który pozwala na ocenę technicznego poziomu bezpieczeństwa sieci oraz usług, jako całości. Oprócz aspektu technicznego bezpieczeństwa poprawnie wykonane testy penetracyjne mogą również zobrazować skuteczność działania procesów w obrębie organizacji – np. odpowiedzieć na pytanie, czy wdrożony proces aktualizacji systemów działa poprawnie i jest skuteczny oraz zobrazować skuteczność reagowania organizacji na incydenty informatyczne. Testy penetracyjne mają na celu ocenę środowiska informatycznego pod kątem znanych, a także nieznanych („0day”) podatności, które narażają bezpieczeństwo przetwarzanych przez organizację informacji.

W procesie testowania aplikacji webowych wykorzystano standard OWASP ASVS (Application Security Verification Standard).

Standard OWASP ASVS (Application Security Verification Standard) definiuje najlepsze praktyki w zakresie testowania aplikacji i mechanizmów ochronnych aplikacji typu web. Zastosowanie standardu OWASP ASVS na pozwoliło m.in. na weryfikację następnych typów podatności:

• Ataki typu „injection” – np. SQL injection, XML injection, code injection, command injection,
• Zarządzanie uwierzytelnieniem oraz autoryzacją,
• Ataki typu Cross-Site Scripting (XSS) – Reflected, Stored, DOM-based,
• Niebezpieczne bezpośrednie odwołania do obiektów zlokalizowanych na serwerach,
• Błędy konfiguracyjne mające bezpośredni wpływ na bezpieczeństwo,
• Dostępność wrażliwych danych bez uwierzytelnienia/autoryzacji,
• Ochrona kanału transmisyjnego (konfiguracja SSL/TLS, czy też innych wykorzystywanych protokołów),
• Możliwość obejścia autoryzacji, czy też podatność na ataki „Local/Remote File Inclusion”,
• Cross-Site Request Forgery,
• Podatność komponentów systemowych (np. błędy w serwerze WWW, czy też uruchomionych modułach),
• „Open Redirection”.

Dodatkowo do testów API REST wykorzystano kontrole zebrane w ramach dokumentu OWASP REST Security Chear Sheet dostępnego pod adresem:

https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html

Ocena aplikacji typu „Thick client”

Testy bezpieczeństwa aplikacji typu „gruby klient” miały na celu ocenę bezpieczeństwa aplikacji pod kątem znanych, a także nieznanych („0-day”) podatności, które narażają bezpieczeństwo przetwarzanych za jej pomocą informacji.

Ocenie poddawane zostały następujące aspekty:

• Publicznie znane podatności w oprogramowaniu oraz wykorzystywanych bibliotekach,
• Logika biznesowa aplikacji,
• Architektura rozwiązania,
• Bezpieczeństwo danych przechowywanych na stacji z zainstalowanym klientem – np. klucze szyfrujące, dane uwierzytelniające, wrażliwe informacje i inne,
• Sposób komunikacji z serwerem – w tym zapewnienie odpowiedniego uwierzytelnienia klientów oraz autoryzacji operacji,
• Bezpieczeństwo komunikacji z serwerem – zapewnienie poufności oraz integralności przesyłanych danych,
• Podatności przepełnień na stercie oraz stosie – “Stack Overflow”/“Heap Overflow”,
• Podatności związanie z nieprawidłowym oszacowaniem zakresu wartości przyjmowanych zmiennych (“Integer Overflow”),
• Nieprawidłowe przekazywanie argumentów do funkcji operujących na ciągach znaków (“Format String”),
• Błędy wynikające z niekompatybilności typów (“Type Confusion”),
• Bezpieczeństwo procesów/zasobów aplikacji – np. dane uwierzytelniające w pamięci procesu, uprawnienia procesu, bezpieczeństwo wykorzystywanych zasobów (pamięć współdzielona, „pipes”, czy też inne mechanizmy IPC), czy też uprawnienia do wykorzystywanych plików,
• Podatność na ataki typu „DLL hijacking”,
• Uprawnienia dla usług („services”) aplikacji,
• Prawidłowe wykorzystanie kryptografii w ramach aplikacji.

Badanie kodu źródłowego

Nie prowadzono badania kodu źródłowego.

Wykorzystane narzędzia

W ramach analizy tego typu oprogramowania wykorzystano m.in. następujące narzędzia:

• IDA Professional oraz Hex-Rays Decompiler – dezasemblacja oraz dekompilacja kodu w celu dokładnego zrozumienia funkcjonalności aplikacji, czy też przeglądu aplikacji pod kątem błędów programistycznych,
• Burp Suite Professional – jako narzędzie do analizy ruchu HTTP/HTTPS, gdy tego typu komunikacja jest wykorzystywana przez aplikację,
• Wireshark – w celu analizy ruchu sieciowego,
• WinDbg – debugger na platformę Windows – kontrola aplikacji podczas testowania, a także kontrola wykorzystywanej pamięci/obiektów w trakcie szczegółowej analizy,
• GDB – debugger na platformę Linux – kontrola aplikacji podczas testowania, a także kontrola wykorzystywanej pamięci/obiektów w trakcie szczegółowej analizy,
• Narzędzia do kontroli dostępów do plików/obiektów systemowych – np. Process Monitor (narzędzie Windows Sysinternals).

Klasyfikacja podatności

Common Vulnerability Scoring System (CVSS)

W celu dokładnego oszacowania ryzyka jakie wykryta podatność niesie za sobą zespół pentesterów opierł się na systemie Common Vulnerability Scoring System (CVSS). Skutkuje to możliwością precyzyjnego, liczbowego odzwierciedlenia ryzyka zidentyfikowanej podatności wraz z ukazaniem wyniku w formie reprezentacji opisowej (ryzyko – niskie, średnie, wysokie, krytyczne).

Wynik bazowy składa się z następujących elementów:

• Wektor ataku (Attack Vector/AV) – odzwierciedla kontekst, w którym możliwe jest wykorzystanie podatności:
  • Sieć (Network/N) – element podatny na ataki związany jest ze stosem sieci/podatność może być wykorzystana zdalnie,
  • Sąsiadujący (Adjacent/A) – atak musi zostać przeprowadzony z tej samej współdzielonej sieci fizycznej (np. Bluetooth/IEEE 802.11), logicznej (np. lokalnej podsieci IP) lub ograniczonej w specjalny sposób domeny administracyjnej,
  • Lokalny (Local/L) – atak możliwy do przeprowadzenia lokalnie np. przy pomocy komend wydawanych lokalnie na klawiaturze, bądź też zdalnie przy pomocy uwierzytelnionej sesji SSH,
  • Fizyczny (Physical/P) – atak wymaga od napastnika bezpośredniej (fizycznej) interakcji z urządzeniem,
• Złożoność ataku (Attack Complexity/AC) – opisuje warunki, na które atakujący nie ma wpływu, a które są konieczne w celu wykorzystania podatności:
  • Niska (Low/L) – atakujący może spodziewać się powtarzalnego sukcesu podczas wykorzystania podatnego elementu,
  • Wysoka (High/H) – udany atak zależy od warunków, na które atakujący nie ma wpływu, np. konieczność obejścia zaawansowanych mechanizmów bezpieczeństwa przed samym wykorzystaniem podatności.
• Wymagane przywileje (Privileges Required/PR) – ukazuje poziom uprawnień, jakie atakujący musi posiadać, aby wykorzystać podatność:
  • Brak (None/N) – atak można przeprowadzić bez uwierzytelnienia,
  • Niskie (Low/L) – w celu wykorzystania podatności wymagane są podstawowe uprawnienia, które normalnie mają wpływ tylko na ustawienia i dane konkretnego użytkownika,
  • Wysokie (High/H) – atak wymaga uprawnień, które zapewniają znaczącą (np. administracyjną) kontrolę nad wrażliwym komponentem, umożliwiając dostęp do ustawień i plików w całym komponencie.
• Wymagana interakcja użytkownika (User Interaction/UI) – uwzględnia wymagania dotyczące interakcji człowieka (np. użytkownika aplikacji) w procesie przeprowadzania ataku:
  • Brak (None/N) – atak może być przeprowadzony bez interakcji ze strony ofiary,
  • Wymagana (Required/R) – powodzenie ataku uzależnione jest od konkretnej interakcji ofiary.
• Zakres (Scope/S) – określa czy podatna część systemu ma wpływ na inne, wykraczające poza jego zakres bezpieczeństwa, dodatkowe elementy:
  • Bez zmian (Unchanged/U) – wykorzystywana luka może mieć wpływ tylko na zasoby zarządzane przez ten sam organ bezpieczeństwa,
  • Zmieniony (Changed/C) – wykorzystywana podatność może mieć wpływ na zasoby wykraczające poza zakres bezpieczeństwa, którym zarządza organ bezpieczeństwa w odniesieniu do elementu podatnego na dane zagrożenie.
• Poufność (Confidentiality/C) – określa wpływ skutecznego wykorzystania podatności na poufności przetwarzanych danych:
  • Brak (None/N) – nie występuje utrata poufności w ramach podatnego elementu,
  • Niska (Low/L) – istnieje pewna utrata poufności, jednak ujawnienie informacji nie powoduje bezpośredniej, poważnej straty dla dotkniętego nią elementu,
  • Wysoka (High/H) – następuje całkowita utrata poufności, w wyniku czego wszystkie zasoby w ramach dotkniętego komponentu mogą zostać ujawnione,
• Integralność (Integrity/I) – określa wpływ skutecznego wykorzystania podatności na integralność przetwarzanych danych:
  • Brak (None/N) – nie występuje utrata integralności systemu,
  • Niska (Low/L) – modyfikacja danych przez atakującego jest możliwa w ograniczonym zakresie,
  • Wysoka (High/H) – następuje całkowita utrata integralności systemu.