Wampiryczny blog

ONI Cię śledzą!

2009-11-14T09:49:00-08:00

Jakiś czas temu z pewnym zdziwieniem patrzyłem na ludzi, którzy mówili, że śledzą ich Oni, okręcali głowy folią aluminiową, by Oni nie mogli czytać ich myśli albo "wkładać myśli prosto do głowy". To, co kiedyś można było uznać za wytwór chorego umysłu cierpiącego na urojenia, dziś zaczyna być przykrą rzeczywistością...

Kilka fragmentów z artykułu Billboard z wysokim IQ (Newsweek 46/2009):

(...) skanery, w jakie wyposażono plakaty, wychwytują fale radiowe docierające do anteny każdego auta na drodze. (...) Jeśli jest to radio, którego słuchaczkami są np. młode dobrze zarabiające kobiety (...), na ekranie pojawi się reklama spa (...),
(...) uczeni wyposażyli go w system analizy twarzy (...), który rejestruje ludzką mimikę (...) by przewidzieć, jak przechodzień reaguje na konkretną reklamę (...),
(...) będzie w stanie z daleka ustalić, czy zbliża siędo niego kobieta, czy mężczyzna (...) zaproponuje reklamę perfum lub sportowego auta (...),
(...) plakat będzie mógł wysłać komunikat dźwiękowy do wybranej osoby, tak by inni go nie słyszeli (...),
(...) gdy sięgną po wózek - do jego odczepienia (...) używają specjalnej karty lojalnościowej, na której zapisana jest lista produktów kupowanych wcześniej. Układ elektroniczny wózka ją analizuje i wyświetla reklamy podobnych towarów (...),

Podoba się Wam taka wizja świata? Mnie nie. Ale niestety - tak będzie. Wszystko po to, by Oni sprzedawali coraz więcej nikomu niepotrzebnych produktów.

OWASP Top10 2010 (RC1)

2009-11-14T01:37:19-08:00

Pojawiła się nowa wersja OWASP Top10. Nie jest to jeszcze wersja ostateczna, ma status RC. Zmiany w stosunku do OWASP Top10 2007 są niewielkie (fragment PDF):

Warto zapoznać się z tym dokumentem.

Kiedy powstał tamten post - odpowiedź

2009-11-13T08:45:00-08:00

Jakiś czas temu pisząc o identyfikatorach globalnych i pośrednich zadałem pytanie całkiem niezwiązane z tematem:

Pytanie dodatkowe nie związane z tematem: kiedy (prawdopodobnie) powstał ten post? Co za tym przemawia?

Temat chyba nikogo nie zainteresował, nie każdy jest tak nienormalny jak ja, ale co tam, odpowiem sam sobie - może komuś się przyda.

Wymieniony post zawiera ten obrazek. Przy odwołaniu do niego serwer zwraca następującą odpowiedź:

HTTP/1.1 200 OK
Server: IdeaWebServer/v0.60
Date: Thu, 12 Nov 2009 21:33:10 GMT
Content-Type: image/png
Content-Length: 71467
Connection: Keep-Alive
Last-Modified: Wed, 05 Aug 2009 20:21:52 GMT
Expires: Fri, 13 Nov 2009 21:33:11 GMT

Odpowiedź na zadane pytanie sugeruje nagłówek Last-Modified.

Piramida potrzeb

2009-11-12T08:19:00-08:00

W psychologii istnieje pojęcie piramidy (hierarchii) potrzeb. Potrzeby wyższe aktywizują się dopiero po zaspokojeniu potrzeb niższych. Również w przypadku budowania aplikacji, (w)budowania bezpieczeństwa i jego testowania są rzeczy, które mają większy priorytet niż inne. Dopiero po ich realizacji można przejść "poziom wyżej".

Aplikacja MUSI działać

