Security – ostatnie różności (zabezpieczenia moBILETu ponownie).

Wczorajszy dzień jakoś tak obfitował w wydarzenia związane z bezpieczeństwem, że postanowiłem to podsumować.

Po pierwsze, po dyskusji z netu na ten temat, postanowiłem się przyjrzeć moBILTowi. W sumie po raz kolejny bo i na zabezpieczenia patrzyłem (i to dwa razy). Przy dyskusji zeszło oczywiście na temat jak oni to sprawdzają (jak pisałem, sprawdzają źle) oraz jak mogą sprawdzać. Oczywiście najdoskonalsza wersja, to sprawdzenie online (odpytanie bazy o fakt skasowania danego biletu). Ponieważ twierdziłem, że jakby napisanie fake’owej aplikacji było proste (grafiki są – jak pisałem – dostępne, cudów tam nie ma, zwykła Java ME i trzy semi statyczne ekrany), to na pewno studenci (taki gatunek człowieka, co to nigdy kasy nie ma, dostęp do wiedzy i czas ma (chyba, że akurat pije, co mimo braku kasy zdarza się często, albo sesja), więc do skutecznego kombinowania pierwszy) by to zrobili. I że pewnie jest algorytm, który na podstawie cyfr/kodu z biletu pozwala zweryfikować prawdziwość biletu offline.

Nie ukrywam, że pozazdrościłem Niebezpiecznikowi opisu hackowania karty IKEI w celu dostania kawy, więc był czas, kawa, motywacja…

Bliższe przyjrzenie się ujawniło, że to, co brałem za QR code, to raczej Aztec code. Na dodatek odwrócone kolory ma (nie doczytałem, czy oryginalny Aztec na to pozwala, na wiki wszystkie są odwrotne). Ale Neoreader czyta to. Po przeczytaniu okazuje się, że twórcy nie ułatwili kontrolerom pracy – nie ma żadnego unikatowego ID zaszytego w tym kodzie. Jest tylko dokładny timestamp kasowania biletu. Opieram się wyłącznie na screenach dołączonych do instrukcji na stronie (dead link) – wyglądają na prawdziwe.

Niestety, inaczej niż w przypadku Niebezpiecznika, ludzie zawiedli. Apel na blipie pozostał może nie tyle bez odpowiedzi (odezwały się 2 osoby, z czego tylko jedna mogłaby pomóc), co bez danych. Pozostali znajomi nie odezwali się jak na razie z danymi, więc zostałem tylko ze swoimi danymi. Szybka analiza wykazuje, że są tak naprawdę 3 dane brane pod uwagę. Dokładny czas kasowania, numer ze strony pierwszej, bieżący numer ze strony drugiej i… tyle. Przy czym numer ze strony pierwszej jest stały (być może dla danego użytkownika, typu usługi, regionu) w trakcie jednego dnia. Natomiast bieżacy numer to po prostu inkrementowane ID w bazie (też nie wiem, czy dla danego typu usługi i regionu, czy transakcji globalnie, ale wiem, ile przyrasta dobowo).

Szybkie odświeżenie wiadomości z pracy magisterskiej i naklepanie prostego AG (algorytmu genetycznego) w Perlu nie przyniosło rezultatu w postaci znalezienia korelacji między datą danego dnia, a numerem ze strony pierwszej, choć na oko wygląda, że taka może istnieć (Perl i algorytm wolne i nie do końca przemyślane). Tak naprawdę czekam na więcej danych, w szczególności chcę porównać, czy dany numer jest stały dla wszystkich użytkowników (i usługi) w danym dniu. Jeśli jest, to ewidentny błąd twórców moBILETu – nawet jeśli nie ma algorytmu, to wystarczy, że jeden student skasuje bilet w danym dniu i przekaże numer innym. I nie da się zweryfikować offline, na podstawie sumy kontrolnej czy czegoś takiego, czy to autentyczny bilet…

