1.
Nowe technologie w aplikacjach
bankowości elektronicznej -
- Wyzwania dla bezpieczeństwa
Wojciech Dworakowski

2.
Agenda
Nowe trendy
 Aplikacje mobilne
 NFC
 Bank wirtualny
 Integracja z serwisami społecznościowymi
Jak to zrobić bezpiecznie?
2

3.
Kto stoi w miejscu, ten się cofa, bo
cały świat idzie do przodu.
3

4.
Aplikacje mobilne
Aplikacja mobilna vs aplikacja „przeglądarkowa”
Inny profil ryzyka
 Urządzenie użytkownika  Kradzież, zgubienie, chwilowy dostęp, …
 Aplikacja pod kontrolą użytkownika  Może być analizowana i dowolnie
modyfikowana
 Inne aplikacje na urządzeniu  Mogą stanowić zagrożenie
 Uaktualnienia  z opóźnieniem
 API po stronie serwera  Osiągalne bezpośrednio, bez aplikacji użytkownika
Nie można traktować jak „prawie WWW”
 To nie jest tylko inny sposób prezentacji
4

5.
Aplikacje mobilne
Dane przechowywane na urządzeniu
Co w przypadku utraty urządzenia?
 Dane wrażliwe (tajemnica bankowa, dane osobowe, dane
uwierzytelniające i autoryzujące transakcje, …)
Czy dane są szyfrowane?
Czy klucz szyfrowania łatwo odzyskać?
 Musi być przetwarzany przez (niezaufane) urządzenie
5

6.
Aplikacje mobilne
Dane przechowywane na urządzeniu (c.d.)
Co jest zapisywane do logów w trakcie pracy aplikacji?
Dane uwierzytelniające
 Jaka jest przestrzeń poszukiwań?
 Ile prób odgadnięcia ma atakujący?
 Czy można je „złamać” bez kontaktu z serwerem?
6

7.
Aplikacje mobilne
Przykład
Grafika: technabob.com
Aplikacja mobilna
Sekret używany do uwierzytelnienia,
zaszyfrowany kluczem generowanym na
podstawie PIN
Dodatkowo - na urządzeniu dane
zaszyfrowane tym kluczem
Efekt
 Klucz można łamać off-line
 4 cyfry = 10 tys. prób = kilka minut
Koszt usunięcia: Zmiana algorytmu (po
wdrożeniu)
7

8.
Aplikacje mobilne
Autoryzacja transakcji
Podstawowy mechanizm
bezpieczeństwa
 Większe ryzyko dostępu
atakującego do uwierzytelnionej
sesji
Mechanizm powinien umożliwiać
zweryfikowanie danych transakcji Jak to zrobić wygodnie?
Użycie innego kanału –
niekontrolowanego przez intruza Na pewno?
 SMS
 Token (osobna aplikacja)
8

9.
Aplikacje mobilne
Wrogie oprogramowanie (malware)
Dostęp fizyczny  mała skala
Malware  skala masowa
Skutki te same
Telefon / tablet – to nie są urządzenia bezpieczne !
… tak jak komputer, ale:
 ryzyka są mniej rozpoznane
 brak kontroli AV (standardowo)
 brak unifikacji systemu (wielu dostawców)
 rzadsze uaktualnienia
 użytkownik może instalować dowolne oprogramowanie
 mniej doświadczony użytkownik
9

10.
NFC
NFC – nowy interfejs do aplikacji = zwiększenie powierzchni ataku
Przykład: BlackHat 2012
 Wywołanie podatnej aplikacji przez NFC
 Wykorzystanie podatności w aplikacji
 Wykonanie dowolnego kodu na telefonie
Przykład: NFC Proxy
 Wroga aplikacja na telefonie ofiary
 Jeśli karta zbliżeniowa znajdzie się w zasięgu NFC…
 …to można zdalnie zrobić dowolną transakcję (zbliżeniową)
10

11.
Wirtualny kontakt z klientem
Przeniesienie „oddziałów” i „doradców klienta” do Internetu
Uproszczenie procedur, wyeliminowanie papieru
Zakładanie konta
 Potwierdzanie tożsamości przez przelew z innego banku
 Zagrożenie: Kradzież tożsamości
 Przykłady: Zakładanie kont – słupów
Przekazywanie hasła dla innych podmiotów
 Zarządzanie finansami osobistymi
 Weryfikacja zdolności kredytowej
 Nowe systemy e-płatności
11

12.
Integracja z serwisami
społecznościowymi
Wstawienie cudzego kodu do własnej aplikacji
 Publikowanie informacji w sieciach społecznościowych, „polecanie”,
