Thursday 29 September 2011

Stored XSS in phpMyAdmin 3.4.5-all-languages *update*17.10.2011*

Like I said in one post below, few days ago I wrote my own source code security scanner.
Yesterday it found a new 'possible insecure' parameter in new phpMyAdmin (3.4.5).
Here is a quick note about it:

1. goto http://phpMyAdmin-3.4.5-all-languages/setup/index.php
2. Go to 'New server'
3. vulnerable is (could be) $value, be cause:
when you type 'Save' PMA is going to:
http:///phpMyAdmin-3.4.5-all-languages/setup/validate.php (here is $value param).
Content of thi $param should be:

(... this is 'name of the server')
btw: doing research using Data Tamper I check the vulnerable parameter is $Servers-0-verbose in PMA/setup/index.php.
Anyway I dont saw any of this in PMA/setup/index.php (or either in all *.php files located in PMA directory.
So next I decide to search via grep:

so I think vuln is right here ;)

Testing is in progress, so this post will be updated soon...

2.10.2011 * So update here *
It looks like PMA does not validate some "Server-*" parameters.
Vulnerability exist in :
Server-0-verbose <-here will be XSS (upper in this post)
Server-0-host <- here will be vulnerable too

File ./setup/validate.php contains unpropper validation for $value.
Code of XSS placed here is forwarded to ./setup/index.php as a parameters.
And whats next:

to parameters AFTER You click 'Forward' for validate.php try to put the same value (script,etc...) to ./setup/index.php :)


Update: released the patch for this vuln. Check it out, and try a new version of this amazing webapplication :)

Details here .

*** Important thing *** I really recommend cooperation with PMA Team. People know what they're doing, and doing it fast! Good job! :)

Wednesday 28 September 2011

phpMiniAdmin 1.7 vulnerable to SQL Injection and more...

Today I finished 'version 4' of one of my python project: a PHP source code scanner.
I decided to run it against some simple web application.
Found one of course at : phpMiniAdmin (1.7.110429).

For a few seconds program found few interesting possiblility of vulnerabilities existing in scanned php.
One from the list is possible SQL Injection attack:

--- cut phpminiadmin.php ---
130 function do_sql($q){
--- cut ---

So for a quick-test, type for $q= some'thing, and see whats happen?

Other one is unpropper validation of the same parameter ($q), but this time, is XSS:

I know this web application isnt something like Fusion CMS or ect... Im just happy, the code is working;)

Tuesday 27 September 2011

Enticore CMS (0.8) vs 24.09.2011

Once upon a day I decide to sit back and enjoy a few moments of ‘free time’ spending for vulnerability research in some popular CMS applications.

First I’ve found Enticore CMS 0.8 ( avaliable at ).
I decide to download it and install in my lab-box :)

To make this news more precisely:
„the lab” configuration was: Ubuntu 10.10 with Apache 2.2.16, and PHP 5.3.3. One more important think is that, I set display_errors = On
in php.ini file.

So first what I’ve done was install it on my test lab.
Nothing special in this process but here I found first Cross Site Scripting vulnerability.

1) Cross Site Scripting in ‘install.php’:
Here we go: when we set „include/external/” to 777, we can click to the „next step” of installation process. Our link will be:


First I tried to make some ../ request for $page parameter, but there was ‘only’ an error:
‘Notice: Undefined index: ../ in ./enticore-0.8/install.php on line 66 Fatal error: Call to
a member function getPage() on a non-object in ./enticore-0.8/install.php on line 67 ‘

Ok, so lets see, what is behind line 66-67:
63 function getPage($page) {
64 global $installationSteps;
66 $installationStep = $installationSteps[$page]['item'];
67 $retval = $installationStep->getPage();

We must definetly choose one of the ‘item’. So I tried to ‘choose’ item, that not exist.
For example: testujto:

Notice: Undefined index: testujto in (…) line 66.

Ok. Once again, error output informed me, that ‘item’ I decided to use is placed ‘like I wrote it’ in $page parameter.

So next test will be simple

And here we have our ‘Cross Site Scripting vulnerability’. Checked in source (view source) looks like this:


So vulnerability exist, and there is a possibility to send malformed URL to the victim with JS/HTML payload.

PoC could look like this:

2) XSS in ./include/plugin/EnticorePluginUsers.php
241 return Helper::getMessage(‘warn.png’, _(‘Login incorrect, please try again.’)).$this->getLoginForm($_POST['username']);

Vulnerability founded here is the same. Enticore not properely validate user input.
So we have another one Cross Site Scripting:
POST http://enticore-0.8/index.php?plugin=EnticorePluginUsers&site=login
$username=you <— try to put here some POST values, for example y0

Remember, this vulnerable was checked with „display_error = On”! (Some more info about errors in webapps, maybe soon...;))
3) Vulnerabilities for ‘Logged only’.
Now is time for searching some vulnerabilities for logged users. First one has been found for $site parameter.
(Default password for admin is ‘enticore’.)

PoC :
(GET send to logged user) http://enticore-0.8/index.php?plugin=EnticorePluginUsers&site=’>test
Vulnerable code:

