Prywatność to termin, który – w najszerszym znaczeniu – określa możliwość jednostki lub grupy osób do utrzymania swych danych oraz osobistych zwyczajów i zachowań nieujawnionych publicznie.
Ja bym nieco rozszerzył jeszcze to pojęcie. Moim zdaniem z prywatnością powiązane jest również prawo do decydowania o tym z kim i w jakim stopniu swoją prywatnością się dzielę.
Mówiąc “SSL” w rzeczywistości nie mówi się nic na temat wykorzystanego protokołu. Bo może to być równie dobrze SSLv2, SSLv3 lub TLSv1. Do tego dochodzi jeszcze całkiem spora grupa szyfrów, które mogą być wykorzystane w ramach danego połączenia, przy czym nie dla każdej wersji protokołu każdy szyfr jest dopuszczalny. W efekcie czasem pojawia się problem i klient nie może dogadać się z serwerem i zestawić połączenia. Jest to szczególnie irytujące, gdy akurat tym klientem jest twoje ulubione local proxy , a cała sytuacja uniemożliwia rozpoczęcie testów aplikacji...
Z problemem można radzić sobie na kilka sposobów. Można próbować użyć socat (trzeba pamiętać o opcjach cipher i method bo OpenSSL, z którego korzysta socat, sam z siebie również może mieć problemy z wynegocjowaniem parametrów połączenia), można próbować zestawiać kilka narzędzi w łańcuch (np. Burp i Fiddler)... Okazuje się jednak, że można również wpłynąć na wersję protokołu, którą używać będzie Fiddler. Całość sprowadza się np. do jednej linii kodu:
Jedna uwaga: socat może być przydatny wówczas, gdy narzędzia kompletnie nie radzą sobie z SSL. Przykładowo intruder21 ma zwyczaj, by wysyłać żądania wyłącznie jako HTTP, nawet jeśli oryginał korzystał z HTTPS.
Tak tak, “we are feeling confident” to bardzo popularne podejście. A potem jest pożar w burdelu. Albo na produkcję idzie dziurawa aplikacja, bo już “inaczej się nie da”...
Jeśli do tej pory uszło to Waszej uwadze już 23 maja odbędzie się w Krakowie kolejne spotkanie OWASP. Więcej informacji na ten temat można znaleźć oczywiście na stronie polskiego chapteru OWASP, jak również np. tu: [Kraków] Spotkanie OWASP.
Tym razem tematyka nieco inna niż na ostatnich spotkaniach:
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?