itp.
 Mapy, statystyki odwiedzin, widgety, gadgety, …
 Czy ufamy zewnętrznemu serwisowi?
 Co wiemy o bezpieczeństwie tego serwisu?
 Czy ufamy operatorom serwisu?
 Czy zostało uwzględnione ryzyko istnienia podatności w
integrowanym serwisie?
12

13.
Integracja z serwisami
społecznościowymi
Wstawienie własnego kodu do cudzej aplikacji
 Aplikacja na serwisie społecznościowym
 Czy zostało uwzględnione ryzyko ataku na sesję użytkownika w
zewnętrznej aplikacji?
 Funkcje bezpieczeństwa (np. uwierzytelnienie) – poza kontrolą banku
 Sieci społecznościowe  użytkownik zalogowany non-stop
 Potrzebne są dodatkowe zabezpieczenia (np. limity)
13

14.
Jak to zrobić bezpiecznie?
Rosnące koszty usuwania
podatności
Utrzymanie
Wdrażanie
Wytwarzanie
Projektowanie
Definiowanie
Wpisanie bezpieczeństwa w cały
cykl rozwojowy aplikacji
SDLC (Secuity in Development Lifecycle)
14

15.
Od czego zacząć?
zagrożenia
Żeby efektywnie planować
zabezpieczenia trzeba znać:
• zagrożenia
• scenariusze ataków
zabezpieczenia • potencjalne skutki
aktywa skutki
15

16.
• Zidentyfikowanie
Modelowanie
zagrożeń • Wymagania
zagrożeń
dotyczące
• Scenariusze bezpieczeństwa
ataków
• Scenariusze
• Dobranie testowe
zabezpieczeń
Niezbędne:
• Doświadczenie
• Umiejętność wczucia się w rolę atakującego
16

17.
Testowanie bezpieczeństwa
Niezbędne - bo może zawieść implementacja założeń
W trakcie implementacji
 przegląd założeń, testy jednostkowe
Przed wdrożeniem
 Testy penetracyjne
 Przeglądy kodu i konfiguracji
17

18.
Testowanie bezpieczeństwa
Na podstawie zidentyfikowanych zagrożeń
Według ustalonych priorytetów
NIE black-box !
Pamiętaj o uwzględnieniu całego środowiska
 Atakowany jest cały system
a nie jeden element
 Połączenia z innymi systemami, biblioteki, framework
Kluczowe – doświadczenie testujących
18

19.
Podsumowanie
Wdrażając nowe technologie myśl o bezpieczeństwie!
 od planowania po wdrożenie i eksploatację systemu
Zaplanuj bezpieczeństwo
 Identyfikacja zagrożeń
 Projektowanie zabezpieczeń
Jeśli chcesz uniknąć zbędnych kosztów i kłopotów
 Testuj przed  Modelowanie zagrożeń
 … i po  Testy penetracyjne, przeglądy konfiguracji, ...
Niezbędne - doświadczenie i metnalność atakującego
19

20.
Wsparcie procesów związanych z utrzymaniem bezpieczeństwa
 Od identyfikacji zagrożeń i tworzenia założeń…
 …po testy odbiorcze i okresowe testy podczas eksploatacji
 Audyty
 Specjalizowane szkolenia
Niezależność od dostawców rozwiązań
 Nasza firma nie prowadzi aktywnej sprzedaży produktów zabezpieczających.
 Koncentrujemy się wyłącznie na usługach dotyczących bezpieczeństwa IT.
Działamy od 2003 roku
Zbadaliśmy bezpieczeństwo ponad 200 systemów informatycznych i
aplikacji
20

21.
Nasze podejście
Kluczem do właściwej oceny bezpieczeństwa jest uwzględnienie realnego
wpływu na ryzyko
 Identyfikacja lub modelowanie zagrożeń przed rozpoczęciem oceny
Podczas testów nie opieramy się wyłącznie na automatach
 Narzędzia automatyczne są w stanie wykryć tylko ułamek problemów
 Badane zagrożenie to prawdziwy atak człowieka a nie automatu
 Uwzględnienie zidentyfikowanych zagrożeń, wpływu na biznes i logiki
biznesowej
 „Ręczna” weryfikacja, specjalizowane narzędzia
Podczas formułowania zaleceń staramy się brać pod uwagę wymagania
biznesowe
Przede wszystkim kierujemy się zdrowym rozsądkiem
21

22.
Pytania
http://www.securing.pl Wojciech Dworakowski
e-mail: info@securing.pl wojciech.dworakowski@securing.pl
Jontkowa Górka 14a tel. 506 184 550
30-224 Kraków
tel. (12) 4252575
fax. (12) 4252593
22