Tak tylko informacyjnie jeśli ktoś tego nie zauważył:
XTS-AES encryption algorithm. BitLocker now supports the XTS-AES encryption algorithm. XTS-AES provides additional protection from a class of attacks on encryption that rely on manipulating cipher text to cause predictable changes in plain text. BitLocker supports both 128-bit and 256-bit XTS-AES keys.
P.S: A piszę o tym dlatego, że w końcu zebrałem się w sobie by zmienić AES-CBC na XTS-AES i jestem pod wielkim wrażeniem tego, jak mój szybko laptop poradził sobie z ponad 100GB danych.
Doprecyzujmy – w grubych klientach lub aplikacjach mobilnych. Normalnie, w przypadku aplikacji webowych, testowanie transport layer security polega na sprawdzeniu jakie protokoły/szyfry są oferowane przez serwer. W takim scenariuszu ma to trochę sensu, bo to ostatecznie serwer decyduje co zostanie wynegocjowane a przeglądarki, jeśli nie są za stare, nie używają archaicznych protokołów i szyfrów.
Inaczej sytuacja wygląda w przypadku aplikacji (mobilnych, desktopowych). Może okazać się, że klient jest skłonny zaakceptować wszystko co popadnie łącznie z czymś, co nie daje właściwie żadnego bezpieczeństwa (głównie aNULL). Coś takiego aż prosi się o MitM.
Właśnie skończyłem czytać/słuchać (no dobrze, bardziej słuchać) REAMDE. Miałem ochotę przeczytać tę książkę wkrótce po tym, jak się ukazała, ale zniechęciła mnie ta recenzja Gwoździa: Dwie powieści o graniu serio:
Niestety lektura książki okazała się sporym zawodem, bo zamiast tego wszystkiego, dostałem tysiąc stron banalnej opowieści o terrorystach (zwykłych, islamskich, a także szlachetnych, dwuwymiarowych cyber-terrorystach), zaś przedstawiona w książce gra T’Rain wydała się być zupełnie niegrywalną.
Zauważyłem, że synchronizacja czasu coś nie do końca mi działa tak jak powinna. I nie chodziło o kilka sekund, ale o kilka dni różnicy między czasem na urządzeniu, a tym rzeczywistym. Trochę dziwne, bo urządzenie ma na sobie ntpd i powinno się synchronizować z pool.ntp.org. Po sprawdzeniu logów okazało się, że nie ma odpowiedzi od serwerów. Dziwne...
By skrócić potencjalnie długą historię – jeśli pakiet ma ustawiony port źródłowy na 123 to nie ma odpowiedzi od serwera. Jeśli natomiast port źródłowy jest inny (np. ntpdate -u), wówczas wszystko działa jak należy. Zapewne ISP blokuje takie pakiety...
Oczywiście opcja masquerade nie zmienia portu 123 na inny, więc trzeba było dorobić dodatkową regułę src-nat i wszystko zaczęło działać prawidłowo. Nie zmienia to faktu, że jestem nieco zirytowany zaistniałą sytuacją. Przy okazji – niestety, nie mam możliwości zainstalowania OpenNTPD, tam tego problemu nie ma bo usługa nie jest przywiązana do portu 123 (źródło).
Wpadłem na pomysł pobawienia się skryptami w OWASP ZAP i już tego żałuję. Tak, uwielbiam przeglądać kod OWASP ZAP tylko po to, by dowiedzieć się jak coś zrobić w skrypcie, bo na przykład to, co jest w template dołączonym do ZAP już jest nieaktualne....
Przy testowaniu aplikacji na iOS bardzo przydatny jest cycript. Ma on jednak jedną wadę – nie można “wstrzyknąć się” do procesu, który jest dopiero tworzony. Kiedy to jest potrzebne? Na przykład wtedy, gdy aplikacja przeprowadza jailbreak detetection i chcielibyśmy ten test oszukać.
Rozwiązaniem tego problemu może być użycie narzędzia Frida, które pozwala uruchomić proces i jednocześnie wstrzyknąć nasz skrypt, który pożądane modyfikacje wprowadzi.
Frida ma swoje wady, dość kiepską dokumentację, nie do końca działa na iOS7 (w moim przypadku cały binding do ObjC nie działa w iOS7), ale jeśli do czynienia mamy z iOS8 to zwykle działa zgodnie z oczekiwaniami.
Od dość dawna używam prostego skryptu, który identyfikuje:
nowe pliki;
usunięte pliki;
zmodyfikowane pliki.
Głównie chodzi mi o wykrycie sytuacji, w której pliki na moim serwerze zmieniają się w sposób “nieoczekiwany” (malware, włamanie, dostęp z konta innych użytkowników hostingu). Samo porównanie wykonywane jest w sqlite.
Skrypt napisałem, sprawdziłem, że działa i potem po prostu używałem. Raz na jakiś czas wpadał mi jednak do głowy pomysł, by zrobić jego optymalizację. Nie jakąś dużą, po prostu zrobić indeksy na tabelach. I tak przez długi czas pomysł pozostawał w koszyku “może kiedyś”, aż w końcu...
Załóżmy, że w trakcie testów udaje się znaleźć miejsce, w którym następuje jednocześnie brak walidacji danych wejściowych oraz brak encodingu na wyjściu. Te dwie słabości składają się na podatność - XSS.
XSS jest oczywiście zły, niedobry i można przy jego pomocy zrobić (prawie) wszystko, więc ryzyko jest duże, prawda?
Kiedyś świat był prosty, dwie metody GET i POST były wystarczające. Do tego od biedy HEAD i OPTIONS. A teraz? Jakieś takie wynalazki typu REST wymagające metod typu PUT, DELETE. Normalnie zgroza! A teraz pytanie – czy da się w tym scenariuszu wykorzystać CSRF?
Pierwszy z nich to sposób klasyczny, wymagający podania czterocyfrowego kodu PIN, drugi przy użyciu najlepszego i najłatwiejszego narzędzia weryfikacji, czyli odcisku palca.
Bardzo jestem ciekawy jakie były kryteria określania “najlepszości” tego rozwiązania. Jestem również bardzo ciekawy jakie będą zalecenia dla klientów w takim przypadku: Millions of fingerprints stolen in US government hack.
Powtórzę to jeszcze raz – nasza biometria dość dobrze nas identyfikuje. Niestety, nie kontrolujemy jej (zostawiamy nasze ślady), nie możemy jej również zmienić. Z tego powodu zawsze, gdy będę miał do wyboru biometrię lub np. PIN, wybiorę PIN.