Przemyslaw Skowron BLOG

Zacieranie śladów

2011-08-17T21:37:00.000+02:00

Temat wpisu celowo ma sprawić, że z większą ciekawością ktoś zajrzy do tego krótkiego wpisu.

Do rzeczy. Mniej więcej od roku 2004 mniej lub bardziej etatowo jestem trenerem. Miałem okazję prowadzenia różnych szkoleń z zakresu szeroko pojętego bezpieczeństwa informacji. Może powinienem napisać, że z pentestów, DDoSów, obchodzenia DEP'a czy innych fajnych słów kluczowych dla wyszukiwarek, ale nie ;)

Co mnie ciekawi?
Część firm organizujących szkolenia z "testów bezpieczeństwa" kieruje swoje usługi do szeroko pojętych pracowników działów IT. Pytanie brzmi, po co tam taki rozdział jak "Zacieranie śladów"? - jedyny przychodzący mi do głowy powód to pokazać jak ktoś może po sobie zacierać ślady i co po sobie pozostawi by go złapać. Z drugiej strony czy to jest potrzebne na tym szkoleniu?

Jak często w ramach usługi "testu bezpieczeństwa" ktoś zamówił "zacieranie śladów" po sobie? Do czego innego się to przyda?

Co z tym można zrobić?
Szczerze pisząc jeśli otrzymuję materiały szkoleniowe po innym trenerze i mam na to wpływ to staram się omówić taki punkt z zamawiającym/organizującym szkolenie, a jeśli nie znajdziemy uzasadnienia dla życia takiego rozdziału szkolenia usuwamy go lub zamieniamy na inny.

Inne pytanie: Czy developer piszący kod, którego zadaniem jest tworzenie możliwie bezpiecznych aplikacji musi znać bardzo wysublimowane sposoby wykorzystywania podatności czy przede wszystkim znać ogólne zasady ataków, a świetnie poruszać się w mechanizmach obronnych, które zaimplementuje/wykorzysta?

Moim zdaniem to drugie, które od pewnego[1] czasu wprowadzam na szkoleniach, które prowadzę[2] i to się sprawdza.

[1] - sorry, tajemnica zawodowa.
[2] - j/w, jeśli już prowadzę to głównie szkolenia zamknięte, których nie mogę/muszę promować.

Komentarz do panelu David vs. Goliat

2011-06-07T00:42:00.003+02:00

Od ponad roku staram się inaczej podchodzić do otaczającej mnie rzeczywistości. Jednak jak rymuje Eldo: "Czasem nie wolno odpuścić i stanąć z boku. Bo w życiu są sprawy dużo ważniejsze niż spokój."

Do dzieła.

Ostatni CONFidence 2011 (edycja w Krakowie) był pierwszym od ładnych kilku lat, który musiałem odpuścić - jak to mawiają "służba nie drużba". "Konferencja", a raczej wydarzenie, które kreuje Andrzej bardzo przypomina już imprezy z za zachodniej granicy (CCC Conference) niż klasyczne dwa dni prelekcji i networking przy lunchu - mnie się to podoba, tak dalej!

Z nowych propozycji pojawił się panel dyskusyjny: "David vs Goliat – jak zgłosić podatność i nie zrobić sobie przy tym krzywdy.", do którego zaproszenia przyjąć nie mogłem z uwagi na brak możliwości pojawienia się na miejscu. Na szczęście zasięgnąłem opinii na jego temat wśród znajomych a także jeden z moderatorów - Mirek Maj, opublikował podsumowanie, do którego chciałem się odnieść. Jest to blog prywatny więc uprzedzę, że poniższy komentarz to tylko i wyłącznie moje prywatne zdanie w tym temacie.

AD "WNIOSEK PIERWSZY – ZGŁASZANIE SŁABOŚCI TO TAKŻE POLSKI PROBLEM"

Nie wiem jaki kontekst miało stwierdzenie: "To, że nie mamy wielkich fabryk software-owych nie znaczy, że nie ma co zgłaszać.." - chodziło o potencjalne zgłaszanie podatności do PSIRT[1]'ów? Natomiast z mojego doświadczenia i obserwacji wynika, że rzadko zgłaszane są błędy w konkretnych produktach (pominę przypadki zgłaszania podatności polegającej na tym, że serwis przetrzymuje hasła w postaci nieszyfrowanej, bez odpowiedniego salta, itp.). Powinienem napisać "nagłaśniane", a nie zgłaszane, ale o tym później. Najczęściej błędy zgłaszane do firm lub szeroko pojętych mediów są w konkretnych przypadkach instalacji/konfiguracji danego rozwiązania. Najczęściej są to aplikacje webowe gdyż żyjemy w dobie Web (2.0) lub w starych wersjach usług (problem, że tutaj trudniej o spektakularne screenshoty), ewentualnie pracujących z uprawnieniami użytkownika o wysokich uprawnieniach w systemie operacyjnym.

Nie znam prawdziwego powodu dlaczego nie pojawił się nikt z sektora finansowego, mogę jedynie przypuszczać dlaczego tak się stało. Uważam, że w utrzymaniu dialogu pomiędzy potencjalnymi, już Klientami banków a sektorem finansowym powinna pośredniczyć jakaś organizacja. W naszym kraju taką rolę może mogłoby objąć Forum Abuse, które zrzesza zespoły CERT/CSIRT największych dostarczycieli treści, operatorów telekomunikacyjnych, także banków i co najważniejsze innych, strategicznych dla bezpieczeństwa kraju jednostek. Jeśli nie Forum Abuse to może Związek Banków Polskich? - to ZBP odpowiada za wizerunek, komunikację ze społeczeństwem w imieniu zrzeszonych banków. Dialogu bezpośredniego na dzień dzisiejszy sobie nie wyobrażam. Jeśli ktoś chce coś zgłosić to każdy bank ma ogólny formularz kontaktowy na swojej stronie. Uważam, że tutaj szybko nic się nie zmieni, bo nie ma takiego trendu.

Słowo odnośnie "nagłaśniania" podatności. O podatnościach zgłoszonych w ramach "gentlemen’s agreement" zazwyczaj się nigdzie nie słyszy, nie można o nich przeczytać. Myślę, że jest to jeden ze sposobów utrzymania potencjalnie zdrowych relacji między zgłaszającym, a adresatem. Zwróćmy uwagę na to co pojawi się w kolejnych punktach, najczęściej podatności odnajdywane są podczas niezamówionej usługi badania podatności lub już daleko idącego pentestu. Uważam, że znacznie łatwiej rozjuszyć adresata podatności w sytuacji gdy opublikujemy informację o niej publicznie równo z mailem na przypadkowy adres hakunamatata@company.com by poinformować o nieszczęściu, które zaraz ich spotka (dzisiątki, setki, ... prób wykorzystania opublikowanej podatności, poszukiwanie podobnych gdzieś "obok"). Temat rzeka.

AD "WNIOSEK DRUGI – BRAK REGUŁ POSTĘPOWANIA"

Jeśli chcę zgłosić podatność polegającą na tym, że po wprowadzeniu w parametrze X wartości: 2 and (select 1 where length(database()>8)) dowiemy się czy nazwa aktualnie używanej bazy danych ma więcej niż 8 znaków to muszę mieć świadomość co robię i co zrobiłem. Jeśli nie działamy zgodnie z prawem (czyt. nie posiadamy odpowiedniej umowy na usługę, adresat nie ma jasnych reguł postępowania w takich przypadkach) to nie próbujmy naginać czyichś zasad i liczyć, że będą dla nas korzystne. To ingerencja w czyjeś podwórko, a my wchodzimy tam bez zaproszenia. Nie każdy ma czas, ochotę, pieniądze i potrzebę regulowania sposobu postępowania przy zgłoszeniach podatności, a już na pewno będzie z tym trudno jeśli mamy się tymi zasadami podzielić publicznie. To, że niektórzy tak robią nie stanowi to od razu reguły. Bolesny przykład firmy Sony, nie mieli nawet CISO. Kto miał się tym zająć? - np. zarządzaniem podatnościami. Kto z "nagłaśniających" podatności by chciał by do jego drzwi mieszkania lub samochodu wg. ogólnie przyjętych zasad lub stworzonych przez niego, próbowano się włamać? - nawet nie żeby coś ukraść, ale żeby spróbować zajrzeć do środka. Chcemy oglądać porysowane drzwi, zniszczone zamki? Za każdym razem będziecie pobłażliwi dla "napastnika"?

Jestem za prowadzeniem badań/wykrywaniem podatności, natomiast zdrowy rozsądek podpowiada by odpowiednio dobierać miejsce, w których je prowadzimy - NIE na obcych instalacjach.

AD "WNIOSEK TRZECI – GRATYFIKACJE SĄ POTRZEBNE, TYLKO TRZEBA USTALIĆ CO TO JEST"

O ile rozumiem gratyfikacje za podatności w rozwiązaniach, to w konkretnych, wdrożonych produktach już mniej. Na swoim labie nie ma ryzyka przełamania bezpieczeństwa firmy, utraty poufności/integralności informacji, zachwiania dostępnością. Wystawianie środowisk testowych to śliska sprawa: można popełnić błąd w konfiguracji takiego środowiska i przypadkiem zbudować interfejs do produkcyjnych systemów. Przykładów jest cała masa, doświadczeni administratorzy doskonale wiedzą co mam na myśli. To są koszty, czas, który będzie trudno uzasadnić w kosztach IT, a zarazem stanowić spore ryzyko reputacyjne. W moim odczuciu temat środowisk testowych jest i będzie mało popularny.

Podsumowując: moim zdaniem na przestrzeni ostatnich lat sporo się zmienia w temacie sposobów zgłaszania podatności, nie wiem czy na lepsze, na pewno dobrze, że zaczęliśmy o tym rozmawiać w szerszym gronie. Nie miejmy pretensji do adresatów podatności o to, że się denerwują, czas nie gra na ich korzyść. Nie stawiajmy z definicji każdego zgłaszającego w najgorszym świetle, może to młodsza siostra zostawiła przypadkiem uruchomiony skaner podatności... i wystrzelił w najmniej oczekiwanym momencie. Zachowujmy zdrowy rozsądek, a na pewno wszyscy będą docelowo zadowoleni z efektów współpracy.

A co Ty o tym myślisz?

[1] - Product Security Incident Response Team

Co dalej?

2010-03-23T21:43:00.000+01:00

Guzik mniej lub bardziej świadomie prowokuje mnie do wznowienia prowadzenia bloga. Ponieważ blog prowadzony jest przede wszystkim dla mnie, nie czułem potrzeby pisać o tym, że na czas nieokreślony zawieszam pisanie. Dlaczego?
- bo prowadzenie OWASP Poland zabiera mi dużo czasu, w mojej opinii dobrze przygotowane spotkania są dużo bardziej wartościowe niż moje wpisy
- bo jestem całkowicie pochłonięty nowym projektem w pracy, resztki energii wolę wykorzystać inaczej niż przy komputerze
- bo zmieniłem front i nie chcę udawadniać, że bezpieczeństwo jest ważne, jeżeli dla Ciebie jest to wiesz gdzie mnie szukać
- bo ... przyszła wiosna :)

Jeżeli nadal jest ktoś zainteresowana/zainteresowany moim punktem widzenia w temacie bezpieczeństwa aplikacji to polecam spotkania OWASP Poland oraz listę dyskusyjną, na której zapisanych jest wielu specjalistów w tej dziedzinie.

PS
W kwietniu pojawię się na konferencji SEConference.

Psychoza w bezpieczeństwie

2009-12-26T23:21:00.000+01:00

Kończy się przerwa świąteczna, a ja natchniony kilkoma wypowiedziami na forum GoldenLine chciałbym coś z siebie wyrzucić. Dodatkowo mój serdeczny kolega zauważył, że stał się bohaterem jednego z wpisów - (Najtrudniejsze) Podstawy bezpieczeństwa aplikacji.... Zastanawiam się jak bardzo unikalni w naszym kraju są programiści, których ciekawią problemy związane z bezpieczeństwem aplikacji, które tworzą. Przyznam szczerze, że znam ich dosłownie kilku, a pozostali... no cóż, bezpieczeństwo dla nich to: przymus, kara, opóźnienia, niechciane marzenia, niepotrzebne gadżety, killerzy biznesu - nadal często z takimi określeniami spotykam się od ładnych paru lat, głównie na początku współpracy. Są też wyjątki "nawróconych" :-)

Prawda jest taka, że jeżeli wymagam od programisty by aplikacja była wolna od znanych błędów/podatności, a w żaden sposób mu w tym nie pomagam to nie przesadzę napisząc, że to jak wymaganie od początkującego kierowcy bez uprawnień na prowadzenie pojazdów, by jeździł bezpiecznie. Niby już wie gdzie gaz, hamulec, sprzęgło, skrzynia biegów, po osiedlu jeździ, ale co z ze skomplikowanymi skrzyżowaniami kiedy w dodatku światła zostały wyłączone? Staje prawie na środku, inni trąbią, wyzywają, pomagają by stres zrobił swoje - pomagają popełnić błąd. Wcześniej nie przerabiał takiego scenariusza. Nie oczekujmy, że ten przyszły kierowca na pewno zachowa się w tej sytuacji dobrze.

Wiecie już co mam na myśli? :)

Zadałem takie pytanie na forum, ale może ktoś trafi na mojego bloga: Czy widziałaś/widziałeś oferty pracy dla programistów, gdzie jednym z wymagań była choćby podstawowa znajomość zagadnienień związanych z bezpieczeństwem? - technologii z jaką miałaby taka osoba pracować albo chociaż ogólnie: bezpieczeństwa aplikacji.

Pomijam oferty z firmy Google, oni prawdopodobnie potwierdzają regułę.