Pierwszą podstawową potrzebą jest to, by aplikacja działała i realizowała swoje cele. Jak już kilka razy pisałem aplikacje zwykle mają jakiś cel. Istnieje jakaś potrzeba, podejmowana jest więc decyzja o wdrożeniu lub stworzeniu aplikacji, która potrzebę (potrzeby) będzie zaspokajać/realizować. Sam proces definiowania wymagań odnośnie aplikacji, modyfikowania ich w trakcie jej tworzenia/wdrożenia i konfrontacja koncepcji z projektem a projektu z rzeczywistością może być... zaskakująca, co zresztą doskonale pokazuje znany(?) obrazek:

Osiągnięcie stanu, w którym aplikacja działa i realizuje swoje pierwotnie zdefiniowane zadania (a przynajmniej pewien "wystarczający" ich podzbiór) ma znaczenie priorytetowe. To zadanie otrzymuje większość dostępnych zasobów i zagładza (od zagłodzenia procesu) pozostałe zadania, które tak krytyczne nie są, a przynajmniej nie wydają się być.

Czym to objawia się w praktyce? Ciekawym zajęciem może być obserwacja zmian zachodzących w harmonogramach projektów. Można często zaobserwować wydłużanie się etapu tworzenia kodu i jednocześnie skracanie czasu poświęcanego na testy (weryfikację poprawności działania) stworzonego i wdrożonego systemu. Skracanie, ponieważ data produkcyjnego uruchomienia systemu jest "święta" i nie może zostać w żaden sposób przesunięta.

Poza skróceniem czasu przeznaczonego na testy, skraca się również czas zarezerwowany na poprawę znalezionych błędów. W wielu przypadkach przyjmowane jest optymistyczne założenie, że takich błędów nie będzie. W efekcie tego założenia zakończenie testów zbiega się z udostępnieniem produkcyjnym systemu i czasu na wprowadzenie poprawek po prostu nie ma.

Choć skrócenie czasu przeznaczonego na testy, poprawki i ich weryfikację jest zjawiskiem niekorzystnym, to zdecydowanie gorsze efekty ma to, co dzieje się po stronie "produkcji". Działanie pod presją czasu często prowadzi do tego, że tworzony kod jest niskiej jakości (w szczególności - nie jest bezpieczny). Powód jest prosty - dążenie do osiągnięcia sytuacji, w której spełnione są wymagania funkcjonalne. Wszystko to, co nie jest niezbędne, odkładane jest "na potem". Rezygnuje się z niektórych dobrych praktyk, tylko po to, by zdążyć na czas. I później w kodzie można znaleźć takie fragmenty:

$stm = $db->prepare('SELECT * FROM tabela WHERE a=:p_a AND b=:p_b AND c='.$c);
$stm->bindParam(':p_a', $a, PDO::PARAM_INT);
$stm->bindParam(':p_b', $b, PDO::PARAM_STR, 32);

...i jak łatwo się domyślić w $c zapewne będzie SQLi... Dodatkowym rezultatem tego typu praktyk będą prawdopodobnie duże niespójności w aplikacji, przez co wyciąganie ogólnych wniosków będzie niemożliwe, co z kolei spowolni proces testów.

A jak to wygląda po stronie testów?

Jak to przekłada się na testowanie bezpieczeństwa? Tu też widzę pewną hierarchię potrzeb (i zadań)... Pewne warunki muszą być spełnione po to, by można było nie tylko rozpocząć testy, ale by również testy były efektywne. Testy, które zostaną przeprowadzone, również układają się w pewne logiczne następstwo. Najpierw rzeczy podstawowe, w dużym stopniu uniwersalne. Dopiero później rzeczy specyficzne dla konkretnej aplikacji.

Aplikacja musi działać (a przynajmniej badana funkcja)

Po pierwsze trzeba sprawdzić, czy aplikacja działa. Trudno testować jest funkcję, która nie jest jeszcze zaimplementowana lub działa w sposób błędny. Sensowność testowania funkcji, która ulegnie istotnym zmianom (bo nie przeszła testów funkcjonalnych czy akceptacyjnych) jest wątpliwa. Owszem, wykazanie błędów bezpieczeństwa jest przydatne, bo w trakcie modyfikacji można je jednocześnie usunąć, to stwierdzenie, że błędów nie ma jest praktycznie bezwartościowe - błędy mogą zostać wprowadzone w trakcie koniecznych modyfikacji.

