Bezpieczeństwo Systemów Sieciowych

Transkrypt

1 Bezpieczeństwo Systemów Sieciowych dr inż. Łukasz Sturgulewski, dr inż. Andrzej Frączyk, BSS - v2013 1

2 Zagrożenia danych Przechwycenie Internet BSS - v2013 2

3 Zagrożenia danych Fabrykacja Internet BSS - v2013 3

4 Zagrożenia danych Modyfikacja Internet BSS - v2013 4

5 Zagrożenia danych Przerwanie Internet BSS - v2013 5

6 Najistotniejsze cechy przy transmisji danych przez niebezpieczny kanał Poufność. Uwierzytelnianie (i autoryzacja). Autentyczność wiadomości. Integralność wiadomości. BSS - v2013 6

7 Bezpieczeństwo metod kryptograficznych Zastosowanie bardzo dobrego (silnego) algorytmu szyfrowania. Maksymalna ochrona tajnego klucza. BSS - v2013 7

8 Metody kryptograficzne DES, 3DES, AES Kryptografia symetryczna. z jednym kluczem Tekst jawny Kodowanie Kryptogram Dekodowanie Tekst jawny UWAGA!! Problemem jest wymiana klucza pomiędzy jednostkami przez niebezpieczne medium. BSS - v2013 8

9 Algorytm DES 32 bits 32 bits 28 bits 28 bits Li-1 Ri-1 Ci-1 Di-1 Initial permutation Pemuted Choice 1 Round 1 K1 Permuted Choice 2 Left circular shift Expansion/permutation (E table) Left shift(s) Left shift(s) Round 2 K2 Permuted Choice 2 Left circular shift F 48 XOR 48 Ki Permutation/contraction (Permuted Choice 2) 48 Substitution/choice (S-box) Round 16 K16 Permuted Choice 2 Left circular shift 32 Permutation (P) 32-bit swap 32 Inverse initial permutation XOR Li Ri Ci Di BSS - v2013 9

10 Atak siłowy na kryptogram Rozmiar klucza (bity) Liczba możliwych kombinacji Czas wyszukiwania klucza (1 klucz na mikrosekund ę) Czas wyszukiwania klucza (10 6 kluczy na mikrosekund ę) minut 2.15 ms 4.3x lat godzin x x x1024 lat 5.4x10 18 lat BSS - v

11 Metody kryptograficzne RSA (Ronald Rivest, Adi Shamir, Leonard Adleman) Kryptografia asymetryczna. z dwoma kluczami Tekst jawny Kodowanie Kryptogram Dekodowanie Tekst jawny BSS - v

12 Algorytm Diffie-Hellman'a Alicja i Bob wyznaczają dwie liczby: p będącą liczbą pierwsza oraz g (zwany generatorem) mniejsze od p (z następującymi właściwościami: dla każdego n pomiędzy 1 i p-1 włącznie, istnieje potęga takiego k od g że n = gk mod p). Protokół ten zakłada że jest niewykonalne obliczenie K, jedynie na podstawie wartości publicznych Alicji i Boba jeżeli p jest dostatecznie duże. KSBG (v2013) 12

13 Podpis elektroniczny Główne cechy: Łatwy do sprawdzenia; Trudny do podrobienia; Jednoznacznie określający nadawcę. Zastosowanie znanych metod kodowania. Zastosowanie funkcji mieszających. UWAGA!! Algorytm generujący podpis nie musi być odwracalny! BSS - v

14 Funkcje mieszające Główne cechy dobrej funkcji mieszającej: spójność; unikalność; jednokierunkowość; małe zmiany na wejściu = duże zmiany na wyjściu. BSS - v

15 Funkcje mieszające Najpopularniejsze funkcje mieszające: MD5 SHA-1 Atak brutalny dla tego algorytmu wymaga wykonania 2^80 operacji. Atak chińskich kryptologów Xiaoyun Wang, Yiqun Lisa Yin, i Hongbo Yu ogranicza liczbę wymaganych operacji do 2^69 co nadal pozostaje trudne do zrealizowania na pojedynczych maszynach. Mając jednak do dyspozycji maszyn z procesorem 2GHz, które mogą obliczyć 2 miliardy funkcji SHA-1 na sekundę, znalezienie kolizji będzie trwało sekund czyli zaledwie 17 dni! BSS - v