Krótkie zastanowienie i może trochę przedwczesne wnioski, "Nie ma takich ofert pracy bo":
1) nie ma takich programistów - moim zdaniem są, chociaż nie ma ich zbyt wielu, dlaczego? kto zna szkolenia w Polsce, na których programista może poznać zagrożenia związane z atakami na aplikacje i nauczyć się jak z nimi walczyć?
2) pracodawcy nie myślą o tym, nie czują problemu - bo przecież taki programista ma inne zadania, bezpieczeństwo to "ficzer"
3) bezpieczeństwo to temat dla kogoś z bezpieczeństwa, jak znajdą jakieś błędy to programista usunie je - kiedyś na takie teksty otwierał mi się scyzoryk w kieszeni, teraz potrafię spokojnie przedstawić ten temat w taki sposób by dał do myślenia
4) w Javie pisze się tylko bezpieczne aplikacje - za krótko obracam się w środowisku programistów języku Java by to dobrze wytłumaczyć dlaczego jest takie myślenie, ale przykro mi, że muszę to zrobić: aplikacje w Javie nie są bezpieczne "by default". Nie są, przykro mi.
5) nie ma dostatecznie dobrego dialogu pomiędzy samym IT, a osobami z bezpieczeństwa. Za krótko żyję na tym świecie by mieć kilkanaście i więcej lat doświadczenia na styku IT <-> Bezpieczeństwo -> wymierną próbkę, ale dlaczego tak mało rozmawiamy? Jeśli już to bardzo oficjalnie i głównie o nakazach/zakazach. Tuż przed świętami sporo rozmawiałem ze znajomym, który szukał podstaw uzasadniających kilka punktów w umowie dla pracownika IT. Jak dla mnie były to punkty ze świata absurdu co też mu powiedziałem. Zacznijmy od pracy u podstaw!
6) i w konsekwencji z 5) - nie ma programu/pomysłu w firmie zapewniającego bezpieczeństwo aplikacji. J/w. Praca u podstaw. Tomasz Kopacz z firmy Microsoft, na którego prezentacji podczas CONFidence 2009 2.0 miałem okazję być, powiedział, że wprowadzenie Secure SDLC w takiej firmie jak gigant z Redmond było i jest bardzo kosztowne. Musiało wyniknąć z samej góry (Bill Gates) i tylko z jej błogosławieństwem miało/ma szansę powodzenia. MS to bardzo duża firma i może nie być najlepszym przykładem w naszych warunkach, ale chciałbym powiedzieć, że da się to zrobić bez bardzo dużych kosztów. Ba, one się nawet zwrócą. Przynajmniej do czasu zanim nie trafi się na firmę, która będzie chciała na tym duuuużo zarobić.

Całkiem możliwe, że znajdzie się sporo osób o odmiennym zdaniu, jeżeli tak to bardzo serdecznie zapraszam do komentowania tego wpisu - w ten sposób mam nadzieję uda się zrobić coś dobrego dla nas wszystkich, którzy korzystają później z takich aplikacji.

Podsumowując, nie chcę i nie obarczam programistów winą za błędy bezpieczeństwa w aplikacji. Uważam, że w większości przypadków nie ma odpowiedniej organizacji ich pracy co skutkuje często mniejszymi/większymi katastofami. Nie zwalniam z odpowiedzialności za tą sytuację osoby zajmujące się bezpieczeństwem, chociaż i oni czasami nie są przygotowani do tematu bezpieczeństwa aplikacji. Natomiast od kogoś musi to wyjść.

PS
Tak się stało, że od grudnia 2009 jestem nowym liderem OWASP Poland Local Chapter. Kilka miesięcy temu, aktualny wtedy lider - Andrzej Targosz, poinformował mnie, że nie będzie miał czasu na aktywne prowadzenie Chapteru i czy nie jestem zainteresowany przejęciem go. Ku mojej uciesze, drugi ze współzałożycieli OWASP Poland - Robert Pająk, wskazał mnie jako osobę, do której mógłby trafić oddział. Chociaż początkowo odmówiłem to po kilku miesiącach stwierdziłem, że warto spróbować. Serdecznie zapraszam na spotkania OWASP Poland! Tam dowiecie się tego jak nie być koniem i jak tworzyć bezpieczne aplikacje webowe!

Threat Modeling in The End

2009-11-01T19:03:00.000+01:00

Odrabiając zaległości RSS'owe przeczytałem ciekawy wpis firmy Matasano - Ninja Threat Modeling. Szkoda czasu na dłuższe streszczenie tego wpisu, obrazuje on podejście do modelowania zagrożeń w sytuacji kiedy aplikacja już istnieje. Czy kogoś to jeszcze dziwi? Powtórzę, "kiedy aplikacja już istnieje".

Żyjemy w części planety, w której jeszcze moim skromnym zdaniem bardzo słabo rozwinięty jest cykl powstawania i rozwoju aplikacji, szczególnie jeśli chodzi o aspekt bezpieczeństwa - mam na myśli głównie kraj, w którym żyję, czyli Polskę. Jednym z elementów takiego cyklu życia aplikacji jest modelowanie zagrożeń. W pierwotnym zamyśle powinno ono być przeprowadzane jak najwcześniej, zanim programiści zaczną implementować założenia aplikacji.

Niestety często bardzo ciężko o to z kilku powodów:

- niska świadomość osób pracujących przy tworzeniu i rozwoju aplikacji (nie czują potrzeby przeprowadzenia modelowania, nie widzą wartości dodanej - w tym przygotowanie stosownej dokumentacji, która właściwie im samym jest _potrzebna_ stanowi problem, jeszcze nikt nigdy im o tym nie wspomniał)

- opór związany z naciskami po stronie biznesu by system/aplikacja była gotowa na zadany termin - mam w tym temacie różne doświadczenia, widziałem sytuacje kiedy stosowny zespół nie chciał współpracować przy modelowaniu, bo był "zajęty", bo oni nie wiedzą jak to działa, realizują to co chce "biznes" (zaraz, zaraz... ale chyba bez scenariuszów testów akceptacyjnych nie można iść do testowania danego procesu?)

- brak stosownych zapisów w umowie zlecający-wykonawca... i kilka innych.

Aby jakość testów penetracyjnych była możliwie wysoka, ale też adekwatna do ustaleń pomiędzy zlecającym pentest, a wykonującym, moim skromnym zdaniem powinno być przeprowadzone modelowanie zagrożeń na koniec, szczególnie jeżeli nie zostało przeprowadzone wcześniej. Przykładowe podejście do tematu można znaleźć w podanym na samym początku poście firmy Matasano. Jeżeli kogoś zniechęciły problemy na jakie można się natknąć przy modelowaniu zagrożeń na początku projektu aplikacji to mam nienajlepsze wiadomości ;) Jeżeli nie udało się przeprowadzić modelowania na początku to tym bardziej jest duże prawdopodobieństwo, że na koniec będzie z tym kłopot. Mimo tych przeciwności, nazwę to roboczo "losu", WARTO przeprowadzać takie modelowanie na koniec - przed testami bezpieczeństwa.

Dlaczego tytułowy "Threat Modeling in The End" jest warty świeczki?

Bo mam obawę, że bez niego testy penetracyjne to klasyczne, próby przełamania aplikacji w rozumieniu całej rodziny wstrzyknięć (słowo klucze to m.in.: XSS, SQL Injection), testy kontroli dostępu na "chybił trafił" (czyt. bez wiedzy o rolach w aplikacji) czy wytknięcie używania SSL'a w wersji 2. Bez odpowiedniego przygotowania do testów bezpieczeństwa w części przypadków, szczególnie kiedy pentester nie ma doświadczenia z obranym w aplikacji modelem biznesowym, trudno jest mi sobie wyobrazić dobrze opracowane scenariusze testów. Częściowo zahaczyłem o temat we wpisie: Testowanie logiki biznesowej. Moim zdaniem pentest bez uwzględnienia innych aspektów systemu niż tylko (nie)użyte mechanizmy bezpieczeństwa dla przykładowo, podatności wymienionych w OWASP Top 10, jest niepełny[1].

PS
Na blipie zauważyłem zainteresowanie tematem modelowania :-) Dla dobra Nas wszystkich.

[1] - wyjątkiem będą testy, które mają sprawdzić aplikację właśnie _tylko_ pod tym kątem.

Bezpieczeństwo w bankowości internetowej

2009-10-20T22:46:00.000+02:00

O tak dobrze brzmiącym tytule pojawił się dzisiaj artykuł na stronie prnews. Abstrahując od samej treści raportu o bezpieczeństwie w bankowości internetowej, który na pierwszy rzut mojego śpiącego oka wygląda nawet rzetelnie przypomniałem sobie o swoich ambitnych pomysłach wykonania podobnego porównania bezpieczeństwa, ale trochę w innych warstwach.

Z jednej strony wręcz standardem jest potwierdzanie większości transakcji jednorazowym kodem (bez względu jak został on wygenerowany, dostarczony i jak jest powiązany z parametrami transakcji), ale moim zdaniem w dzisiejszych czasach ważna jest sama informacja, że ktoś posiada takie, a nie inne saldo, lokaty, akcje. Spłaca kochanki czy wydaje dużo pieniędzy na drogie hotele w centrum dużego miasta. Bez instalowania trojanów, przejmowania (fragmentów) (jednorazowych) haseł dla części e-bankowości można łatwo pozyskać takie informacje w lekko sprzyjających warunkach.

Czy bankowość, z której korzystasz ustawia dla najważniejszych ciasteczek atrybut Secure? Jeżeli nie to pomyśl: z jakiej sieci łączysz się do bankowości? czy to 34-zakładka w Twojej przeglądarce? czy możesz ufać środowisku w jakim pracujesz? czy na pewno po zakończeniu pracy udało się poprawnie wylogować zanim otworzysz dowolny link z Internetu/Intranetu?

To tylko jeden prosty przykład do badań :) Nie wspomnę o braku autocomplete=off dla pola login w formularzu logowania...

A żeby wzniecić zainteresowanie i sprowokować do głebszych przemyśleń to może ktoś zna banki, które aktywnie walczą/walczyły z trojanami próbując np. losować nazwy parametrów, które są przesyłane podczas zlecania np. przelewu - w ten sposób wypadając z szablonów nazw zmiennych, które dany trojan podmienia?

White Hat Hacker Man - song

2009-10-13T23:43:00.000+02:00

Planowałem dzisiaj dłuższy wpis, ale zmęczenie po trasie Warszawa-dom jest zbyt duże. Dla relaksu polecam najnowszy hit jaki wpadł w moje sidła... ;)

White Hat Hacker Man - videoclip + tekst.
Sam videoclip na youtube - link.

Miłego!

Nomenklatura: Zarządzanie ryzykiem

2009-10-09T22:28:00.002+02:00

Zakładając, że Michał Wiczyński na swoim blogu ma racje to wygląda na to, że zmienia się optyka ludzi zainteresowanych bezpieczeństwem lub trafił na taką próbkę populacji, która miała potrzebę usystematyzowania nomenklatury związanej z zarządzaniem ryzykiem. Co ciekawe wyszukiwarka Google'a skierowała kilka osób na mój blog z hasłem: "roznica miedzy podatnoscia a zagrozeniem". Odpowiadając na pytanie wheelq'a napiszę co moim zdaniem oznaczają następujące słowa na przykładzie XSS'a.

Podatność - np. brak walidacji danych wejściowych, brak encodingu danych wyjściowych
Zagrożenie - np. przejęcie tożsamości użytkownika aplikacji
Skutek - np. zapoznanie się z historią transakcji użytkownika, któremu skradziono ciastko sesyjne
Ryzyko - prawdopodobieństwo, że ktoś stworzy zagrożenie wykorzystując podatność o mniej lub bardziej dokładnie określonych skutkach

Jak można zauważyć zarządzanie ryzykiem operując na takich parametrach może być dość trudne. Na pomoc przychodzą inne metody wyliczania ryzyka. Ich spis można zobaczyć na wiki OWASP - Threat Risk Modeling. Żeby nie duplikować dobrego wpisu Pawła Golenia polecam jego analizę metodyki DREAD - DREAD by wampir.

Testowanie logiki biznesowej

2009-10-08T20:57:00.000+02:00

Jednych bardziej cieszą XSSy, innych SQLi, a jeszcze kogoś innego błędy w logice biznesowej, które najtrudniej wykryć przez systemy bezpieczeństwa jak Web Application Firewall, IDS/IPS czy analizę logów serwerów www. Od jakiegoś czasu właśnie one zyskują w moich oczach najwięcej. Może dlatego, że każda aplikacja to co najmniej lekko zmieniona logika, a najczęściej zdecydowanie inna. To niestandardowe wyzwanie, które sprawia, że pentest nie jest taki nudny.

Dlaczego wspominam o tego rodzaju testach? Bo nadal często spotykam ludzi, którzy dziwią się po co pentesterowi założenia biznesowe jaki ma realizować aplikacja. Czy one naprawdę są potrzebne aby wykonać dobry pentest? Może nie są potrzebne, ale mogą dużo pomóc. Szczególnie jeśli testowana jest aplikacja o słabo zrozumiałej logice działania.

Dla zainteresowanych tematem: Na niedawno zakończonej konferencji FRHACK 2009 miała miejsce nawet ciekawa prezentacja: Identification & Exploitation of Business Logic Flaws in Web Applications, do której udostępniono już slajdy. Może komuś się to przyda.

BTW: Czy ktoś próbował lub musiał na podstawie logów z serwerów WWW, ruchu do/z aplikacji webowej sprawdzić czy nie doszło do udanej próby wykorzystania nieznanej luki, może w logice biznesowej aplikacji? Od takie przykładowe zadanie na CTF w kategorii Forensic. :-)

Hardening aplikacji webowych

2009-10-07T22:43:00.001+02:00

Aplikacje systemowe można kompilować kompilatorem, który dołoży kanarka, zlinkować z biblioteką, która podmieni funkcje z definicji niebezpieczne na ich bezpieczniejsze odpowiedniki, kernel ma lepiej albo gorzej zaimplementowaną ochronę stosu. Po co to wszystko? Poza marnowaniem kolejnych cykli procesora ;) chodzi o minimalizację ryzyka skutecznego wykorzystania podatności, które nas otaczają.