Sprawdzenie czy aplikacja działa nie oznacza oczywiście przeprowadzenie przed testami bezpieczeństwa testów funkcjonalnych. Chodzi tu o zweryfikowanie czy dana funkcja była już testowana i czy jest "przyjęta". Jeśli tak - można ją testować. Co w przypadku, gdy dana funkcja jest niegotowa? Można wykonać szybki rekonesans po to, by wychwycić "grube" błędy. Trzeba jednak pamiętać, że do tego fragmentu aplikacji trzeba będzie wrócić, gdy będzie gotowy.

I jeszcze jedno. Do listy sposobów jak wkurzyć pentestera dodałbym trzy, dość istotne punkty:

Niech aplikacja działa niestabilnie. Wykonanie dwa razy tej samej operacji pod rząd daje różne rezultaty. I niech pojawiają się losowo błędy 500. Nie zapomnij o nieregularnych i absolutnie niezapowiedzianych aktualizacjach aplikacji, oczywiście bez żadnego logu zmian.
Niech aplikacja działa wolno. Przecież to tylko dwie minuty czekania na odpowiedź serwera. I nie, nie da się tego poprawić, bo akurat teraz są wykonywane również testy wydajnościowe.
Połącz dwa powyższe punkty w jedno. Niech pentester poczeka sobie dwie minuty na odpowiedź serwera tylko po to, by dowiedzieć się, że wystąpił błąd. Tym razem. Bo przy drugiej próbie niech wszystko działa poprawnie. I nie zapomnij umilić czasu oczekiwania jakąś hipnotyzującą animacją!

Zbyt długi czas, w którym aplikacja zgłoszona do testów "nie działa" (lub działa tak, jakby nie mogła) jest o tyle niebezpieczny, że tego straconego czasu zwykle nie można odzyskać. Można z dużym prawdopodobieństwem zakładać, że priorytetem będzie utrzymanie wcześniej podanego terminu produkcyjnego udostępnienia systemu. Jeśli z przewidzianych 20 dni roboczych zniknie nagle 5 (lub więcej), zaczyna brakować czasu. I nie, nie uda się go odzyskać "pracując dłużej", bo testerzy to też (tylko) ludzie i mają swoje granice wytrzymałości. A testy bezpieczeństwa to (często) monotonna, metodyczna praca wymagająca skupienia.

Sprawdzenie podstawowych rzeczy

Jeśli aplikacja działa, w drugiej kolejności warto poszukać błędów w architekturze (przykład: Znajdź błąd projektowy: wykorzystanie AJAX (część I)) oraz typowych błędów w implementacji.

Ten etap niestety wciąż zajmuje za dużo czasu. I, również niestety, często jest bardzo owocny. Co zrobić, gdy okaże się, że aplikacja została zaprojektowana błędnie a błąd jest tak poważny, że w zasadzie należy aplikację napisać od nowa? Co zrobić, gdy okaże się, że typowe błędy w implementacji popełniane są nagminnie i potrzebna jest bardzo duża ilość poprawek? Przypominam, że czas przeznaczony na testy został skrócony do minimum i nie został przewidziany czas na poprawki...

Współczuję kierownikom projektów, którzy znajdują się w sytuacji opisanej wyżej. Jakie możliwości działania mają? Obawiam się, że nie mają wielkiego pola manewru... Osobiście uważam, że prawdopodobieństwo wystąpienia takich sytuacji trzeba minimalizować poprzez zmianę cyklu procesu tworzenia oprogramowania (jeśli oprogramowanie wytwarzane jest "własnymi siłami") lub wymaganie odpowiedniego procesu tworzenia oprogramowania u dostawców.

I coś więcej niż podstawy...

