ݺߣ

ݺߣShare a Scribd company logo

Ataki po stronie klienta w publicznych punktach dostępowych

•Download as PPTX, PDF•
•
Pawel Rzepa
Pawel Rzepa

Ataki po stronie klienta w publicznych punktach dostępowych”. Coraz więcej restauracji i hoteli decyduje się na otwarcie publicznych punktów dostępowych. Wizja darmowego surfowania po Internecie wydaje się dla wielu atrakcyjna, ale czy na pewno bezpieczna? Czy można przechwycić dane przesyłane do "bezpiecznej" aplikacji? Czy szyfrowanie to droga dla paranoików, czy jedyne słuszne rozwiązanie?

1 of 28
Download to read offline
Ataki po stronie klienta w publicznych punktach dostępowych Paweł Rzepa
Agenda • Kim jestem • Zarys problemu • Środowisko testowe • SSLstrip • SSLsplit • Metody obrony przed atakami MitM • Dnsspoof • Złośliwy kod w Captive Portals • Wnioski • Dla zainteresowanych
Kim jestem? • Specjalista ds. bezpieczeństwa w organizacji EY. • Na co dzień zajmuję się szukaniem podatności w wewnętrznych aplikacjach EY. • Kontakt: pawel.rzepa@outlook.com https://pl.linkedin.com/pub/pawel-rzepa/5b/696/532
Zarys problemu, czyli skąd pomysł na tą prezentację? • Mit 1. Jak aplikacja działa na HTTPS to niemożliwe są ataki MitM. • Mit 2. Jeżeli aplikacja używa flagi secure to niemożliwe są ataki MitM. Niestety nie zawsze jest to prawdą! A ponadto: • Większość aplikacji, które testuję zezwalają na transmisję HTTP (poprzez wymuszenie http:// w adresie, lub zmianę User Agent) i/lub nie mają zaimplementowanej flagi secure.
Flaga secure • Atrybut „secure” w nagłówku Set-Cookie wymusza użycie protokołu HTTPS do transmisji ciasteczek. Więcej o implementacji flagi secure: https://www.owasp.org/index.php/SecureFlag
Środowisko testowe – WiFi Pineapple • To zwyczajny Router WiFi z niezwyczajnym soft’em Więcej na https://www.wifipineapple.com/
WiFi Pineapple – połączenie z Internetem • Może korzystać z Internetu mobilnego (modem 3/4G) • Może pracować jednocześnie jako klient innego AP i rozgłaszać swoją sieć. • Może w ogóle nie mieć podłączenia do Internetu i dalej być wartościowy.
WiFi Pineapple – połączenie z klientem • Rozgłaszanie otwartej sieci WiFi pod zachęcającą nazwą (np. „Miejski Internet”). • Fałszywy AP – podstawienie pod istniejącą sieć. • Podszycie się pod sieć szukaną przez urządzenie końcowe (Karma).
SSLstrip • SSLstrip po prostu wymusza przekierowanie żądania na port HTTP. • Wciąż możliwe w niektórych aplikacjach.
SSLstrip • Przykład:
SSLstrip • I jeszcze jeden...
SSLsplit • SSL/TLS proxy. • Przedstawia się klientowi dynamicznie wygenerowanym certyfikatem. • Nie działa na portale, używające HSTS, ale...
SSLsplit • ...nie wszystkie portale używają HSTS...
Co jest nie tak? Co robić? Jak żyć?! • Stosować nagłówek HTTP Strict Transport Security (HSTS). Wymusza transmisję HTTPS oraz nie zezwala na akceptację niezaufanego certyfikatu.
Co jest nie tak? Co robić? Jak żyć?! • Stosować Certificate Pinning – „na sztywno” przypisany certyfikat do klienta (aplikacji mobilnej, przeglądarki). Połączenie jest ustanowione tylko gdy certyfikat jest zaufany. • Stosować tylko certyfikaty podpisane przez zaufane Certificate Authority – piękne, ale czy realne?
Chain of trust • Hierarchicznie Certificate Authority gwarantują, że dany certyfikat jest prawdziwy. • Podpisanie certyfikatu wiąże się z dodatkowymi kosztami, dlatego nie każdy decyduje się na ten krok (powszechny problem w aplikacjach mobilnych).
Czy grozi nam coś jeszcze? • Załóżmy, że mamy to wszystko – czy grozi nam jeszcze jakieś niebezpieczeństwo? • Odp: Oczywiście  • Dnsspoof • Captive Portals ze złośliwym kodem • Podatności w samym SSL (więcej na ten temat https://www.digicert.com/cert-inspector- vulnerabilities.htm#certificate_vulnerabilities) • Podatności w TLS, czyli Key Compromise Impersonation (więcej https://kcitls.org/) • Podstawienie plików aktualizacyjnych na złośliwe (np. peinjector https://peinjector.eu/ czy evilgrade http://www.infobyte.com.ar/down/isr-evilgrade-Readme.txt)
Dnsspoof – stary, ale wciąż jary! • Czyli przekierowanie dowolnej nazwy domeny na kopię własnej strony.
Dnsspoof
Dnsspoof
Obrona prrzed Dnsspoof • HTTPS w adresie! • VPN z proxy z przypisanym DNS (np. korporacyjny VPN) • Mimo to zawsze ktoś się nabierze 
Captive Portals z BeEF hook • Captive Portal czyli strona, która wyświetli się jako pierwsza zanim nastąpi przekierowanie na żądaną stronę.
Captive Portals z BeEF hook • Nic nie stoi na przeszkodzie, aby umieścić tam dowolny kod, np. BeEF hook.js 
Captive Portals z BeEF hook
Captive Portals z BeEF hook
Obrona przed złośliwym kodem na Captive Portals • Wyłączona obsługa skryptów? • Chrome extension? http://blog.cylance.com/vegan-chrome- extension-to-defeat-beef • Zaktualizowana przeglądarka + zdrowy rozsądek 
Wnioski • Komunikacja nieszyfrowana to zeszła epoka! • Szyfrowanie to metoda na ataki MitM, ale tylko jeśli jest WŁAŚCIWIE zaimplementowane! • Sama flaga secure to za mało. Należy ją uzupełnić o nagłówek HSTS! • Stosuj certificate pinning! • Multi-factor Authentication do poufnych operacji! • Duża ostrożność w stosowaniu publicznych punktów dostępu! • Wyłącz łączenie się przez WiFi jeśli z niego nie korzystasz!
Dla zainteresowanych tematem • Wszystko, co powinieneś wiedzieć o komunikacji szyfrowanej: https://www.owasp.org/index.php/Transport_Layer_Protec tion_Cheat_Sheet • Dobrze wytłumaczone działanie HSTS: http://sekurak.pl/hsts-czyli-http-strict-transport-security/ • Ataki na Pineapple też są możliwe: http://www.networkworld.com/article/2462478/microsoft- subnet/hacker-hunts-and-pwns-wifi-pineapples-with-0-day- at-def-con.html

More Related Content

Ataki po stronie klienta w publicznych punktach dostępowych

  • 1. Ataki po stronie klienta w publicznych punktach dostępowych Paweł Rzepa
  • 2. Agenda • Kim jestem • Zarys problemu • Środowisko testowe • SSLstrip • SSLsplit • Metody obrony przed atakami MitM • Dnsspoof • Złośliwy kod w Captive Portals • Wnioski • Dla zainteresowanych
  • 3. Kim jestem? • Specjalista ds. bezpieczeństwa w organizacji EY. • Na co dzień zajmuję się szukaniem podatności w wewnętrznych aplikacjach EY. • Kontakt: pawel.rzepa@outlook.com https://pl.linkedin.com/pub/pawel-rzepa/5b/696/532
  • 4. Zarys problemu, czyli skąd pomysł na tą prezentację? • Mit 1. Jak aplikacja działa na HTTPS to niemożliwe są ataki MitM. • Mit 2. Jeżeli aplikacja używa flagi secure to niemożliwe są ataki MitM. Niestety nie zawsze jest to prawdą! A ponadto: • Większość aplikacji, które testuję zezwalają na transmisję HTTP (poprzez wymuszenie http:// w adresie, lub zmianę User Agent) i/lub nie mają zaimplementowanej flagi secure.
  • 5. Flaga secure • Atrybut „secure” w nagłówku Set-Cookie wymusza użycie protokołu HTTPS do transmisji ciasteczek. Więcej o implementacji flagi secure: https://www.owasp.org/index.php/SecureFlag
  • 6. Środowisko testowe – WiFi Pineapple • To zwyczajny Router WiFi z niezwyczajnym soft’em Więcej na https://www.wifipineapple.com/
  • 7. WiFi Pineapple – połączenie z Internetem • Może korzystać z Internetu mobilnego (modem 3/4G) • Może pracować jednocześnie jako klient innego AP i rozgłaszać swoją sieć. • Może w ogóle nie mieć podłączenia do Internetu i dalej być wartościowy.
  • 8. WiFi Pineapple – połączenie z klientem • Rozgłaszanie otwartej sieci WiFi pod zachęcającą nazwą (np. „Miejski Internet”). • Fałszywy AP – podstawienie pod istniejącą sieć. • Podszycie się pod sieć szukaną przez urządzenie końcowe (Karma).
  • 9. SSLstrip • SSLstrip po prostu wymusza przekierowanie żądania na port HTTP. • Wciąż możliwe w niektórych aplikacjach.
  • 12. SSLsplit • SSL/TLS proxy. • Przedstawia się klientowi dynamicznie wygenerowanym certyfikatem. • Nie działa na portale, używające HSTS, ale...
  • 13. SSLsplit • ...nie wszystkie portale używają HSTS...
  • 14. Co jest nie tak? Co robić? Jak żyć?! • Stosować nagłówek HTTP Strict Transport Security (HSTS). Wymusza transmisję HTTPS oraz nie zezwala na akceptację niezaufanego certyfikatu.
  • 15. Co jest nie tak? Co robić? Jak żyć?! • Stosować Certificate Pinning – „na sztywno” przypisany certyfikat do klienta (aplikacji mobilnej, przeglądarki). Połączenie jest ustanowione tylko gdy certyfikat jest zaufany. • Stosować tylko certyfikaty podpisane przez zaufane Certificate Authority – piękne, ale czy realne?
  • 16. Chain of trust • Hierarchicznie Certificate Authority gwarantują, że dany certyfikat jest prawdziwy. • Podpisanie certyfikatu wiąże się z dodatkowymi kosztami, dlatego nie każdy decyduje się na ten krok (powszechny problem w aplikacjach mobilnych).
  • 17. Czy grozi nam coś jeszcze? • Załóżmy, że mamy to wszystko – czy grozi nam jeszcze jakieś niebezpieczeństwo? • Odp: Oczywiście  • Dnsspoof • Captive Portals ze złośliwym kodem • Podatności w samym SSL (więcej na ten temat https://www.digicert.com/cert-inspector- vulnerabilities.htm#certificate_vulnerabilities) • Podatności w TLS, czyli Key Compromise Impersonation (więcej https://kcitls.org/) • Podstawienie plików aktualizacyjnych na złośliwe (np. peinjector https://peinjector.eu/ czy evilgrade http://www.infobyte.com.ar/down/isr-evilgrade-Readme.txt)
  • 18. Dnsspoof – stary, ale wciąż jary! • Czyli przekierowanie dowolnej nazwy domeny na kopię własnej strony.
  • 21. Obrona prrzed Dnsspoof • HTTPS w adresie! • VPN z proxy z przypisanym DNS (np. korporacyjny VPN) • Mimo to zawsze ktoś się nabierze 
  • 22. Captive Portals z BeEF hook • Captive Portal czyli strona, która wyświetli się jako pierwsza zanim nastąpi przekierowanie na żądaną stronę.
  • 23. Captive Portals z BeEF hook • Nic nie stoi na przeszkodzie, aby umieścić tam dowolny kod, np. BeEF hook.js 
  • 24. Captive Portals z BeEF hook
  • 25. Captive Portals z BeEF hook
  • 26. Obrona przed złośliwym kodem na Captive Portals • Wyłączona obsługa skryptów? • Chrome extension? http://blog.cylance.com/vegan-chrome- extension-to-defeat-beef • Zaktualizowana przeglądarka + zdrowy rozsądek 
  • 27. Wnioski • Komunikacja nieszyfrowana to zeszła epoka! • Szyfrowanie to metoda na ataki MitM, ale tylko jeśli jest WŁAŚCIWIE zaimplementowane! • Sama flaga secure to za mało. Należy ją uzupełnić o nagłówek HSTS! • Stosuj certificate pinning! • Multi-factor Authentication do poufnych operacji! • Duża ostrożność w stosowaniu publicznych punktów dostępu! • Wyłącz łączenie się przez WiFi jeśli z niego nie korzystasz!
  • 28. Dla zainteresowanych tematem • Wszystko, co powinieneś wiedzieć o komunikacji szyfrowanej: https://www.owasp.org/index.php/Transport_Layer_Protec tion_Cheat_Sheet • Dobrze wytłumaczone działanie HSTS: http://sekurak.pl/hsts-czyli-http-strict-transport-security/ • Ataki na Pineapple też są możliwe: http://www.networkworld.com/article/2462478/microsoft- subnet/hacker-hunts-and-pwns-wifi-pineapples-with-0-day- at-def-con.html