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ę…

Masz DD-WRT? Masz problem.

A raczej, możesz mieć problem, jeśli skonfigurowałeś router tak, by serwer WWW (zarządzania przez WWW) słuchał na zewnętrznym interfejsie. Jakiego typu problem? Zdalne wykonanie kodu z prawami roota. Bez konieczności jakiegokolwiek uwierzytelniania.

Niestety, nawet ci, którzy skonfigurowali swój router tak, by serwer WWW nie słuchał na zewnętrznym interfejsie nie mogą spać spokojnie. Powodem jest niezałatana możliwość ataku przez CSRF.

Co robić? Jeśli nie chcemy/możemy zmienić softu na Tomato czy OpenWrt – co byłoby najlepszym rozwiązaniem, bo brak doniesień o podobnych problemach w tych firmware’ach – to na pewno wyłączyć zarządzanie przez WWW na zewnętrznym interfejsie i unikać podejrzanych stron (mogących być źródłem ataku CSRF). Przynajmniej do czasu opublikowania poprawionej wersji firmware’u przez DD-WRT. Jeśli to możliwe, należy wyłączyć serwer WWW całkowicie, wtedy i CSRF nie będzie groźny.

Źródło: DD-WRT (httpd service) Remote Command Execution Vulnerability

UPDATE: Jeszcze link do wątku na forum DD-WRT nt. tej luki oraz link do poprawionego firmware’u.