16 Funkcje mieszające Kolejne etapy działania funkcji: Dodanie bitów paddingu. Dodanie informacji o długości wiadomości. Inicjalizacja bufora. Przetwarzanie wiadomości w 512-bitowych blokach. Wynik. BSS - v

17 Podpis elektroniczny MAC (ang. Message Authentication Code) BSS - v

18 Przykładowy proces szyfrowania Nadawca koduje wiadomość (użycie klucza publicznego otrzymanego od adresata). Nadawca dołącza podpis elektroniczny (użycie klucza prywatnego nadawcy). Wysłanie tak spreparowanej wiadomości niebezpiecznym kanałem. Adresat rozkodowuje wiadomość (użycie klucza prywatnego). Adresat weryfikuje podpis (użycie klucza publicznego otrzymanego od nadawcy). BSS - v

19 Przeglądarki internetowe NCSA Mosaic najpopularniejsza z pierwszych przeglądarek WWW, które działały w trybie graficznym. Została ona przygotowana przez NCSA (National Center for Supercomputing Applications) na uniwersytecie w Illinois w 1993 roku. W 1997 NCSA oficjalnie ogłosiło koniec prac nad programem. Od NCSA Mosaic wywodzą się przeglądarki Netscape Navigator i Windows Internet Explorer. BSS - v

20 Przeglądarki internetowe Netscape Navigator Netscape Communicator (przeglądarka, program pocztowy, edytor HTML, komunikator, kalendarz) Netscape Netscape Navigator Napisana przez amerykańską firmę Netscape Communications Corporation potem przejęta przez AOL. Pierwsza wersja programu pojawiła się w roku 1994, ostatnia, 9. wersja programu ukazała się w roku BSS - v

21 Przeglądarki internetowe W 1995 r. (sierpień) został wydany Internet Explorer 1 W 2002 r. Korporacja Mozilla: Phoenix -> Firebird -> Firefox W 1996 r. norweska firma Opera Software ASA: Opera Do wersji 4.x włącznie, Opera rozprowadzana była na zasadach shareware, następnie od wersji 5.x do 8.50 na licencji adware (z możliwością wyłączenia reklam po zakupie klucza licencyjnego). Od 20 września 2005 jest programem w pełni darmowym na licencji freeware. W 2008 r. Google: Google Chrome (silnik WebKit) W 2003 r. Apple: Safari (silnik WebKit; system Mac OS X a od 2007 Windows) Lista przeglądarek internetowych: BSS - v

22 Przeglądarki internetowe Raport z badania przeprowadzonego przez firmę Gemius, mającego na celu opracowanie między innymi rankingu popularności przeglądarek i systemów operacyjnych r. BSS - v

23 Przeglądarki internetowe BSS - v

24 SSL, TLS SSL (ang. Secure Socket Layer) TLS (ang. Transport Layer Security) SSL jest protokołem sieciowym używanym do bezpiecznych połączeń internetowych. Został opracowany przez firmę Netscape Communications Corporation w 1994r. Początkowo jako standard szyfrowania dla WWW (HTTP). Działa w warstwie sesji/prezentacji, a więc można łatwo zastosować go do zabezpieczenia różnych protokołów warstwy aplikacyjnej. BSS - v

25 SSL, TLS SSL 1 brak weryfikacji procedury uzgadniania szyfru, SSL 2 wersja weryfikuje procedurę negocjacyjną, SSL 3 już w roku 1995! (w tym wybrany do obsługi transakcji bankowych oraz płatności kartami płatniczymi), TLS 1.0 rozwinięcie SSL 3 (SSL 3.1) opisane w RFC 2246, standard IETF (Internet Engineering Task Force) TLS 1.1 wersja opisana w RFC 4346, zalecana przez IETF jako standard i obecnie najczęściej używana, TLS 1.2 RFC BSS - v

26 Przykłady 2014 rok BSS - v

27 TLS Trzy fazy pracy protokołu TLS: Negocjacja z klientem wspieranych algorytmów szyfrowania ( uścisk dłoni TLS handshake TLS): Asymetryczna kryptografia: RSA, Diffie-Hellman, DSA; Symetryczna kryptografia: RC2, RC4, IDEA, DES, Triple DES, AES, Camellia; Funkcje mieszające: MD2, MD4, MD5, SHA-1, SHA-2. Wymiana klucza publicznego i certyfikatu. Transmisja danych szyfrowanie symetryczne. BSS - v