Co można zrobić dla poprawienia bezpieczeństwa aplikacji webowych bez względu na podatności związane z błędną walidacją danych wejściowych czy iluzorycznym bezpieczeństwie korzystania z szyfrowanych kanałów transmisji? Jak pokazuje świat przeglądarek, można zrobić całkiem dużo. Pytanie tylko co? Jaki da to efekt? Ile to będzie kosztowało? I czy ktoś z tego (s)korzysta?

Atrybuty cookie
Poza takimi jak site, path, expire mamy jeszcze dwa: secure oraz httponly. Secure przyda się w sytuacji kiedy przez cały czas pracujemy z aplikacją webową z wykorzystaniem szyfrowanej transmisji (https) i chcemy obronić się przed atakami typy surfjacking. HttpOnly spróbuje uniemożliwić XSS'om (Javascriptowi) ukraść ciastka.

X-FRAME-OPTIONS
O którym już kiedyś[1] pisałem[2]. Niestety chyba nie zdobył on (nagłówek) popularności[3].

Frame breaker
Nikt nie lubi być w czyjejś ramce. W stosunku do rozwiązania X-FRAME-OPTIONS wspierany jest przez większą rzeszę przeglądarek. Niestety napisanie kawałka kodu w JS, który tak samo zachowa się w każdej przeglądarce aktualnie nie jest takie proste i oczywiste.

Content Security Policy
Stary temat w nowej wersji - narazie w wersji beta. (zapowiada się całkiem ciekawie :-))

Aby powyższe zabezpieczenia zadziałały potrzebna jest odrobina dobrej woli po stronie programisty i/lub administratora. To wszystko dlatego, że wprowadzenie odpowiednich atrybutów dla ciastek czy dodanie nagłówków HTTP można wykonać przez modyfikację kodu aplikacji lub zmiany w konfiguracji serwerów www/load-balancerów.

Jak często rekomendujecie wybrane z powyższych zabezpieczeń?
Jak często się z nimi spotykacie podczas testów bezpieczeństwa?

Testy DoS - potrzebne?

2009-10-06T23:09:00.000+02:00

Zanim dojdę do głównego tematu kilka nowinek:
- na blogu pojawiła się dodatkowa adnotacja odnośnie charakteru mojego bloga - w moim profilu
- jestem świeżo po kolejnej (dla mnie już trzeciej) edycji warsztatów z testów penetracyjnych aplikacji webowych, wkrótce zapraszam na kolejną!
- nadal gdy do znajomych mówię "do zobaczenia na CONFidence" część z nich smutno pyta dlaczego zobaczymy się dopiero w przyszłym roku, przypominam, że najbliższa edycja CONFidence już w listopadzie 2009 :-)

Wracając do tematu... atak typu Denial of Service dla aplikacji webowych to ciut inne zagadnienie od tych występujących w pozostałych warstwach szeroko pojętych usług. W pierwszym rzucie można przyglądnąć się stosownej kategorii na wiki OWASPa - Denial of Service Attack , która naświetla problem na konkretnych przykładach. Pozostaje jednak pytanie jak często pentesterzy sprawdzają czy można przeprowadzić skuteczny atak DoS i czy są o to proszeni? Spotkałem się z różnymi opiniami - niestety większość osób, z którymi poruszałem ten temat sądziła, że DoS zawsze się uda, kwestia przyłożonej siły. W związku z powyższym dość rzadko przeprowadza się takie testy.

Moim zdaniem testy DoS warto przeprowadzać zawsze, ale nie za wszelką cene. Co to oznacza? Że nie ma potrzeby zawsze wykupować botnetu żeby sprawdzić ile dana infrastruktura wytrzyma SYNów/sec czy równoległych slowlorisów tylko zobaczyć jak zachowuje się aplikacja i środowisko, w której pracuje przy podstawowych testach, o których mówi choćby OWASP Testing Guide. Dobrze jest przeprowadzić testy DoS z jednej maszyny/jednego adresu IP aby sprawdzić jak bardzo odporni jesteśmy na jednego napastnika. Wstyd jeśli się okaże, że jeden wystarczy by osiągnąć niedostępność usługi dla pozostałych, prawda? :-)

Poza testami wymienionymi w OWASP Testing Guide proponuję testy wydajnościowe aplikacji. Mogą one pomóc w określeniu miejsc, w których aplikacji odwołuje się do bazy danych i wykonuje na niej kosztowne z punktu widzenia czasu operacje. Szczególnie niebezpieczne będą to miejsca jeśli dostęp do nich jest przed zalogowaniem się do aplikacji - napastnik pozostaje wtedy bardziej anonimowy i nie musi w ogóle posiadać konta. Zwróciłbym jeszcze szczególną uwagę na cache'owanie. Jeżeli wydaje się nam, że zapewniliśmy odpowiedni poziom cache'owania obiektów np. na reverse-proxy i aplikacja nie będzie zawsze odpytywała bazy danych to trzeba się zastanowić czy zmieniając/dodając dodatkowe, unikalne parametry w zapytaniu HTTP odpowiedź będzie nadal z cache'a czy za każdym razem generowana na nowo. Jeszcze innym przykładem, który czasami jest ignorowany to posiadanie ciasteczek. Automat próbujący wykonać DoS aplikacji nie będzie przejmował się ciasteczkami ustawianymi przez nagłówek Set-Cookie, a nawet może próbować go wykorzystać jako wektor ataku. W końcu identyfikatory sesji też są w jakiejś bazie :-)

A jakie doświadczenia z testami typu DoS mają inni?

Low-level hacking

2009-09-26T19:34:00.002+02:00

Jakiś czas temu niefortunnie przypiąłem sobie plakietkę - "Przemek od OWASPa". Stało się to pewnie za pomocą udziału w grancie i aktywności na spotkaniach OWASP Poland Local Chapter. Zapewne ten i poprzedni blog, który w dużej części zawiera wpisy dotyczące bezpieczeństwa aplikacji webowych nie pomaga mi pokazać tego co naprawdę lubię i od zawsze szanuję. Nawet praca dyplomowa była o WAF'ach..., a przez 3 lata pracowałem dla jednego z największych portali w Polsce - pozdrowienia dla całej ekipy z tych lat! :) Ja rozumiem, że jest taki trend. XSS'y to dzisiaj współczesny shellcode, który kiedyś był pisany w staranności co do bajta. Właśnie o tych bajtach, rejestrach i językach niskiego poziomu zapomnieć nie mogę.

Dzisiaj Adam podesłał mi URL'a do swojego bloga i materiałów z konferencji, na których był prelegentem - tu i tu. Część prezentacji znałem, bo widzieliśmy się na tym imprezach (choćby ostatnio na FIŚ'ie), ale dały mi one do myślenia. Czy większość swojego czasu poświęcam zagadnieniom, które dają mi prawdziwą radość i satysfakcję? Przecież na początku mojej kariery zawodowej (umowa o pracę - pełny etat) prowadziłem podobną prezentację. Pamiętny rok 2004, pawilon konferencyjno-wystawowy "Kotłownia" i temat "Bezpieczne programowanie - zagrożenia i ochrona". W prezentacji na dość wysokiem poziomie abstrakcji podszedłem do opisywach podatności przez co wydaje mi się, że nie straciła bardzo na czasie. Wiadomo, trochę inaczej organizowany jest kod przez kompilatory, struktury danych wyglądają nieco odmiennie choćby z uwagi na architekturę, wykorzystuje się teraz podatności, które wtedy były uznawane za odporne na kontrolę przez piszącego exploita, ale nadal spotykam wiele osób, które o format string czy signal race nie słyszeli... w ogóle.

Co będzie ze mną dalej? \x90\x90 ;) Będzie dobrze.

Tips&Tricks: Standard bezpiecznych aplikacji

2009-09-22T23:45:00.004+02:00

Od jakiegoś czasu zastanawiam się jak napisać dobry standard bezpieczeństwa dla programistów aplikacji webowych. Z tego powodu zapytałem na blipie o dobre praktyki przy tworzeniu takiego dokumentu. Niestety nikt nie odpisał, ale z racji kończącego się dzisiaj SecDay'a wierzę, że np. w komentarzach do tego posta ktoś podzieli się ze mną swoim doświadczeniem i pomysłami.

Dlaczego w ogóle chcę napisać dobry standard?

Po pierwsze... chcę napisać dobry, bo napisałem już kilka (każda wersja mam nadzieję lepsza od poprzedniej), ale nadal nie jestem zadowolony z tego jak to wygląda. Po drugie... OWASP Top 10 jako spis najczęściej wykorzystywanych podatności, OWASP Development Guide jako przewodnik tworzenia bezpiecznych aplikacji webowych moim zdaniem nie do końca nadają się na zestaw rekomendacji i wymagań dla programisty, który powinien wiedzieć jak napisać bezpieczną aplikację webową. Dlaczego tak uważam? OWASP Top 10 to co najmniej 10 kategorii podatności, którymi m.in. powinni zajmować się ludzie od bezpieczeństwa aplikacji. Moim zdaniem to nie spis podatności powinien być bazą dla standardu, a ogólne i szczegółowe propozycje zastosowania środków/rozwiązań, dzięki którym podatności nie występują albo są trudne do wykorzystania. Niestety podobnie ma się sytuacja z projektem OWASP Development Guide. Ostatnia aktualizacja dokumentu miała miejsce w roku 2005. Od tego czasu w świecie bezpieczeństwa aplikacji webowych sporo się zmieniło, a niestety nikt nie zadbał o świeżość dokumentu. Może jestem zbyt wybredny, ale moim zdaniem przewodnik nie proponuje rozwiązań w sposób pozwalający łatwo zaadoptować je w dowolnej aplikacji. Każdy programista jest inny, inna jest szkoła wg. której uczył się programować, ale nadal mam nadzieję, że moja propozycja podejścia do tworzenia standardu może być dla niego przyjazna i w rezultacie efektywna. Ważne jest zrozumienie różnicy pomiędzy dwoma rodzajami zapisów w standardzie - rekomendacje (nice to have!) i wymagania (must be!). Nie zawsze chodzi o 100% zgodność ze standardem, bo obejmuje on znacznie szerszy zakres zagadnień niż aplikacja potrzebuje lub pewne rozwiązania mogące mieć znamiona podatności zostały zaakceptowane w procesie analizy ryzka. O tym więcej trochę później - modelowanie zagrożeń.

Dlaczego mam szansę napisać dobry standard?

Albo przewrotnie dlaczego takich szans nie mam ;-) Ogólnie mówi się, że tylko programista powinien szkolić programistów z pisania bezpieczniejszych (bo bezpiecznych w 100% nie ma ;>) aplikacji. Żaden ze mnie etatowy programista, a jedynie okazjonalny koder. Ba, nie lubię pisać aplikacji webowych. Wychowałem się na języku C, ASM (8-... bitowym) i shellu w latach (1999-...) kiedy proste CGI w C/Perlu i HTML z SSI był czymś 'jami' w dzisiejszych czasach. Wygląda na to, że powinienem trzymać się daleko od programistów, a jednak życie i sam zdecydowałem inaczej. Jestem bardzo otwarty na programistów, od lat rozmawiam z nimi chociaż zajmują się różnymi rodzajami aplikacji. Od programistów sterowników, kawałków kernela systemów operacyjnych, przez aplikacje systemowe, usługi, aplikacje webowe, aż po GUI. Rozmawiam, czasami próbuję napisać fragment aplikacji by zrozumieć na czym polega implementacja zabezpieczeń z ich perspektywy. Staram się uczyć przekładać zagrożenia z wykorzystaniem podatności na ogólne sposoby uniknięcia zaimplementowania ich przez programistę. Moim skromnym zdaniem kluczem do napisania dobrego standardu jest zrozumienie genezy powstawania podatności. W skrócie, pomogą dobre praktyki i wzorce projektowe. Jeżeli nikogo poza samym sobą nie przekonałem do tego, że mam szansę napisać niezły standard to śmiało można zamknąć to okno przeglądarki :-)

Co warto wziąć pod uwagę przy pisaniu standardu tworzenia bezpiecznych aplikacji?

Poza ogólnymi 'best practices' nie można zapominać, że aplikacja pracująca w danej warstwie (np. webowa w przeglądarce, po stronie serwera) rządzi się swoimi prawami. Przykładowo pisząc standard dla aplikacji systemowej pisanej w języku niskiego poziomu jak C będzie trzeba pamiętać o takich rzeczach jak zarządzanie pamięcią na stercie czy odpowiednią kontrolą otwieranych plików by nie doszło do sytuacji wyścigów, obcinania plików i innych konsekwencji podobnych podatności. W aplikacji webowej pisanej w J2EE czy PHP nie będziemy bezpośrednio przejmować się zarządzaniem stertą bo robi to za nas inna warstwa środowiska, w której pracujemy.

Następnym elementem pisania standardu jest pokora. Trudno napisać uniwersalny standard bo zaraz się okaże, że dany framework nie realizuje pewnych wymagań, inne realizuje w sposób odmienny od oczekiwanego, a przecież nagle zespół programistów nie będzie przepisywał połowy kodu bazowego większości aplikacji. W takich przypadkach proponuję nieco inne podejście - dopisanie fragmentu kodu, który będzie możliwie prosty do dołączenia i użycia w popularnym dla danego zespołu frameworku. Są też inne, ale ciekawa sprawa tuż, tuż. Właściwie dotykam tutaj moim zdaniem bardzo śliskiego tematu. Trudno jest oczekiwać od programistów z mniejszym albo większym doświadczeniem w pisaniu bezpiecznych aplikacji, że nagle zaimplementują dla swojej wygody klasy/metody, funkcje realizujące wymagania i rekomendacje ze standardu bezpieczeństwa. Fakt, faktem tak powinno być, powinien taki stały pakiet 'bezpieczeństwa' chodzić za każdą aplikacją i w ten sposób gwarantować możliwość szybkiego podniesienia poprzeczki dla napastników. Dla coraz większej ilości języków myślę tutaj o wykorzystaniu projektu OWASP ESAPI, który wkrótce zamierzam opisać bardziej szczegółowo. Póki nie ma stałego frameworka dla nowych aplikacji webowych będziemy mieli sporo pracy z programistami, a oni z nami :) zanim dojdziemy do satysfakcjonującego poziomu bezpieczeństwa by default.

