Sekurak Offline 2015-01.pdf

(14398 KB) Pobierz
OFFLINE
N 1 / 2015
o
sekurak.pl/offline
ZendFramework
SQLi
OWASP AppSensor
Object Injection
Bezpieczeństwo
aplikacji WWW
Burp Suite
CSRF
CSP
rozwal.to
HSTS
Nuxeo
©
sekurak
XSS
Edytorial
Sekurak/Offline Startuje
Wreszcie doczekaliśmy się pierwszego numeru długo za-
powiadanego sekurak-zina. Idea magazynu jest prosta
– chcemy zbierać interesujące teksty z danego obszaru
związanego z bezpieczeństwem IT, a następnie udostępniać
je w profesjonalnym wydaniu.
Pierwszy numer zina skupia się na tematyce aplikacji webo-
wych. Jest trochę podstaw, ale też kilka bardziej zaawanso-
wanych tekstów. Mamy również materiały zupełnie premie-
rowe, jak choćby opis znalezionych przez nas podatności we
frameworku Nuxeo. Wystarczy przeczytać od deski do deski
cały numer i obiecuję, że nauczycie się czegoś nowego.
Jeśli Wam mało, to jednocześnie oddajemy nowe zadania
w platformie
hackme/CTF – rozwal.to.
Można tu na żywo
przetestować swoją wiedzę z obszaru ITsec (również w te-
matyce bezpieczeństwa aplikacji webowych).
Sekurak/Offline udostępniamy
bezpłatnie, zachęcamy do
dzielenia się zinem ze znajomymi.
Do pobrania nie jest wymagany adres e-mail, ale możecie
zapisać się
na autopowiadomienie o kolejnych numerach.
Masz pytania? Prośby? Chciałbyś podzielić się uwagami?
Czekamy na Twój kontakt (sekurak@sekurak.pl).
redaktor naczelny
Michał Sajdak
Współpraca/teksty
Michał Bentkowski
Piotr Bratkowski
Rafał Janicki
Bartosz Jerzman
Adrian Michalczyk
korekta
Katarzyna Sajdak
Julia Wilk
skład
Keylight
Treści zamieszone w Sekurak/Offline służą wyłącznie celom informacyjnym oraz edukacyjnym.
Nie ponosimy odpowiedzialności za ewentualne niezgodne z prawem wykorzystanie
materiałów dostępnych w zinie oraz ewentualne szkody czy inne straty poniesione w wyniku
wykorzystania tych materiałów. Stanowczo odradzamy działanie niezgodne z prawem czy
dobrymi obyczajami.
Wszelkie prawa zastrzeżone. Kopiowanie dozwolone (a nawet wskazane)
– tylko w formie niezmienionej i w całości.
Michał Sajdak
sekurak
.
pl
/
offline
Spis treści
Czym jest
podatność CSRF…?
Michał Sajdak
W bazie tekstów portalu seku-
rak.pl zamieściliśmy już opisy
kilku podatności występujących
w aplikacjach webowych: XSS,
SQL injection…
Problemy z XXE
(XML eXternal Entity)
Michał Bentkowski
Podatności związane z XXE (XML
eXternal Entity) ostatnio zdo-
bywają coraz większą „popular-
ność” w aplikacjach interneto-
wych…
Czym jest Content
Security Policy?
Rafał ‘bl4de’ Janicki
W dobie coraz powszechniej-
szych zagrożeń, czyhających na
nas w cyberprzestrzeni, coraz
bardziej istotną kwestią staje się
poziom zabezpieczeń…
HSTS czyli HTTP Strict
Transport Security
Piotr Bratkowski
W kolejnym odcinku opisującym
nagłówki HTTP związane z bez-
pieczeństwem webowym skupi-
my się na HSTS czyli HTTP Strict
Transport Security…
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
Czym jest SQL
injection?
Michał Sajdak
To jedna z dość częstych i jedno-
cześnie niebezpiecznych podat-
ności w aplikacjach webowych
(oraz niewebowych). Nie bez po-
wodu SQL injection należy do…
Czym jest
XSS?
Michał Sajdak
O błędzie Cross-Site-Scripting
napisano już zapewne wiele
powieści. Podatność ta jest też
częstym przedmiotem żartów.
Osoby zajmujące się…
Pozwalasz ładować pliki
SVG? Masz XSS-a!
Adrian “Vizzdoom” Michalczyk
Dodawanie plików przez użyt-
kowników web aplikacji wiąże
się z wieloma zagrożeniami.
Pentesterzy w tym obszarze czę-
sto szukają luk…
Wprowadzenie do
narzędzia Burp Suite
Adrian “Vizzdoom” Michalczyk
Pośrednik HTTP analizują-
cy ruch między przeglądarką
a serwerami WWW jest podsta-
wowym narzędziem pracy teste-
ra web aplikacji. Burp Suite…
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
PHP
Object Injection…
Michał Bentkowski
Wyszukiwanie „PHP Object
Injection” w Google’u zwraca
też wyniki dla frazy „dependen-
cy injection”. W rzeczywistości
„object injection” i…
PHP Object Injection
i ZendFramework2
Michał Bentkowski
Podatność PHP Object Injection
jest już czytelnikom Sekuraka
znana; opisywaliśmy ją, poka-
zując na przykładzie błędu tego
typu w Joomli jak…
OWASP AppSensor
– obroń swoją aplikację
Bartosz Jerzman
Projekt AppSensor został ofi-
cjalnie dołączony do grupy
flagowych (flagship) projektów
organizacji OWASP. Celem tego
projektu jest integracja…
Błędy bezpieczeństwa
we frameworku Nuxeo
Michał Bentkowski
Kilka miesięcy temu przeprowa-
dzaliśmy ogólną analizę bezpie-
czeństwa frameworka Nuxeo.
Nuxeo to aplikacja typu ECM
(Enterprise Content…
sekurak
.
pl
/
offline
Michał Sajdak
 Początkujący  |  Średni  |  Zaawansowany
 Defensywa  |  Ofensywa 
Czym jest podatność CSRF
(Cross-Site Request Forgery)?
W bazie
tekstów
portalu
sekurak.pl
zamieściliśmy już opisy
kilku podatności występujących w aplikacjach webowych:
XSS, SQL injection, XPaTh injection, PhP Object injection,
RcE poprzez deserializację obiektów w Pythonie
czy
XXE.
Te-
raz czas na kolejny problem:
CSRF.
.
.
)
)
)
)
Po przeczytaniu tekstu będziesz wiedział:
czym jest podatność CSRF,
jak wyglądają przykładowe scenariusze ataku,
jak CSRF wykorzystywany jest jednocześnie z innymi podatnościami,
jak się chronić.
Czyli w wolnym tłumaczeniu: jest to
zmuszenie przeglądarki ofiary do wyko-
nania pewnej nieautoryzowanej akcji (wykonania requestu HttP).
Zauważmy
przy okazji, że jest to atak na
przeglądarkę internetową
(a nie część serwerową
aplikacji webowej; dla serwera requesty powstałe w wyniku ataku to w pełni legalna
komunikacja z przeglądarki użytkownika).
CSRF nie należy mylić z atakiem
Man-in-The-Browser,
gdzie atakujący też może
wpływać na działanie przeglądarki, ale wiąże się to z wcześniejszym zainstalowa-
niem w systemie ofiary malware. W przypadku CSRF system, jak i przeglądarka ofia-
ry nie są w żaden sposób trwale modyfikowane. Wykorzystana jest po prostu pewna
właściwość architektury web i przeglądarek internetowych.
CSRF to również nie to samo co
XSS.
Jeśli mamy XSS-a – to da się zrealizować
CSRF, ale jeśli nasza aplikacja podatna jest na CSRF – to niekoniecznie musimy być
podatni na XSS. Z kolei sam Cross-Site Scripting może służyć do ominięcia metod
ochrony przed CSRF (szczegóły w dalszej części tekstu).
Chyba najlepiej uczyć się na konkretnych przykładach, zobaczmy więc od razu
pierwszy scenariusz wykorzystania podatności CSRF, zmuszający przeglądarkę admi-
nistratora aplikacji webowej do wykonania requestu http, który doda w niej nowego
użytkownika.
sekurak
.
pl
/
offline
)
.
Czym jest podatność CSRF
(Cross-Site Request Forgery)?
)
.
Problemy z XXE
(XML eXternal Entity)
)
.
Czym jest
Content Security Policy?
)
.
HSTS czyli
HTTP Strict Transport Security
)
.
Czym jest SQL injection?
)
.
Czym jest XSS?
)
.
Pozwalasz ładować pliki SVG?
Masz XSS-a!
)
.
Wprowadzenie do narzędzia
Burp Suite
)
.
PHP Object Injection
– mało znana klasa podatności
)
.
PHP Object Injection
i ZendFramework2
)
.
OWASP AppSensor
– obroń swoją aplikację
)
.
Błędy bezpieczeństwa
we frameworku Nuxeo
WStęp
CSRF
(Cross-Site Request Forgery; alternatwnie używane nazwy:
XSrf, session ri-
ding
czy
one-click attack)
to chyba jedna z najmniej rozumianych podatności opi-
sywanych w ramach słynnego projektu
OWASP Top Ten.
Często mylona jest z
podat-
nością XSS,
czasem również prezentowana jednocześnie z innymi podatnościami,
co też zaciemnia obraz problemu.
Na czym więc polega istota tej podatności? Definicja OWASP mówi tak:
A CSRF attack forces a logged-on victim’s browser to send a forged
HTTP request, including the victim’s session cookie and any other au-
tomatically included authentication information, to a vulnerable web
application. This allows the attacker to force the victim’s browser to
generate requests the vulnerable application thinks are legitimate requ-
ests from the victim.
pRzykład 1. panel adminiStRaCyjny FoRum
W tym przypadku dostępną mamy aplikację (forum dyskusyjne) pod jedną domeną.
Panel administracyjny posiada ograniczony dostęp (logowanie tylko z określonej
puli adresów IP). Atakujący będzie chciał zmusić przeglądarkę administratora (wy-
korzystać podatność CSRF) do zarejestrowania nowego konta (Rysunek 1).
Całość odbywa się w kilku krokach:
1. Atakujący rejestruje konto, podając w swoim loginie tag: <img src=”http://pro-
forum.sekurak/admin/addUser?login=malgorzata4&pass=1234&type=adm”>
2.
Możliwe są tu również
inne sposoby ataku
(tag <img> to tylko przykład).
3. Administrator loguje się oraz wchodzi na stronę z akceptowaniem nowych kont.
4. Podczas próby pobrania obrazu z tagu <img>, przeglądarka administratora reali-
zuje automatycznie request do panelu administracyjnego (mamy tu CSRF) – i tym
samym tworzy nowe konto w systemie o uprawnieniach administracyjnych.
5. Aby atakujący mógł się zalogować, wystarczyłoby jeszcze raz wykorzystać CSRF
do wykonania np. requestu usuwającego blokadę na IP użytkownika.
4
Podziel się zinem
Michał Sajdak
Czym jest podatność CSRF (Cross-Site Request Forgery)?
sekurak
.
pl
W takim scenariuszu może być atakowany w zasadzie dowolny panel admini-
stracyjny aplikacji webowej, który przetwarza (np. wyświetla) pewne dane kontro-
lowane od użytkownika.
Z przykładu widać, że domyślnie aplikacje webowe są na CSRF podatne (chyba
że użyły
osobnych bibliotek
czy mechanizmów ochronnych) – po prostu w ten spo-
sób została zaprojektowana architektura web.
W tym momencie może też powstać pytanie: co byłoby w przypadku, gdyby
aplikacja odpowiednio filtrowała wartości przekazywane przez użytkownika do
pola login? CSRF również byłby możliwy – ale ścieżka ataku wyglądałaby nieco ina-
czej. Zobaczmy więc kolejny przykład.
/
offline
)
.
Czym jest podatność CSRF
(Cross-Site Request Forgery)?
)
.
Problemy z XXE
(XML eXternal Entity)
)
.
Czym jest
Content Security Policy?
)
.
HSTS czyli
HTTP Strict Transport Security
)
.
Czym jest SQL injection?
)
.
Czym jest XSS?
)
.
Pozwalasz ładować pliki SVG?
Masz XSS-a!
)
.
Wprowadzenie do narzędzia
Burp Suite
)
.
PHP Object Injection
– mało znana klasa podatności
)
.
PHP Object Injection
i ZendFramework2
)
.
OWASP AppSensor
– obroń swoją aplikację
)
.
Błędy bezpieczeństwa
we frameworku Nuxeo
pRzykład 2. CSRF i RouteR doStępoWy do inteRnetu
Tym razem prześledźmy scenariusz wykorzystujący dwie domeny (pod jedną jest
atakowany system, drugi to domena pomocnicza z wprowadzonymi przez atakują-
cego pewnymi zmianami). Ponadto scenariusz ten wykorzystuje poza CSRF jeszcze
dodatkowe podatności w aplikacji webowej.
Podatności w routerze ASMAX
1. CSRF – przykład.
Wnioski:
1. Atak zadziałał, mimo tego że ofiara początkowo nawet nie mogła dostać się do
panelu administracyjnego (ograniczenie na adres IP).
2. W ataku nie został wykorzystany javascript.
3. W ataku nie została wykorzystana
podatność XSS
(choć gdyby ona była dostępna
w aplikacji – można by również zrealizować CSRF – wykonując odpowiedni requ-
est za pomocą javascript).
4. Atakujący nie znał loginu ani hasła administratora.
5. W logach serwera www jako źródłowy adres IP requestu, który dodał nieautory-
zowanego użytkownika widoczny będzie realny adres IP atakowanego admini-
stratora (nie będzie to więc adres IP atakującego).
6. Atakujący nie widzi odpowiedzi na request, do którego wykonania został zmu-
szony administrator, ale nie ma to wpływu na skuteczność ataku.
Jakiś czas temu udało mi się znaleźć kilka błędów bezpieczeństwa w routerze
ASMAX (podatności te swoją drogą nie zostały chyba do dzisiaj załatane). Najistot-
niejszą z nich była możliwość wykonania kodu w systemie operacyjnym routera
z odwołaniem się
bez uwierzytelnienia
do zasobu /cgi-bin/script – na przykład
w sposób zaprezentowany na Rysunku 2.
Mieliśmy więc tutaj dwie podatności:
1.
wstrzyknięcie kodu systemu operacyjnego,
2.
ominięcie uwierzytelnienia (a de facto jego brak).
Podatności w routerze ASMAX – CSRF
Jak ma się do tego omawiany CSRF? Zobaczmy przykładowy scenariusz ataku na
urządzenie, przy dodatkowym założeniu, że panel zarządczy urządzenia
w ogóle
nie jest dostępny z poziomu internetu.
Atak ten skutkował będzie nieograniczo-
nym dostępem (jako root) na systemie operacyjnym urządzenia (Rysynek 3).
Całość ataku odbywa się w kilku krokach (cyfry 1-4 na zrzucie ekranowym obok):
1. Atakujący umieszcza na dowolnej stronie webowej tag <img> z parametrem
5
Podziel się zinem
Zgłoś jeśli naruszono regulamin