Bezpieczeństwo Systemów Sieciowych dr inż. Łukasz Sturgulewski, luk@kis.p.lodz.pl, http://luk.kis.p.lodz.pl/ dr inż. Andrzej Frączyk, a.fraczyk@kis.p.lodz.pl BSS - v2013 1
Zagrożenia danych Przechwycenie Internet BSS - v2013 2
Zagrożenia danych Fabrykacja Internet BSS - v2013 3
Zagrożenia danych Modyfikacja Internet BSS - v2013 4
Zagrożenia danych Przerwanie Internet BSS - v2013 5
Najistotniejsze cechy przy transmisji danych przez niebezpieczny kanał Poufność. Uwierzytelnianie (i autoryzacja). Autentyczność wiadomości. Integralność wiadomości. BSS - v2013 6
Bezpieczeństwo metod kryptograficznych Zastosowanie bardzo dobrego (silnego) algorytmu szyfrowania. Maksymalna ochrona tajnego klucza. BSS - v2013 7
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
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
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 ę) 32 2 32 35.8 minut 2.15 ms 4.3x10 9 56 2 56 1142 lat 10.01 godzin 16 7.2x10 128 2 128 3.4x10 38 5.4x1024 lat 5.4x10 18 lat BSS - v2013 10
Metody kryptograficzne RSA (Ronald Rivest, Adi Shamir, Leonard Adleman) Kryptografia asymetryczna. z dwoma kluczami Tekst jawny Kodowanie Kryptogram Dekodowanie Tekst jawny BSS - v2013 11
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. http://www.algorytm.org/inne/algorytm-diffie-hellmana.html KSBG (v2013) 12
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 - v2013 13
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 - v2013 14
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 200 000 maszyn z procesorem 2GHz, które mogą obliczyć 2 miliardy funkcji SHA-1 na sekundę, znalezienie kolizji będzie trwało 1475739 sekund czyli zaledwie 17 dni! BSS - v2013 15
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 - v2013 16
Podpis elektroniczny MAC (ang. Message Authentication Code) BSS - v2013 17
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 - v2013 18
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 - v2013 19
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 2007. BSS - v2013 20
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: http://pl.wikipedia.org/wiki/lista_przeglądarek_internetowych BSS - v2013 21
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. http://www.ranking.pl/ 2011r. BSS - v2013 22
Przeglądarki internetowe BSS - v2013 23
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 - v2013 24
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 5246. BSS - v2013 25
Przykłady 2014 rok BSS - v2013 26
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 - v2013 27
http://en.wikipedia.org/wiki/transport_layer_security BSS - v2013 28
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 - v2013 29
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 - v2013 30
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 - v2013 31
Wykorzystanie HTTPS FTPS (nie mylić z SFTP!) SSL VPN i wiele, wiele innych BSS - v2013 32
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 - v2013 33
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 - v2013 34
PKI BSS - v2013 35
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. http://www.europki.pl/polish_ca/help/intro/intro.html BSS - v2013 36
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 - v2013 37
Certyfikaty - specyfikacja X.509 v3 alternatywne nazwy podmiotu, takie jak np. adres e-mail, 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 - v2013 38
Certyfikaty BSS - v2013 39
Certyfikaty Certyfikaty SSL można kupić np. w: Thawte (http://www.thawte.com), VeriSign (http://www.verisign.com), RSA Security (http://www.rsasecurity.com), Entrust (http://www.entrust.com). Najpopularniejszą firmą w Polsce wystawiającą certyfikaty jest Centrum Certyfikacji Unizeto (http://www.certum.pl). Koszt komercyjnego certyfikatu dla pojedynczej nazwy domenowej to wydatek od 29.99 $ rocznie. BSS - v2013 40
CA W3Techs VeriSign Thawte Geotrust BSS - v2013 41
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: https://docs.google.com/spreadsheet/pub?key=0ahthxmawqu3dgx0cgfobg9qm192nfm4uwnbmlbaeke&single=tr ue&gid=1&output=html polityka: http://www.mozilla.org/projects/security/certs/policy/ CA Świat: https://www.tractis.com/help/?p=3670 BSS - v2013 42
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 - v2013 43
BSS - v2013 44
e-mail z WHOIS CA/Browser Forum https://www.cabforum.org/guidelines_v1_4.pdf BSS - v2013 45
http://www.certum.pl/ BSS - v2013 46
BSS - v2013 47
Google Chrome BSS - v2013 48
Przykłady 2014 rok BSS - v2013 49
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 - v2013 50
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 - v2013 51
SSLStrip Działanie: MITM: np. ARP spoofing Przed Po BSS - v2013 52
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 10000. Uruchomienie SSLStrip na porcie 10000. Będzie pośrednikiem pomiędzy serwerem a klientem oraz będzie zapisywał przechwycone dane. BSS - v2013 53
SSLStrip BSS - v2013 54
SSLStrip Konrad Knop Aspekty bezpieczeństwa połączeń sieciowych realizowanych za pomocą rodziny protokołów SSL/TLS. BSS - v2013 55
SSLStrip znak V oznaczał niepowodzenie podsłuchu. BSS - v2013 56
SSLStrip Obrona: Serwery (szyfrowanie całej sesji, id sesji szyfrowane - cookies) Klient (certyfikat, kłódka ;) ) DAI (port-security to zbyt mało!) WPA2 BSS - v2013 57
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 6265. 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 - v2013 58
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 2965. BSS - v2013 59
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 - v2013 60
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 2021 10:18:14 GMT BSS - v2013 61
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 - v2013 62
Cookies (ciasteczka) Zombie cookie Third-party cookie BSS - v2013 63
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 - v2013 64
Firesheep Problem: Ruch szyfrowany: obciążenie serwera większe o około 30%, Kryptografia kosztuje BSS - v2013 65 http://niebezpiecznik.pl/post/firesheep-firefox-ataki-na-sesje/
Firesheep Wtyczka Firesheep wymagania: WinPcap w wersji 4.1.2 Firefox w wersji 3.6.13 Wtyczka odpowiada za przechwytywanie ruchu a dzięki integracji z Firefox pozwala na szybkie użycie, tego co zostało przechwycone. BSS - v2013 66
Firesheep Ma wgranych kilka znanych witryn internetowych np.: facebook.com, twitter.com, google.com. Można dodać własne: BSS - v2013 67
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 - v2013 68
Firesheep Popularnymi stronami, które w chwili publikacji wtyczki były podatne na atak, to: facebook.com hotmail.com BSS - v2013 69
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 - v2013 70
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 - v2013 71
BEAST Zastosowane narzędzia: Java Sniffer sieciowy Przeglądarka internetowa (MITB) Plaintext wstrzyknięty do przeglądarki Ujawnienie ID sesji z ciasteczka. BSS - v2013 72
BEAST wymagane podaności SSLv3 lub TLSv1 używające szyfrowania CBC. Błąd w Java SOP - System.out.println(). BSS - v2013 73
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 - v2013 74
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 - v2013 75
BEAST Interesujący blok do szyfrowania w hex może wyglądać: 7365737369643d35 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 - v2013 76
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 - v2013 77
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 - v2013 78
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 - v2013 79
CRIME Cel: odgadnięcie zawartości szyfrowanego ciasteczka. Tylko gdy: komunikacja jest kompresowana za pomocą jednego z algorytmów, na przykład DEFLATE. BSS - v2013 80
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 - v2013 81
CRIME Wymuszenie wysłania (modyfikacja żądania) klienta: sessid=4 oraz sessid=7 BSS - v2013 82
CRIME Następnie kompresja DEFLATE. Co da krótszy szyfrogram??? Problem dane kontrolowane przez atakującego są kompresowane wspólnie z poufnymi danymi. BSS - v2013 83
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). http://www.youtube.com/watch?v=ggphhyyg9r4 BSS - v2013 84
TestSSLServer Program TestSSLServer został opracowany przez Thomasa Pornina i sprawdza strony internetowe pod kątem zabezpieczeń rodziną protokołów SSL/TLS. BSS - v2013 85
TestSSLServer BSS - v2013 86
https://www.howsmyssl.com BSS - v2013 87
Bezpieczeństwo połączeń SSL http://niebezpiecznik.pl/post/nsa-jest-w-stanierozszyfrowywac-polaczenia-ssl-4g-vpn-i-ssh-czy-to-koniecbezpiecznej-komunikacji-w-internecie/ 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 - v2013 88
Co dalej? VPN IDS, IPS Application Firewall (zagrożenia w warstwie aplikacji głównie web w tym także DNS) TOR Sandbox, Honeypot BSS - v2013 89
BSS KONIEC BSS - v2013 90