Trzecim aspektem, któremu obecnie niestety nie poświęca się wystarczająco dużo uwagi jest poszukiwanie błędów w logice biznesowej aplikacji oraz to, o czym pisał ostatnio Przemek, czyli testy wynikające ze scenariuszy ataków.

Niestety, z tym czymś więcej pojawia się pewien problem. A nawet kilka problemów. Warto zadać sobie pytanie, czy i w jakim zakresie można przystąpić do badania tego czegoś więcej, jeśli aplikacja nie została zbadana (dokładnie) pod kątem podstawowych problemów. Albo inaczej - czy można pominąć testy podstawowe i przejść bezpośrednio do badania logiki biznesowej oraz sprawdzenia możliwości określonych (wcześniej, na przykład tak: Don't Forget EVIL User Stories) celów intruza? Jak zwykle odpowiedź będzie zależała od konkretnego przypadku. Testowania pewnych rzeczy mam już dość, ale obawiam się, że do czasu, gdy te podstawowe rzeczy będą uwzględniane w procesie tworzenia aplikacji, wciąż to coś więcej będzie odkładane na później, bo te podstawowe rzeczy zajmują zbyt wiele zasobów. Tak jak w piramidzie potrzeb...

No dobrze, nie jest aż tak źle. W rzeczywistości w trakcie testów przychodzi również czas na to coś więcej, ale prawdą jest to, że kwestie związane z podstawowymi zagadnieniami zajmują zbyt dużo czasu. Nie można przejść dalej, bo wciąż ilość podstawowych błędów jest duża. Jest lepiej niż kiedyś, ale ciągle w procesie tworzenia aplikacji czegoś brak.

Święta są ZŁE!

2009-11-10T06:38:33-08:00

Nie lubię świąt. Radosne święto przypadające 1 listopada mamy już za sobą, skończyły się sprzedawać świeczki, więc pora na... Tak! Choinki, mikołaje, głupie czerwone czapki z pomponem, zestawy bombek szklanych (jedyne 24,95 PLN za 16 sztuk!) i inne świąteczne barachło.

Co mnie tak naszła świąteczna, radosna atmosfera? Raz na jakiś czas trzeba wybrać papierowy spam ze skrzynki. Jak myślicie, co w nim znalazłem? Skoro ja muszę cierpieć, to cierpcie razem ze mną :P

Pierwsza gazetka reklamowa (sklepu pierwszego), na pierwszej stronie mogę przeczytać, że zbliżają się święta.... Przypominam. Jest 10 listopada. Przyznam się, że musiałem sięgnąć do kalendarza (by się upewnić). Tak, rzeczone święta występują w dniach 25 i 26 grudnia wraz z 24 grudnia w roli "dnia przed". No ale przecież to już tak blisko! Na okładce mogę obejrzeć mikołaja, bombkę, skarpety przy kominku (zaiste bardzo polska tradycja), choinkę, prezenty, szczęśliwą metroseksualną rodzinkę pod choinką w głupich czerwonych czapkach, prezenty pod choinką i coś w rodzaju "wigilijnego" stołu. Zawartości środka opisywać mi się nawet nie chce.

Druga gazetka (sklepu drugiego), ponownie bombki, choinki, stroiki, świeczki, światełka, (...). I przy okazji informacje o dostępnych opcjach kredytowania, bo przecież wszystkie te produkty są absolutnie niezbędne do życia i szczęścia, a jak wygląda zawartość portfela dość sporej części społeczeństwa, chyba wiadomo. Ale w sam raz zakupy świąteczne się spłaci do marca/kwietnia tak by na kolejne święta można się było znów radośnie zadłużyć.

Kolejna gazetka (ponownie sklepu drugiego) wywiera na mnie presję, abym się gotował do świat. A wała!

Autorom tych i wszystkich przyszłych "świątecznotematycznych" gazetek mam do powiedzenia tylko tyle: oddalcie się ode mnie w podskokach, tanecznym krokiem na lekko ugiętych nogach. Szybko. Zanim się zrobię agresywny.

Ups. Za późno.

Zwykle swoje destrukcyjne zapędy wykorzystuję w trakcie testów aplikacji, tym razem zrobiłem wyjątek :)