Po drugie, za sprawą wpisu u Marcina Kasperskiego dowiedziałem się, że wbrew temu, co mówili sceptycy, słynną Nokię 1100 da się wykorzystać do przechwytywania SMSów z kodami jednorazowymi do transakcji. Czarny scenariusz się sprawdza – kody SMS nie są bezpieczne, istnieje metoda na oszukanie czytnika kart chipowych… Nadchodzą niedobre dni dla banków internetowych?

Po trzecie, atak phishingowy na Lucas Bank (dead link). Tu lekka lipa ze strony banku, bo korzystajac z formularza kontaktowego na stronie nie możemy wprost zgłosić takiego zdarzenia. Co więcej, wymagane jest podanie adresu email. A korzystając z tego formularza wyrażamy zgodę na przysyłanie spamu przez bank. Słowo kretyn w stosunku do osoby, która to wymyśliła nie oddaje w pełni tego, co chcę wyrazić…

UPDATE: Szybkie sprawdzenie z mobiletem kumpla pokazuje, że numer ze strony pierwszej jest stały w obrębie danego dnia dla wszystkich użytkowników (danej usługi, w danym regionie, kupujących dany typ biletu).

Błędy w moBILET – przepis na DoS i proste oszustwo.

Z moBILETu korzystam od dawna, ogólnie jestem zadowolony. Kiedyś, na starym blogu, pisałem o słabych punktach tej usługi i ogólnych wrażeniach. Dziś zaszło pewne zdarzenie, które przypomniało mi o tym, że miałem napisać parę słów więcej o bezpieczeństwie i możliwościach nadużyć.

Po pierwsze, najsłabszym punktem moBILETu są… kontrolerzy. Nigdy nie zdarzyło mi się, bym został poproszony o przełączenie na inny ekran, nie był sprawdzony kod i w ogóle całe sprawdzenie skończyło się na sprawdzeniu, czy godzina na wyświetlonym bilecie jest OK. Zatem najprostszy sposób oszustwa to prosta aplikacja w javie, która wyświetli co trzeba i doda taką godzinę, by bilet był ważny. Pewnie z 30 min roboty, jeśli ktoś zna Javę ME.

Po drugie, stosunkowo łatwo uniemożliwić komuś skasowanie biletu. Wystarczy zacząć dzwonić w momencie, kiedy próbuje skasować bilet. Zaowocuje to wyświetleniem przez aplikację komunikatu, żeby najpierw zakończyć rozmowę, a samo kupno biletu nie będzie możliwe do czasu, kiedy dzwoniący nie przestanie dzwonić (czy się nie rozłączy, nie testowałem dokładnie). De facto pozwala to na DoS na kasującego bilet, możliwe, że skuteczny, bo kanary mają przykry zwyczaj rozpoczynania kontroli tuż po ruszeniu tramwaju.

Tak dziś wyszło, jak kumpel zadzwonił tuż po moim wejściu do tramwaju. Chwilę później zadzwonił z pytaniem, czy moBILET się wywalił. Nie, ale i tak gratki za pomysł. Ląduje w kategorii security, choć nietypowe.

Jak mieć bezpieczne hasło i nie popaść w paranoję?

Za sprawą włamania na Wykop wywiązała się dyskusja o hasłach. Pisali o tym groszek (dead link), kUtek, Zal i generalnie z żadnym zaprezentowanym podejściem do końca nie mogę się zgodzić.

Jak dla mnie wszystkie te zabawy ze skrótami itp. są nie do przyjęcia. Albo hasło jest takie, że trzeba je pamiętać (czyli umieć wpisać z głowy), albo można sobie pozwolić na jakiś portfel haseł (i wtedy nie ma się co bawić, tylko można wygenerować losowe). Hasłami losowymi nie ma się co zajmować – mają być długie i możliwie losowe.

