Tag: bilet

Opublikowane w

Pożegnanie z moBILET.

Autobusy mijanie

Źródło zdjęcia: Autobusy mijanie

Rzadko zdarza się tak, że rezygnuję z usługi, z której jestem zadowolony. A dokładnie tak jest w tym przypadku. Mimo pewnych wad, o których pisałem podczas opisu pierwszego wrażenia z kontaktu z moBILETem, mimo wielu wad systemu: stosunkowo długi czas doładowania konta, problemy związane z brakiem wersji na wiele telefonów (nie dotyczyło mnie), tylko minuta na włączenie moBILETu i skasowanie (na to jest obejście, szukaj o zabezpieczenia czasowe aplikacji w tym wpisie), muszę przyznać, że to świetny system. Niezawodność OK – z 2 albo 3 razy nie skasowałem biletu z racji problemów z siecią lub serwerami moBILETu (trudno stwierdzić, kto naprawdę był winien).

Jasne, na pewno wpłynął na to fakt, że moBILET działa w trzech miastach, w których przebywam najczęściej, czyli Szczecinie, Poznaniu i Stargardzie Szczecińskim. Jeden telefon komórkowy i doładowane konto załatwiały sprawę biletów we wszystkich tych miastach, niezależnie od dnia tygodnia czy pory dnia, a trzeba przyznać, że kupno tradycyjnych biletów jest często problematyczne.

Ale trochę zmienił mi się profil korzystania z komunikacji miejskiej, co oznacza, że będę wydawał więcej. Sieciówka za 81 zł stała się opłacalna (mimo ostatniego wydłużenia okresów ważności biletów czasowych w Poznaniu), więc pora pożegnać się z tym fajnym systemem. Przy okazji mała statystyka – przez 32 miesiące, kiedy korzystałem z moBILETu, wydawałem na doładowania średnio 54 zł/m-c, faktem jest, że nie tylko w Poznaniu korzystałem (i nie tylko dla mnie bilety kasowałem), ale i tak sporo…

Oczywiście w związku z zakupem sieciówki nie rezygnuję całkowicie z systemu – nadal przyda się w Szczecinie i Stargardzie Szczecińskim, ale będzie to naprawdę sporadyczne użycie.

A jeśli kogoś przerażają wady moBILETu, to niedawno pojawiła się w Poznaniu alternatywa, również oparta o GSM, choć w innym wydaniu – wystarczy zadzwonić. Chodzi oczywiście o CallPay, który ostatnio intensywnie się promuje. Na razie nie ma zbyt wielu miast, ale pewnie będzie ciekawe szczególnie dla tych użytkowników, z obsługą telefonów których moBILET miał problem.

Opublikowane w

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

Opublikowane w

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.