vicidial.org

Posted: **Tue Sep 24, 2013 4:21 pm**

Today, at around 4am PH time. We at GOautodial had encountered an intrusion on our server. Someone was using blind SQL injection on our website. Good thing one of our NOC noticed that our Inbound Group and DID lists were empty and was replaced with SQL queries and ASP functions (attached are screenshots of our vicidial DID list page).

http://imageshack.us/photo/my-images/547/v44z.png/
http://imageshack.us/photo/my-images/833/dkog.png/

After we renamed the vicidial folder, the SQL injection attacks stopped.

Below are the links that we found when searching for clues.
http://cxsecurity.com/issue/WLB-2012090093
http://www.exploit-db.com/exploits/8755/
http://www.securityspace.com/smysecure/ ... 1.0.900916

Posted: **Wed Sep 25, 2013 5:16 am**

Vicidial svn/trunk eliminated these issues a while ago. This is not a problem if you are using recent svn/trunk vicidial.

Posted: **Wed Sep 25, 2013 5:45 am**

unfortunately not

domedan@host:/usr/local/src/vicidial/trunk$ svn up
Är på revision 2022.
domedan@host:/usr/local/src/vicidial/trunk$ egrep -e '\$user|\$agent' www/vicidial/AST_agent_time_sheet.php #removed a few unnecessary lines
if (isset($_GET["agent"])) {$agent=$_GET["agent"];}
elseif (isset($_POST["agent"])) {$agent=$_POST["agent"];}
$user=$agent;
$stmt="INSERT INTO vicidial_report_log set event_date=NOW(), user='$PHP_AUTH_USER', ip_address='$LOGip', report_name='$report_name', browser='$LOGbrowser', referer='$LOGhttp_referer', notes='$LOGserver_name:$LOGserver_port $LOGscript_name |$user, $query_date, $end_date, $shift, $file_download, $report_display_type|', url='$LOGfull_url';";

I guess the other vulnerabilities is still in trunk too:

http://cxsecurity.com/issue/WLB-2012090093 wrote:site.com/AST_agent_time_sheet.php?agent=some-agent' and sleep(15)='&calls_summary=1&query_date=2012-09-07
site.com/AST_timeonVDADall.php?adastats=1&DB=0&groups[]=1345' and sleep(15)='&RR=4
site.com/vicidial_demo/user_stats.php?user=2000' and sleep(10)='

XSS :

site.com/admin_search_lead.php?alt_phone_search=&DB=1&first_name=lskkuuaj&last_name=lskkuuaj&lead
_id=1&list_id=1&log_lead_id=1&log_phone=555-666-0606&phone=555-666-0606&status=1&submit=SUBMIT&a
mp;user=[XSS]&vendor_id=1
site.com/user_stats.php?user=[XSS]
--------------
HTTP Prameter plution:

site.com/./user_stats.php?user=shtuasvb&begin_date=2012-09-07&end_date=2012-09-07{HTPP}
example : /user_stats.php?user=shtuasvb&begin_date=2012-09-07&end_date=2012-09-07&hadi685=sep148

site.com/admin.php?ADD=3&user=someuser{HTPP}
example : ./admin.php?ADD=3&user=hadi&sep18=tell15

The blind sql injection on DID is interesting, where do they execute them? is it sip invites on port 5060 or is it on the web-server?

Posted: **Wed Sep 25, 2013 6:51 am**

Just to note, none of those will work unless you have a valid administrative user through HTTP authentication. And for several months the code has been in svn/trunk that prohibits brute force auth attacks.

Of course, if you have a valid admin account, you can do a lot more damage than with an SQL attack.

Posted: **Wed Sep 25, 2013 7:05 am**

True, still serious if a manager goes berserk or if the input is bad, just a comma would create a error with the query.
Or a agent could play a little bobby tables:

All input should be sanitized in my opinion.

But what about the DID blind sql injection?

Posted: **Wed Sep 25, 2013 8:17 am**

Sanitizing all input in every script would take a very long time to implement, but we have taken care of the most vulnerable ones.

If your Manager goes berserk, you will have much bigger problems, since they could effectively delete everything in your system anyway.

As for DID SQL injection attacks, haven't heard of that one yet, but it shouldn't be too hard to clean the extension of quotes, spaces and semi-colons, without which SQL injection attacks are not possible. Only a few AGI scripts need to be altered to do this. I'll see if I can add that this morning.

Posted: **Wed Sep 25, 2013 8:37 am**

mmixx: dude, post your apache access_log for this!

Posted: **Wed Sep 25, 2013 8:42 pm**

Just added fixes for those documented SQL injection attack issues(which you have to be a manager to execute)

I also added some new DID SQL injection attack filters as well, those were tricky to test, but they do work.

These are now committed in svn/trunk and are tested in production with live calls.

Posted: **Fri Nov 29, 2013 4:34 am**

I just came across this blog post. http://adamcaudill.com/2013/10/23/vicid ... abilities/
Is it true that vicidial hosting clients are on a newer version then the latest SVN trunk?

Posted: **Fri Nov 29, 2013 5:07 am**

Just looked at one of the issues that Adam Caudill posted "$server_ip in agc/manager_send.php"
this is from the svn trunk:

2013-06-15 16:08 mattf Added several security changes to the agent interface,
+$session_name = preg_replace("/\'|\"|\\\\|;/","",$session_name);
+$server_ip = preg_replace("/\'|\"|\\\\|;/","",$server_ip);

So it was fixed 2013-06-15
I guess that Adam looks at the sourceforge page for the latest code, because there the last release is astguiclient_2.7rc1.zip from 2013-05-09

the sourceforge page should probably be updated,
but Adam should be aware of the svn if he is "...a software developer, security researcher & pen-tester"

Posted: **Fri Nov 29, 2013 10:10 am**

Adam is aware, I have had several email conversations with him about this, and he was very helpful. He is aware of the svn/trunk codebase, but in the security world they are focused on releases, which is why the alert was posted in that way.

Posted: **Sat Nov 30, 2013 3:07 am**

Also worthy of note is that if you use a whitelist IP system (pure lockdown or managed with something like our Dynamic Good Guys), the access to these vulnerabilities is limited to those IPs which you have approved to have access to your system.

So when these are repaired for everyone ... and a hacker finds another vulnerability ... be sure you're locked down so only your friends have access. Keeping hackers out of that friend group of authorized IPs is also good. 8-)

vicidial.org

VICIDIAL Blind SQL Vulnerability

VICIDIAL Blind SQL Vulnerability

Re: VICIDIAL Blind SQL Vulnerability

Re: VICIDIAL Blind SQL Vulnerability

Re: VICIDIAL Blind SQL Vulnerability

Re: VICIDIAL Blind SQL Vulnerability

Re: VICIDIAL Blind SQL Vulnerability

Re: VICIDIAL Blind SQL Vulnerability

Re: VICIDIAL Blind SQL Vulnerability

Re: VICIDIAL Blind SQL Vulnerability

Re: VICIDIAL Blind SQL Vulnerability

Re: VICIDIAL Blind SQL Vulnerability

Re: VICIDIAL Blind SQL Vulnerability