28 BSS - v

29 TLS - Ustanowienie połączenia Wymiana komunikatów klient-serwer Przed rozpoczęciem transmisji muszą być wykonane następujące działania pomiędzy serwerem a klientem: Klient wysyła komunikat ClientHello zawierający: najwyższą obsługiwaną wersje protokołu TLS, losową liczbę, listę sugerowanych algorytmów szyfrowania i kompresji. Serwer odpowiada komunikatem ServerHello, zawierającym: wybraną wersję protokołu, losową liczbę, wybrany zestaw algorytmów szyfrowania i kompresji. Serwer wysyła swój certyfikat - Certificate (zgodny ze standardem X.509) Serwer wysyła informację o swoim kluczu publicznym ServerKeyExchange BSS - v

30 TLS - Ustanowienie połączenia Wymiana komunikatów klient-serwer Serwer wysyła komunikat ServerHelloDone, o zakończeniu negocjacji. Klient odpowiada komunikatem ClientKeyExchange, który może zawierać PreMasterSecret, klucz publiczny, lub nic (w zależności od wynegocjowanych algorytmów szyfrowania). Klient i Serwer używają liczb losowych oraz PreMasterSecret do obliczenia symetrycznego klucza zwanego MasterSecret. Klient wysyła komunikat ChangeCipherSpec, przekazując Serwerowi informacje wszystko co zostanie teraz wysłane będzie szyfrowane. Ostatecznie klient wysyła już zaszyfrowany komunikat Finished, z MAC (Message Authentication Code) poprzedniego komunikatu. BSS - v

31 TLS - Ustanowienie połączenia Wymiana komunikatów klient-serwer Serwer sprawdza czy MAC jest poprawny, jeśli tak to wysyła ChangeCipherSpec oraz jego zaszyfrowana wersję Finished. Klient sprawdza poprawność MAC, jeśli wszystko jest prawidłowo można rozpocząć przesyłanie danych. BSS - v

32 Wykorzystanie HTTPS FTPS (nie mylić z SFTP!) SSL VPN i wiele, wiele innych BSS - v

33 PKI (ang. Public Key Infrastructure) Infrastruktura Klucza Publicznego Problem, potrzeba certyfikatów: Zagrożenie pojawia się, gdy klucz publiczny jednej ze stron zastąpiony zostanie kluczem publicznym intruza. Nieświadoma druga strona zaszyfruje wiadomość takim kluczem i umożliwi intruzowi jej odczytanie!!! Sposobem na uniknięcie takiej sytuacji jest certyfikacja klucza publicznego: Zakłada się istnienie tzw. zaufanej trzeciej strony, czyli instytucji, której ufają komunikujące się ze sobą strony. Wydaje ona certyfikaty, które stwierdzają autentyczność klucza publicznego oraz prawo używania go przez daną osobę. Takie właśnie instytucje, zwane urzędami certyfikacji CA (ang. Certification Authority), tworzą PKI. BSS - v

34 PKI (ang. Public Key Infrastructure) Infrastruktura Klucza Publicznego PKI jest koncepcją zawierającą w sobie wszystkie niezbędne elementy do pewnej i bezpiecznej wymiany danych oraz zapewnienia prawdziwości i tożsamości podmiotów. PKI może składać się z wielu komponentów takich jak użytkownicy, centra autoryzacyjne czy rejestracyjne, certyfikaty, katalogi, listy certyfikatów (platforma serwisowa dla klientów). PKI to kombinacja elementów oprogramowania, technologii kodujących, procesów i usług, które pozwalają organizacji zabezpieczyć jej kanały transmisyjne i wykonywane transakcje. PKI bazuje na wymianie cyfrowych dowodów tożsamości (certyfikatów) pomiędzy uwierzytelnionym użytkownikiem a zaufanym zasobem. Certyfikaty mogą służyć do zabezpieczenia danych i potwierdzania tożsamości użytkowników i komputerów zarówno wewnątrz danej firmy, jak i pomiędzy różnymi organizacjami. BSS - v

35 PKI BSS - v

