„Sphinx, Dyre, Slave - potomkowie ZeuSa: jest czego się bać?”

O złośliwym oprogramowaniu atakującym klientów sektora finansowego w Polsce do połowy roku 2015. Jeśli przeglądasz slajdy, prezentacja na pewno wymaga aktualizacji o nowe scenariusze, choć zdecydowana większość jest nadal aktualna.

Transcript

1. „Spinx,  Dyre,  Slave  -­‐  potomkowie  ZeuSa:   jest  czego  się  bać?”     Przemysław  Skowron,  17.09.2015,  Wrocław  
2. O  mnie   •  Poznaję  „wroga”  od  roku  2001   •  Doświadczenie  w  „red  &  blue”  team   •  W  latach  2008-­‐2015  lider  i  architekt  CSIRT  Grupy  Alior  Bank  –   pierwszy  CSIRT  w  Polsce   •  Od  2015  (oficjalnie)  lider  White  Cat  Security:   –  Blog  hYp://www.whitecatsec.com   –  Usługi  hYp://www.whitecatsec.com/p/oferta.html       •  Więcej:  hYps://linkedin.com/in/pskowron       2  
3. Agenda   •  Zdefiniujmy  problem  wyzwanie   •  Jak  się  bronimy?   •  Jak  jesteśmy  atakowani?   •  Dlaczego  to  nie  działa?   •  Co  więc  działa?   •  Podsumowanie   3  
4. Zdefiniujmy  problem  wyzwanie   •  Ataki  celowane:  Równolegle  atakowani  są  Klienci  od  kilku  do   kilkunastu  banków  w  Polsce  –  prawdopodobnie  co  najmniej   jeden  z  naszych  członków  Rodziny   •  Ataki  niezależne  od  marki  danego  banku:  wszystkie  banki  w   Polsce  i  nie  tylko  banki  –  KAŻDY  z  Nas   4  
5. Zdefiniujmy  problem  wyzwanie   •  Dżentelmeni  nie  rozmawiają  o  $,  my  musimy:   – 35  mln.  PLN  wg.  Redaktorów  TVP2  („pewne  jak  w   banku”)   – Przypadki  na  setki  tyś.  PLN  z  pojedynczych   przypadków  wg.  Redaktorów  TVN  (Jaworzno,   Rząśnia,  etc.)   – Wg.  mnie  między  kilkadzesiąt,  a  kilkaset  MLN/rok   – Potencjalna  strata  >  1  MLD  PLN/rok  w  .pl   5  
6. Zdefiniujmy  problem  wyzwanie   •  Skąd  taki  potencjał?   – 75%  nie  obawia  się  nadużyć  z  użyciem  ich  danych   – 71%  nie  obawia  się  o  bezpieczeństwo  transakcji   – 57%  nie  ma  AV   – 71%  otwiera  maile  od  nieznanej  osoby     Special  Eurobarometer  423:  Cyber  Security       6  
7. Jak  się  bronimy?   •  Klienci:   – AV   – Inny  Anty(„coś”)   – Firewall   – Aktualny  system  i  oprogramowanie   – Wiedza  o  zagrożeniach  i  stale  rozwijany  wew.   mechanizm  obronny  (detekcyjny)     Tak  to  wygląda  na  „papierze”   7  
8. Jak  się  bronimy?   •  Klienci:   –  AV  (brak,  ignorowany,  nieskuteczny)   –  Inny  Anty(„coś”)  (j/w)   –  Firewall  (j/w)   –  Aktualny  system  i  oprogramowanie  (nie  ma  nawet  w   filmach)   –  Wiedza  o  zagrożeniach  i  stale  rozwijany  wew.   mechanizm  obronny  (detekcyjny)  (przestępcy   „edukują”  skuteczniej)     Tak  to  wygląda  w  rzeczywistości   8  
9. Jak  się  bronimy?   •  Banki:   – SSL   – „silne”,  wieloskładnikowe  metody  autoryzacji   – Systemy  FDS  (Fraud  Detecion  System)   – Inne  (operacyjne  działania  owiane  „poufnością”)   – Regulamin  bezpiecznego  korzystania  z  bankowości     Tak  to  wygląda  na  „papierze”   9  
10. Jak  się  bronimy?   •  Banki:   –  SSL  (MITM,  Phishing,  etc.)   –  „silne”,  wieloskładnikowe  metody  autoryzacji   (zmieniają  wysokość  poprzeczki,  nie  są  wystarczające)   –  Systemy  FDS  (Fraud  Detecron  System)  (j/w)   –  Inne  (operacyjne  działania  owiane  „poufnością”)   –  Regulamin  bezpiecznego  korzystania  z  bankowości     Tak  to  wygląda  w  rzeczywistości   10  
11. Jak  jesteśmy  atakowani?   •  Kradzież  loginu  i  hasła  (nawet  gdy  maskowane   –  poproszą  o  całe  J)   •  Kradzież  danych  o  środkach   •  Wykonanie  akcji  w  bankowości   •  Zlecenie  transakcji  finansowej   •  Kradzież  kodu  autoryzującego   •  Podmiana  nr.  rachunku  beneficjenta   11  
12. Jak  jesteśmy  atakowani?   •  Kradzież  loginu  i  hasła  (nawet  gdy  maskowane   –  poproszą  o  całe  J)   – Podsłuchają  w  ruchu  sieciowym  (lokalnie,  przed   zaszyfrowaniem)   – Wstawią  swój  formularz  lub  zmodyfikują  istniejący   •  Kradzież  danych  o  środkach   – “Podsłuchają”  odpowiedź  serwera  zwracającą   informacje  o  naszych  produktach  bankowych   12  
13. Jak  jesteśmy  atakowani?   •  Wykonanie  akcji  w  bankowości   – Zmiana  numer  zaufanego  tel.  (kody  SMS)   – Stworzenie/modyfikacja  szablonu  płatności   •  Zlecenie  transakcji  finansowej   – Stworzenie/modyfikacja  płatności  odroczonej   – Stworzenie/modyfikacja  płatności  do  autoryzacji   13  
14. Jak  jesteśmy  atakowani?   •  Kradzież  kodu  autoryzującego   – Przekazanie  kodu  SMS  z  tel.   – Fałszywy  formularz  autoryzacji  operacji  (innej  niż   ta,  którą  faktycznie  kod  autoryzuje)   •  Podmiana  nr.  rachunku  beneficjenta   – Podmiana  danych  w  „schowku”,  na  stronie  (nie   tylko  banku)   14  
15. Dlaczego  to  nie  działa?   •  „silne”  metody  autoryzacji  i  FDSy  (o  ile  je   posiadamy)  działają,  ale  nie  są  w  100%   skuteczne   •  Nie  miejmy  złudzeń,  że  Klienci  sektora   finansowego  nagle  nie  będą  przegrywać  walki   ze  złośliwym  oprogramowaniem  –  będą  i  to   częściej!   15  
16. Co  więc  działa?   •  Motywacja:   – Reputacja  (banku,  klienta,  dostawcy)   – Prawo  (od  min.  2010  sądy  przychylne  bankom,   KNF  również  jasno  określa  się  w  temacie   złośliwego  oprogramowania)   – Kto  nie  chce  być  „Batmanem”  ?!   – Rekomendacja  Europejskiego  Banku  Centralnego   odnośnie  bezpieczeństwa  transakcji                                                                     finansowych  w  kanałach  elektronicznych   16  
17. Co  więc  działa?   •  KK10.1   „Systemy  te  powinny  również  być  zdolne  do   wykrywania  symptomów  infekcji  sesji  przez   szkodliwe  oprogramowanie  (np.  poprzez   sprawdzenie,  czy  dana  czynność  realizowana   jest  przez  skrypt,  czy  przez  człowieka)  oraz   znanych  scenariuszy  oszustw.”     17  
18. Co  więc  działa?   1.  Musimy  porzucić  dogmaty:  „nic  nie  możemy   zrobić”,  „użyli  obfuskacji!”,  „wykrywają  VM!”     2.  Przeanalizujmy  atak:   1.  Co  go  charakteryzuje?  -­‐>  IOC   2.  Co  go  odróżnia  od  „normalnego”  Klienta?  -­‐>  IOC   3.  Gdzie  go  mogę  zidentyfikować?  -­‐>  mam  lub   potrzebuję  nowych  narzędzi  –  zazwyczaj   wystarczy  to  co  masz!   18  
19. Co  więc  działa?   4.  Zaimplementuj  detekcję  i  zintegruj  z   procesem  obsługi  Klienta.  Jest  DOBRZE!   5.  Powtarzaj  1-­‐4  lub  równolegle  przejdź  do  6.   6.  Opracuj  plan  działania  by  wcześniej  być   gotowym  na  kolejny  atak  –  z  mniejszą  ilością   udanych  kradzieży  po  zmienia  scenariusza/ wektora  ataku.   19  
20. Co  więc  działa?   •  Co  potrzebujemy?   – Ludzi:  CSIRT  +  IT  +  dostawca  bankowości   – Klasyczne  systemy  bezpieczeństwa  są   wystarczające  –  naprawdę  (!)   •  Co  otrzymamy?   – Skuteczną  detekcję  wszystkich*  znanych  i   częściową,  nieznanych  ataków  na  użytkowników   systemów  transakcyjnych   20  
21. BONUS  (jeśli  mamy  czas)   •  Dedykowane  systemy  detekcji  złośliwego   oprogramowania  dla  bankowości:   1.  Czy  ktoś  zamierza  spróbować?   2.  Czy  ktoś  korzysta(ł)?   3.  Stopień  zadowolenia:  SUPER!  /  ŚREDNIO  /  …   21  
22. Podsumowanie   •  Potencjalne  straty  >  niż  można  to  sobie   wyobrazić   •  Nie  oddawajmy  (klienci,  banki,  dostawcy   bankowości)  walkowerem  pieniędzy   •  Wiem  jak  walczysz  i  nic  nie  stoi  na   przeszkodzie  by  z  Tobą  nie  przegrać!   22  
23. Sesja  Q&A     Dziękuję  za  aktywny  udział!     Do  zobaczenia  w  2016!         przemyslaw.skowron@whitecatsec.com   23