Wczoraj w ramach rozrywki wybraliśmy się na Turbacz. Trasa prosta, najpierw niebieski szlak z Rdzawki (stacja Statoil) na Stare Wierchy, a potem czerwony na Turbacz. Powrót w to samo miejsce tym samym szlakiem.
Z tą trasą mam już kilka doświadczeń. Kilka lat temu szlak niebieski niepostrzeżenie zmienił nam się w szlak zielony w okolicach Starych Wierchów przez co zamiast do Rdzawki zeszliśmy do Obidowej (ale szczęśliwie złapaliśmy PKS do Klikuszowej). Poprzednie wyjście skończyło się natomiast odwrotem z uwagi na zdecydowanie za duży deszcz.
Tym razem na Turbacz udało wejść się sprawnie, problem pojawił się przy zejściu. Jeśli szliście tą trasą (albo ogólnie – po Gorcach) to wiecie, że charakterystyczną cechą tych szlaków są drogi, które zaczynają się równolegle, często ponownie łączą w jedną, ale czasami jednak oddalają się od siebie i można wyjść w miejscu innym od zamierzonego. Z tego powodu staram się trzymać szlaku, a nie iść “na pamięć” bo po prostu brak jest wystarczająco charakterystycznych punktów orientacyjnych by być pewnym, którą z rozgałęziających się dróżek wybrać.
I tu właśnie coś, czego nie potrafię zrozumieć. Idąc niebieskim szlakiem zeszliśmy ze szlaku (właściwego) w okolicach tego punku: 49.548546N, 19.995380E i poszliśmy w prawo zamiast dalej do nieodległej już Rdzawki. Co najśmieszniejsze jednak – cały czas szlak (lub coś, co go bardzo dobrze udawało) był wyznakowany aż urywał się nagle i niespodziewanie na granicy lasu.
Od pewnego czasu pulsometr(y) zaczął wskazywać mi dziwne wartości. Nie żeby przez cały czas, ale jednak w dość powtarzalny sposób wskazania szły w kosmos. Po długich i ciężkich zmaganiach wygląda na to, że najprostsze rozwiązania są najlepsze – wystarczyło przesunąć pulsometr (opaskę) nieco w lewo.
Ostatnio głośno jest o zakończeniu(?) projektu TrueCrypt. Pojawiają się różne teorie, w tym te bardziej spiskowe z NSA w tle. Nie, nie wiem o co chodzi, ale najprostsze wyjaśnienia są czasem najlepsze. Może po prostu ktoś (bo w sumie nie wiadomo do końca kto rozwijał ten projekt) miał dość? Znalazł pracę/dziewczynę i stracił zainteresowanie tym projektem. A może to po prostu się nie opłacało. Tak, ideowcy też za coś żyć muszą.
Jeszcze jedna sprawa, na stronie TrueCrypt znajduje się następujące ostrzeżenie:
WARNING: Using TrueCrypt is not secure as it may contain unfixed security issues
Zastanawia mnie to, że w pojawiających się komentarzach to słówko “may” kompletnie umyka uwagi. Mało tego, często przyjmuje się za pewnik, że w TrueCrypt jest jakaś przeraźliwa dziura. Znów, wytłumaczenie może być mniej sensacyjne – projekt, który nie jest już rozwijany/utrzymywany może zawierać błędy bezpieczeństwa i nikt ich nie usunie, bo nikt już nad nim nie pracuje.
Przypominam jednocześnie, że wyniki audytu kodu źródłowego były dla TrueCrypt (projekt IsTrueCryptAuditedYet) dość pozytywne. Jednocześnie trzeba pamiętać o zakresie tego audytu, który był dość ograniczony:
iSEC performed a source code assisted security assessment of the TrueCrypt bootloader and Windows kernel driver.
Druga faza, kryptoanaliza, dopiero była planowana.
Jak wiecie coś, co kiedyś nazywało się Alior Sync obecnie nazywa się T-Mobile Usługi Bankowe. Moje poczucie estetyki (tak, wbrew pozorom jakąś estetykę jednak mam) zostało brutalnie zgwałcone przez nową skórkę. Podobnie się czułem gdy Era zmieniała się w T-Mobile. Ale ja nie o tym.
Poprzedni wpis (Czy dłuższe jest lepsze?) spotkał się z nadspodziewanie dużym zainteresowaniem, przynajmniej sądząc po ilości komentarzy. Ja chciałbym wrócić do tematu potencjalnych zysków atakującego/strat banku. Czy jesteśmy w stanie w jakiś sposób je oszacować?
Tak to czasem bywa, że nowi klienci mają zdecydowanie lepsze oferty, niż dotychczasowi. Czasami bardziej opłaca się kupić ponownie tę samą usługę, niż przedłużać ważność już posiadanej. Jeśli przedłużenie usługi kosztuje mniej więcej 10x więcej niż rejestracja nowej, to motywacja by poświęcić trochę czasu na przeprowadzkę jest spora. Właśnie wczoraj ta przeprowadzka się skończyła.
Zauważyłem, że w niektórych bankach długość kodu jednorazowego (SMS) używanego do autoryzacji transakcji została wydłużona. Chętnie poznałbym uzasadnienie takiej decyzji – dlaczego 8 cyfr ma być bezpieczniejsze niż 6. W praktyce, a nie w jakiejś teorii. Bo jeśli chodzi o teorię...
Muszę przyznać, że dziwnie się czuję rozmawiając o arp poisoning i różnym zachowaniu Windows i Linux w kontekście komendy arp -s (swoją drogą muszę sprawdzić jak zachowują się w tym przypadku Windowsy nowsze niż XP), różnicami w reasemblacji pakietów albo manipulacji TTL w kontekście unikania IDS/IPS.
Ja uczyłem się od podstaw, z nieśmiertelnej Biblii TCP/IP. Ponieważ wiem (mniej więcej) jak to działa, te pomysły są dla mnie zrozumiałe (w zasadzie każdy mając taką wiedzę może na to wpaść). Mam jednak wrażenie, że w tej chwili dominuje podejście od drugiej strony, od strony narzędzi/rozwiązań. Ludzie są uczeni, że jeśli wydadzą takie magiczne polecenie, to są bezpieczni. Nie rozumieją jednak do końca na czym polega problem i jak jest w danym przypadku rozwiązywany. I właśnie to powoduje, że czuję się dziwnie.
PS: No dobra, może i z tej książki nie nauczysz się na czym polegają optymalizacje w obsłudze[arp who-has](http://en.wikipedia.org/wiki/AddressResolutionProtocol), ale z drugiej strony będziesz w stanie sam się domyślić dlaczego system otrzymujący takie zapytanie aktualizuje swoją tablicę arp.
By zobrazować to lepiej – dlaczego 172.16.0.6 odpowiedział 172.16.0.128 skoro wcześniej nie zapytał jaki jest adres MAC dla tego adresu?
30516 91.105464000 Microsofd1:3c:14 Broadcast ARP 60 Who has 172.16.0.6? Tell 172.16.0.128
30517 91.105507000 IntelCorca:c2:74 Microsof_d1:3c:14 ARP 42 172.16.0.6 is at 00:16:ea:ca:c2:74
30518 91.106570000 172.16.0.128 172.16.0.6 ICMP 98 Echo (ping) request id=0x2cc6, seq=1/256, ttl=64 (reply in 30519)
30519 91.106884000 172.16.0.6 172.16.0.128 ICMP 98 Echo (ping) reply id=0x2cc6, seq=1/256, ttl=128 (request in 30518)
Oryginał tego wpisu dostępny jest pod adresem Old School