36 PKI Najważniejszą częścią struktury jest Główny Urząd Certyfikacji (ang. Root Certification Authority). Podlegają mu pośrednie urzędy certyfikacji, które wydają certyfikaty użytkownikom końcowym. W PKI występuje jeszcze pojęcie urzędu rejestracji (ang. Registration Authority). Urząd rejestracji sprawdza tożsamość użytkowników na podstawie dostarczonych przez nich dokumentów. Procedura ta ma na celu powiązanie tożsamości osoby z wydawanym cyfrowym certyfikatem. W celu usprawnienia procesu można utworzyć wiele urzędów rejestracji podlegających jednemu urzędowi certyfikacji. Urząd certyfikacji natomiast ma za zadanie wystawić certyfikat, oczywiście po potwierdzeniu tożsamości tej osoby przez urząd rejestracji. Certyfikat ten jest umieszczany w repozytorium, a następnie publikowany np. przez WWW lub usługę katalogową LDAP, skąd może zostać pobrany. BSS - v

37 Certyfikaty - specyfikacja X.509 v1 podmiot (subject) nazwa komputera, użytkownika, urządzenia sieciowego, usługi czy firmy dla której certyfikat został wystawiony. Podmiot jest najczęściej definiowany przez nazwę zgodną z formatem X.500 lub LDAP, numer seryjny w unikalny sposób wyróżnia dany konkretny certyfikat (każdy podmiot może mieć ich wiele) wystawiony przez dany urząd, wydawca w pełni kwalifikowana (X.500 lub LDAP) nazwa urzędu, który dany certyfikat wystawił, ważny od data i czas, od kiedy certyfikat może być używany, ważny do określa datę i czas, po którym wygasa ważność certyfikatu, klucz publiczny pole zawiera klucz publiczny podmiotu, związany z odpowiednim (przechowywanym poza certyfikatem) kluczem prywatnym, BSS - v

38 Certyfikaty - specyfikacja X.509 v3 alternatywne nazwy podmiotu, takie jak np. adres , nazwa logowania UPN, czy inne nazwy w dowolnych formatach, punkty dystrybucyjne CRL pozwalają odbiorcy certyfikatu sprawdzić w trybie online czy dany certyfikat nie został wycofany przez urząd, który go wystawił, tzw. AIA (Authority Information Access) - adres, który pozwala na sprawdzenie certyfikatu samego urzędu CA, rozszerzone użycie kluczy (enhanced key usage) pole zawiera identyfikatory OID aplikacji i usług, które mogą korzystać z kluczy skojarzonych z certyfikatem, polityki certyfikatów - określają w jaki sposób może być sprawdzona autentyczność podmiotu ubiegającego się o wystawienie certyfikatu. BSS - v

39 Certyfikaty BSS - v