Mój kubeczek to ile filiżanek?

2009-11-09T22:56:19-08:00

Herbata jest dobra na wszystko:

(...) Optymalna dzienna dawka kofeiny dla osoby dorosłej to 400 miligramów, czyli tyle, ile znajduje się w 8 filiżankach herbaty lub 4 kubkach kawy. (...)

No dobrze, to na dzień dobry przyjmuję 320 miligramów kofeiny (patrz: Green IT). W jednej filiżance herbaty znajduje się 50 miligramów (a tak przynajmniej wychodzi mi z prostego dzielenia). Czyli mogę wypić jeszcze 1,5 filiżanki herbaty. Super. Tylko ile filiżanek zawiera mój kubeczek?

Bootcamp XVII: hint I

2009-11-09T22:34:57-08:00

Moje drugie wyzwanie doczekało się pierwszej prawidłowej odpowiedzi. Tak naprawdę, to odpowiedź pojawiła się już 8 listopada, ale Sławek przesłał ją bezpośrednio do mnie, by nie psuć innym zabawy. Przygotował nawet skrypt, który w rozwiązaniu zadania pomaga, a który udostępnię za jakiś czas.

A teraz obiecany hint: tym razem przykład demonstruje w praktyce CWE-642: External Control of Critical State Data.

Bootcamp XVII: wyzwanie II

2009-11-07T11:09:30-08:00

Pod adresem http://bootcamp.threats.pl/lesson17/ znajduje się kolejny przygotowany przeze mnie w ramach bootcamp przykład. Tym razem jest to pewnego rodzaju wyzwanie.

Jest to prosty przykład aplikacji, która pozwala na logowanie użytkowników i, w zależności od uprawnień użytkownika (guest/user/admin), udostępnia użytkownikowi różne funkcje (formatki).

Przedmiotem wyzwania jest:

podglądnięcie danych innego użytkownika (formatka
Dane użytkownika),
eskalacja uprawnień,

Dodatkowo znaleźć można:

XSS,
brak kontroli dostępu do funkcji (tu - formatek),

Dane użytkownika z uprawnieniami gościa:

login: guest,
hasło: CicKiCinMirkakew,

Przyznam się, że nie do końca testowałem ten przykład, ale powinien działać i powinien robić to, co założyłem :)

Powodzenia!

Nie ma to jak sprawdzone chińskie wzorce

2009-11-06T07:19:00-08:00

Nic tak nie cieszy jak dobre informacje z rana: Koniec internetowej wolności w Polsce. Nie chodzi mi o ten konkretny przypadek, obejście ewentualnych ograniczeń nie będzie zbyt trudne, ale o trend, kierunek, w którym zmierza nasz "wolny świat".

Ludzie ciągle wierzą w bzdurne stwierdzenie "im więcej wolności, tym mniej bezpieczeństwa". Pojawiają się coraz to nowe pomysły "drobnych" ograniczeń wolności (lub/i prywatności), bo tak "będzie bezpieczniej". Co gorsza znajdują one poparcie w "społeczeństwie", bo temu "społeczeństwu" (przynajmniej znacznej jego części) jest tak wygodniej, wolą gdy ktoś myśli i podejmuje decyzje za nich.

Proponuję przeczytać artykuł Przeciw Prohibicji (Newsweek 45/2009), którego autorem jest Marcin Król, a z którego pozwolę sobie zacytować jedno zdanie:

Zapewne obywateli, którzy lubią rządy silnej ręki, zawsze będzie więcej niż radykalnych zwolenników wolności, gdyż zawsze więcej jest ludzi tchórzliwych niż odważnych.

Wyjątkowo trafne stwierdzenie.

Jak można przegapić DOM based XSS

2009-11-05T12:09:22-08:00