Kontynuując podobnie ma się sprawa z różnymi językami. Standard powinien być ponad podziałami w tej kwestii, ale już przykłady, które można dodać w załącznikach warto gromadzić i pokazywać na potrzeby potomnych.

Podsumowanie.

Tematu rzecz jasna nie wyczerpałem. Mam nadzieję, że pokazałem kulisy powstawania standardów dla programistów i może komuś się to nawet przyda. Chętnie przyjmę wszelkie uwagi, szczególnie te krytyczne jak podejść do tematu by standard był praktykowany. Na koniec będąc natchniony przez kumpla (dzięki qba!) mam prośbę do ludzi, którzy 'zmuszają' programistów do pisania bezpieczniejszych aplikacji: Nie ubierajcie się mentalnie i na co dzień w takie ciuszki z wyrazem twarzy: "Nie mogę Ci pomóc, jestem koniem." :) Do następnej części: trening dla programistów w oparciu o standard i nie tylko...

PS
Liczę na szczere uwagi także od programistów ;)

(Najtrudniejsze) Podstawy bezpieczeństwa aplikacji

2009-09-20T20:23:00.004+02:00

W cyklu życia aplikacji NAJtrudniejsze są podstawy bezpieczeństwa. Chciałbym poruszyć dość poważny, często lekceważony problem w procesie powstawania i rozwoju aplikacji (SDLC). Zanim do tego dojdę to trochę o powodach dlaczego uznałem temat za warty wpisu na blogu.

Bardzo jest miło kiedy grupa zbiera się na tyle wcześnie, że mogę dobrze zaplanować mój kolejny tydzień, a jeszcze lepiej jeśli myślę o miesiącu. Tak też się stało ze zbliżającą się edycją warsztatów. Dziękuję za zaufanie i postaram się nie zawieść - następna jeszcze w tym roku.

Co takiego skłoniło mnie w temacie warsztatów do przemyśleń o SDLC? Otóż dość spore zainteresowanie nimi. Testy penetracyjne aplikacji webowych to niewątpliwie teraz temat numer jeden (przynajmniej w środowiskach, w których się obracam, a są one bardzo różne) wśród sposobów zapewnienia bezpieczeństwa aplikacji. Oczywiście pośrednio, bo same testy nie wpływają na poziom bezpieczeństwa, a jedynie go sondują. Niepodważalny jest fakt, że testy są potrzebne i nie namawiam do odchodzenia od nich.

Przez ostatnich kilka lat spotkałem się z bardzo skrajnym podejściem programistów do problemu bezpieczeństwa aplikacji. Pod pojęciem programisty rozumiem zarówno dewelopera, architekta aplikacji i sztabu ludzi, którzy są najbliżej cyklu życia aplkacji. Z jednej strony widzę programiste, który pyta w jaki sposób zaimplementować dany mechanizm bezpieczeństwa, czy narażony jest on na jakieś ataki, a z drugiej (bezczelnego), takiego który ustosunkuje się tylko do błędów wykazanych w raporcie z testu penetracyjnego, ale właściwie tylko tych ze statusem CRITICAL. Stosunek do bezpieczeństwa aplikacji obu podejść jest zdecydowanie inny. Kiedyś przeżyłem szok kiedy jeden z moich kolegów, który zawodowo tworzy aplikacje w języku klasy Enterprise zapytał mnie, czy jak poszedł do "bezpieczników" w firmie gdzie pracuje i zapytał ich o wytyczne, może jakieś źródła informacji o tym jak bezpiecznie wykonać implementację jednego z ważniejszych projektów to czy się wygłupił. Chwila konsternacji... i aby nie oceniać za szybko (jego i owych bezpieczników) mało elegancko zapytałem skąd ta obawa. Okazało się, że programista został zbyty informacją by teraz nie zawracał głowy. Bezpiecznicy zadeklarowali chęć zajęcia się tematem jak będzie trzeba przetestować aplikację przed "wystawieniem na Świat". Żeby nie wdawać się w szczegóły ;) ze swojej strony powiedziałem koledze, że szkoda, że nie pracujemy razem - bo taki programista to Skarb. Nie dość, że jest zainteresowany tematem bezpieczeństwa zanim zaczął pisać to jeszcze sam pofatygował się do tych, którzy powinni o tym wiedzieć najlepiej. Nie chcę rozmieniać się na drobne by ocenić postawę "bezpieczników", którzy tak podeszli do tematu... lepiej jak zostawię uśmieszek :-) Mam nadzieję, że na podstawie tych kilku postaw (bezczelnego programisty i nazwę to, leniwego bezpiecznika) przybliżyłem problem z jakim większość z nas się boryka.

W takim razie jak ogarnąć temat bezpieczeństwa aplikacji zanim dojdzie do testów penetracyjnych?

Pisali o tym wprost i między wierszami mądrzy ludzie, którzy zajmują się bezpieczeństwem aplikacji dłużej niż ja żyję - może trochę przesadziłem ;). Nie będę oryginaly i wymienię następujące tematy:
- standard bezpieczeństwa, którego powinni się trzymać programiści przy implementacji zarówno samej aplikacji jak i mechanizmów bezpieczeństwa, w które zostanie ona wyposażona,
- trening = szkolenia + warsztaty dla programistów, tematyka wzięto prosto ze standardu i na zachętę pokaz konsekwencji nie trzymania się standardu - pokaz w stylu 'case study' na błędach kolegów może wyostrzyć wyobraźnię i być pozytywnym bodźcem do zdrowej konkurencji pomiędzy programistami,
- modelowanie zagrożeń per aplikacja i najlepiej infrastruktura (im wcześniej [zanim powstanie pierwszy kB kodu] tym lepiej).

Dopiero gdzieś tutaj jest moment kiedy aplikacja jest tworzona (programista pisze kod). Standard oraz trening pozwala programistom przewidywać pewne zagrożenia i daje wskazówki jak minimalizować ryzyko ich występowania/wykorzystania. Modelowanie zagrożeń pozwoli programiście wspólnie z konsultantem ds. bezpieczeństwa (najlepiej aplikacji, a nie tylko firewalli...) zidentyfikować zagrożenia, ... i określić środki minimalizujące ryzyko wykorzystania ich. Jak aplikacja dojrzeje do testów bezpieczeństwa to właściwie zaczyna się temat..., ale jeszcze nie pentestów. Niespodzianka? Testy bezpieczeństwa i nie muszą, a nawet więcej, nie zawsze mają postać testów penetracyjnych. Mogą je zastąpić lub występować równolegle dość czasochłonne przeglądy kodu (code review).

To nie wszystko, a już ta krótka lista może być natchnieniem dla kilku blogów. O ile będę miał trochę (więcej) szczęścia - czasu, kolejne wpisy rozwiną tematykę podstaw bezpieczeństwa aplikacji, które przedstawiłem powyżej.

CONFidence 2009 - II

2009-09-06T20:15:00.003+02:00

16 maja tego roku napisałem o ostatniej konferencji CONFidence 2009 z przekonanie, że zobaczymy się za rok. Chociaż wiedziałem (tak, jestem w posiadaniu tajnych informacji ;>), że w listopadzie będzie kolejna impreza to jeszcze nie było wiadomo, że będzie to CONFidence 2009 - część II w Warszawie. Agenda jeszcze nieznana, ale to chyba nie przeszkadza by zarezerwować kilka dni w listopadzie, bo przecież nie dla samej agendy bywa się na CONFidence. Prawda?

Zapomniałbym! Planowana jest ścieżka w języku polskim. Od Andrzeja wiem, że brakuje na nią prelegentów. Zachęcam do zgłaszania się!

Po ostatniej konferencji/wpisie na blogu nic się nie działo. Nawet guzik to zauważył i wyraził swoje zdanie na ten temat. Chociaż od kilku lat (za) dużo pracuję (moja praca to w większości przypadków przedłużenie pasji) to od wiosny tego roku było tego dużo więcej niż kiedykolwiek wcześniej. Nadal tak jest i pewnie potrwa to jeszcze jakiś czas. Poza kilkoma projektami, o których nie mogę napisać z uwagi np. na podpisane NDA, miałem przyjemność spotkać się z ludźmi zajmującymi się informatyką śledczą - Forum Informatyki Śledczej. Chociaż nie jest to tak duży event jak kilka konferencji w kraju to warto się tam spotkać, bo nie zawsze agenda jest najważniejsza.

Mam jeszcze coś do opisania, ale po co zapeszać ;) Lepiej dać sobie szansę by podnieść statystyki wpisów w tym miesiącu.

OWASP EU: Poland / CONFidence 2009

2009-05-16T23:12:00.003+02:00

Już po. Czas na małe podsumowanie.

1) OWASP EU: Poland 2009

Prezentacje:
- Exploiting Web 2.0 – Next Generation Vulnerabilities - bardziej przypomnienie, że w Web 2.0 też można exploitować ;) chociaż jest to bardziej skomplikowane niż kiedyś... warto wspomnieć, że takie testy to nie _nowość_
- The Truth about Web Application Firewalls: What the vendors do not want you to know - niestety nie byłem, ale dema były pokazywane już na koniec "awesome!", świetna praca Sandro&Wendel! Wasze zdrowie!
- OWASP Enterprise Security API (ESAPI) Project - trwają prace nad ESAPI 2.0, nowe funkcjonalności... czas potraktować temat poważniej :)
- HTTP Parameter Pollution - NAJciekawsza prezentacja całej konferencji, IMHO oczywiście, czekam na pdf'a!

Eventy:
- CTF by Andres i Jarek wyglądał ciekawie... ale więcej zobaczyłem dopiero na CONFidence :-)

Uwagi:
- konferencja całkiem dobrze zorganizowana, widać, że tu zupełnie inny klimat niż CONFidence, brakowało nowych rzeczy dla kogoś ogólnie zaznajomionym z OWASPem...

2) CONFidence 2009

Prezentacje:
- A Pentester’s Guide to Credit Card Theft Techniques - jedna z prezentacji, na której musiałem być, poza wskazanymi słabościami PCI DSS najciekawsze było pytanie kogoś z sali: Czy PCI DSS wymaga by numer CVV był weryfikowany podczas operacji wykonywanej kartą kredytową? Okazało się, że autor pytania wpisuje dowolny ciąg cyfr i robi zakupy swoją kartą. Powalające...
- Oracle SQL Injection in Webapps - nie-sa-mo-wi-te :-)
- Introducing Heyoka: DNS Tunneling 2.0 - pamiętam jak wiele lat temu kolega potrzebował skorzystać z sieci, a że podczas urlopu nikt nie opłacił abonamentu został wycięty... został tylko DNS. Wystarczy.
- Lockpicking 101 - jak życia starczy to warto się tym zainteresować, choćby dla samego siebie
- VAASeline: VNC Attack Automation Suite - byłem tylko ciałem (coś tam grałem w CTF), muszę zobaczyć w prezentację
- Bakeca.it DDoS: How Evil Forces Have Been Defeated - ciekawa z prawdziwymi przypadkami, jedna z lepszych prezentacji w tym roku
- Java and JEE Vulnerabilities explained - spodziewałem się chyba czegoś innego, a może właściwie za dużo czytam... po prostu wcześniej to widziałem
- Corporate Security and Intelligence: the dark links - niesamowita opowieść Raula, kto nie był niech żałuje!

Eventy:
- duża ilość konkursów bardzo podniosła atrakcyjność imprezy, ŚWIETNY CTF (15 zadań! grałem tylko ~1,5h, ale zabawa przednia, wygrał zespół w skład którego wszedł: Mateusz ‘j00ru’ Jurczyk i Gynvael Coldwind), crackme ESETu (nie miałem okazji ani siły ;) zerknąć, wygrał Gynvael) i konkurs Try to break F5 Security, gdzie zabezpieczono serwis WWW konfiguracją F5 ASM i trzeba było poszukać luk, których WAF nie pokrył dostatecznie (wygrałem ja :P a w nagrodę wpadł mi w ręce Ipod Touch)
- była też impreza... a właściwie to trwały już od wtorku więc podaruję komentarz, było fajnie ;)

Uwagi:
- do zobaczenia za rok! :-)

Pozdrowienia:
- dla wszystkich... od 'Hi!', 'Hello!', 'Cześć!', 'Siema!', przez wspólne stoliki, kolejki przy barze, obiady, kolacje, rozmowy, gry na automacie, aż po tych, z którymi mieszkałem przez te kilka dni ;)
- dla ORGANIZATORÓW: wielkie dzięki za CONFidence 2009 i do zobaczenia w przyszłym roku!

Blip

2009-05-04T20:06:00.002+02:00

Stało się. Mam konto na Blipie. Krótkie notatki tam, dłuższe tutaj. Po prawej stronie bloga można zobaczyć ostatni blip-wpis ;)

Modelowanie zagrożeń na wesoło

2009-05-04T13:13:00.002+02:00

Jak w tytule. POLECAM KAŻDEMU.

PS
Sam już nie wiem czy potrzebuję bloga czy blip by wystarczył...

OWASP AppSec Europe 2009 - Poland

2009-05-04T00:41:00.002+02:00

Kolejny AppSec już tuż tuż. Tym razem będę ;-) Poniżej moja prawdopodobna agenda.

Dzień I:

