Jak wiecie, wprost przepadam za długimi weekendami. Dziś na przykład plany wyjścia w góry musiałem zrewidować, bo dotarcie do planowanego punktu wyjścia nie powiodło się. Z uwagi na korki oczywiście. Zamiast tego powłóczyliśmy się po okolicznych (w stosunku do drogi) pagórkach. Też było miło. Co nie zmienia faktu, że długie weekendy są BARDZO ZŁE!
Oryginał tego wpisu dostępny jest pod adresem Długie weekendy są ZŁE! A.D. 2009
Autor: Paweł Goleń
Tradycyjnie 1 maja: OpenBSD 4.5.
Jednym z projektów OWASP jest projekt Application Security Verification Standards. Warto przyglądnąć się udostępnionym dokumentom (choć znajdują się wciąż w fazie beta)
Od pewnego czasu doświadczam pewnego, nieco irytującego, problemu z przeglądarką Firefox. Nader często zdarza się tak, że nie ładuje ona arkuszy stylów CSS, w związku z czym wyświetlana strona jest “goła”. Coś jakby CSS Naked Day...
Tak, to prawda. Problem dotyczy programów Acrobat Reader i Acrobat, ponownie jest związany z JavaScript. Więcej informacji: Update on Adobe Reader Issue, JavaScript flaw reported in Adobe Reader, Two new vulnerabilities in Adobe Acrobat Reader.
Każdy bank twierdzi, że jego system bankowości internetowej jest bezpieczny. Użytkownik zwykle nie ma możliwości zweryfikowania tych twierdzeń. Można jednak popatrzeć na taki system krytycznym okiem. Tu kilka przykładów na co warto zwrócić uwagę.
Jeśli ktoś sobie jeszcze nie poradził z zadaniem http://bootcamp.threats.pl/lesson05/, udostępniam tekst: Bootcamp: Cross Site Request Forgery i Cross Site Scripting. Oczywiście zadanie to można zrealizować również w inny sposób. There's more than one way to skin a cat.
W trakcie spotkania SPIN pojawiło się pytanie w jaki sposób można określić czas trwania/pracochłonność penetracyjnego testu bezpieczeństwa. Nie istnieje prosta formuła, która na wejściu dostaje “opis aplikacji” (cokolwiek to oznacza), a na wyjściu podaje ilość osobodni potrzebnych na wykonanie testu. W znacznym stopniu określenie pracochłonności (co wprost przekłada się na czas trwania testu) opiera się na doświadczeniu i wcześniej realizowanych projektach. Po rekonesansie w aplikacji (no niestety, bez tego każda “wycena pracochłonności” jest w zasadzie zgadywaniem) można porównać aplikację z wcześniej wykonywanymi testami – w szczególności istotną informacją jest jak długo w rzeczywistości trwał taki test. Warto zauważyć, że ten sposób określania harmonogramów “występuje w przyrodzie”: Evidence Based Scheduling (wielkie dzięki dla Tomka za to, że polecił mi kiedyś stronę Joel on Software).
Na konferencji Hack In The Box zaprezentowany został VBootkit2 (materiały konferencyjne), w rezultacie czego można przeczytać tego typu informacje: Researchers show how to take control of Windows 7, albo Windows 7 z nieusuwalnym exploitem (autor artykułu chyba nie do końca rozumie pojęcie “exploit”). Ja powiem tak – proponuję zapoznać się z pracami Joanny Rutkowskiej (Invisible Things Lab, blog), gdzie tego typu koncepcje przewijają się od kilku lat. Ot, choćby taki przykład: Attacking SMM Memory via Intel® CPU Cache Poisoning. Zresztą in the wild występuje już od pewnego czasu malware “przejmujący system przed jego uruchomieniem”, mowa oczywiście o Mebroot. To chyba pozwala popatrzeć na temat VBootkit2 z szerszej perspektywy. Przy okazji warto zauważyć, że ten problem nie dotyczy tylko Windows. W 2007 roku, po prezentacji pierwszej wersji VBootkit pojawił się artykuł VBootkit vs. Bitlocker in TPM mode, ciekawe, czy i tym razem pojawi się taka analiza.
Na koniec jeszcze jeden artykuł do przeczytania: Why do I miss Microsoft BitLocker?
Zgodnie z zapowiedzią udostępniam materiały dotyczące spotkania SPIN. Znajduje się tam prezentacja (cała, wyciętych tylko kilka nieistotnych slajdów z obrazkami), oraz tekst (tylko do tej części slajdów, które zdążyłem pokazać).