/enticore-0.8$ cat -n ./include/plugin/EnticorePluginUsers.php | grep site
32 * @see include/plugin/EnticorePlugin#getMenuEntries($site)
34 public function getMenuEntries($site) {
38 array_push($retval, array(‘uri’ => $this->generatePluginPart(‘admin’),
‘site’ => ‘admin’, ‘name’ => _(‘Administrate users’), ‘css’ => $this->getSelectedCss(‘admin’)));
40 array_push($retval, array(‘uri’ => $this->generatePluginPart(‘logout’),
‘site’ => ‘logout’, ‘name’ => _(‘Logout’), ‘css’ => $this->getSelectedCss(null, $site != ‘admin’)));
43 array_push($retval, array(‘uri’ => $this->generatePluginPart(‘login’),
‘site’ => ‘login’, ‘name’ => _(‘Login’), ‘css’ => $this->getSelectedCss(null, $site != ‘admin’)));
49 public function getContent($site) {
50 if ($site == ‘login’) {
52 } else if ($site == ‘logout’) {
54 } else if ($site == ‘admin’ || $site == ‘show’) {
56 } else if ($site == ‘add’) {
58 } else if ($site == ‘edit’) {
60 } else if ($site == ‘delete’) {
63 return get_class($this).’: Unkown site ‘.$site;

I uderstand this vuln as: get_class is no properly validated, so the PoC can be placed in line 63 of EnticorePluginUsers.php.
Payload for test could be: ‘>testtest2 or whatever you want in HTML/JavaScript.

You should already knew, if there will be something like:
(…) switch { if 1 then… if 2, then…, else if anyDifferentSiteValue, and here else Default } (…)
the vulnerability should not exist. So think about it how You write your if/else part of code;)

4) DB password stored in clear-text.
mysql> use enticore;
Database changed

mysql> select * from ec_users limit 1;
| idx | username | password | encryption | email | name | status |
| 1 | admin | enticore | plain | | Enticore Administrator | 1 |
1 row in set (0.00 sec)


Very, very nice! :)

5) Shell upload is possible.
Enticore CMS has a nice page for uploading files via web browser when You’re logged.
First, what „bad hackers” do is trying to upload some kind of shell in PHP, to better
remote access. When we upload a shell in php (shell.php), Enticore, puts in in $webroot/content/shell.php.
File is accessable via web browser, so for this time is game over.
Good practice here is to think about what kind of files could and should be possible to upload.

6) Directory traversal attack (for logged only):

I looked at the source of this CMS and there is opendir() function. Like I thought, we can do a directory traversal attack :



Be cause of vulnerability in source code:

— cut include/helper/Helper.php —

$ cat -n include/helper/Helper.php | grep opendir
109 if ($handle = opendir($dir)) {
139 if ($handle = opendir($dir)) {
301 $handle = opendir($path.’/');

— cut include/helper/Helper.php —

7) stored XSS in http://enticore-0.8/index.php?plugin=EnticorePluginConfiguration
Try $title too. It is vulnerable to stored xss attack… ;)
Testing in progres...

WordPress 3.2.1 user enumeration vulnerability

Like we all know, not only banks have an user enumeration vulnerabilities in their webapplications :)
Almost all the time „user enumeration” is possible, be cause of bad informing about ‘wrong credentials’ in login process.
So, lets see how it lookgs in new WordPress (3.2.1).

(In pseudo code):

if user_ok --> echo 'user ok'
else if user_bad --> echo 'username invalid'
So thats the simple way to enumerate users (bruteforce as welcome) ;)
Here I wrote a simple tool, to check if there is an admin account:

Like You see, this simple tool can enumerate only ‘admin’. So the idea is simple. Check if there is a name(wordlist?;) ), and if it is – analyse/log the answer.


*Update 12.03.2012*
If You want more information about vulnerabilities in latest WordPress,
try here ;) - inspired by catonman

I have been searching about 'how to automate searching in net' and then I found really interesting thing. I saw On this site, author wrote a nice "hack" for implementing a kind of 'google-searchr code' in python. I thought about possibilities which its gave me. And thats how I wrote...

# :
# : @ 13.o6.2o11
# :
# : 20.o6 : dodane ua
# : 15.o6 : dodane spanie na googlu
# : 14.o5 : dodane logowanie + edit
# : 13.o5 : dodane szukanie v1
# :
# :
from import GoogleSearch, SearchError # szukanie
import sys # argz
import socket # gniazda
from time import sleep # spanie na googlach
from urllib import FancyURLopener # UAaaaaaaa ;-)
if len(sys.argv) < 2:
print ‘\n-=[ searcher ]=-\n’
print ‘usage: python what2find…\n’
gs = GoogleSearch(sys.argv[1])
gs.results_per_page = 100
results = []
while True:
tmp = gs.get_results()
for res in results:
print res.url.encode(„utf-8″) # wyswietla tylko urla
if not tmp: # brak wynikow
# wyjatki/bledy
except SearchError, e:
print „Search failed: %s” % e

Its of course just a simple example and was made for fun only. Anyway I wish You luck in python learning and programming.
- sths wrong with searching (google drop some request; sleep()?)
- make searching more ‘unix style’ – uniq to implement
- add google hacks (filetype, etc)

Drugi post

Zobaczmy :)