Szybki test Freenetu.

Jakoś tak się złożyło, że wpis Zala przypomniał, że zarzuciłem zabawę z Gnunetem (którego po prostu nie udało mi się w 5 minut na czuja uruchomić). Postanowiłem przyjrzeć się Freenetowi, który powinien być prostszy i popularniejszy. I którego do tej pory skreślałem ze względu na Javę.

Z prototą bym nie przesadzał – nie wiadomo, który plik wybrać (a w Debianie nie ma tego pakietu). Na stronie projektu plików do pobrania jest wiele, nie wiadomo, która wersja jest stabilna. Ostatecznie podążam dosłownie za wytycznymi z przykładu, tym bardziej, że liczba pobrań też jest największa.

Instalator brzydki, ale instaluje bez problemu. Z niefajnych rzeczy – bez pytania dodaje usługę Freenet do uruchomienia po reboocie.

@reboot   "/home/rozie/programs/Freenet/run.sh" start 2>&1 >/dev/null #FREENET AUTOSTART - 8888

Irytujące, szczególnie, że może warto wyrzucić na osobnego usera. Oczywiście, przeniesienie nie jest problemem, ale IMHO powinien zapytać, czy może dodać wpis. Na zakończenie drobny fail – pisze An uninstaller program has been created in: (tak, potem pustka). Brak informacji o tym, czy demon zostaje automatycznie włączony (tak, zostaje). Niezły wizard.

Prywatność. Widać, że twórcy dbają o prywatność w sieci – użytkownik proszony jest o korzystanie z oddzielnej przeglądarki do łączenia z demonem Freenetu. Jak najbardziej zasadne, bo w przypadku wspólnej przeglądarki nie będzie żadnego problemu z wywołaniem zwykłego URLa ze strony freenetowej, co w połączeniu z dostępem do ciasteczek itd. jest oczywistą metodą pozbawienia anonimowości. Tylko zwiedzam, więc olewam i poprzestaję na wywaleniu ciasteczek (w tym flashowych), ale jak najbardziej zasadne.

Następnie określa, na ile zależy mu na ochronie przed rządem, ISP oraz (wybieram opennet i normal)… osobami określonymi jako przyjaciele. Domyślnie mają oni (lub malware na ich komputerach) sporą możliwość naruszenia prywatności (wybieram high). Kolejne pytanie jest o pliki tymczasowe i pobrane. Do wyboru 4 poziomy zabezpieczenia, w tym takie, które wyglądają na bezpieczne (oczywiście jeśli nie ma błędów w implementacji/backdoorów) nawet bez szyfrowanego systemu plików/katalogu. Najbardziej paranoidalny tryb oznacza trzymanie klucza tylko w pamięci (do testu wystarczy normal), czyli dane tracone są bezpowrotnie chwilę po wyłączeniu maszyny (modulo wejście na swap, modulo bruteforce). Na koniec testu wybieram 5GB przestrzeni dyskowej do wykorzystania.

No i tu zaczyna się jazda. Zużycie procesora (PIII 1 GHz) utrzymuje się od tego momentu na ok. 40-50%, a pamięci RAM na 8,7% (z 1GB) i rośnie (maksymalnie widziałem 20%). Program pozwala ustawić limit RAM – domyślny limit RAM to u mnie 192 MB. W praktyce oznacza to, że procesor nie ma wytchnienia i będzie się włączał wiatrak. Do not like. Wychodzi, że łącze 32 KB powinienem wybrać, co czynię.

Szybkość działania jest tragiczna. Nawet prostą wiki otwierał długo. Kolejna rzecz, którą sprawdzam (i która otwiera się nieco szybciej, ale skojarzenia z modemem i wczesnym dzwonieniem na 0202122 silnie wskazane) to Freenet TEXTlink Index. Tu zdziwienie. Nawet sporo linków jest po polsku. Nie wiem na ile to zbieg okoliczności, a na ile odwzorowanie stanu faktycznego. Tematycznie dominuje metatematyka (tu: wolność, libertarianizm, linki freenetowe) oraz polityka i… chrześcijaństwo (zwł. polskie strony), które często pod politykę podpada. Bliższe przyjrzenie się treści i okazuje się, że śmierdzi trupem – większość stron aktualizowana w 2008, 2010 to święto. Do testowania pobierania plików nie dotarłem – skoro wolniejsze, niż wbudowane strony, to nie chcę nawet sobie tego wyobrażać.

W sumie nie wypada to za ciekawie. Bawiłem się około godziny – możliwe, że potem zużycie procesora spadnie (pobierał do lokalnego cache dane cały czas i szyfrował je), a prędkość wzrośnie, ale IMHO cały projekt dla hobbystów. W zwykłym użytkowaniu Tor znacznie szybszy, bardziej użyteczny (dostęp do wszystkich treści, nie tylko wydzielonego, osobnego skrawka Internetu), choć mniej bezpieczny i trochę inne zastosowanie, jednak.

Deinstalacja: katalog Uninstaller w głównym katalogu programu Freenet i java -jar uninstaller.jar Działa ładnie, usuwa wpis z crona i cały katalog. I w sumie to jedyny element programu, do którego nie mam zastrzeżeń.

Nie taki błąd straszny, jak go malują.

Dziś przeczytałem wpis na Niebezpieczniku o backdoorze w switchach. I z jednej strony ewidentny fail, a z drugiej błąd niezupełnie (czy też: nie tylko) tu leży…

  • Jaki administrator zostawia dostęp po SNMP włączony (niestety, sporo administratorów nie widzi w tym nic złego, zwłaszcza jeśli tylko RO jest)?
  • Jaki producent sprzętu ma w defaulcie włączone SNMP (niestety, wielu vendorów domyślnie włącza SNMP z domyślnymi community)?
  • Kto daje nieograniczony dostęp ze świata do klasy zarządzania swoich urządzeń?
  • Poznanie MAC mimo wszystko nie jest trywialne. Trzeba mieć dostęp albo po warstwie drugiej (ew. do odczytu tablicy ARP urządzenia, które ma dostęp po L2 do switcha), albo do wspomnianego SNMP.

Jasne, ludzie się mylą. Jasne, kwestię hasła serwisowego (padło pytanie, czy inne sprzęty mają coś takiego – chyba każdy sprzęt sieciowy ma możliwość przynajmniej resetu hasła przy podłączeniu się RSem, sporo ma hasła serwisowe – mam nadzieję, że tylko po RS dostępne). Jasne, taki zdalny backdoor nie powinien mieć miejsca. Ale czy to naprawdę dramat?

PS. Dziś spotkałem się z opinią (na szczęście od nikogo ode mnie z firmy), że trzymanie dokumentów firmy (nie najtajniejsze tajemnice, ale nie dane dostępne na publicznym WWW) na Google Docs to nic złego. W porównaniu z tym backdoor w switchu, którego można zneutralizować/zminimalizować to IMO pikuś.

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