Jakiś czas temu na blogu Security Ninja pojawił się wpis Can you find the vulnerabilities?, teraz dostępne są rozwiązania zadań: Can you find the vulnerabilites? Part Two. Zadania są stosunkowo proste, ale jeśli ktoś jeszcze tego nie robił, proponuję spróbować się chwilę nad nimi zastanowić. Ja natomiast chciałem zwrócić uwagę na jeden konkretny przykład.

Fragment kodu, o którym mowa to:

var pos=document.URL.indexOf(”name=”)+5;
document.write(document.URL.substring(pos,document.URL.length));

Istnieje duża szansa, że w "tradycyjnych" testach z wykorzystaniem local proxy (np. Fiddler) podatność ta nie zostałaby wykryta. Przypominam, że testy takie polegają na modyfikowaniu parametrów przekazywanych do aplikacji i obserwowaniu tego, co aplikacja zwraca.

Dlaczego przypadek ten mógłby zostać pominięty? Dlatego, że aplikacja dla dowolnie różnych wartości parametru name może zwracać dokładnie taką samą treść. Skrypt natomiast pobierze wartość parametru z... no właśnie, skąd?

W przypadku wykorzystania local proxy żądanie wysyłane do serwera jest przechwytywane przez wykorzystane narzędzie, modyfikowane, a następnie wysyłane do serwera. Serwer widzi zmodyfikowane żądanie, przeglądarka generująca żądanie natomiast nic nie wie o wprowadzonych modyfikacjach. W tym przypadku parametr name jest przekazywany w GET, czyli jest częścią adresu URL. Skrypt osadzony na zwracanej stronie odwołuje się (w uproszczeniu) do przeglądarki, odczytuje adres URL i pobiera z niego oryginalną wartość parametru name. Nawet jeśli za pomocą proxy wartość parametru name zmieniliśmy, przykładowo, z Albercik na <script>alert(/XSS/);</script> to ten skrypt z przykładu nic o tym nie wie, wykorzysta oryginalną wartość parametru i wypisze jak gdyby nigdy nic Albercik.

Przykład ten pokazuje, że czasami warto popatrzeć również w kod skryptów działających po stronie klienta. Nie zawsze jest to łatwe, czasami ilość kodu JavaScript dołączanego do strony (aplikacji) jest naprawdę duża, czyli może nie wystarczyć czasu, a w dodatku kod jest "kompresowany", przez co kompletnie nieczytelny (w takich przypadkach korzystam zwykle z Malzilli, Fiddler ma z kolei plugin JavaScript Formatter, ale z niego nie korzystam)...

Tu jedno pytanie/temat do dyskusji - mając do dyspozycji ograniczony czas na czym (i dlaczego właśnie na tym) skupilibyście się? Na części "serwerowej" aplikacji, czy może na skryptach działających po stronie klienta, w przeglądarce?

Jankomuzykantyzm

2009-11-04T09:46:00-08:00

Był sobie uzdolniony muzycznie, ale chorowity chłopiec. Bardzo chciał sobie pograć na skrzypkach, a te znajdowały się w dworze. Zakrada się więc chłopak i... łapią go, posądzają o kradzież (...). Wiadomo jak to wszystko się skończyło. Później na lekcjach, przynajmniej za dawnych czasów, były rozważania co zrobiliby "państwo", gdyby wrócili wcześniej, jak to zaopiekowali się Jankiem i jaki wspaniały byłby z niego skrzypek.

Wczoraj zakończyła się sprawa o odszkodowanie dla rodziców zastrzelonego przez Policję motocyklisty. Miał chłopak pecha, znalazł się w nieodpowiednim czasie w nieodpowiednim miejscu, ale przede wszystkim usiłował uciec przed Policją i nie zatrzymał się do kontroli. Sąd uznał, że odszkodowanie się nie należy.

Kilka dni temu hakerzy (haker vs. cracker) włamali się na stronę UW, uczelnia sprawę zgłosiła prokuraturze. Podobnie jak w przypadku innych tego typu spraw, tak i tym razem rozległy się głosy typu: Wsadzajmy do więzienia ludzi za to że pokazują błędy w systemach komputerowych. Brak słów... albo (...), Uniwersytet zamiast składać doniesienie do prokuratury, powinien być wdzięczny hakerom, że pokazali jego władzom wadliwość zabezpieczeń.

