Bezpieczeństwo PKO BP

Dzisiejszego wieczora udało mi się wspólnie z Panem Mateuszem Stępniem z Hack.pl zakończyć badania nad wykrytymi przeze mnie lukami w portalach www.pkob.pl oraz www.pkointeligo.pl. Owocem naszej pracy jest artykuł znajdujący się pod tym adresem. Zachęcam do lektury :)

Informacja o banku Nordea.

W dniu wczorajszym na łamach Hack.pl została opisana sprawa Nordeii.

Luki w zabezpieczeniach polskich banków 2

Po przeanalizowaniu zabezpieczeń Banku Nordea udało mi się wykryć kilka błędów. Poniważ nie posiadam konta w tym banku, nie byłem więc w stanie w pełni ocenić potencjalnego niebezpieczeństwa wynikającego z wykorzystania tych luk. Skorzystałem więc, ze znajdującego się na stronie www.nordea.pl formularza w celu, choć częściowego, uzupełnienia mojej wiedzy i ponformowania o zaistniałej sytuacji. Szczerze powiedziawszy, jak to często się zdarza, nie spodziewałem się żadnej reakcji Dużym zaskoczeniem okazała się dla mnie bardzo szybka odpowiedź pracowników banku. Doszło między nami do wielokrotnej wymiany maili oraz kilku rozmów telefonicznych. Poproszono mnie o przedstawienie szczegółów dotyczących moich badań. Udzielono mi również szczegółowych informacji na temat natury wykrytych przeze mnie błędów. Jak się okazało część z nich wynikała z pomyłki producenta oprogramowania serwera www, a nie samego serwisu. Dowiedziałem się również iż całość skrytpów zostało sprawdzona pod kątem zgłoszonych błędów. Po zakończeniu wszystkich prac poproszono mnie o ponowne przyjrzenie się serwisowi. Tym razem nie udało mi się znaleźć żadnej podatności na ataki typu XSS. Cieszy mnie, iż Bank Nordea podszedł do sprawy tak poważnie i to zanim doszło do jakiegokolwiek szumy medialnego. Ta pozytywna reakcja powinna być przykładem dla innych instytucji. Najczęściej informacje o lukach albo ignorowane, albo dochodzi do tzw "cichego łatania" zanim jakakolwiek informacja dotrze do opinni publicznej. Opisuję tą historię mam nadzieję, iż ten stan rzeczy (pod wpływem pozytywnego przykładu) ulegnie zmianie. Równocześnie chciałbym zapowiedzieć, iż już w tej chwili posiadam informacje na temat stanu zabezpieczeń większośći polskich banków i w stosownym czasie poinformuję o wykrytych lukach.

Allegro tylko częściowo potwierdza zarzuty

Zapraszam do lektury artykułu znajdującego się pod tym adresem. Jak się okazuje Allegro niechętnie, ale przyznaje się do wykrycia błędu.

Allegro pełne dziur 2

Po krótkiej przerwie postanowiłem umieścić kolejny wpis na blogu, jako że nadarzyła się ku temu okazja. Wszyscy zapewne pamiętają słynną historię z błędami w Allegro wykrytymi przed świętami przez ekipę hacking.pl. Po dwóch tygodniach od załatania tamtej luki postanowiłem przyjrzeć się zabezpieczeniom allegro. Jak się okazało znalezienie kolejnego błędu o takim samym stopniu niebezpieczeństwa zajęło mi 10 minut. Skontaktowałem się z autorem artykułu, który potwierdził moje spostrzeżenia. Celowo nie informowałem Allegro czekając, aż sami znajdą owy błąd. Jak się okazało Administratorom serwisu zajęło to ponad miesiąc! Teraz kiedy luka jest już nieaktywna przedstawię jej szczegóły. Otóż Allegro poprawnie przetwarzało zarówno zmienną PHP_SELF jak i wartości zmiennych przekazywanych przez użytkownika. Niepoprawnie były jednak obsługiwane same nazwy zmiennych. Oto zrzuty ekranów:

A oto przykładowy link wyświetlający ciasteczko i efekt jego działania:

Oraz wykorzystanie JavaScript Injection do XSS:

Jak przypuszczam Allegro liczyło na to, iż sprawa nigdy nie wyjdzie na światło dziennie. Szkoda, że tak podchodzi się do polityki bezpieczeństwa. Użytkownicy mają prawo wiedzieć o ryzyku jakie im grozi. Domyślam się, że gdybym przed publikacją tej informacji napisał maila do Allegro, to dowiedziałbym się, że serwis jest bezpieczny i żadnego ryzyka z jego użytkowania nie ma i nie było. Mam nadzieję, że po tej historii sprawa lekko się zmieni i tak oczywiste błędy będą łatane szybciej, niż w miesiąc!

