Paweł Goleń, blog

Na początek zagadka. Co jest nie tak z tym kodem (Python):

import random osoby = ['osoba1', 'osoba2', 'osoba3'] print osoby[random.randint(0,10)%25len(osoby)]

Czytaj dalej...

Okazało się, że w czasie ostatniej ślizgawicy ucierpiała nie tylko moja dup^wduma, ale również taki mój jeden gadżet:

Nie widać tego dokładnie na zdjęciu, ale elektronika jest uszkodzona, w szczególności kość pamięci pokryła się ładną siatką pęknięć.

Nie był to najbardziej pojemny pendrive, szybkością również nie grzeszył. Miał natomiast jedną cechę, którą bardzo lubiłem – po podłączeniu do komputera przedstawiał się jako dysk, a nie jako nośnik wymienny. Co z tego? To, że wówczas można było na nim zrobić partycje (specyfika Windows), jedną zostawić nieszyfrowaną i trzymać na niej niezbędny toolbox, a drugą zaszyfrować w całości TrueCryptem i trzymać na niej notatki z testów.

Zna ktoś może jakieś powszechnie dostępne gadżety, które mają taką samą cechę?

Oryginał tego wpisu dostępny jest pod adresem Buuuu :(

Autor: Paweł Goleń

Prosty eksperyment:

  1. zainstaluj Google Drive,
  2. w synchronizowanym folderze utwórz kontener TrueCrypt, zaczekaj aż się zsynchronizuje,
  3. zamontuj kontener, utwórz w nim plik,
  4. odmontuj kontener,
  5. pobierze kontener z Google Drive,
  6. zamontuj pobrany kontener,
  7. ...gdzie jest mój plik?!

Właściwie do ostatniego punktu może się nie uda dojść, bo samo zamontowanie kontenera może okazać się niemożliwe (właściwie – otwarcie zamontowanego kontenera).

Czytaj dalej...

Załóżmy, że mamy aplikację mobilną, która korzysta z chmury. Aplikacja przechowuje pewne ustawienia/dane specyficzne dla użytkownika, ale nie są to dane, których ujawnienie lub modyfikacja spowodowałyby koniec świata. W takim scenariuszu wymaganie uwierzytelnienia użytkownika może być nadmiarowe, wystarczająca będzie jego identyfikacja. Identyfikacja ta może odbywać się w sposób kompletnie dla użytkownika niezauważalny. Identyfikowana może być instancja aplikacji (konkretna instalacja) lub urządzenie, na którym ta aplikacja jest zainstalowana.

Czytaj dalej...

Jeśli ktoś zaoferuje wam wykonanie projektu (najczęściej jakiegoś serwisu) w oparciu o “autorski, profesjonalny CMS”, to uciekajcie tak szybko i tak daleko, jak tylko się da. Może i w jednym przypadku na dziesięć popełnicie błąd. W pozostałych dziewięciu właśnie uniknęliście poważnych kłopotów.

Czytaj dalej...

Co do zasady wykorzystanie pewnej dodatkowej “warstwy abstrakcji” ogranicza ryzyko związane z błędami typu SQL Injection. Ogranicza, ale nie eliminuje, bo:

  • ta “warstwa abstrakcji” może być źle użyta,
  • w wykorzystanym rozwiązaniu mogą być błędy,

I tak właśnie jest w przypadku Ruby on Rails: SQL Injection Vulnerability in Ruby on Rails (CVE-2012-5664) (patrz też: Rails 3.2.10, 3.1.9, and 3.0.18 have been released!).

A teraz pytania, które zadawałem programistom na szkoleniu, i na które odpowiedź brzmiała zwykle “nie”:

  • czy jesteś w stanie wymienić wszystkie biblioteki, z których korzysta Twoja aplikacja,
  • czy śledzisz informacje o nowych wersjach wykorzystanych bibliotek,
  • czy jesteś pewny, że są one aktualne,

Pojęcie “biblioteki” jest tutaj pewnym placeholderem. Patrz też: Remember the Giblets! i The Trouble with Giblets.

Błąd w takim “dodatku” nie jest błędem w Twoim kodzie, ale jest błędem w Twojej aplikacji. Jeśli używasz cudzego kodu, musisz o niego dbać (On handling your pets and a CSRF protection that wasn't). Absolutne minimum to:

  • wiedzieć co się użyło (a wybierać rzeczy do użycia też trzeba z głową!),
  • śledzić informacje na temat użytych elementów,

A co, kiedy ktoś mówi “nie mogę zagwarantować, że po aktualizacji nasz system będzie nadal działał”? Cóż, z tym też można sobie poradzić: Test-driven development.

Oryginał tego wpisu dostępny jest pod adresem SQLi w RoR

Autor: Paweł Goleń

Na początek odsyłacz do “materiału poglądowego”: Hacking an Android Banking Application. Chodzi mi szczególnie o sekcję “Memory dump analysis”, choć nie tylko. Na potrzeby tego krótkiego wpisu jednak ograniczmy się do tego scenariusza.

A teraz fragment zdania, które w stosunkowo często pojawia się w książkach Schneiera:

If (...), you already have much bigger problems.

A teraz temat do przemyśleń – jeśli atakujący dysponuje takim dostępem do urządzenia ofiary, że jest w stanie pozyskać i analizować zrzut pamięci, to czy przypadkiem nie znaczy to, że mamy już większy problem, niż to, co atakujący w tej pamięci znajdzie?

Oryginał tego wpisu dostępny jest pod adresem Czy aby na pewno TO jest problem?

Autor: Paweł Goleń

Załóżmy, że w wyniku błędu w aplikacji mamy możliwość odczytu dowolnego pliku z serwera, pod warunkiem, że znamy jego nazwę (i oczywiście ścieżkę). Załóżmy, że serwer pracuje pod kontrolą systemu Windows, a aplikacja jest napisana w PHP. Załóżmy dodatkowo, że ciekawe dane znajdują się w sesji użytkownika i bardzo chcemy się do nich dostać.

Czym te “bardzo ciekawe dane” mogą być? Zależy. Jednym z ciekawszych przypadków, które widziałem w ciągu ostatnich 12 miesięcy, była sytuacja, w której w sesji użytkownika był zapisywany jego login i hasło. Działo się tak, ponieważ aplikacja webowa pełniła właściwie tylko rolę GUI do WS, który to WS z kolei wymagał podania danych uwierzytelniających przy wywołaniu każdej metody. Możliwość masowego odczytywania danych zapisanych w sesji niewątpliwie w tym przypadku byłaby bardzo “owocna” dla atakującego.

To jak, damy radę się dostać do tych konfitur?

Czytaj dalej...

Chodzi oczywiście o to jak przechowywać hasła (i potencjalnie inne dane uwierzytelniające) w systemie tak, by były bezpieczne. Odpowiedź na to pytanie powtarzana jest jak mantra:

Hasła powinny być hashowane z użyciem kosztownego obliczeniowo algorytmu (np. scrypt, bcrypt, PBKDF2), należy do tego użyć unikalny dla każdego hasła salt i opcjonalny pepper. Szyfrowanie jest złe, bo w systemie musi być przechowywany klucz i atakujący, który uzyska dostęp do klucza będzie w stanie rozszyfrować wszystkie hasła przechowywane w bazie.

I wszystko się zgadza. Prawie.

Czytaj dalej...

Tym razem z okazji TechCamp#6.

Czytaj dalej...