- Mirage: building an application model made easy (OWASP Orizon v 1.2) - Paolo Perego, Spike Reply
- The Truth about Web Application Firewalls: What the vendors do not want you to know - Wendel Guglielmetti Henrique, Trustwave & Sandro Gauci, EnableSecurity
- Maturing Beyond Application Security Puberty - Roger Thornton, Fortify
- O2 - Advanced Source Code Analysis Toolkit - Dinis Cruz, Ounce Labs
- Advanced SQL injection exploitation to operating system full control - Bernardo Damele Assumpcao Guimaraes, lead developer of sqlmap
- Exploiting Web 2.0 – Next Generation Vulnerabilities - Shreeraj Shah, Blueinfy

Dzień II:

- OWASP Source Code Flaws Top 10 Project - Paolo Perego, Spike Reply / Flash Parameter Injection - Adi Sharabani, IBM
- OWASP Enterprise Security API (ESAPI) Project - Dave Wichers, Aspect Security
- The Bank in the Browser - Defending web infrastructures from banking malware - Giorgio Fedon, Minded Security
- HTTP Parameter Pollution - Luca Carettoni, Independent Researcher & Stefano Di Paola, MindedSecurity
- Real Time Defenses against Application Worms and Malicious Attackers, Michael Coates, Aspect Security
- Factoring malware and organized crime in to Web application security - Gunter Ollmann, Damballa
- The New Web-Based Man-in-the-Middle Attack - Adi Sharabani, IBM

Odnośnie jednej z prezentacji dnia pierwszego mam pewien plan ;-) ale dzisiaj jeszcze za wcześnie by o tym mówić.

Prawdziwe wsparcie dla WAF

2009-04-30T22:33:00.003+02:00

Sprzedawcy sprzedają, inżynierowi integratorów instalują, a potem? W USA jest firma WhiteHat Security, która współpracuje z F5 oraz SecureWorks współpracujący z Impervą. Nic mi nie wiadomo o takim czy podobnym wsparciu dla tych i innych WAFów w Polsce. W Europie podobno nie jest specjalnie lepiej. Niby jest Xiom, ale poza świetną pracą wykonaną przy mod_security i aktualnymi pracami przy WAFEC 2.0 nie kojarzę wsparcia dla produktów F5 czy Impervy.

Czy w Polsce nie mamy specjalistów od WAFów? Czy może ci co są pomagają tylko w firmach gdzie pracują? Kto właściwie korzysta z funkcjonalności WAF'a i w jakim zakresie? A może po prostu nie ma takich potrzeb?

Zapomniałem, że świadomość zagrożeń nadal jest kiepska... a programiści bezkrytyczni ;) Czasami ;>

Analiza podatności

2009-04-30T00:14:00.002+02:00

Krótko i na temat: tu oraz tu można znaleźć ciekawe i techniczne opisy podatności. Głównie w jądrach systemów operacyjnych, ale nie tylko. Respekt za ten exploit.

Can't sleep

2009-04-29T02:03:00.006+02:00

ZzZzZzZz...

PS
Jak już temat przepełnień, rzutowań to może to.

WAFW00F

2009-04-28T00:34:00.002+02:00

2 dni temu pojawiła się kolejna prezentacja rozwiązań typu WAF. Najciekawszy w niej jest sam WAFW00F - z niecierpliwością czekam na udostępnienie jego źródeł.

WAF jako SaaS

2009-04-26T00:58:00.002+02:00

Nie jestem znawcą rynku i wizjonerem przyszłość (tudzież teraźniejszości), ale można trochę poczytać w sieci, że przychodzi (przyszedł?) czas na rozwiązania bezpieczeństwa dostarczane jako usługi. SaaS na te potrzeby rozwinę jako "Security as a Service". Okazuje się, że pierwsze firmy w Europie będą oferowały WAFy w chmurach. Temat całkiem ciekawy, szczególnie kiedy widzę niepewność dużej części ludzi, z którymi rozmawiam o temacie Web Application Firewalli. Pewnie nie do zastosowania wszędzie... ;) ale na pewno w kilku ciekawych miejscach. Już wkrótce będę mógł napisać cokolwiek więcej.

Valgrind tu, Valgrind tam

2009-04-19T16:19:00.002+02:00

Valgrind to tylko podpucha dla tego wpisu. Fajnie brzmi i chociaż nigdy nie interesowałem się SEO to pozwoli mi poruszyć inny temat. Mój kolega daper od dłuższego czasu prowadzi bloga. Wpisy nie pojawiają się za często za to ich jakość oceniam bardzo wysoko - o ile taki "programista systemowy" jak ja może wypowiadać się o zawodowym programiście :) Polecam tego bloga każdemu komu się on przyda. Sam czytam go dla usystematyzowania wiedzy. Najnowszy wpis przypomniał mi o całkiem ciekawym projekcie zespołu ds. bezpieczeństwa w Google Inc. Projekt Flyer ma już dobre 1,5 roku, ale na stronie nie widzę żadnych zmian :( Czy ktoś coś wie o dalszych jego losach?

Konkurs: CONFidence Security Evangelist 2009

2009-04-17T23:58:00.002+02:00

Mhm... powiew wyobraźni. Przy okazji CONFidence 2009 odbywa się całkiem ciekawy konkurs. Zgłoś pretendentów i oddaj głos na swojego faworyta!

Zgłosiłem:
- Blog o bezpieczeństwie IT w języku polskim:

* http://bothunters.pl/ - za dobrą robotę, bez udziału Wielkich!

- Blog o bezpieczeństwie IT w języku angielskim

* http://chuvakin.blogspot.com/ - głównie za TAGi o PCI DSS, obsłudze incydentów, zarządzaniu logami i rozwiązania typu SIEM

Najbardziej zasłużony dla społeczności polski hacker

* Michał 'lcamtuf' Zalewski - za Browser Security Handbook i Ratproxy

PS
Konkurs w zamyśle ma wyłonić "naj" za ostatni rok, poprzedni CONFidence do teraz.

Rozwiązanie problemu 1000000x1000000

2009-04-13T16:38:00.002+02:00

Krótko i na temat: Algorytm Aho-Corasick zaimplementowany m.in. w fgrep'ie. Używany także w mod_security jako operator pm.

Performance vs. Security

2009-04-12T13:47:00.002+02:00

Wydajność kontra Bezpieczeństwo. Kto o tym myśli? Czy dzisiaj bezpiecznik decydując się na rekomendację danego rozwiązania bierze to pod uwagę?

Będąc administratorem, a później architektem w jednym z największych portali w Polsce (łezka się kręci, co my wyrabialiśmy w pracy i po...:-)) przy wyborze danego rozwiązania najważniejsze dla mnie były takie cechy jak:
- Wydajność -> Skalowalność
- Dostępność (w rozumieniu zapewnienia HA)
- Bezpieczeństwo (! - nigdy nie przestałem być bezpiecznikiem)
- inne jak łatwość w utrzymaniu, wsparcie zew./wew., elastyczność jeśli chciałbym coś zmienić, dostępność dokumentacji/kodu źródłowego (!), realne przełożenie na polepszenie się jakości usług w stosunku do wymaganej pracy przy wdrożeniu/utrzymaniu i rozwoju (!!!) oraz kilka innych

Dzisiaj (wczoraj też ;)) bezpiecznik musi patrzeć przez pryzmat właśnie takiego administratora.

Przypadek #1 i ostatni: ProPolice
Dodatek ProPolice, teraz natywny w nowych gcc, to pewien narzut na aplikację, która została skompilowana z odpowiednimi opcjami (-fstack-protector, -fstack-protector-all). Czy martwię się nim? Googlając po benchmarkach dostępnych w sieci nie specjalnie. Moja propozycja prawdopodobnie będzie trafiona i nie spowoduje problemów z wydajnością. Ba. Część dystrybucji przygotowuje paczki specjalnie z ProPolice i innymi flagami dla aplikacji w C (Ubuntu? Gentoo? RHEL? CentOS? ... ?). Świat od razu wydaje się być bezpieczniejszy. Mark Cox nie tak dawno temu napisał ciekawe podsumowanie o RHEL 4 i wpływie hardeningu by default na ryzyko wykorzystania podatności jakie zostały odkryte przez ostatnie 4 lata. Czy na pewno jest tak fajnie? Właściwie co zyskał bezpiecznik rekomendując i wymagając stosowanie ProPolice, a co administrator? Wezmę pod uwagę jeszcze developera.

Bezpiecznik: "Teraz exploity mi nie straszne!" - oj myli się ;-)
Administrator: "O ja &*$#)%(^%&, na tym starym systemie nie ma wsparcia dla ProPolice. Mam tu zrobić upgarde gcc? No way!", "Jasne, będę musiał Makefile przeglądać zanim coś skompiluję, &^*)($#^$ bezpiecznik!" - częściowo ma racje ;]
Developer: "ProPo..., że co? A po co mi to?" - Bezpiecznik mówiący developerowi, że przez to trudniej będzie wykorzystać jego błędy raczej nie zdobędzie jego symaptii ;-)

Pomijając zbędną złośliwość każdego z bohaterów widać, że wprowadzenie rekomendacji może implikować trochę dodatkowych prac i spowodować czasowy spadek wydajności... efektywności pracy wielu ludzi. Stanie się tak pod warunkiem, że rekomendacja będzie praktykowana.

Ktoś czytając ten wpis może pomyśleć, że trafiłem w swoim życia na "złych" ludzi. Leniwych adminów i programistów. To nie tak. Wiem, że nie każda rekomendacja spotka się z zachwytem, szampanem i imprezą do białego rana. Wiem, że administrator/programista (nie wrzucam Was do jednego worka!) skupiony jest na czymś innym niż bezpieczeństwo. Nie o to pyta go szef każdego ranka. Chcę pokazać, że rekomendacja stosowania dwóch opcji do gcc niesie za sobą konsekwencje, a znam przykłady, które wymagają nieporównywalnie większego nakładu pracy po stronie samego IT by rekomendacja weszła w życie. Mam wrażenie, że dlatego tak dużo kupuje się - kupują ci, których stać - pudełek z kolorowym GUI, które konfiguruje się w "kwadrans", a właściwie jego możliwości kończą się tip-top dalej niż zaczynają. Trochę generalizuję i nie nawołuję do bojkotu rozwiązań "z pudełka" - czasami są bardzo przydatne i wygodne, chciałbym jednak by IT lepiej rozumiało potrzeby Security i na odwrót.

Idealną sytuacją jest kiedy osoby reprezentujące IT i Security dzielą się uwagami, spostrzeżeniami i sugestiami odnośnie rekomendacji. Jeśli rozmowa jest konstruktywna i merytoryczna to jest szansa osiągnąć dobry wynik rozmów, satysfakcjonujący obie strony.

PS
Rekomendacja ProPolice jest słuszna w pewnych warunkach i ten wpis nie ma za zadanie odwrócić bezpieczeników od stosowania jej.

PS#2
Rekomendacje skonsultowane z IT będą lepiej przyjmowane, a co najważniejsze, skuteczniej wdrażane.

Edukacja przez CTF

2009-04-11T15:30:00.002+02:00

Od początku 2004 r. jestem zamieszany w szeroko pojętą edukację, skupioną głównie na problemach bezpieczeństwa IT. Od wysokiego poziomu abstrakcji kiedy mowa o ogólnych zasadach zapewnienia bezpieczeństwa aż do analizy działania exploita na kernel.

Podzielam zdanie "starej gwardii" - ludzi, którzy uważają, że aktualnie dostęp do materiałów (książki, Internet), szkoleń/warsztatów, prezentacji jest dużo lepszy niż kiedyś. Zanim zacząłem dzielić się wiedzą gdzieś musiałem ją zdobyć - nadal zdobywam. Teraz jest zdecydowanie lepiej, ale może być jeszcze bardziej.

Czytając tony newsów z Google Readera wpadłem na taki link. To nic nowego, ale przypomniały mi się czasy kiedy DJB prowadził podobny kurs. Pamiętam jak dziś, że bardzo chciałem uczestniczyć w podobnym - w końcu zaczynałem studia.

Tutaj pojawia się moje pytanie: Czy ktoś z czytających ten wpis kojarzy podobne kursy na uczelniach w Polsce? Chętnie zrobię listę takich miejsc. Proszę o dodanie odpowiedniego komentarza pod wpisem. Może zmotywuje mnie to do kontynuowania edukacji na uczelni.

Nawiązując do tematu wpisu, pewien doktor wygłosił wykład o CTF. W Polsce mamy 2-3 konkursy rocznie, gdzie można zmierzyć się z samym sobą. Z pamięci i z ostatniego roku najłatwiej wymienić mi Security Days, CTF i Wargame (czasami brany za CTF...) na CONFidence 2008. Nie będę rozpisywał się nad tym co opisane, przedstawię mój punkt widzenia. Uważam, że raz zorganizowany konkurs typu CTF/Wargame można wykorzystać w edukacji:
- analizując wyniki zmagań innych
- ucząc się sposobów zabezpieczenia, testowania zabezpieczeń i przełamywania ich, a na koniec lub nawet w trakcie sprawdzając swoje teoretyczno-praktyczne umiejętności w takim konkursie - w ramach zajęć

Tak wykorzystany konkurs może wzbudzić spore zainteresowanie, szczególnie jeśli będzie realizowany jako przedmiot fakultatywny, a nie obowiązkowy.

Jest jeszcze jedna zaleta takich zmagań. Czasami autorzy wystawiają obrazy systemów, które zostały użyte w konkursie. Stanowi to gotowy poligon do testów. Tak też zrobiliśmy rok temu z Filipem. Link do naszego obrazu można znaleźć na tej stronie - łącznie z rozwiązaniami zwycięzców.

PS
Na CONFidence 2009 przygotowywany jest nowy CTF. Na pewno pracują nad nim dwie osoby: mój kolega z Argentyny - Andres Riancho i niezmordowany Jarek Sajko. Możliwe, że ktoś jeszcze. Tego nie wiem, proszę się nie obrażać jeśli pominąłem (proszę napisać do mnie, uzupełnię listę).

PS2
Przy organizowaniu CTF też można sporo się nauczyć :-)

One simple exploit, please.

2009-04-10T20:21:00.005+02:00

