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. 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.

10. SSLstrip
• Przykład:

11. SSLstrip
• I jeszcze jeden...

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.

19. Dnsspoof

20. Dnsspoof

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