Zgodnie z zapowiedzią z poprzedniego wpisu wracam do tematu LastPass. Tym razem trochę na temat webowego klienta LastPass, tego co mogłoby się stać, gdyby był w nim (odpowiedni) XSS i wdrożenia Content Security Policy przez LastPass.
Jak zapewne wiecie, do trzymania swoich haseł używam KeePass. Zapewne wiecie/słyszeliście również o potencjalnych problemach LastPass. Potencjalnych, bo w zasadzie nie wiadomo co się stało i czy coś się stało, ale istnieją pewne przesłanki wskazujące na to, że jakiś incydent mógł mieć miejsce.
Idea LastPass nie do końca do mnie przemawiała. Jakoś przyzwyczaiłem się do KeePass (wcześniej do Password Minder) i nie odczuwałem specjalnej potrzeby bliższego zapoznania się ze sposobem działania LastPass. Z uwagi na to całe zamieszanie temat zaczął mnie trochę interesować.
Jakiś czas temu przygotowałem nową wersję zadania. Jak na razie zabrał się za nią chyba tylko Krzysiek Kotowicz, oczywiście jak zwykle z sukcesem. Samo zadanie nie jest zbyt trudne, występujące warianty sql injection nie różnią się wiele od tych już opisanych, choć jest co najmniej jedna drobna, ale istotna różnica.
Celem tego ćwiczenia jest nie tyle znalezienie samego sql injection (a jest jego kilka wariantów), ale pokazanie, że da się je wykorzystać. Oznacza to co najmniej skonstruowanie (pod)zapytania, które będzie zawierać SELECT, AND lub OR. Można oczywiście również wykorzystać UNION SELECT.
I jeszcze jedno – być może ciekawszym zadaniem niż to (nudne już) sql injection jest znalezienie i zrozumienie wskazówki, którą ukryłem w tym zadaniu. Wyszło z tego coś podobnego do wyzwania Beatthis! crypto challenge przygotowanego przez Krzyśka (pierwszych poziomów).
Zadanie dostępne jest pod adresem: http://bootcamp.threats.pl/lesson25c/.
Oryginał tego wpisu dostępny jest pod adresem Bootcamp XXV: przypominam o “nowej” wersji zadania
Autor: Paweł Goleń
W ramach porannej prasówki natknąłem się na ten post: Nikon Image Authentication System: Compromised. Jeśli dobrze rozumiem, to wszystkie aparaty, w których zaimplementowana jest funkcja Image Authentication korzystają z tego samego klucza. Super...
Warto się też zastanowić, czy można to zrobić dobrze (czyli skutecznie). Oczywiście lepszym rozwiązaniem byłoby wygenerowanie unikalnego klucza prywatnego dla każdego urządzenia z osobna. Można również próbować lepiej zabezpieczyć klucz przed pobraniem go na zewnątrz. Ale czy do sfałszowania zdjęcia na pewno potrzebne jest pozyskanie tego klucza? Może wystarczy ładnie poprosić taki aparat, by podstawione przez nas zdjęcie (w domyśle – zmodyfikowane) podpisał. Bo czy cały aparat jest w 100%25 odporny na modyfikacje?
Oryginał tego wpisu dostępny jest pod adresem Ciekawy temat: czy to zdjęcie jest prawdziwe
Autor: Paweł Goleń
Szlaban, o którym już pisałem, jak był niszczony, tak nadal jest. Właśnie zakładany jest nowy, już straciłem rachubę który. Ciekawe jak długo ten przeżyje. A wszystko “pod okiem kamery”, która znajduje się dosłownie 5 metrów od wjazdu na osiedle tak bohatersko, aczkolwiek nieskutecznie, bronionego przez szlaban. To tyle w temacie prewencyjnej roli kamer, nie czuję się przy nich bezpieczniej. A i w ujęciu sprawców kamera nie pomaga...
Jaki efekt? Taki, że czuję się biedniejszy. Po pierwsze dlatego, że za ten “monitoring” płacę, po drugie dlatego, że za kolejne szlabany również płacę. Super!
Oryginał tego wpisu dostępny jest pod adresem Kolejne życie szlabanu
Autor: Paweł Goleń
Pytanie, czy pierwsza odpowiedź jest najlepsza miała drugie dno. Tym dnem jest książka 50 wielkich mitów psychologii popularnej. Jedenym z mitów(?) omawianych w tej książce jest stwierdzenie:
Kiedy rozwiązujesz test i nie jesteś pewny odpowiedzi, najlepiej zaufać pierwszemu przeczuciu.
Istnieje przeświadczenie, że pierwsza odpowiedź (w testach wyboru) jest najlepsza. Sam z tej “zasady” wielokrotnie korzystałem, raczej z dobrym skutkiem. Uważam ją za skuteczną nie z jakichś magicznych powodów, ale dlatego, że mam skłonność do przekombinowania. Po prostu często wydaje mi się, że odpowiedź nie może być taka prosta i na pewno musi być w pytaniu jakiś haczyk, więc doszukuję się w pytaniach i odpowiedziach drugiego i trzeciego dna. Jak pokazuje doświadczenie – zwykle tak nie jest, pytania (i odpowiedzi) są z reguły tym, czym wydają się być na pierwszy rzut oka.
Zasada “pierwsza odpowiedź jest najlepsza” nie zwalnia oczywiście od przeczytania (i zrozumienia) pytania oraz odpowiedzi. Nie zwalnia również od myślenia i zastanowienia się. To nie jest “strzelanie w ciemno”. W moim przekonaniu takie podejście jest specyficznym wykorzystaniem zasady ekonomii myślenia.
Jakie jest Wasze zdanie na ten temat? Macie podobne, czy inne doświadczenia? I tak, tym razem pytanie ma drugie dno. A może nawet trzecie :)
Oryginał tego wpisu dostępny jest pod adresem Pierwsza myśl zawsze najlepsza?
Autor: Paweł Goleń
W trakcie testów bezpieczeństwa aplikacji nie jestem zwolennikiem podejścia “czarnego pudełka”. Wychodzę z założenia, że celem testów jest identyfikacja jak największej ilości podatności oraz słabości (słabość nie jest tożsama z podatnością). Wszystko po to, by bezpieczeństwo aplikacji poprawiło się.
Jakiś czas temu wspominałem o scenariuszu związanym z network forensic (Network Forensic: Nitroba University Harassment Scenario). Opierając się na dostępnym w ramach tego przykładu zapisie ruchu sieciowego, pokażę małą ciekawostkę. Jak ruch NTP może posłużyć do ustalenia ile komputerów jest aktywnych za NAT.
Krótki i gawędziarski wpis odnośnie tego, jak szukać prostych przypadków XSS. Przynajmniej teoretycznie prostych. Jeśli mamy do czynienia z dużą aplikacją, w ramach której można zidentyfikować kilkadziesiąt punktów wejścia (w uproszczeniu – formatek), z których każdy przyjmuje kilka(naście) parametrów, dokładne przeanalizowanie każdego z nich może być niemożliwe przez ograniczenia czasowe. Z drugiej strony dobrze jest zidentyfikować te miejsca, w których dane pochodzące od użytkownika są wypisywane na stronie i w dodatku są wypisywane w kontekście, który na XSS pozwala.