Na początku warto sobie przypomnieć, że nie jestem etatowym exploit writerem. Nie jestem, nie byłem, a co przyniesie przyszłość jeszcze nie wiem ;-)

Od ~10 lat przyglądam się metodom wykorzystywania różnego rodzaju podatności. Atakom zdalnym/lokalnym, na poziomie kernela, biblioteki, aplikacji w userspace. Z elementami systemowego hardeningu. Masą IDS/IPSów, aplikacyjnych proxy, ... czy zwykłych firewalli. Właściwie to firewalli i uprawnień w systemie/aplikacji.

Wszystkie wymienione i pozostałe metody/poziomy utwardzania systemów/aplikacji w jakimś stopniu utrudniają wykorzystanie podatności. Czasami sam w sobie błąd jest tak zaszyty w aplikacji, że trzeba się dobrze zastanowić jak ją zmusić do wykonania podatnego fragmentu kodu. Pominę błędy typu "flaws", które powstały np. w wyniku źle przemyślanej architektury czy też złego określenia granic zaufania.

Erm. Wróć. A co jeśli sam firewall zawiera podatność? Lipa. Dodajmy do tego fakt, że nie potrzebujemy zalogować się na wspomniamy firewall by ją wykorzystać. Lipa^2. Można by powiedzieć, że jest jeszcze jakiś IPS po drodze ;-) - tylko jak często wystawia się taki system przed brzegowy FW? Lipa^2 (+1).

Co ja na to? Cisco! ;-)

Czy tak proste wywołanie błędu to nowość? Nie. Prostota wynika głównie z typu ataku - DoS.
Czy często można spotkać takie błędy? Nie potrafię odpowiedzieć obiektywnie. Na pewno są miłym przerywnikiem w testach aplikacji gdzie trzeba się zmierzyć z funkcją/filtrem czy też środowiskiem pracy aplikacji, które próbuje uniemożliwić skuteczny atak - mhrauu! ;-)

Problem: 1000000x1000000

2009-04-09T21:23:00.002+02:00

Teraz, gdy jestem już po studiach zaczynam za nimi tęsknić. Ciekawe dlaczego ;)
Do rzeczy. Spotkałem się z problemem Milion na Milion. Może zagadnienie nie jest tak ciekawe jak problem C10K, ale IMHO wymaga ruszenia głową. Na czym polega ten problem?

Na znalezieniu prostej i szybkiej metody, która odpowie na pytanie: Które wersy ze zbioru 1 000 000 wersów zawierają słowo ze słownika składającego się z 1 000 000 słów?

Zanim pokażę jedno z rozwiązań, którego złożoność i czas wyszukiwania satysfakcjonuje mnie, podpuszczę tych, którzy jednak tu zerkają. Proszę w komentarzach umieścić proponowane rozwiązanie problemu.

Na koniec (13.04.2009?) wyzwania umieszczę wyniki testu wykonanego na tym samym sprzęcie i tych samych plikach dla wszystkich propozycji z komentarzy.

Dla ujednolicenia warunków pracy zamieszczam je poniżej:
- system Linux (mogą być 32-bity)
- wszystko co dostępne po standardowej instalacji dystrybucji Ubuntu (8.10 lub nowszy), ewentualnie mogę coś doinstalować.

Żeby było wszystko jasne dodam jeszcze wymaganie odnośnie czasu rozwiązania problemu: Dla 1 000 000 linii logów i słownika złożonego z 1 000 000 słów odpowiedź powinienem otrzymać w czasie poniżej 1h. (najlepiej poniżej minuty ;))

Powodzenia!

suid_dumpable

2009-04-08T21:59:00.002+02:00


SUIDDUMP=`cat /proc/sys/fs/suid_dumpable`
if [ $SUIDDUMP -lt 1 ]; then
    echo -e "suid_dumpable=0 - system not vulnerable!\n";
else
    echo "Oops... You must read and try exploit it";
fi

PS
Fajny sploit. Zawsze chciałem zostać exploit writerem ;)

No More Free Bugs

2009-04-08T20:33:00.003+02:00

W pełni popieram inicjatywę No More Free Bugs. W związku z tym załączam poniższy obrazek.

Uwaga:
Wszystko powinno odbywać się zgodnie z prawem.

CCN, Luhn a WAF

2009-04-05T20:22:00.003+02:00

W przerwie pomiędzy przyjemnościami weekendu postanowiłem zerknąć w Google Readera. Natknąłem się na całkiem ciekawy post. Honeypoty to bardzo ciekawy temat i był pierwszym gdzie zauważyłem zastosowanie skryptu do wykrywania numerów kart kredytowych. Moje doświadczenie pokazuje, że zastosowanie miałby także na serwerach z dużą liczbą kont shellowych. Nie jedno z nich zostało/zostanie/jest przejęte przez osoby związane z phishingiem i stanowi kanał wymiany danych w ramach grupy dystrybucyjnej dla skradzionych numerów kart kredytowych. Taki skrypt to rzecz jasna nie panaceum na całe zło ;) Phisher może odwrócić sytuację i uruchomić skrypt na przejętym serwerze. A nóż widelec ktoś zapisze numer swojej/czyjejś (powstrzymam wodze fantazji - sami wymyślcie, nie chcę by ktoś się obraził ;)) karty, tak na chwilę, jako okienko do przeklejenia go gdzieś dalej. Wtedy nawet nie trzeba specjalnie namawiać kogoś do podania numeru karty. Uważam, że ryzyko jest tutaj na tyle mniejsze od zastosowania w wykrywaniu incydentów, że gra warta jest świeczki.

Nie chcę skupiać się na samym inotify, bardziej interesujący wydaje mi się sposób rozpoznawania numeru karty kredytowej. Autor zastosował bardzo popularny sposób detekcji numerów kart, wyrażenie regularne. Niestety generuje on bardzo dużo fałszywych pozytywów. Dobrze, że doczytałem cały post do końca, razem z komentarzem Marcina Wielgoszewskiego. Od razu zaświeciła mi się lampka - "przecież jest algorytm Luhn'a!". Marcin właśnie go polecił, a argumentował to w taki sam sposób jak ja - duża liczba false positive przy zastosowaniu tylko wyrażenia regularnego.

Nie byłbym sobą ;) bez spojrzenia na temat oczami rozwiązań typu WAF. Znam tylko jeden, który potrafi sprawdzać dany ciąg cyfr wg. algorytmu Luhna. Jest nim mod_security. Poniżej znajduje się fragment kodu, implementacja algorytmu (plik apache2/re_operators.c).

Za pomocą operatora verifyCC można w prosty sposób weryfikować poprawność numeru karty kredytowej.

"Czy to oznacza, że mój WAF jest zły? :/" - nie. Nie mam aktualnie wiedzy czy algorytm ten zaimplementowany jest dla innych WAF'ów. Po kilku kliknięciach w Google widzę, że nie jest tak tragicznie. Np. z poziomu iRules można zrobić to na urządzeniach firmy F5.

Czy to już wszystko? Nie. Do obowiązkowej lektury należy Anatomia numerów kart kredytowych. W całość zaskakuje mnie jedno. Już sam wpis na wiki mówi o dodatkowym wariancie w algorytmie Luhn'a. Niestety nie został on uwzględniony w implementacji operatora verifyCC mod_security. Zaznaczony na czerwono fragment kodu wskazuje, że wykonywana jest operacja sum[odd] %= 10;. Implementacja (iRule) dla F5 robi (tylko :() to samo.

PS
Problem fałszywych pozytywów dla CCN dotyczy także wielu innych rozwiązań, które mają utrudnić/uniemożliwić ich kradzież. Powstrzymam się i nie zaprezentuję jak można je omijać. Berek ;-)

Kwiecień 2k9

2009-04-02T20:08:00.002+02:00

To nie prima aprilis. Poniższe zdjęcie jest tak kiepskiej jakości, w tak kiepskim świetle.

Nie mam czasu i ochoty sprawiać by było lepsze. Wystarczająco dobrej jakości jest kalendarz na ścianie. To mój miesiąc i będę robił co mi się podoba ;-)

Kwiecień miesiącem... Nie interesuj się ;-p

Warsztaty: Testy penetracyjne aplikacji webowych - 22-24/04 2009

2009-03-25T23:24:00.002+01:00

Tak się złożyło, że mam ten zaszczyt i przyjemność poprowadzić kolejną edycję warsztatów: Testy penetracyjne aplikacji webowych, organizowanych przez Akademię Linux Magazine. Warsztaty trwają 3 dni i odbywają się w Warszawie.

Serdecznie zapraszam :-)

mod_filter: miesięczny czy jednorazowy?

2009-03-18T23:29:00.002+01:00

Zastanawia mnie jak bez kupowania drogich zabawek i pisanie "paczy" (jamzed - ;P) zmieniać treść zapytań/odpowiedzi serwera WWW w locie. Myślę, dumam, pytam... i nic. Taram! Latając liniami mod_filter lub mod_ext_filter wszystko może wyglądać inaczej ;-) Udanych lotów!

Inne propozycje?

OWASP Podcast#12: Ryan C. Barnett

2009-03-13T00:08:00.002+01:00

Kolejny bardzo ciekawy podcast. Tym razem wywiad z przedstawicielem m.in. Breach Security. Z ciekawostek: warto w trakcie słuchania ściągnąć prezentację Ryan'a z konferencji BlackHat Federal 2009 i dokładnie ją przeglądać.

Można też wygodnie usiąść w fotelu i napić się dobrego (Guinnessa) piwa ;) (o ile masz ukończone 18 lat!) Cheers!

CONFidence 2009

2009-03-12T00:37:00.002+01:00

To już piąty (a mój trzeci) CONFidence. Nie będę opisywał czym ta impreza jest dla wszystkich, bo każdy ma swoje odczucia. O ile w zeszłym roku przyszło mi pierwszego dnia koordynować konkurs (materiały tutaj), a drugiego dnia "aktywnie" odpoczywać po nocnej balandze, to w tym roku jednak chyba kogoś posłucham ;) Agenda zapowiada się całkiem ciekawie, nie jest to też jej ostatni forma. Lista prelegentów jeszcze ciekawsza. Czego nie dowiem się z prelekcji mogę dopytać tuż po. Czy to wszystko? Nie nie... nie ma tak lekko. Strona konferencji zmienia się bardzo dynamicznie, obserwuj ją, a może nie przegapisz prawdopodobnie najlepszego eventu w Polsce i jednego z lepszych w Europie!

d0z0!

IFRAME w polityce

2009-03-11T21:10:00.002+01:00

Vagla poruszył wczoraj (prawie dzisiaj) sprawę ramek. Temat został rozszerzony o nagłówek HTTP (Host:) i jak odpowiadają serwery WWW kiedy nie jest on wysyłany.

Szkoda czasu na opisywanie wszystkiego od początku, lepiej zająć się konkretami. Poniżej wypisałem kilka sposób jak nie pozwolić (czyt. utrudnić) na wyświetlenie mojej strony pod innym adresem niż oczekiwany:

1) Domyślny Vhost powinien wykonywać przekierowanie (301 czy 302?) pod wskazany, poprawny adres. Np. osoba odwołująca się do serwera przez adres http://127.0.0.1/ powinna zostać przekierowana na http://localhost/ - jeżeli to "localhost" będzie poprawnym i oczekiwanym adresem pod jakim chcemy zobaczyć nasz serwis. Zrealizować to można na wiele sposobów. Najlepiej zrobić to na poziomie konfiguracji serwera WWW, load-balancera. Unikałbym wykorzystanie kodu PHP czy TAGów HTML.

Dla serwera Apache można to zrobić np. tak:

(z wykorzystaniem mod_alias)

RedirectMatch 301 .* http://localhost/

(z wykorzystaniem mod_rewrite)

RewriteRule .* http://localhost/

2) Jeżeli nie chcemy by nasz serwis był umieszczany w (I)FRAME'ach innych serwisów to można zastosować kod Javascript, który powinien wykryć, że zostaliśmy umieszczeni w ramce i zmusić przeglądarkę do przejścia na naszą stronę. Poniżej przykład takiego JS.


< script> if (top != self) top.location=location </script>

3) Dla najnowszych przeglądarek (narazie dla IE8) przyda się nagłówek X-FRAME-OPTIONS, który skutecznie powinien utrudnić zamieszczanie naszego serwisu w ramce innego. Wspominałem już o nim tu i tu.

4) Innym sposobem może być korzystanie z nagłówka HTTP, który powinien zawierać adres URL serwisu, z którego został wywołany. Już sama wikipedia odstrasza osoby, które chcą zaufać referrerowi. Niestety jest on "spoofowalny" i nie powinien być wykorzystywany jako główny/jedyny sposób złapania złośliwego użytkownika, który chce umieścić nasz serwis pod swoim "złym" adresem. Tak czy inaczej raczej[1] nie zaszkodzi.

Lista ta nie wyczerpuje tematu, a że mój wolny czas jest ostatnio bardzo ograniczony zapraszam do komentowania moich i dodawanie swoich propozycji rozwiązań problemu zamieszczania serwisów WWW pod innymi adresami.

[1] - ból doświadczeń z przeszłości podpowiada mi, że czasami "stare", ale nadal popularne przeglądarki jak IE 6 gubią lub zapamiętują na dłużej referrer. Przy agresywnym sprawdzaniu pola Referrer może to mieć zgubne konsekwencje. Proponowałbym podejście gdzie sprawdzamy go "offline", np. skryptami parsującymi logi serwera WWW. Jeżeli zobaczymy podejrzane adresy możemy ogłosić alarm. Jest to działanie "post factum", ale co zapamiętane i odłożone może zostać wykorzystane w przypadku obsługi incydentu.

F5 Rule Editor

2009-03-10T22:59:00.003+01:00

Jest późny wieczór, może czas iść spać... ale jak? Kiedy pomysłów tuzin mam.
Jeżeli się nudzisz to zapraszam do skorzystania z F5 Rule Editora. Sporo frajdy może przynieść nauka nowego języka (TCL w tym wypadku), a jeśli dane będzie jeszcze wykorzystać krótkie fragmenty kodu w "produkcji" to już w ogóle.

