Miałem ostatnio okazję popatrzeć w kod jednej aplikacji, napisanej w PHP. Schemat działania był taki, że był główny “kontroler”, który w parametrach przyjmował informacje o module. Kontroler wykonywał include modułu. I niby wszystko działało, gdyby nie kilka drobnych szczegółów. W dodatku te szczegóły powtarzają się w wielu różnych kawałach kodu, różnych autorów, więc warto o nich wspomnieć.
Jeśli ktoś chciałby się sprawdzić w temacie computer forensic , to tu jest przykładowe wyzwanie: Competition – Computer Forensic Investigation. Wyzwanie ma to dwie zalety:
Dobra zabawa na deszczowe lato :)
Od pewnego czasu wiadomo było, że DNS jest dziurawy, w związku z czym rozpoczął się proces jego łatania. Informacje o szczegółach problemu stały się publiczne jednak nieco wcześniej, niż było to planowane (Details of DNS Flaw Leaked; Exploit Expected by End of Today). W rezultacie dostępny jest już odpowiedni plugin do Metasploit.
Kilka razy spotkałem się z SQL Injection w mechanizmach sortowania danych. Konstrukcja aplikacji często wygląda w taki sposób, że w parametrach przekazywana jest nazwa kolumny do sortowania, oraz kierunek sortowania (ASC/DESC). Parametry te następnie wstawiane są (poprzez sklejanie) do zapytania SQL, co jest oczywiście ZŁE! Do tego kilka razy słyszałem stwierdzenie, że w ORDER BY nie da się zrobić sql injection. Cóż, obawiam się, że jednak się da i wcale nie jest to specjalnie skomplikowane. Poniżej przykład w MySQL.
Razem z Windows 2000 i NTFS 3.0 (wówczas zwanym NTFS 5.0) pojawił się EFS. EFS pozwalał na szyfrowanie poszczególnych plików, nie pozwalał i nie pozwala na szyfrowanie całych partycji lub dysków. Równolegle pojawiło się kilka narzędzi komercyjnych, które pozwalały szyfrować całe dyski i wymagały uwierzytelnienia użytkownika przed uruchomieniem systemu. Możliwość szyfrowania partycji systemowej pojawiła się również w TrueCrypt od wersji 5.0. Od czasu, gdy pojawiła się taka możliwość w TrueCrypt, dysk systemowy mojego “roboczego” laptopa jest zaszyfrowany. Dlaczego whole disk encryption a nie EFS?
Czy warto szyfrować cały dysk? Tak. Dowód “nie wprost” znajduje się tutaj: TrueCrypt's Deniable File System. Nie, nie chodzi mi tu o DFS, tylko o to, że system i aplikacje ciekną. Szyfrując cały dysk, problem plików tymczasowych, pliku pagefile.sys , hiberfil.sys , rejestru (The Windows Registry as a Log File), narzędzi indeksujących i innych tego typu “niespodzianek” znacznie się zmniejsza. Oczywiście, należy pamiętać choćby o możliwości odzyskania kluczy z pamięci (Lest We Remember: Cold Boot Attacks on Encryption Keys)... A szyfrowanie na wyższych warstwach (kontenery TC, EFS, szyfrowane archiwa, ...) też się przydaje. Oczywiście z kluczem/hasłem innym, niż przy starcie systemu.
O tym, że walidacja danych wejściowych jest istotna, pisałem już wiele razy. Tym razem będzie o XML.
Kolejny element w kolekcji rzeczy ZŁYCH. Dziś w roli głównej protokół FTP.
Ostatnio miał miejsce gigantyczny wyciek danych osobowych z PEKAO S.A.. Można się spierać, czy był on rzeczywiście taki gigantyczny, ale nie o tym chcę pisać. Jeśli ktoś jeszcze o tym nie słyszał, może zacząć swoją lekturę tu. Chcę pokazać dlaczego do takich zdarzeń dochodzi i będzie dochodzić.
W informacjach dotyczących phishingu jak mantrę powtarza się zalecenie, by sprawdzić adres strony, oraz to, czy adres zaczyna się od https. Problem w tym, że to nie daje wiele, o czym już zresztą pisałem. Owszem, zalecenia te mogą być wystarczające, gdy jest to “czysty” phishing, gorzej, gdy pojawia się wrogi kod.