I w tym właśnie momencie wkracza jankomuzykantyzm. Bo przecież to tacy zdolni młodzi(?) ludzie, a tu zły świat się na nich tak uwziął... Zamiast wdzięczności, kłody pod nogi... Główne argumenty "obrońców" są zwykle mniej więcej takie:

włamują się tylko po to, by pokazać, że można,
robią to w celach edukacyjnych,
nikomu nie dzieje się krzywda,

Warto zastanowić się, czy rzeczywiście nikomu nie dzieje się krzywda. Utrata wizerunku, utrata zaufania (potencjalnych) klientów, koszty poniesione na odtworzenie działania aplikacji. Zdecydowanie nie jest to "nic", więc twierdzenie, że "nikomu nie dzieje się krzywda" jest oderwane od rzeczywistości. Wcale się nie dziwię, że "uszczęśliwieni" niechcianą usługą wcale nie są nią zachwyceni i decydują się na złożenie wniosku o ściganie przestępstwa, do czego mają pełne prawo. Z dostępnych informacji dotyczących zdarzenia wynika, że przestępstwo prawdopodobnie zostało popełnione, ale decyzja w tej sprawie należy do prokuratury i sądu. Można również dyskutować, czy można ominąć zabezpieczenia, których nie ma, ale to zupełnie inna kwestia.

Pokazanie, że aplikacja jest podatna wcale nie musi zawierać w sobie umieszczania "charakterystycznych wpisów" oraz informowania mediów o całej sprawie. Podejrzewam, że uczelnia zareagowałaby inaczej, gdyby została o problemie poinformowana w nieco bardziej cywilizowany sposób. Pewności w tym względzie mieć jednak nie można, więc we własnym interesie lepiej trochę uważać, bo konsekwencje takiej "edukacji" mogą być dość nieprzyjemne. Może nie w tak gwałtowny sposób jak, przykładowo, domowe zabawy "edukacyjne" z niewybuchami, ale jednak uciążliwe.

"Edukować się" można na wiele sposobów, poczynając od wykorzystania aplikacji typu OWASP WebGoat, różnych hackme (tu wspomnę o moim przewodniku po podstawach bezpieczeństwa aplikacji internetowych), a na testowaniu dostępnych aplikacji (co za problem zainstalować sobie WordPress, Drupal, Xyz, FooShmu, ... albo skorzystać z moth) kończąc.

W kodeksie karnym istnieją (między innymi) dwa artykuły: 267 i 268, o których warto pamiętać. W obu przypadkach ściganie przestępstwa następuje w wyniku wniosku pokrzywdzonego. Trzeba po prostu przyjąć do wiadomości, że "pokazywanie wadliwości zabezpieczeń" bez wiedzy i zgody zainteresowanego (właściciela) może skończyć się ograniczeniem wolności do lat dwóch/trzech/(...), w zależności od tego, pod jakie paragrafy zostanie to ostatecznie podciągnięte. Do tego można jeszcze dodać ewentualne problemy z zatrudnieniem tam, gdzie wymagane jest zaświadczenie o niekaralności, przynajmniej do czasu zatarcia skazania. Trzeba znać potencjalne konsekwencje swoich czynów. Nie ważne czy jest to ucieczka przed Policją (pechowo w czasie obławy), czy "tylko" edukacyjne włamanie na serwer, które, zgodnie z obowiązującym prawem, jest przestępstwem.

A jeśli ktoś dysponuje zbyt dużą ilością wolnego czasu i bardzo chce pokazać, że można, to proszę bardzo, ma okazję: Live Labs Web Sandbox.

Na zakończenie spojrzenie z nieco innej strony - nie można zakładać, że jakiekolwiek przepisy powstrzymają "prawdziwych" włamywaczy, w związku z czym aplikacje i systemy powinny być bezpieczne. Przynajmniej tak bezpieczne, by potencjalni intruzi znaleźli sobie inne, łatwiejsze obiekty ataku.

