Jak zapewne wiecie pojawiła się informacja o skutecznym ataku na przeglądarkę Chrome (np. tu: Dziura i exploit na Google Chrome [0day] i u źródła: Google Chrome Pwned by VUPEN aka Sandbox/ASLR/DEP Bypass). Oczywiście całość okraszona podejściem “wiemy, ale nie powiemy”, a konkretniej “wiemy, ale powiemy tylko naszym klientom, a producent niech sam dziury szuka”. Z drugiej strony pojawiają się informacje, że dziura wcale nie jest w Chrome. I w tym momencie warto spróbować wykonać mały eksperyment myślowy: o co może chodzić.
Była sobie rozróba na stadionie. Nie pierwsza i nie ostatnia. A jej skutki są takie, że znowu mamy prześciganie się w pomysłach odnośnie tego co z tym trzeba zrobić i jak to zrobić. Postanowiłem się do tego strumienia pomysłów przyłączyć.
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).
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?
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!
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 :)
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ę.