19/7/2013
We wtorek ekipa Tumblr poinformowała o wydaniu aktualizacji swojej aplikacji na iOS. Usunięto błąd bezpieczeństwa — aplikacja przesyłała hasło do serwisu bez szyfrowania.
Nie wykorzystywali HTTPS przy logowaniu
Ponieważ dane nie były w żaden sposób szyfrowane w transporcie, mogły zostać łatwo przechwycone przy użyciu sniffera wykorzystywanego przez atakującego znajdującego się gdziekolwiek na trasie pakietów pomiędzy klientem a serwisem.
Niedopatrzenie odkrył jeden z czytelników The Registera, który otrzymał zadanie zbadania aplikacji mobilnych wykorzystywanych przez jego współpracowników pod kątem (nie)bezpieczeństwa dla danych firmy, w której pracuje.
Jak sprawdzić, czy inne aplikacje nie “wyciekają” haseł?
Proces testowania jest prosty, dlatego zachęcamy każdego z was do wykonania podobnych testów na wykorzystywanych przez siebie aplikacjach.
Wystarczy wyjąć kartę SIM (aby mieć pewność, że dana aplikacja nie wysyła danych przez transmisję pakietową) a następnie
- a) połączyć się z siecią Wi-Fi i uruchomić sniffing pakietów na interfejsie routera (np. poprzez tcpdump) lub
- b) udostępnić połączenie Wi-Fi smartphone’owi poprzez bridging interfejsów w systemie operacyjnym, dzięki czemu będziemy mogli sniffować np. Wiresharkiem wprost z naszego komputera
Jeśli korzystasz z Tumblr
Jeśli korzystasz z aplikacji Tumblr na swoim iPadzie/iPhonie, to zaktualizuj ją do wersji 3.4.1. Dodatkowo, warto na wszelki wypadek zmienić hasło do swojego konta (a nuż ktoś je zesniffował?). Nie wspominamy o zmianie haseł w innych portalach, bo chyba nie używacie jednego hasła w wielu miejscach, prawda?
A że się spytam – po co w ogóle wysyła hasło? Do tamtych programistów nie dotarła jeszcze nowinka zwana challenge-response authentication???
Raczej dotarła: “The simplest example of a challenge-response protocol is password authentication, where the challenge is asking for the password and the valid response is the correct password.” ;)
;) na końcu Twojego posta sugeruje, że wiadomo o co chodzi. Miałem oczywiście na myśli choćby najprostsze C-R z losowym challengem i hashowaniem odpowiedzi (a’la APOP z POP3)
Ale do tego serwer musiałby mieć hasło zapisane otwartym tekstem. Lub niekoniecznie hasło, ale “coś” np hash hasła który po wyciągnięciu z serwera umożliwiłby logowanie na serwer.
@e a jak by serwer trzymal klucz publiczny, klient klucz prywatny i wysylalby ot chocby zaszyfrowany timestamp+login? :)
W takich momentach człowiek się cieszy, że zazwyczaj to produkty Apple jako pierwsze dostają aktualizacje :)
…bo jako jedyne potrzebują? ;)
Android też potrzebuje i co? Błędy leżą miesiącami (te jawne w samym systemie nie mówiąc o aplikacjach) bo nawet jeśli Gugiel załata to zanim to dojdzie do Samsunga czy innych plastikowców miną miesiące / lata.
na co komu https skoro kazdy moze sobie skrobnac wlasna wersje sslstripa
Czy bankowosc tez jest na to narazona ? czyli mozna ominac wszedzie https uzywajac ssltripa ?
a nie można po prostu podsłuchać będąc w tej samej sieci bezprzewodowej co telefon? czy jakaś popołudniowa zamuła mózgu mnie złapała i czegoś nie uwzględniłem?
Nie wszystkie karty pozwalają na przełączenie w tryb promisc? Nie jest to najłatwiejsze rozwiązanie? No dobra na Mac OS X to kwestia 1 polecenia, ale na Win czasem jest z tym trochę zabawy.
np poprzez wifi mozna mitm i nawet https nie zda egzaminu chyba ze o czyms nie wiem co jest dosyc prawdopodobne
ale wtedy przecież wywali Ci błąd certyfikatu
Opcja izolacji klientów bezprzewodowych w OpenWRT chroni przed takim podsłuchiwaniem w sieci lokalnej?
Dobrze, że nie korzystam z tumblra z tego programu i tak w większości korzystają młodzi.
A tak wszystkie rzeczy od Apple chwalą, że bezpieczne ;)
Myślałem, że w cywilizowanym świecie https to standard i nie może być innej możliwości przesyłania haseł…. :)
I bardzo dobrze. Wszystkie szanujące się serwisy mają SSL i
tylko SSL. Reszta to śmieci których nie stać na wprowadzenie SSL na
serwerze a to przecie tylko kilka set USD… a ludzie sami sobie
winni! Logowanie przez SSL trwa o 1,5-2sek dłużej :-) Może to jest
winą???