Brak działającego SSL w OS X i iOS od września 2012

Przed paroma dniami pojawiło się niespodziewane uaktualnienie dla iOS 7, która naprawiało jeden błąd – problem z weryfikacją połączeń SSL. Został on odkryty przez firmę CrowdStrike oraz inżyniera Google. W międzyczasie okazało się również, że istnieje on od września 2012 roku – pojawił się razem z premierą iOS 6. Ale nie panikujcie jeszcze…

Czy problem dotyczy też Was?

Możecie to sprawdzić, w bardzo prosty sposób. Wystarczy udać się na stronę gotofail.com, która sprawdzi Waszą aktualnie używaną przeglądarkę.

Co robić?

Brak działającego SSL dotyczy, jeśli to co specjaliści od bezpieczeństwa piszą jest prawdą, nie tylko Safari, ale również FaceTime, iMessage, Twitter, Calendar, Keynote, Mail, iBooks, Software Update oraz kilku innych programów. Przypominam – nie panikujcie… i tak niewiele możecie zrobić w tym względzie.

W jakiej sytuacji Wasze dane mogły wpaść w niepowołane ręce?

Jeśli byliście zalogowani do niezabezpieczonej i/lub publicznej sieci Wi-Fi, która wykorzystywała inne standardy szyfrowania niż WPA2, to ktoś mógł przechwycić Wasze dane logowania, bankowe, hasła i tym podobne, która normalnie są przesyłane w zaszyfrowanej formie. Zostało to szczegółowo opisane przez CrowdStrike:

To pull off the attack an adversary has to be able to Man-in-The-Middle (MitM) network connections, which can be done if they are present on the same wired or wireless network as the victim. Due to a flaw in authentication logic on iOS and OS X platforms, an attacker can bypass SSL/TLS verification routines upon the initial connection handshake. This enables an adversary to masquerade as coming from a trusted remote endpoint, such as your favorite webmail provider and perform full interception of encrypted traffic between you and the destination server, as well as give them a capability to modify the data in flight (such as deliver exploits to take control of your system).

W dużym skrócie, hacker dostaje się „pomiędzy” Was, a serwer, z którym się łączycie. Nie jestem specjalistą od bezpieczeństwa, więc liczę bardzo na to, że Krzysztof Młynarski opisze to szczegółowo na łamach iMagazine, aby przybliżyć sytuację.

Jak uniknąć problemów?

1. iOS – Zaktualizować system do 7.0.6 jak najszybciej.
2. OS X – Czekać na łatkę od Apple. Jest już takowa od osoby trzeciej, ale nie ufam tej osobie, więc nie linkuję. Oficjalna ma się pojawić lada moment.
3. iOS i OS X – Unikać niezabezpieczonych sieci lub posiadających szyfrowanie po WEP lub WPA. WPA2 jest obowiązującym standardem.
4. OS X – Zainstalować najnowszego Chrome’a lub Firefoxa i sprawdzić czy na pewno są bezpieczne przez stronę gotofail.com.

Teorie spiskowe

Bardzo ciekawą teorię spiskową wysnuł John Gruber. Zwraca uwagę na to, że bug w kodzie SSL pojawił się w październiku 2012 roku, a miesiąc później Apple „przystąpiło” do PRISM. Na tej podstawie wyciąga pięć możliwych wniosków:

1. NSA nic o tym nie wiedziało.
2. NSA o tym wiedziało, ale nie wykorzystało tej luki.
3. NSA wiedziało o luce i ją wykorzystało.
4. NSA wprowadziło problem do kodu Apple przez agenta pracującego w Apple.
5. Apple samo dodało buga do swojego kodu.

Gruber sam wybiera bramkę numer 3 i jestem skłonny się w tej kwestii zgodzić – ładnie też tłumaczy obecność Apple na slajdach PRISM. Opcja numer 4 wydaje się być dobra dla Hollywood, a piąta kompletnie oderwana od rzeczywistości.

---

Niezależnie od powyższego oraz tego jak łatwo było tego buga wprowadzić do kodu, tak duży fuckup jest niedopuszczalny. Najbardziej martwią mnie połączenia z iTunes Store, w którym mam podaną kartę kredytową. Połączenia, które wykonywałem między innymi w Indiach na sieciach, które są monitorowane m.in. przez rząd. Nic niepokojącego nie zauważyłem przez ostatnich kilka miesięcy, więc trzymam kciuki.

Apple niedawno rozszerzyło listę krajów, w których można włączyć podwójną autoryzację dla naszego Apple ID, ale Polska jeszcze się na niej nie znalazła… Mogliby się pośpieszyć w tym względzie…