Tylko nie mówcie, że nie kręcą Was takie ficzery ;-) Zapowiada się kolejny miesiąc sponsorowany przez trzy literki: W A F.

PS
Przyjmę dowolne, ale ciekawe, zlecenie dotyczące Web Application Firewalla, którego znam.

4+3 reasons not use Apache mod_security/mod_rewrite

2009-03-09T20:56:00.004+01:00

Pod DevCentral F5 podpiętych jest kilka blogów. Najbardziej "podoba" mi się blog Lori MacVittie. Co w nim tak przebojowego? Klapki na oczy...

Chciałbym się odnieść do dwóch postów. Polecam czytanie po fragmencie: kawałek komentowanego, mój, kawałek komentowanego, mój.

Pierwszy to "4 reasons not to use mod_security". Od razu napiszę, że Ivan Ristic merytorycznie skomentował go w komentarzu. Ja czuję niedosyt.

Ad. 1. "It runs on every web server." - rozproszona architektura mod_security w trybie "Embededd" IVMHO pozwala osiągnąć lepszą skalowalność niż pojedyńczy/podwójny WAF na dedykowanych urządzeniach. Duplikowanie części konfiguracji jest prawdziwe, ale jak się chce to można to ogarnąć.

Ad. 2. "You have to become a security expert." - osobiście nie mam oporów by dążyć do poziomu eksperta. Ktoś tutaj zapomniał, że poza podejściem, w który można opisywać atak na aplikacje webowe istnieje tzw. "model pozytywny". Nie jestem taki pewny siebie by w ciemno porównywać mod_security z ASM'em F5 czy Imperva SecureSphere w każdej płaszczyźnie, natomiast mam wrażenie, że reguły jakie można budować dla tego modułu do Apache mogą być (są?!) dużo bardziej rozbudowane od sygnatur z pozostałych wymienionych rozwiązań. Podkreśliłbym konieczność [?] (jakie "?" ?!?!) współpracy z ekspertem przy konfiguracji i utrzymaniu WAF'a, bez względu na to kto jest jego dostawcą.

Ad. 3. "You have to become a protocol expert." - łatwiej jest nauczyć się jak dobrze konfigurować jeden serwer, np. Apache, niż wszystkie (IIS, lighttpd, Tomcat, nginx, etc.) i hardenować każdy z nich osobno.

Ad. 4. "The configuration must be done manually." - ech... . ModSecurity Core Rules, który jakiś czas temu został przeniesiony pod opiekę OWASPa. BTW: WAF to nie drukarka! Czy ktoś wyobraża sobie kogoś kto potrafi _dobrze_ zaprojektować, skonfigurować i utrzymywać firewall bez znajomości stosu TCP/IP na poziomie trochę bardziej niż podstawowym? ;) A jak ktoś ma problem z pisaniem wyrażeń regularnych - to nie takie trudne, naprawdę, to zawsze można dopisać kawałek kodu w Lua.

Podsumowując, stroniąc od bycia ekspertem nigdy nim nie zostaniesz ;-) Wybór należy do Ciebie.

Drugi post, który sprowokował mnie do komentarza to: 3 Reasons not to use Apache mod_rewrite. Szybkim skokiem z telemarkiem pomijam bełkot wstępu i...

Ad. 1. "It's less efficient." - nie ma co czarować, że mod_rewrite może wygrać z iRules. Nie, nie może. Porównanie to jest w stylu żółw vs. zając. Wychowałem się na otwartym oprogramowaniu i tanio skóry nie sprzedam ;) Za pomocą prostej regułki można zmusić przeglądarkę do szybkiego opuszczenia naszego serwisu, np. za pomocą przekierowania - 301/302. Jeżeli znajduje się ona w pliku htaccess to serwer właściwie ledwo zdąży zająć się requestem i już go żegna. To naprawdę nie jest trudne dla niego. Litości.

Ad. 2. "It only works in homogeneous environments.". - ech...#2. mod_rewrite to moduł dla Apache. Oczywiste, że nie będzie działał dla innych serwerów. Załóżmy taką sytuację: Jesteśmy DDoSowani przez kilkaset klientów-zombie, którzy w nagłówku User-Agent wstawiają charakterystyczny string: "KokoJambo". Nie mamy super wypasionego ASMa F5. Czy mam szukać telefonu do eksperta od firewalli, bo od protokołu HTTP takowych nie ma, może mnie uratuje? Ten .htaccess całkiem możliwe, że tak:


RewriteEngine On

RewriteCond %{HTTP_USER_AGENT} ^KokoJambo$
RewriteRule .* http://localhost/bad_user.html

Bardzo trudne, wymaga znajomości wyrażeń regularnych, nie można wyklikać tego z panelu administracyjnego, potrzebna jest znajomość edytora tekstu i umiejętności połączenia się na serwer, np. za pomocą ssh. Praca dla Eksperta.

Ad. 3. "It requires an interruption to services." - ta, jasne. Zapomniałem, że musiałem obudzić pół biznesu by zapytać czy mogę zatrzymać serwery WWW. Ogólnie min. pół godziny okienka serwisowego, może godzinka, nie wiem, nie ma tu ekspertów od tych spraw. Proszę. Bez takich. Powyższy fragment konfiguracji mod_rewrite można umieścić w pliku .htaccess i cieszyć się z działającej konfiguracji bez jakiegokolwiek restartu serwera czy jakiejś przerwy w jego działaniu.

Uznam, że te posty to marketingowy bełkot i na tym zakończę mój komentarz. Dodam tylko, że z dnia na dzień ASM i iRules firmy F5 podoba mi się coraz bardziej, wbrew pozorom można z ich wykorzystaniem zrobić dużo. Dużo więcej niż spora część ludzi robi.

HttpOnly i Secure na F5

2009-03-08T01:17:00.002+01:00

Wiem, wiem, wiem... Zostanę oskarżony o stronniczość. Że już mod_security mi nie wystarcza, zmieniłem prace i w ogóle. Bez jaj ;-)

Ponad dwa miesiące temu Ryan Barnett opublikował sposób na dodanie takich atrybutów jak HttpOnly i Secure do ciasteczek, których autor aplikacji odpowiednio nie wzbogacił. Mod_security ma tą moc.

Na DevCentral znalazłem przepis jak zrobić to na F5: "Stop Those XSS Cookie Bandits iRule Style". Może nie byłoby w tym nic "złego" gdyby nie to, że programista powinien o to zadbać w aplikacji. Czuję odcisk ręki na buzi po tym jak ktoś właśnie wymierza mi policzek. Pytam: Za co? Bo chcę rozwiązać problem inną drogą niż przez developera? Bo czasami go nie mam? Bo czasami nie ma czasu? Bo ...? :-) Korzystajmy z tego co dała fabryka, a morały zostawmy sobie na potem.

Tak na zakończenie zadam pytanie: Czy te atrybuty rozwiązują wszystkie problemy związane m.in. z XSS'ami? *ZONK* !!! Nie. Minimalizują ryzyko m.in. kradzieży tożsamości użytkownika korzystającego z aplikacji webowej. Nic więcej. O tym co można zrobić z XSS'em napisał Michał, więc szkoda czasu by opisywać to na nowo.

Chociaż nie. Mam przykład, o którym nie wspomniał. Mając XSS'a na stronie można przełamać kilka metod zabezpieczeń przed atakami typu CSRF. Jakie można? Wszystkie?

X-FRAME-OPTIONS na F5

2009-03-07T23:39:00.003+01:00

Preferuję otwarte rozwiązania, ale jak nikt nie chce czytać bloga to warto dla siebie samego napisać o czymś o czym inni nie do tej pory nie napisali.


when HTTP_RESPONSE {
    if { not [HTTP::header exists "X-FRAME-OPTIONS"] } {
        HTTP::header insert "X-FRAME-OPTIONS" "SAMEORIGIN"
        log local0. "Inserting header - X-FRAME-OPTIONS: SAMEORIGIN"
    }
}

Jeżeli nic to nie mówi to podpowiem. iRule'ka dla F5'tki.

Nadal czekam na czytających, którzy zaprezentują jak to zrobić dla innych rozwiąząń (serwery WWW, load-balancery, proxy, Web Application Firewall, etc.)

Marzec 2k9

2009-03-01T18:23:00.003+01:00

Next Month of WAF ;-)

ClickjackFilter

2009-03-01T17:51:00.002+01:00

Bardziej słusznym tytułem byłby clickjacking, ale zależy mi na propagowaniu jak budować, a nie burzyć.

Jeff Wiliams opracował implementację filtra dla J2EE, który pozwoli na blokowanie prób wykorzystania tego rodzaju ataku dla przeglądarki IE 8. ClickjackFilter to kawałek kodu do zastosowania wprost. Nie ma co się rozpisywać w temacie, warto przeczytać oryginalny opis i stosować. Jako, że jest to okazja do dyskusji, a takie lubię najbardziej, można zadać pytanie, ale po co to stosować, skoro jest to rozwiązanie tylko dla IE, w dodatku dla wersji 8?

1) bo z nowymi laptopami/netbookami/komputerami stacjonarnymi będzie/jest dostarczany Windows Vista z IE8
2) bo może (musiałbym odszukać, ale nie teraz informacji jak jest na pewno) Firefox zaimplementuje ochronę w taki sam sposób jak to zrobił Microsoft
3) bo uratuje to część użytkowników, a rozwiązanie tego typu nigdy nie obejmują 100% użytkowników
4) bo nie zawsze trzeba angażować w to programistów (?!?!?!?!)

Ktoś powie, jak to?!?! (4))

Zagadka: jak można dodać taki nagłówek (X-FRAME-OPTIONS) z poziomu konfiguracji serwera/WAFa? Jeżeli ktokolwiek czyta tego bloga i ma pomysł to proszę o podsyłanie (najlepiej jako komentarz) przykładów praktycznych jak można to zrobić.

PS
Przy okazji przypomniał mi się jeden z grzechów głównych przy pisaniu "bezpiecznych" aplikacji: "O bezpieczeństwo zadbamy po realizacji wymagań biznesu." - bez jaj!

Battle of WAF 1/2009

2009-02-11T23:20:00.003+01:00

Jak to ma miejsce co jakiś czas... na jednej z list mailingowych (websecurity), w kilku wątkach (np. tu tu | egrep -i WAF) pojawia się motyw bitwy o WAFy. Sporo flejmu, ale można też czegoś się nauczyć - warto prześledzić. Iskierką był ostatni, #6 podcast OWASPa, który już zapowiada kolejną MPtrójkę, gdzie WAF będzie jednym z głównych tematów.

Do tego czasu szczerze POLECAM #2 OWASP Podcast, gdzie Stephen Craig Evans opowiada o swojej przygodzie z OWASP Securing WebGoat using ModSecurity Project. Stephen wraz z Jim'em ukoją nerwy, a jeśli spędzasz w drodze choćby 1/2h dziennie to zainteresują co piszczy w innych podcastach.

Punkt widzenia zależy od miejsca siedzenie, jednak zdrowy rozsądek przede wszystkim. FRS - Fanatyzm Robi Swoje; nie tolerujmy i sprytnie zwalczajmy.

WAFEC V1.0 vs WAFC V2.0.1

2009-02-09T01:43:00.003+01:00

Kontynuując miesiąc Web Application Firewall na tapecie miałem "Web Application Firewall Certification Criteria" by ICSA Labs - w wersji 2.0.1. Co ciekawe dokument nie nazywa się WAFC^2 tylko WAFC. Szczegół :)

Przechodząc do meritum, WAFC opisuje jakie wymagania stawiane są WAF'om aby mogły uzyskać certyfikat by ICSA. W kolejnych rodziałach weryfikowana jest:
- Documentation - IMHO bardzo fajny rozdział, czym jest "szarego bezpiecznika" jest rozwiązanie/produkt bez dobrej dokumentacji? (kiedyś może za to oberwę na ulicy, ale miałem na myśli inżyniera, który specjalnie nie wnika co i dlaczego tylko wykonuje polecenia/zalecenia z "User Guide"). Jak ktoś potrzebuje rozpoznać coś na "sucho" to dobrze napisana dokumentacja może dać całkiem fajny pogląd na to co "na pewno" można. Dlaczego "na pewno" ? Bo to co w dokumentacji nie zawsze idzie w parze z praktyką.
- Platform Security - ogólny spis wymagań co do bezpieczeństwa platformy, na której stoi WAF. Fajne z uwagi na wymaganą rozliczalność, uwierzytelnienie administratorów czy wymaganie związane z zachowaniem integralności polityk bezpieczeństwa przy jednoczesnej pracy dwóch adminów nad konfiguracją. Dodatkowo wymagania co do zdalnego dostępu pokrywające się częściowo z WAFEC. Na chwilkę zatrzymałbym się przy tym punkcie. WAFC stawia wymagania platfomie, aby nie zawierała aplikacji w wersjach z ogólnie znanymi podatnościami, czy też nie była podatna na proste ataki typu DoS. Dodatkowo konfiguracja platformy, polityki bezpieczeństwa, logi, ustawienia czasu i daty powinny być odporne na zaniki napięcia czy restarty. Niby takie oczywiste, ale jak jest zapisane to robi się od razu lepiej.
- Functional Security - w tej części dokumentu autorzy skupili się na możliwościach samego WAFa. Pragną zapewnienia odporności na popularne ataki jak "Buffer overflow / code injection" czy "Cross Site Scripting". Życzą sobie obsługi różnych modeli bezpieczeństwa: Negative i Positive, możliwości normalizacji i przepisywania URLi, a także trybu nauczania, o którym coś więcej innym razem. W sporej części widać tutaj pokrycie z WAFECiem. Co wbudza moje obawy to fakt, że wymagania są bardzo ogólne. "Ma być normalizacja URL" - nie uwierzę jak nie zobaczę co autor miał na myśli.
Już w WAFTP V1.0 było więcej informacji na ten temat. Mimo braku szczegółów znajduje się tutaj wymaganie, które mnie akurat bardzo się podoba. Lubię kiedy dany proces jest uporządkowany, mam rozliczalność, wiem kiedy, kto, co i dlaczego. Dlatego urzekły mnie wymagania związane z zapewnieniem wprowadzania zmian w konfiguracji polityk bezpieczeństwa: edytowanie czy powrót do poprzedniej wersji to coś bardzo przydatnego w utrzymaniu WAFa. Kto się o tym jeszcze nie przekonał na pewno będzie miał jeszcze okazję. Kolejnym mocnym punktem (ale znów bardzo ogólnym!) jest wymaganie związane z zapewnieniem możliwości konfiguracji ustawień protokołu HTTP: typy/metody encodingu, walidacja protokołu, długość nagłówków, etc. W tym fragmencie osiągnięto niemal 100% pokrycie z WAFECiem. Nareszcie! ;) Ludzi zaczynający rozpoznawanie tematu WAFów ciekawi jak to rozwiązanie poradzi sobie z HTTPSem. Otóż dobrze lub doskonale ;) Zależy od tego jak go użyjemy. Odpowiedni punkt "HF5 - SSL Support" mówi o tym co powinien WAF potrafić robić z SSLem, chyba, że jest on integralnym elementem serwera WWW.
- Logging - całkiem sporo szczególików, co, gdzie, jak... a ja zaczynam się śmiać... Dlaczego? Dlaczego?!?!? Dlaczego po raz kolejny nie widzę wymagania co do logowania parametrów przekazywanych inaczej niż w URLu?! Czy metodą POST/HYDYZ/TEST/ABRAKADABRA lub w nagłówku HTTP nie można zaatakować? Pewnie nie ;-)

