Krótki(?) wpis w nawiązaniu do historii o uwierzytelnieniu w aplikacjach mobilnych i danych, które mogą wyciec z uwagi na wykorzystanie baz sqlite. Postanowiłem przeprowadzić prosty eksperyment – zapisać w bazie pewien rekord, a następnie zmodyfikować go na kilka sposobów:
przez UPDATE,
przez sekwencję INSERT, DELETE i VACUUM,
przez sekwencję DELETE, INSERT i VACUUM,
W każdym z przypadków spróbuję znaleźć w systemie plików pozostałości tego rekordu. Tajna wartość brzmi tak:
Czasem zdarza mi się wystąpić na jakiejś konferencji. Z reguły jest tak, że na każdą taka okazję przygotowuję inna prezentację. Nie jest to zbyt efektywne podejście, ilość czasu poświęcona na przygotowanie prezentacji jest zdecydowanie większa, niż czas, przez który wykorzystuję otrzymany “produkt”. By trochę poprawić sytuację, umieszczam treść (oczywiście nie słowo w słowo) prezentacji na blogu. Tym razem jest to prezentacja przygotowana na SecurityBSIDEs Polska (albo Warszawa, jak kto woli).
Przykłady podawane w tekście brane są z różnych aplikacji mobilnych, z którymi miałem do czynienia. Nie podaje ich nazw i nie demonstruję konkretnych podatności w konkretnej aplikacji. Raczej staram się dokonać uogólnienia i wykazać ogólne klasy problemów.
Całość dotyczy jednej z podstawowych funkcji bezpieczeństwa, czyli uwierzytelnienia użytkownika. Czy atakujący, który uzyska dostęp do urządzenia ofiary będzie w stanie ustalić jego dane uwierzytelniające i uzyskać dostęp do (jakiegoś) systemu?
Wygoda i bezpieczeństwo zwykle nie idą w parze. Jeśli system jest bezpieczny, zwykle wpływa to na wygodę jego użytkowania. Jeśli z kolei jest wygodny, cierpi na tym bezpieczeństwo. Ważne jest, by znaleźć taki punkt, w którym wygoda spełnia oczekiwania użytkowników, ale bezpieczeństwo ciągle jest na akceptowalnym poziomie. Ważne jest też to, by rozumieć skutki (dla bezpieczeństwa) przyjętych rozwiązań.
Dzisiaj zajmę się bezpieczeństwem “logowania przez wzorek”, a w szczególności porównaniem jego mocy z “normalnym” hasłem. Tak, chodzi mi o to rozwiązanie, gdzie użytkownik na kropkach rysuje wzorek. I nie, nie będę się zajmował atakami związanymi ze smugami zostawionymi na ekranie.
Zbliża się SecurityBSIDEs Polska. Na tej konferencji będę mówił na temat uwierzytelnienia w aplikacjach mobilnych, a konkretnie jak zepsuć ten mechanizm. Zepsuć, czyli zaimplementować go w taki sposób, że atakujący uzyskując dostęp do danych zapisanych na urządzeniu, będzie w stanie uwierzytelnić się w aplikacji i działać w kontekście ofiary, a czasami nawet autoryzować wykonywane operacje. Tak, problemy/błędy, o których będę mówił mają swoje pierwowzory w prawdziwych aplikacjach mobilnych o wiadomym zastosowaniu...
Ale ja nie o tym chciałem... Nie lubię robić slajdów na prezentacje. Nie lubię i nawet specjalnie nie staram się, by były jakieś wybitnie ładne. A jeśli bym się starał zrobić coś ładniejszego, to przy moich wybitnych zdolnościach plastycznych rezultat jest dokładnie odmienny od założonego. Poza tym moje prezentacje są z założenia mówione, a nie pokazywane. I tak będzie również tym razem.
P.S. A ja cały czas nosze się z zamiarem prezentacji bez slajdów...
Szczerze polecam lekturę tego wpisu: Capture ALL the Flags. szczególnie chodzi mi tutaj o ostatni poziom. Jest to piękny przypadek wykorzystania side-channel w celu uzyskania pewnych informacji. W tym wypadku szukaną informacją było hasło.
Od czasu do czasu pojawiają się oferty pracy dla osoby, która ma zajmować się bezpieczeństwem tworzonej aplikacji (webowej), między innymi projektowaniem architektury bezpieczeństwa tej aplikacji. Na podstawie takiego ogłoszenia można typować w jakim języku napisana jest dana aplikacja (tak, zwykle w FooBar). I tu pojawia mi się wątpliwość, czy rzeczywiście przy tego typu stanowisku ta “bardzo dobra znajomość” jest rzeczywiście niezbędna.
Ten wpis powstał w ramach zbierania myśli przy przygotowaniu prezentacji, którą ostatnio prowadziłem naForum Bankowości Elektronicznej. Całość dość ogólna, bez technicznego “mięsa”, ale taka jest specyfika tego typu imprez i chyba nie pozostaje nic innego, jak pogodzenie się z nią. Zresztą ankiety oceniające prezentacje pokazują, że uczestnicy takich imprez właśnie takiego przekazu oczekują.
Całość wypada zacząć znanym powiedzeniem:
Kto stoi w miejscu, ten się cofa, bo cały świat idzie do przodu.
Tak samo jest w przypadku bankowości. Funkcjonowanie banków, oferowane produkty i sposób ich oferowania, zmienia się. Często wykorzystywane są najnowsze technologie. Wszystko po to, by klienta obsługiwać w sposób bardziej efektywny, bardziej nowoczesny, zgodny z jego oczekiwaniami.
Postępu nie można ignorować, jeśli ktoś nie chce utracić swojej pozycji, musi wprowadzać do swojej oferty nowe produkty i oferować je w sposób oczekiwany przez klientów. Musi korzystać z nowych technologii. Ale co z bezpieczeństwem?
W tym zakresie tematów jest wiele, tym razem chcę poruszyć tylko te:
Jedną z podstawowych definicji/wymagań odnośnie bezpieczeństwa w kryptografii jest semantic security. Chodzi w niej o to, że atakujący dysponujący wiedzą o algorytmie szyfrowania i zaszyfrowanymi wiadomościami nie może powiedzieć na ich temat nic innego, poza określeniem ich długości.
Tak, pisałem już o tym wielokrotnie. Ale napiszę jeszcze raz. Drogi X. Pamiętaj, że świat jest pełen złych ludzi. Ludzi, którzy zastanawiają się jak wykorzystać każdą rzecz, którą zrobisz dla swojej korzyści. To dobrze, że w trosce o wygodę swoich użytkowników wprowadzasz coraz to nowe, bardziej zaawansowane, nowatorskie funkcje. Spróbuj jednak za każdym razem gdy żądasz/proponujesz/implementujesz kolejną ociekającą fajnością funkcję zastanowić się przez chwilę jak ta funkcja może zostać wykorzystana przez złych ludzi do ich złych celów. Uwierz mi, oni są pomysłowi i gotowi na wiele...
Podam Ci taki obrazowy przykład. To miło, że Twój klient lubi psy. Takie prawdziwe, duże psy. Nie takie nie wiadomo co, które można przypadkiem nadepnąć, przysiąść na kanapie, albo które w trakcie spaceru mogą niespodziewanie odfrunąć do krainy wiecznej szczęśliwości w szponach przypadkiem przelatującego ptaka drapieżnego. To dobrze dla Ciebie, że zdecydował się kupić drzwi Twojej produkcji. Wzmacniane, ze skomplikowanym systemem zamków i blokad. Takie drzwi, dzięki którym ich posiadacz może być pewien, że żaden nieproszony gość nie zjawi się u niego w domu. Ale pomyśl, czy na pewno dobrym pomysłem było dodanie do tych drzwi uchylnej klapki, przez którą pupilek Twojego klienta, wielkości średnio wyrośniętego cielaka, może swobodnie wchodzić/wychodzić do/z domu bez angażowania swojego właściciela do otwarcia drzwi? Ja wiem, my homo sapiens jesteśmy potomkami homo erectus. Ale obawiam się, że osoba, która chce się dostać do środka, niekoniecznie w cnych zamiarach, będzie skłonna do chwilowego schowania dumy do kieszeni i wykorzysta to uchylane udogodnienie do swoich celów. Na czworakach.
I nawet nie są wymagane takie zdolności:[Squeeze](http://en.wikipedia.org/wiki/Squeeze(TheX-Files)). A to, że ten odcinek jest więcej niż pełnoletni, to...
Zacznijmy od końca. Jest coś takiego jak principle of good enough. W wielu przypadkach rzeczywiście wystarczające jest zastosowanie rozwiązania, które jest wystarczająco dobre. A skoro temat ten pojawia się u mnie, można przypuszczać, że będzie o aplikacjach internetowych i bezpieczeństwie. I tak rzeczywiście będzie.