2. Agenda
Czy współczesne aplikacje są bezpieczne?
Jakie są przyczyny powstawania podatności?
Jakie są możliwości ograniczania ryzyka?
2
3. Czy współczesne aplikacje są
„bezpieczne”?
Większość aplikacji posiada istotne podatności (o znacznym
wpływie na ryzyko)
Dotyczy to zwłaszcza aplikacji webowych
Pięta achillesowa współczesnych systemów IT
Threat rank N of Vulns N of Sites N of Sites % Sites
Urgent 8918 2287 9.14% 18.77%
Critical 44669 5511 45.79% 45.22%
High 35375 8807 36.26% 72.27%
Medium 4908 4455 5.03% 36.56%
Low 3663 3618 3.75% 29.69%
24678 aplikacji przebadanych metodami testu penetracyjnego black-box,
white-box oraz skanerami automatycznymi w roku 2008 (8 różnych firm)
Źródło: WASC Web Application Secuirty Statistics
http://projects.webappsec.org/Web-Application-Security-Statistics
3
4. Z własnych doświadczeń
Testy najczęściej są zamawiane tuż przed wdrożeniem
produkcyjnym
W większości przypadków tylko testy penetracyjne
Często jest to jedyna forma weryfikacji bezpieczeństwa
Kluczowe podatności znajdujemy w ok. 70% badanych
aplikacji
4
5. Czy podatności w aplikacjach są
faktycznym problemem?
Verizon Data Breach Report Investigations 2010
http://www.verizonbusiness.com/resources/reports/rp_2010-data-breach-report_en_xg.pdf
Dane Verizon i US Secret Service
7 lat, 1700+ incydentów, >900 mln naruszonych rekordów danych
5
6. Co jest celem intruza?
Verizon Data Breach Report Investigations 2010
6
7. 7
Verizon Data Breach Report Investigations 2010
Najgroźniejsze podatności w aplikacjach
8. Przykłady – Błędna implementacja
Podgląd lub modyfikacja transakcji innych użytkowników
– Manipulacja identyfikatorem transakcji na formatce
podglądu / edycji transakcji
Obejście konieczności autoryzowania transakcji kodem
SMS
– Manipulacja logiką aplikacji
– Przeskoczenie wymaganego kroku
8
9. Przykłady – Błędna implementacja
Obejście limitów transakcyjnych
Rozesłanie wrogiego kodu do innych użytkowników
aplikacji
Atak na aplikacje „back office” przy użyciu interfejsu „front
office”
9
10. Przykłady – Błędne założenia
Założenie
– Autoryzacja operacji przy użyciu karty chipowej uniemożliwia atak
przy zastosowaniu wrogiego kodu na stacji użytkownika
Błąd
– W niektórych implementacjach oprogramowanie sterownika karty
zapamiętuje PIN wprowadzony przez użytkownika
– Po pierwszym użyciu karty użytkownik nie musi wprowadzać PIN
przy kolejnych operacjach z użyciem karty
– Karta jest używana również do uwierzytelniania się („zalogowania”)
Skutek
– Wrogi kod / wroga strona mogą sfałszować transakcję i zostanie
ona automatycznie podpisana bez wiedzy użytkownika
– Zabezpieczenie jest nieskuteczne
10
11. Przykłady – Błędne założenia
Autoryzacja transakcji przy użyciu kodu SMS
Założenie
– Telefon komórkowy jest urządzeniem zaufanym
– Nie były znane masowe ataki na telefony komórkowe
– Intruz musi przejąć kontrolę zarówno nad komputerem jak i
telefonem użytkownika
11
12. Man in the Mobile
Grafika: ingbank.pl, cert.pl 12
13. Man in the Mobile
Uwaga: Każda bankowość internetowa jest podatna na tego
typu atak
(wykorzystująca telefon do autoryzacji operacji)
To nie zależy od banku i rodzaju bankowości internetowej !
Istotą ataku jest nieświadomy użytkownik i jego „zarażony”
komputer
Wrogi kod na komputerze skłania użytkownika do podania nr
tel.
Instalacja wrogiego kodu na telefonie (za zgodą użytkownika)
13
15. Źródła problemów - Technologia
Stosunkowo młoda dziedzina oprogramowania bazująca
na „starych” technologiach
– HTTP/HTML nie były projektowane jako technologie do obsługi
aplikacji
– Nie tworzono ich z myślą o bezpieczeństwie
Tradycyjne środki zabezpieczające (Firewall, IDS) nie
sprawdzają się
Środowiska tworzenia i uruchamiania aplikacji nie są
odporne „by design”
– niezależnie od tego co mówią ulotki dostawców oprogramowania
15
16. Źródła problemów – Świadomość wykonawców
Niski poziom wiedzy programistów w zakresie
bezpieczeństwa aplikacji
Brak uwzględnienia bezpieczeństwa w procesie
wytwarzania oprogramowania
Brak wewnętrznych standardów „bezpiecznego
programowania”
Brak testów wewnętrznych
16
17. Źródła problemów – Wzrost potrzeb
Nowe technologie
Aplikacje mobilne, Cloud computing, Web Services, …
Brak wytycznych odnośnie bezpieczeństwa aplikacji
Maleje „time to market”
Rośnie funkcjonalność Maleje bezpieczeństwo
Bezpieczeństwo
Złożoność
17
18. „Wishful thinking”
Zamawiający Wykonawca
• Wykonawcą jest doświadczona • Zatrudniamy doświadczonych
firma, z pewnością wiedzą co programistów, z pewnością
robią wiedzą co robią
• Ich oprogramowania używają • Nasze nowoczesne narzędzia
duże firmy – oni nie pozwoliliby (famework, biblioteki) nie pozwolą
sobie na niską jakość na wykorzystanie ewentualnych
niedoskonałości
• Testy bezpieczeństwa
zaplanujemy N dni wstecz od • Nie otrzymaliśmy żadnych
wdrożenia produkcyjnego / szczegółowych wytycznych –
pilotażowego Pewnie ryzyko będzie
ograniczone innymi metodami
• Raczej nie będzie żadnych
opóźnień
18
19. Syndrom „gumowego” czasu
Zależność „finish to start”
Testy funkcjonalne Testy
Pilotaż
bezpieczeństwa
Go live
Poprawki !
Usunięte
podatności
19
21. Możliwości ograniczania ryzyka
Reaktywne Ograniczenie skutków
Zabezpieczenia techniczne: Firewall, IDS/IPS, WAF, …
Monitorowanie logów
Systemy „fraud detection”
Proaktywne Eliminacja przyczyn
Testowanie bezpieczeństwa aplikacji
– Testy penetracyjne, Przeglądy kodu źródłowego
Eliminacja zbędnych danych i funkcji
Uwzględnienie bezpieczeństwa w cyklu rozwojowym
aplikacji
21
22. Systemy „fraud detection”
Wykrywanie nietypowych zdarzeń
Nierealne scenariusze korzystania z instrumentów
płatniczych
– Np. Zwiększona liczba przelewów w krótkim okresie czasu
Wykrywanie wzorców powtarzających się dla wielu
klientów w krótkim okresie czasu
Skuteczność systemu Fałszywe alarmy
Ilość wykrywanych
zdarzeń Koszty obsługi
22
23. Testowanie bezpieczeństwa aplikacji
Dobre zrozumienie testowanej aplikacji
Identyfikacja zagrożeń przed rozpoczęciem testów
Modelowanie zagrożeń
Ograniczone możliwości zastosowania narzędzi
automatycznych
Automat nie jest w stanie „zrozumieć” logiki aplikacji
Nie umie rozróżnić danych „moich” od „cudzych”
Produktem nie jest sam test ale raport
Forma zrozumiała nie tylko dla specjalistów
Raportowanie istotnych podatności na bieżąco
23
24. Przeglądy kodu źródłowego
Problem: Mało czasu / dużo kodu
Narzędzia automatyczne
Do wykrywania prostych podatności
Z reguły generują dużo „fałszywych alarmów”
Raport z narzędzi musi być zweryfikowany przez
specjalistę
Wywiad z przedstawicielami wykonawcy
Każde twierdzenie jest sprawdzane w kodzie (dowody)
Poszukiwanie podatności czy weryfikacja stosowania
dobrych praktyk?
Lista kontrolna OWASP ASVS 24
25. Dziękuję za uwagę
Wojciech Dworakowski
wojciech.dworakowski@securing.pl
Tel.: 12 425 25 75, 506 184 550
25