1. Zagrożenia dla aplikacji bankowych
i sposoby zmniejszania ryzyka
Wojciech Dworakowski

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

14. Przyczyny

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

20. Ograniczanie ryzyka

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