Pozostają hasła do zapamiętania. Tu trzeba rozróżnić serwisy krytyczne (także maile, na które mamy ustawione przypominanie haseł) i resztę. Krytyczne łatwo wyróżnić – możliwe większe straty finansowe, wycieki prywatnych danych itp. Pierwsza sprawa, to – jeśli to tylko możliwe – do serwisów krytycznych chronimy także login. Po co? Prosta sprawa, jeśli ktoś będzie chciał nam zrobić kuku, to nie ma co ułatwiać mu sprawy. Plus, niektóre serwisy (zwł. banki) mogą blokować po określonej ilości nieudanych logowań, więc źli ludzie mogą nam uprzykrzyć życie już samą znajomością loginu.

Poza tym, do serwisów krytycznych mamy możliwie mocne, nieschematyczne hasła, które pamiętamy, logujemy się możliwie tylko z zaufanych maszyn i w sposób bezpieczny (nie plain text), nie 20 zakładek na innych portalach otwartych w tym czasie. Jeśli zdarzy nam się logowanie awaryjne z niezaufanej maszyny/niebezpiecznym protokołem – jak najszybciej wymieniamy hasło (z bezpiecznej maszyny). Reszta w rękach admina serwisu. No może jeszcze nie chwalimy się zbytnio, które serwisy są dla nas krytyczne. 😉

Reszta, czyli serwisy niekrytyczne. Tak naprawdę zwykły użytkownik może zrobić tylko trzy rzeczy. Pierwsza, absolutnie konieczna: nie stosujemy takich samych haseł. Przy akcjach jak ta z Wykopem i podobnych, w razie czego włamywacz uzyska dostęp do jednego serwisu. Po takich włamaniach zwykle włamywacz automatem sprawdza, czy można zalogować się z takim samym loginem i hasłem na inne portale (chyba, że darzy nas szczególną uwagą, ale to trochę inna sprawa).

Jeśli chodzi o hasła, reszta to sprawy wtórne – jeśli stosujemy schemat/schematy to po takim włamie włamywacz raczej nie będzie miał dostępu do danych z kilku serwisów (chyba, że darzy nas szczególną uwagą, albo jedna i druga baza wpadną w ręce kogoś, kto nas darzy). Oczywiście warto zmieniać hasła okresowo i mieć różne schematy/hasła, ale wygoda kłóci się z bezpieczeństwem.

Sprawa druga: ustawiamy przypominanie/zmienianie hasła na zaufanego maila. W razie włamu przyda się do odzyskania dostępu, choćby po to, żeby zamieścić sprostowanie.

Sprawa trzecia, nieoczywista. Nie ufamy niekrytycznym portalom. Koniec, kropka. Mogą być poziomy dostępu (jak na Joggerze) ale nie znaczy to, że zamieszczone na wyższym poziomie dane są/będą niedostępne dla innych ludzi. Można to traktować jako kosmetykę, ale pisanie tam rzeczy, których nie napisało by się na stronie głównej to proszenie się o potencjalne kłopoty. Generalnie im mniej prywatnych/wrażliwych danych na takich serwisach, tym lepiej.

Trzeba przyjąć, że włamy itp. na serwisy niekrytyczne będą się zdarzały – przy ich ilości jest to jedynie kwestia czasu. I raczej będą to ataki na bazę serwisu, niż na nasze konto (chyba, że ktoś darzy nas szczególną uwagą), dlatego hasło należy mieć nieoczywiste, długie (dodanie przedrostka w stylu abcdefg (oczywiście nie chwalimy się nim) drastycznie wydłuży czas łamania hasła, jeśli ktoś nas „polubi”, ale IMO nie ma co popadać w paranoję. Co tak naprawdę się stanie, jeśli ktoś skorzysta z naszego konta do Wykopu (i tylko z niego)?

Po wykrytym włamaniu oczywiście zmieniamy hasło. Jeśli stosujemy hasła schematyczne, z oczywistym schematem, należy zmienić schemat i wymienić wszystkie hasła objęte danym schematem. Tyle dobrych rad, praktyka pokazuje, że kompromis między użytecznością a bezpieczeństwem zawsze jest trudny. Dlatego polecam określenie krytycznych serwisów i naprawdę dbanie o bezpieczeństwo w ich przypadku. W przypadku niekrytycznych i tak pewnie lenistwo AKA użyteczność AKA wygoda weźmie górę…