40 Certyfikaty Certyfikaty SSL można kupić np. w: Thawte ( VeriSign ( RSA Security ( Entrust ( Najpopularniejszą firmą w Polsce wystawiającą certyfikaty jest Centrum Certyfikacji Unizeto ( Koszt komercyjnego certyfikatu dla pojedynczej nazwy domenowej to wydatek od $ rocznie. BSS - v

41 CA W3Techs VeriSign Thawte Geotrust BSS - v

42 Certification Authorities Rynek certyfikatów SSL jest raczej mały, opanowany przez kilka dużych, międzynarodowych firm. Barierą dla nowych są szczegółowe audyty bezpieczeństwa (takie jak WebTrust dla CA) konieczne aby znaleźć się na liście zaufanych CA w przeglądarkach. Ponad 50 CA posiada status zaufanych w aktualnych wersjach popularnych przeglądarek. Mozilla Firefox: ue&gid=1&output=html polityka: CA Świat: BSS - v

43 Certum CERTUM Powszechne Centrum Certyfikacji zostało uruchomione 15 grudnia 1998 roku, jako jednostka organizacyjna Unizeto Technologies SA, świadcząca usługi certyfikacyjne związane z podpisem elektronicznym. Jest to najstarsze i największe publiczne centrum certyfikacji w Polsce. Zlokalizowane jest w Szczecinie, w nowoczesnym budynku zapewniającym infrastrukturze i systemom CERTUM ciągłość działania oraz bardzo wysoki stopień bezpieczeństwa elektronicznego, mechanicznego i dostępowego. Unizeto Technologies SA jest wiodącym dostawcą usług certyfikacyjnych związanych z podpisem elektronicznym oraz dostawcą technologii e-podpisu i PKI (Public Key Infrastructure) w Polsce. Opracowane przez nas systemy i świadczone usługi znajdują uznanie odbiorców na całym świecie. Produkty związane z podpisem elektronicznym oferujemy klientom biznesowym i indywidualnym oraz administracji publicznej, np. certyfikaty kwalifikowane, certyfikaty ID, certyfikaty SSL, certyfikaty do podpisywania kodu i certyfikaty VPN. BSS - v

44 BSS - v

45 z WHOIS CA/Browser Forum BSS - v

46 BSS - v

47 BSS - v

48 Google Chrome BSS - v

49 Przykłady 2014 rok BSS - v

50 Ataki SSLStrip (Moxie Marlinspike, Black Hat DC, 2009) rodzaj pośrednika (proxy) zazwyczaj używani do szyfrowania danych (tunele VPN, sieci TOR) W tym przypadku do deszyfrowania. Atak typu MITM BSS - v

51 SSLStrip Problemy i ułatwienia ataku: http a nie https w przeglądarce ale strony z mieszaną zawartością Bardzo groźne! Brak szansy na dostrzeżenie ataku. ale reakcja użytkownika na alerty Tak też często działają firewall e: przy czym ruch klient firewall jest szyfrowany. BSS - v

52 SSLStrip Działanie: MITM: np. ARP spoofing Przed Po BSS - v

53 SSLStrip Przekierowanie ruchu skierowanego z przeglądarki internetowej na port 80 na port, na którym będzie nasłuchiwał SSLStrip. Domyślnie SSLStrip korzysta z portu Uruchomienie SSLStrip na porcie Będzie pośrednikiem pomiędzy serwerem a klientem oraz będzie zapisywał przechwycone dane. BSS - v

54 SSLStrip BSS - v

55 SSLStrip Konrad Knop Aspekty bezpieczeństwa połączeń sieciowych realizowanych za pomocą rodziny protokołów SSL/TLS. BSS - v

56 SSLStrip znak V oznaczał niepowodzenie podsłuchu. BSS - v

57 SSLStrip Obrona: Serwery (szyfrowanie całej sesji, id sesji szyfrowane - cookies) Klient (certyfikat, kłódka ;) ) DAI (port-security to zbyt mało!) WPA2 BSS - v

58 HTTP cookies (ciasteczka) Początkowo serwer nie miał mechanizmów pozwalających na stwierdzenie czy dwa zapytania pochodzą z tej samej przeglądarki. Podstawowy problem dotyczył zalogowanych użytkowników i utrzymania ich w tym stanie przez cały czas pobytu na serwerze. To ograniczenie zostało rozwiązane przez firmę Netscape poprzez wprowadzenie technologii zwanej "cookies" już w pierwszej wersji Netscape Navigator. Jak działają cookies zostało opisane w RFC Jeśli serwer otrzyma żądanie HTTP może w odpowiedzi wysłać nagłówek z Set-Cookie. Następnie otrzymane wartości cookies są wysyłane w każdym żądaniu (nagłówku HTTP) od klienta do serwera. Dodatkowo czas wygaśnięcia może zostać określony. Ograniczenia do określonej domeny, ścieżki oraz protokołu i szyfrowania mogą zostać określone. BSS - v

59 Cookies (ciasteczka) Request for Comments: 6265 HTTP State Management Mechanism Abstract This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC BSS - v

60 Cookies (ciasteczka) Cookie zwiera nie więcej niż 255 znaków i nie może zajmować więcej niż 4K miejsca na dysku. Parametry cookie: Name of the cookie Value of the cookie The Max-Age Attribute The Domain Attribute The Path Attribute The Secure Attribute The HttpOnly Attribute I wiele, wiele innych określonych przez twórców stron np. Cookiepolicy: accept BSS - v

61 Przykład == Server -> User Agent == Set-Cookie: SID=31d4d96e407aad42; Path=/; Secure; HttpOnly Set-Cookie: Path=/; Domain=example.com Set-Cookie: lang=en-us; Expires=Wed, 09 Jun :18:14 GMT BSS - v

62 Cookies (ciasteczka) Bank PEKAO SA: W serwisach Banku pliki cookies wykorzystywane są w celu: dostosowania zawartości stron internetowych Serwisu do preferencji Użytkownika oraz optymalizacji korzystania ze stron internetowych; w szczególności pliki te pozwalają rozpoznać urządzenie Użytkownika Serwisu i odpowiednio wyświetlić stronę internetową, dostosowaną do jego indywidualnych potrzeb; (Personalization) tworzenia statystyk, które pomagają zrozumieć, w jaki sposób Użytkownicy Serwisu korzystają ze stron internetowych, co umożliwia ulepszanie ich struktury i zawartości; (Tracking) utrzymanie sesji Użytkownika Serwisu (po zalogowaniu), dzięki której Użytkownik nie musi na każdej podstronie Serwisu ponownie wpisywać loginu i hasła. (Session management) BSS - v

63 Cookies (ciasteczka) Zombie cookie Third-party cookie BSS - v

64 Firesheep (łatwa kradzież ciastek) atak typu Session Hijacking przejęcie identyfikatora sesji zaszytego w ciasteczku (cookies), które zostają wysłane przez niezabezpieczony protokół HTTP (przejęcia ciasteczka). problem: zabezpieczanie jedynie procesu logowania strony zamiast całej komunikacji z nią. Eric Butler, 2010 BSS - v

65 Firesheep Problem: Ruch szyfrowany: obciążenie serwera większe o około 30%, Kryptografia kosztuje BSS - v

66 Firesheep Wtyczka Firesheep wymagania: WinPcap w wersji Firefox w wersji Wtyczka odpowiada za przechwytywanie ruchu a dzięki integracji z Firefox pozwala na szybkie użycie, tego co zostało przechwycone. BSS - v

67 Firesheep Ma wgranych kilka znanych witryn internetowych np.: facebook.com, twitter.com, google.com. Można dodać własne: BSS - v

68 Firesheep W niezabezpieczonej sieci (ARP spoofing, sieci WiFi) program powinien działać bez problemów, jeśli znajdzie użytkownika, który próbuje wejść na stronę znaną przez wtyczkę. Wtedy po prawej stronie przeglądarki pojawią się strony, które można kliknąć w celu przejęcia dostępu. Z powodu działania programu tylko na identyfikatorze sesji, nie jest możliwa na przykład zmiana hasła, ponieważ nie jest znane hasło oryginalne, co jest wymagane do tej operacji w większości przypadków. Niektóre serwisy wiążą identyfikatory sesji z adresem IP, ale w przypadku gdy i atakujący i atakowany znajdują się za tym samym NAT, z reguły nie jest to problemem. BSS - v

69 Firesheep Popularnymi stronami, które w chwili publikacji wtyczki były podatne na atak, to: facebook.com hotmail.com BSS - v

70 Firesheep Rozwiązania: Po stronie serwera: ustawiając ciastko klientowi, można skorzystać z flagi Secure, która gwarantuje, że zawartość ciastka zostanie wysłana tylko wtedy, kiedy przeglądarka rozmawia z serwerem po HTTPS. Pełne szyfrowanie SSL/TLS koszt głównie po stronie serwerów. Po stronie klienta: przed podsłuchaniem można się chronić np. przy pomocy tuneli SSH lub połączeń z niezaufanych sieci poprzez zaufany VPN. Lokalny atakujący zobaczy wtedy zaszyfrowane dane (ciastka), ale zawsze jest ryzyko podsłuchu po drugiej stronie tunelu Dodatki do Firefoks: HTTPS Everywhere oraz Force TLS, które chronią ciastka poprzez wymuszanie połączeń HTTPS z serwerami (o ile te je wspierają!). BSS - v

71 BEAST Atak ten został opracowany przez Juliano Rizzo oraz Thai Duong i opublikowany na Ekoparty w 2011r. Atak na sesje szyfrowane za pomocą rodziny protokołów SSL/TLS. BSS - v

72 BEAST Zastosowane narzędzia: Java Sniffer sieciowy Przeglądarka internetowa (MITB) Plaintext wstrzyknięty do przeglądarki Ujawnienie ID sesji z ciasteczka. BSS - v

73 BEAST wymagane podaności SSLv3 lub TLSv1 używające szyfrowania CBC. Błąd w Java SOP - System.out.println(). BSS - v

74 BEAST Dlaczego sessid jest taki ważny i pożądany? Nagłówek HTTP jest przewidywalny, zawiera także dane z ciasteczka, coś w stylu: Cookie: sessid=5ec20c5e8c2ebe595ab0 BSS - v

75 BEAST Wyrównanie: BEAST wysyła żądania różnej długości (z zaatakowanego hosta) aż osiągnie podział na bloki jak poniżej: Cookie: sessid=5 ec20c5e8 c2ebe595 ab0 Teraz BEAST może rozpocząć odgadywanie pierwszej liczby z sessid. Jeśli to hex to ma 16 możliwości zakłada np. 5. BSS - v

76 BEAST Interesujący blok do szyfrowania w hex może wyglądać: d35 Niech poprzedni blok zaszyfrowany będzie wyglądał tak: de3bedcee3ade70a XOR obu danych: ad5e9ebd8ac9da3f Szyfrogram tego XOR: 0165b037d2e44954 Jeśli wartość została odgadnięta prawidłowo to przeglądarka zaszyfruje ad5e9ebd8ac9da3f i otrzyma 0165b037d2e44954 BSS - v

77 BEAST A teraz sprawdzenie czy tak faktycznie jest. Ostatni zaszyfrowany blok: F4e52a1a9f11f116 Beast wstrzykuje do przesłania (do szyfrowania) tekst jawny: 59bbb4a715d82b29 taki aby XOR jego z szyfrogramem dał: ad5e9ebd8ac9da3f Jeśli szyfrogram będzie miał wartość: 0165b037d2e44954 Wartość 5 została odgadnięta prawidłowo BSS - v

78 CRIME Atak ten został opracowany przez Juliano Rizzo oraz Thai Duong i opublikowany na Ekoparty w 2012 roku w Argentynie. Atak na sesje szyfrowane za pomocą rodziny protokołów SSL/TLS. BSS - v

79 CRIME Pierwszym etapem ataku jest wstrzyknięcie w przeglądarkę ofiary krótkiego kodu napisanego w JavaScript, który pozwoli generować ruch w atakowanym komputerze. Drugim krokiem jest podsłuch generowanego ruchu, na przykład przez atak typu ARP Spoof. BSS - v

80 CRIME Cel: odgadnięcie zawartości szyfrowanego ciasteczka. Tylko gdy: komunikacja jest kompresowana za pomocą jednego z algorytmów, na przykład DEFLATE. BSS - v

81 CRIME Komunikacja z bankiem o adresie nazwabanku.pl, przeglądarka wysyła w każdym żądaniu: Host: nazwabanku.pl Cookie: sessid=4x312dg3wadv Szyfrowane powiązanie żądania z user em! BSS - v

82 CRIME Wymuszenie wysłania (modyfikacja żądania) klienta: sessid=4 oraz sessid=7 BSS - v

83 CRIME Następnie kompresja DEFLATE. Co da krótszy szyfrogram??? Problem dane kontrolowane przez atakującego są kompresowane wspólnie z poufnymi danymi. BSS - v

84 CRIME Rozwiązanie: Wyłączenie kompresji, ale 42% serwerów web ma ją włączoną, choć 93% przeglądarek ma ją wyłączona (głównie dzięki aktualizacjom). BSS - v

85 TestSSLServer Program TestSSLServer został opracowany przez Thomasa Pornina i sprawdza strony internetowe pod kątem zabezpieczeń rodziną protokołów SSL/TLS. BSS - v

86 TestSSLServer BSS - v

87 BSS - v

88 Bezpieczeństwo połączeń SSL Protokół SSL/TLS i kryptografia są BARDZO DOBRE! Działania NSA polegają na: Znanych przez wszystkich atakach słownikowych mających na celu odgadnięcie hasła. Wprowadzaniu backdoorów do oprogramowania lub urządzeń, zazwyczaj poprzez oficjalny kontakt z producentami. Przekabacaniu pracowników firm IT. Projektowaniu słabości w standardach i naciskach, które umożliwią wejście tych słabości do powszechnego użytku. Włamywaniu się do twojego komputera i uzyskiwaniu dostępu do zaszyfrowanych treści przed ich zaszyfrowaniem lub po ich rozszyfrowaniu. BSS - v

89 Co dalej? VPN IDS, IPS Application Firewall (zagrożenia w warstwie aplikacji głównie web w tym także DNS) TOR Sandbox, Honeypot BSS - v

90 BSS KONIEC BSS - v