Konkurs 2.0

2009-11-03T22:24:18-08:00

Z okazji pierwszego w tym roku Confidence odbył się konkurs CONFidence Security Evangelist. Wygląda na to, że z okazji kolejnej edycji Confidence jest również kolejna edycja konkursu.

Bootcamp XVI: jeszcze jedno zadanie

2009-11-02T22:27:54-08:00

Tak sobie pomyślałem, że (prawie) rozwiązany wczoraj przykład można wykorzystać jeszcze do jednego zadania: korzystając z istniejącego w przykładzie XSS osadzić skrypt z innej strony. Przydatny może być XSS Cheat Sheet.

Bootcamp XVI: rozwiązanie

2009-11-02T11:06:00-08:00

Radekk jest pierwszą osobą, która rozwiązała najnowsze zadanie na bootcamp. Przy okazji dołączył do bardzo nielicznego grona osób, które poradziły sobie z wyzwaniem (swoją drogą zapraszam, dostępnych jest kilka wskazówek). Tym razem również nie podam dokładnego opisu rozwiązania, zarówno XSS (w ramach inspiracji: JS Ninja) jak i SQLi (jeśli ktoś potrzebuje pomocy: Lekcja 7: (blind) SQL injection) nie są wyjątkowo interesujące. W przykładzie tym ważne jest coś innego...

Podałem trzy podpowiedzi do zadania:

skąd serwer "wie", jak nazywa się przekazywany plik,
"co z tego, że tak nie można nazwać pliku?",
trust boundary,

Na pierwsze pytanie łatwo odpowiedzieć patrząc na wysyłane przez przeglądarkę żądanie:

Nazwa (czasami również cała ścieżka) przekazywanego pliku zawarta jest w atrybucie filename, który ustawiany jest przez przeglądarkę na podstawie nazwy (ścieżki) wskazanego pliku. Praktycznie każdy system plików narzuca pewne ograniczenia odnośnie nazwy pliku, a i system operacyjny nie jest tu bez znaczenia. Ogólnie rzecz biorąc nazwa pliku nie może być dowolna.

Dwie kolejne podpowiedzi łączą się w zasadzie w jeden scenariusz: wartość atrybutu filename w żądaniu wysyłanym przez przeglądarkę może zostać dowolnie zmodyfikowana przez atakującego. Nowej nazwy pliku prawie nie dotyczą żadne z ograniczeń, które "wymusza" system operacyjny czy system plików. Innymi słowy jeśli ktoś oczekuje, że nazwa pliku nie będzie zawierała znaków typu < czy > tylko dlatego, że nie można utworzyć pliku o takiej nazwie, to jest w błędzie.

Przy okazji warto zauważyć, że w analogiczny sposób w jaki można zmienić "nazwę pliku", można zmienić również jego "typ". Typ (w sensie typu MIME) pliku przekazywany jest w atrybucie Content-Type i, podobnie jak filename, może zostać dowolnie zmodyfikowany przez atakującego. A co z tego wynika, łatwo można się domyślić.

Na zakończenie przypomnę jeszcze raz o wpisie File upload security recommendations. Warto zapoznać się z tymi zaleceniami i je stosować.

Dziwny zbieg okoliczności

2009-11-02T03:09:51-08:00

Dziś można przeczytać, że Polak w pracy - wynosi sprzęt, kradnie towar, oszukuje... I w sumie nie dziwi mnie to, ale zastanawiam się jaki związek ma opublikowanie wspominanego raportu przez firmę Euler Hermes z lekko irytującymi reklamami ubezpieczenia ryzyka sprzeniewierzenia oferowanego przez wspomnianą firmę. Budzi się we mnie "drobna niewiara" w wyniki badania, jeśli firma będąca jego autorem jest równocześnie żywotnie zainteresowana sprzedażą swoich produktów, których to sprzedaż będzie tym wyższa, im bardziej mroczne wizje będą kreślone...