Bezczynność WP

Nie mogę się nadziwić, iż mimo tak dużego nagłośnienia sprawy i poinformowania WP za pomocą specjalnego formularza, jak do tej pory nie tylko nie dostałem żadnej odpowiedzi, ale również nie ma żadnej reakcji ze ztrony WP. Wykryte przeze mnie błędy nadal działają i otworzenie odpowiednio spreparowanego maila może spowodować przejęcie całkowitej kontroli nad naszym kontem.

Sprostowanie w sprawie Onetu.

Chciałbym wyjaśnić kilka szczegółów. W artykukle dostępnym w dzienniku internauów dostępnym pod tym adresem opisana zauważony przeze mnie problem niestety Pan Marcin Maj (częściowo z mojej winy) nie poinformował o ważnej sprawie. Otóż opisany przeze mnie problem występował również przy zapisywaniu załącznika html na dysk. Chciałem również poinformować, że w tej chwili jest tak, jak autor artykułu opisuje i ten błąd już nie występuje. Przepraszam osoby, które wprowadziłem w błąd swoimi niesprecyzowanymi informacjami.

Niszczycielska działalność Onetu

Onet chyba zareagował na wykryte przeze mnie luki. Chciałem poinformować, że żadna z opisanych na tym blogu luk już w onecie nie funkcjonuje, ale niestety to bezpieczeństwo jest zapewnianie naszym kosztem... Użytkownik wysyłający załącznik html spodziewa się, że odbierze załącznik html, a nie zbiór śmieci. Spójrzmy więc na załącznik takiej treści:
<?xml version="1.0" encoding="iso-8859-2"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="pl-PL">
<head>
<meta http-equiv="Content-type" content="text/html; charset=iso-8859-2" />
<meta http-equiv="Content-Language" content="pl" />
<title> Dokument testowy</title>
<link href="http://server.com/css.css" type="text/css" rel="stylesheet" />
<script src="http://server.com/srcipt.js" type="text/javascript"></script>
</head>
<body>
<div style="color: green; text-align: center;">Test</div>
<p>
<a href="http://validator.w3.org/check?uri=referer"><img
src="http://www.w3.org/Icons/valid-xhtml10"
alt="Valid XHTML 1.0 Strict" height="31" width="88" /></a>
</p>

</body>
</html>
Jak widzimy jest to jak najbardziej poprawny ( przynajmniej z punktu widziena validator.w3.org) dokument XHTML 1.1. A teraz zobaczmy co otrzymamy od Onetu:
<!-- /ad-config/
[ ad-server-002 ]
group: @stats
/ad-config/ -->
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="pl-PL">
<head>





</head>
<body>
<div style="color: green; text-align: center;">Test</div>
<p>
<a href="http://validator.w3.org/check?uri=referer" target='_blank'><img src="http://www.w3.org/Icons/valid-xhtml10" alt="Valid XHTML 1.0 Strict" height="31" width="88" /></a>
</p>
</
Jak widzimy część znaczników została zmieniona (choćby w znaczniku a dodano atrybut target, któgo wcześniej nie było!), a część po prostu usunięta. Oczywiście w przypadku tak prostej strony możemy łatwo naprawić wyrządzone szkody, jednakże w wielu przypadkach taka "naprawa" może nam zająć sporo czasu. Poza tym w przypadku bardziej skomplikowanych stron, które używają dużej ilość CSS, JavaScript, itp uszkodzenia są o wiele bardziej rozległe. Rozumiem w pełni, że Onet musi dbać o nasze bezpieczeństwo, a co za tym idzie o swoją reputację, ale nikt nie dał mu prawa ingerowania w treść naszych maili. Po raz pierwszy spotykam się z tego typu praktyką i mam nadzieję, że zostanie to szybko poprawione. Wysłałem już stosowną informację do Biura Obsługi Klientów, jak tylko uzyskam jakąś odpowiedź, zamieszczę odpowiednią informacje. Narazie zalecam dużą ostrożność w wysyłaniu/odbieraniu załączników htm,html, itp w Onecie.

Kolejne dziury w mbanku i szczegóły załatanej.

Okazuje się, że mbank niepoprawnie przetwarza dane wprowadzone prez użytkownika w adresie URL. Na przykład klikając na taki adres otrzymujemy:














Jak widać wartość zmiennej sAccessFlag nie jest umieszczana w cudzysłowiach, a co za tym idzie możemy wykonać na przykład taki url, czego efektem jest przechwycenie ciasteczka:





Możemy również zmienić kod strony i doprowadzić do XSS poprzez taki link. Oto jego efekt:













Dzięki pomocy Pana Łukasza Lacha byłem w stanie dostosować link również do przeglądarki Firefox. Oto odpowiedni link i efekt jego działania:















Jak możemy więc zaobserwować był to bardzo prosty, ale katastrofalny w skutkach błąd. W napięci oczekuję na załatanie przez mbank pozostałych wykrytych przeze mnie błędów. Narazie mogę powiedzieć, że nie są one, aż tak poważne, ale również powinny zostać naprawione, gdzyż zagrażają klientom tegoż banku. Niczego nieświadomy użytkownik po kliknięciu na odpowiednio spreparowany link zostanie przekierowany na stronę mbanku i jeśli atakującemu uda się w jakikolwiek sposób przekonać go do zalogowania i wykonania dowolnej tranzakcji, to wirus bądź hacker zyska 100% kontroli nad jego kontem, gdyż użytkownik nieświadomie prześle mu wszystie swoje dane, mimo faktycznego "przebywania" na domenie mbank.com.pl! Gdy tylko mBank załata dziurę, opublikuję więcej szczegółów.

Zaniedbania w Codeguru.pl

Codeguru jest to największy w polsce serwis poświęcony technologi .NET, a w ich przypadku dokładniej Microsoft .NET. Ponieważ serwis ten jest nastawiony bardzo pro MS wcale nie zadziwił mnie fakt, że błąd, który posiadają, jak dotej pory, udało mi się wykorzystać jedynie korzystając z IE. I znowu błąd Session Fixation umożliwa przejęcie sesji, co pozwala nam na publikowanie artykułów i wszystko to, do czego ma prawo zalogowany użytkownik. Sprawę jeszcze bardzie ułatwia błąd RSCR, dzięki czemu możliwa jest całkowita kradzież konta. Oto zrzut ekranu:

Błędy w tvp.pl

Największa polska telewizja ma błędy w przetwarzaniu zapytań sql. Dane przekazywane przez użytkownika są bezpośrednio wrzucane do zapytania, bez uprzedniej sanityzacji. Efektem jest luka JavaScript Injection/XSS wykryta przez solenzo. Po przeanalizowaniu tej luki okazało się, iż jest tu możliwe SQL Injection ten link spowoduje błąd ten natomiast wykona się poprawnie
Zamieszczam również zrzuty ekranu, które dostałem:

Aktualizacja w sprawie WP

Pomimo załatania przez WP wykrytej przeze mnie wczoraj luki, okazuje się,iż można ją nadal wykorzystać przesyłając, np taki mail:
<html>
<head>
<META HTTP-EQUIV="refresh" CONTENT="0;url=data:text/html;base64,
PHNjcmlwdD5hbGVydCgnWFNTJyk8L3NjcmlwdD4K">
</head>
<body>
</body>
</html>
Oto zrzut:












Chciałem zastrzec, że błąd ten działa tylko na przeglądarkach: Netscape, Firefox, Mozilla i Opera. Przestrzegam jednak użytkowników IE, ponieważ w WP są jeszcze na pewno błędy dotykające również tę przeglądarkę, a ich odkrycie to tylko kwiestia czasu... Błąd ten tak samo jak poprzedni działa również w Onecie.

Szczegóły na temat Onetu i WP

Okazuje się, że Onet i WP niepoprawnie przetwarząją maile. Zacznę od opisania Onetu. Jeśli otworzy załącznik html o następującej treści:
<html>
<head>
<meta equiv="refresh" content="0;url=javascript:alert(document.cookie);">
</head>
<body>
</body>
</html>

to atakujący dzięki luce JavaScript Injection może się dostać do naszych ciasteczek, co widać na załączonym screenie:











Otrzymane w ten sposób ciasteczka można wykorzystać do przejęcia sesji, dzięki błędowi Session Fixation. Stąd atakujący może zdobyć pełny dostęp do naszej skrzynki, czytać i wysyłać maile, ingerować w listę kontaktów, itp.Może również skorzystać z błędu XSS i załączyć do strony swój własny kod JavaScript, który pobierze dane wg własnego uznania. Co więcej, dzięki wykorzystaniu RCSR możliwe jest nawet przejęcie hasła i loginu użytkownika, jeśli oczywiście użył on funkcji zapamiętywania haseł. W tej chwili błąd ten nie działa na WP, jednakże jeszcze wczoraj portal ten był na niego podatny. Co więcej, na WP wystarczyła próba przeczytania maila do wykoniania skutecznego ataku.

Onet i WP dziurawe jak sito