Dokument kończy się ponad 2 stronicowym słownikiem pojęć. Ogólnie wygląda lepiej do wcześniej analizowanego WAFTP, choć nie wiele. Nadal jestem za opcją: zakreślić w WAFEC co istotne + elementy WAFTP/WAFC + przemyślenia. Wtedy można zacznąć oceniać czy dany Web Application Firewall spełnia stawiane przed nim oczekiwania.

Na koniec porównania WAFTP i WAFC z WAFEC mały obrazek. Strona tytułowa WAFECa, a na niej zaznaczone pokrycie pozostałych dokumentów. (Sorry za jakość, ale po 2 w nocy chyba nie mam ochoty wyciągać palić lepszego światła ;))

+ zielony: Web Application Firewall Testing Procedure by NSS Labs
+ pomarańczowy: Web Application Firewall Certification Criteria by ICSA Labs

OWASP Podcast#6: WAF

2009-02-06T00:37:00.002+01:00

Nic tak nie pociesza w stanie wyobcowania jak... ;-) Marcin Wielgoszewski już jakiś czas temu wspominał o nagraniu OWASPowego podcasta. Stało się, dzisiaj ujrzał on światło dzienne. Nie wspominałbym o tym gdyby nie główny temat nagrania: Web Application Firewall. Czy to wystarczający powód? Pomijając próbę cenzury to tak, bo podcast może rzucić nowe światło na temat, którym aktualnie się zajmuję. Co jest bardzo fajne, mam bardzo zbliżone stanowisko do tego jakie prezentują rozmówcy Jim'a Manico.

WAFEC 1.0 vs. WAFTP 1.0

2009-02-05T00:25:00.003+01:00

Z poprzedniego posta można wywnioskować, że sam się zaintrygowałem. Nie mogłem zrobić inaczej jak pójść za ciosem. Na warsztat wziąłem wszystkie 3 dokumenty: Web Application Security Consortium, NSS Labs i ICSA Labs. Jako, że najlepiej z nich znam (znałem?) WAFEC, postanowiłem porównać pozostałe dokumenty właśnie do niego.

Dokument NSS Labs ma zaledwie 8 stron. Chociaż rozmiar czcionki mniejszy niż w WAFEC'u to nadal wiele mniej treści i konkretów.

Web Application Firewall Testing Procedure (V1.0) składa się z kilku części:
- The Test Environment, czyli opis środowiska w jakim będą przeprowadzane testy
- Section 1 - Detection Engine, który opisuje ataki (30 różnych) przed którymi WAF powinien potrafić obronić aplikację webową. Problem w tym, że panowie z NSS Labs używają do tego WebGoat'a, który sam w sobie nie jest zły. Istotą problemu jest prostota ataków jakie można przeprowadzić na tej platformie.
- Section 2 - Evasion, 9 technik obfuskacji zapisu URLa ze skanera Whisker, jak dla mnie zdecydowanie za mało. Warto odnotować, że występuje tutaj pierwsze pokrycie z fragmentem WAFECa (3.1 - Normalisation techniques)
- Section 3 - Performance Under Load (No Security Policies Applied), w tej części można być zapewnionym, że appliance (nie biorą pod uwagi rozwiązań udostępnianych jako software?) wytrzyma taki i taki ruch sieciowy, bez aktywnych polityk bezpieczeństwa
- Section 4 - Performance Under Load (Security Policies Applied), bardziej szczegółowe testy niż w sekcji 3, zarówno dotyczące serwowania strony statycznej (HTML) jak i z grafiką (10 obrazków), dodatkowo maksymalna liczba równoległych połączeń do WAFa. Występuje tutaj druga zgodność z WAFEC'iem(8.1 HTTP-level performance)
- Section 5 - Latency & User Response Times, zbadanie latencji dla poszczególnych pakietów przy ruchu od 250 Mbps do 1Gbps'a (w krokach po 250 Mbps)
- Section 6 - Stability & Reliability, całkiem ciekawa sekcja, WAF testowany jest na wypadek występowania ruchu symulującego atak i tylko atak, wywołujący alarmy i kolejne zdarzenia w logach, tak przez 8h bez przerwy. Jeżeli przez urządzenie przejdzie atak, który nie zostanie w tym okresie czasu zauważony, firewall nie zaliczy testu.
- Section 7 - Management and Configuration, inżynierowie z NSS Labs upewnią się czy na interfejsie do zarządzania WAFem nie nasłuchują aplikacje, na które ataki są powszechnie znane.

Z jednej strony 22 stronicowy WAFEC, z drugiej dokument firmy NSS Labs. Tylko dwie zgodności względem większego z nich. Czy to źle? W mojej opinii tak. Ponieważ produkty o dość ograniczonych możliwościach mogą uzyskać certyfikat jakości, a może lepiej jak napiszę "funkcjonalności". Nie będę przekonany do żadnego rozwiązania, które posiada taki certyfikat. W takiej sytuacji trudno też oceniać WAFy, które go nie posiadają. Vendor świadomie zrezygnował z tej certyfikacji, nie zna jej (!) albo ogólnie ma to w nosie. To, że taki dokument powstał ma też swoje zalety. Postrzegam go jako uzupełnienie i postawienie wymagań co do jakości funkcjonalności danego produktu. Uzupełnienie obszernego WAFECa, który ma już dobre 3 lata. Warto o tym pamiętać.

O wyborze WAFa raz jeszcze

2009-02-04T07:33:00.002+01:00

Potrzebowałem odejść na chwilę od klawiatury, aby przypomnieć sobie o firmach zew., które badają WAFy pod kątem takich powszechnie znanych wymagań/spisów funkcjonalności.

Proszę, ICSA Labs posiada całkiem podobny dokument do WAFEC. Jak tylko nie wypadnie mi to z głowy to porównam oba dokumenty. Obiecujący jest termin ostatniej modyfikacji dokumentu - 15 sierpień 2008. Co ciekawe, firma ta certyfikuje WAFy, które w 100% pokrywają wymagania jakie stawia im ekipa z ICSA Labs. Na zdrowy rozsądek można zgadywać, że oba dokumenty (ICSA Labs i Web Application Security Consortium) powinny się od siebie różnić. Jestem ciekawy co wyjdzie przy porównaniu. Warto dodać, że developerami w ICSA Labs są vendorzy... Nie ma co się łamać, trzeba podejść do tematu z dużą dozą zdrowego rozsądku.

Inna firmą, która także certyfikuje rozwiązania bezpieczeństwa jest NSS Labs. To już prawie temat na prace dyplomową albo magisterską ;-) Porównać wszystkie trzy metody oceny Web Application Firewall. Dokument firmy NSS Labs pochodzi z 2006 roku co bardzo przybliża go do daty wydania WAFECa. Mam nadzieję, że obietnice wydania nowszej wersji w końcu się ziszczą.

PS
Na śmierć zapomniałem o site'ie, gdzie definicje napisane są jakby na moje potrzeby ;) Tutaj znajduje się definicja Web Application Firewall, która może przemówić do człowieka i nie wciskać mu kitu. Nie jest tak metaforyczna jak moja z poprzedniego posta (;-)), ale zawiera to co powinna.

(stary) WAFEC dobry jest

2009-02-03T22:48:00.002+01:00

Życie to nie bajka, a wybór WAF'a (Web Application Firewall) to dopiero przygoda...

Zaczynając od początku: Czym jest WAF? Jest to firewall z rodziny aplikacyjnych, który powinien doskonale znać, rozumieć i potrafić robić "cuda na kiju" na poziomie protokołów wykorzystywanych przez aplikacje webowe. Chociaż od kilku lat interesuje się tego rodzaju rozwiązaniami, nie znalazłem prostej definicji, która w 3-4 zdaniu opisu nie mówi, że jest to "pudełko" do ochrony przed XSS'ami i SQL Injection. FAIL! Rozwiązanie tego rodzaju może służyć do ochrony przed takimi atakami, ale tylko wtedy gdy się o to dobrze zadba. Podejrzewam, że jeżeli taki opis przeczyta 10 menadżerów, którzy są po prezentacji jednego lub kilku vendorów, to więcej niż połowa z nich zacznie dumać co kupili albo co chcieli kupić... skoro WAFy wprost nie blokują jednych z najpopularniejszych ataków na aplikacje webowe.

Zanim podejmie się decyzje o zakupie WAF'a polecam zapoznanie się z następującym projektem: Web Application Firewall Evaluation Criteria. Dzięki dokumentowi, który jest owocem tego projektu, można poznać nasze własne oczekiwania co do takiego rozwiązania jak WAF. Może to dziwnie zabrzmieć, ale ile cech takiego firewalla można wymienić ad hoc? A ile zastanawiając się 2h? Ponieważ WAFEC pozwala w sposób obiektywny ocenić jakie możliwości ma dany Web Application Firewall to moim skromnym zdaniem nie wykorzystanie tego dokumentu jest błędem. Na jego podstawie można nakreślić obraz "idealnego" WAFa do naszych potrzeb i pod tym kątem odpowiadać na pytanie: czy WAF X będzie spełniał nasze oczekiwania? a może Y?

Dostawcy takich rozwiązań bardzo często tworzą tabelki, w których porównują swoje produkty z innymi. Pokazują je podczas prezentacji dla potencjalnych klientów. Rzadko kiedy przedstawiają informacje o wersjach produktów, warunkach w jakich były prowadzone testy czy o innych szczegółach. WAFEC zapewnia obiektywną ocenę rozwiązań. 0 ściemy.

To co może razić to czas kiedy ostatnia wersja WAFECa ujrzała światło dzienne - styczeń 2006 roku. Od tego czasu "trochę" się zmieniło. Nie zmienia to faktu, że nie znam lepszego źródła wiedzy o funkcjonalnościach jakie mogą posiadać WAF'y. Już w zeszłym roku czytałem o pracach nad wersją 2.0, mam nadzieję, że wkrótce zostaną ukończone i będziemy się cieszyć z jeszcze lepszego dokumentu, który pozwoli nam dokonywać lepszych wyborów.

Uwaga. Można by pomyśleć, że chcąc wybrać odpowiednie rozwiązanie należy chwycić w ręce WAFEC, danego WAFa i pozakreślać funkcjonalności w nim dostępne. Powtarzać proces aż do przetestowania wszystkich dostępnych rozwiązań i wybrać mający największą ilość funkcjonalności. Nie. Szkoda czasu - którego nigdy nie mamy, pieniędzy - czasu ;-), zachodu - chyba, że założymy taką firmę (!!!).

Moja propozycja jest taka:
1. Na podstawie WAFEC i własnych analiz (nie popadajmy w skrajność kiedy patrzymy tylko i na WAFEC!) tworzymy listę wymagań co do rozwiązania.
2. Przeprowadzamy testy WAFa pod kątem zgodności z wymaganiami - 1.
3. Powtarzamy czynność 2. aż nie skończą się nam WAFy.
4. Tworzymy ranking WAFów i biorąc pod uwagę budżet potrzebny do zakup, wdrożenie, utrzymania rozwiązania w stosunku do posiadanych środków wybieramy jedno lub więcej z nich.

Ewentualnie drogą analizy ryzyka lub widzimisię nie decydujemy się na WAFa.

Całą lub część takiej analizy można zlecić firmie zew., szczególnie kiedy koszty wynajęcia firmy będą niższe niż zrobienie tego w ramach własnych zasobów. Wtedy zawsze możemy porozmawiać.

Luty 2k9

2009-02-01T17:36:00.002+01:00

Niespodziewanie nadszedł luty.

Miesiąc badań i rozważań na temat WAFów. Start.

Nowy... 2k9

2009-01-25T19:30:00.005+01:00

Nowy rok, nowe obietnice, nowe możliwości... a dla mnie nowy jest kalendarz. Rasowy ziom tubek przywiózł mi go z USA. Szczególnie wielkie dzięki za to, że nie musiałem ponosić dodatkowych kosztów przesyłki, które wynosiły > 100 USD. Rura piwa dla Ciebie tox! Kalendarz prezentuje się następująco:

Fajnieszy jest natomiast "January":

Przepraszam, miał być cały ;-)

Teraz mam powód by napisać jeszcze 11 notek w tym roku.