Paweł Goleń, blog

Częstym problemem jest zabezpieczenie aplikacji/systemu przed klientem, który chce z tego systemu, lub jakiejś jego funkcji, korzystać zbyt często. Potrzeba takiego ograniczenia może wynikać z różnych przyczyn. Może to być na przykład zabezpieczenie przed masową enumeracją danych, ale równie dobrze powód może być bardziej trywialny – ochrona przed wyczerpaniem zasobów. Może byc na przykład tak, że “zwykłe” wyszukiwanie jest kosztowne dla serwera i złośliwy klient może wykorzystać ten fakt do wykonania ataku DoS.

Jak się przed taką sytuacją bronić? Jednym z pomysłów może być uczynienie wywołania takiej metody dużo bardziej kosztownym dla klienta, niż jej obsługa dla serwera. W jaki sposób to zrobić? Na przykład wykorzystując kryptografię.

Czytaj dalej...

Zgodnie z zapowiedzią podam wyniki eksperymentu, ale bez szczegółów odnośnie tego, do czego był mi on potrzebny.

Czytaj dalej...

Czasem bywa tak, że człowiekowi wpadnie do głowy jakiś pomysł. Jak wpadnie, to pół biedy. Gorzej, jeśli go zrealizuje. Mnie wczoraj wpadł pomysł by w końcu zmienić swojego wysłużonego Windows XP na Windows 8. Jak pomyślałem tak zrobiłem...

Nie, nie będę narzekał na system, bo prawdę mówiąc nawet mi się podoba. Mimo, że mój laptop jest dość leciwy, to nowy system nie działa wolniej niż XP. Jedyny problem to urządzanie się na nowo.

Oryginał tego wpisu dostępny jest pod adresem Windows 8

Autor: Paweł Goleń

Raz na jakiś czas mam pomysł na eksperyment. Tak jest i tym razem, ale potrzebna mi Wasza pomoc.

Czytaj dalej...

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:

MAGICPMQ00

Dodatkowe założenie – testy wykonywane na FAT32.

Czytaj dalej...

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?

Czytaj dalej...

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.

Czytaj dalej...

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...

Oryginał tego wpisu dostępny jest pod adresem Jak ja nie lubię robić slajdów!

Autor: Paweł Goleń

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.

Czytaj dalej...

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.

Czytaj dalej...