Chciałem ostrzec wszystkich przed używaniem Onetu i WP. Jutro postaram się udostępnić więcej informacji, czy to na łamach tego blogu, czy w inny sposób. Na razie mogę tylko powiedzieć, że sprawa jest bardzo poważna...

Złe przetwarzanie danych w skryptach gemius.pl

Pisząc o serwisie ranking.pl nie mogłem zapomnieć, iż serwis ten zajmuje się przedstawianiem danych dostarczonych przez firmę Gemius. Przyjrzałem się więc również stronie gemius.pl.
Otóż linki do serwisu mają taką postać: http://www.gemius.pl/Info/sub.php?id=uslugi_mon&idm=uslugi itp. Jak można zauważyć, wartość zmiennej idm jest równa początkowi zmiennej id. Zastanawiamy się więc, po co ktoś miałby używać dwóch zmiennych o takich samych prefixach. Otóż okazuje się, że wartość zmiennej idm jest używana do adresu obrazka, który ma zawsze taką postać: wartosc_idm.jpg. Próbujemy więc to wykorzystać:
ciasteczko:











xss:









I tym razem nikt nie zadbał o bezpieczeństwo internautów.

Błędów w mbanku ciąg dalszy

Mbank wydał właśnie oświadczenie z którego wynika, iż błędy zostały usunięte. Po krótkiej analizie okazało się, że mbank usunął tylko jeden z wielu błędów wykrytych w swoim serwisie. Co prawda został usunięty najważniejszy błąd, ale pozostałe pozwalają na zmianę treści strony mbanku, a w niektórych przypadkach (przy zaangażowaniu użytkownika) pełne włamanie na konto.

Złe przetwarzanie danych w skryptach ranking.pl

Najlepszą polską stroną, poświęconą statystykom Internetu, wg mnie jest www.ranking.pl. W większości przypadków strona ta poprawnie przetwarza dane wysyłane przez użytkownika. Okazuje się jednak, że nie zawsze. http://www.ranking.pl/index.php?page=Content:ContentPage&zone=4abc Po wywołaniu tego linku zostaniemy przeniesieni na stronę informującą nas obłędzie. Okazuje się jednak, że wartość zmiennej zone nie jest w żaden sposób przetwarzana. Korzystając z Javascript Injection możemy więc bezproblemowo dostać się do ciasteczka:
ciasteczko











Czy doprowadzić do XSS:
xss










Jak więc widzimy jesteśmy w stanie zrobić z tą stronką, co nam się żywnie podoba, np. zmienić całkowicie wygląd strony, ładować treści z innych adresów itp. Na te same błędy podatna jest
również międzynarodowa strona serwisu: http://www.rankingcee.com/

Błędy w skryptach mbanku.

Mbank jest pierwszym serwisem, jaki opiszę na tym blogu. Na razie jednak nie publikuję żadnych szczegółów technicznych. Chciałem tylko podziękować Łukaszowi Lachowi i Magdalenie Pogorzelskiej za pomoc. Odsyłam również do lektury hacking.pl.

Tematyka blogu

Tematyką tego blogu będzie poziom zabezpieczeń serwisów internetowych. Skupię się tu głównie na polskich serwisach, gdyż ich poziom jest zatrważający. Polskie serwisy w ogóle nie widzą niebezpieczeństwa w błędach JavaScript Injection, XSS, RCSR, czy Session Fixation. Jest to smutne, gdyż te błędy dotykają nas - użytkowników. Wyobraźmy sobie sytuację, że w przeglądarce IE zostaje odkryta kolejna dziura. Jej efektem są na przykład linki wysłane przez gg, prowadzące zazwyczaj do serwisów typu: http://www.fdstet.com/, których celem jest chociażby zainfekowanie komputera.Łatwo je odróżnić od tych, które są nam już w jakiś sposób znane. Zatem, jeśli dostaniemy link w stylu http://www.sejm.gov.pl/ itp., nasze zaufanie do niego będzie większe i wzrośnie szansa, że na niego klikniemy. Dlatego też serwisy powinny zadbać nie tylko o zabezpieczenie swojego serwisu pod kątem włamań, ale także o zapewnienie bezpieczeństwa użytkownikom. Jeśli bowiem administrator strony np. http://www.sejm.gov.pl/ nie zadba o stosowne zabezpieczenia, jego serwis może zostać wykorzystany chociażby do rozsyłania wirusów lub kradzieży poufnych danych odwiedzającego stronę.Takie podejście do tematu wydaje się dość lekkomyślne. Chciałbym uczulić polskich internautów na ten problem. W tym celu co jakiś czas będę publikował nowe informacje na temat kolejnych stron.
Życzę miłej lektury.