Od czasu do czasu w trakcie testów aplikacji można spotkać się z sytuacją, gdy aplikacja nie działa prawidłowo po skonfigurowaniu proxy (np. Burp). Dotyczy to często “grubych klientów”, które wykorzystywane są do tradingu. Dlaczego tak się dzieje?
Co jakiś czas pojawia się ten sam dylemat – czy przedłużyć subskrypcję AutoMapy (AutoMapa EU – to ważne)? Do tej pory decyzja zawsze była na “tak”, ale teraz mam pewne wątpliwości.
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.
Więcej: What's new in BitLocker?
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.
Oryginał tego wpisu dostępny jest pod adresem XTS-AES w BitLocker
Autor: Paweł Goleń
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ą.
Jakiś czas temu temat tej książki pojawił się po raz kolejny, tym razem w kontekście Cybersecurity Canon, a konkretnie na temat tej książki więcej jest tutaj: The Cybersecurity Canon: Reamde.
Szczerze? Czytało mi się dość ciężko, słuchało (Audible) zdecydowanie lepiej. Ogólnie – ocena na plus.
Oryginał tego wpisu dostępny jest pod adresem REAMDE
Autor: Paweł Goleń
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).
A teraz pytanie – dlaczego? Zgaduję – zapewne dlatego: Understanding and mitigating NTP-based DDoS attacks.
DZIĘ-KU-JE-MY!
Oryginał tego wpisu dostępny jest pod adresem Bo NTP to przecież takie groźne jest, no nie?
Autor: Paweł Goleń
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....
Oryginał tego wpisu dostępny jest pod adresem Głupie pomysły (ZAP)
Autor: Paweł Goleń
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:
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...
Przed:
findnew_files: 24.0540001392 finddeleted_files: 21.9730000496 findmodified_files: 31.5250000954
Po:
findnew_files: 0.0569999217987 finddeleted_files: 0.050999879837 findmodified_files: 0.0410001277924
Ups :)
Oryginał tego wpisu dostępny jest pod adresem Index robi różnicę
Autor: Paweł Goleń
Na początek oczywista oczywistość:
Risk = Impact x Likelihood
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?