Jump to content

SQLi Vulnerability


davet

Recommended Posts

I was going to open a ticket about this but the site is down, so thought I'd post here instead.

 

I'm seeing all sorts of new Tweets within the last 20 minutes in regards to a new script that will check for WHMCS Blind SQLi vulnerabilities that many still are claiming affects the new version. I thought that vulnerability was patched in the latest version but according to a lot out there that is not necessarily true.

 

Is this still a known issue in WHMCS?

Link to comment
Share on other sites

  • WHMCS CEO

Our site is online and functioning. But we have not had any SQL vulnerability in recent times or had to issue any patches for them. The latest security issue of December 2011 was related to smarty templating, and the one before that middle of last year was file related.

 

It's impossible to ever rule these things out. But hopefully as our previous history shows, if we are made aware of security issues we do issue patches for them, and so rest assured if any do get discovered, we'll be here and available to do the same again.

 

Matt

Link to comment
Share on other sites

Any clue if running that script will harm our install? Is it a legitimate script for finding vulnerabilities?

 

I was curious and wanted to run it but it looked suspicious so thought I would check here first.

Link to comment
Share on other sites

  • WHMCS CEO
I am seeing some strange things going on our whmcs and have found some nasty scripts. Im not convinced the issue is over.

Not going to post here.

 

If you haven't already, please open a ticket with all the details you have, and mark it for my attention, and we'll get that checked into immediately.

 

it's worhless crap...

 

We certainly hope this is the case. But at this moment in time, what is being rumoured to exist does not appear to have been disclosed. It would be irresponsible of us to say it doesn't exist, unknown security issues can crop up in any software, at any time, and so can never be ruled out for definite. But we're keeping a very close eye on things.

 

Matt

Link to comment
Share on other sites

I am seeing some strange things going on our whmcs and have found some nasty scripts. Im not convinced the issue is over.

Not going to post here.

 

If you're seeing nasty scripts, get CXS at http://configserver.com/cp/cxs.html installed to your server immediately. It has been a lifesaver for us on our hosting servers.

 

It watches the file system, FTP and HTTP for any suspicious scripts and quarantines them immediately. It can also be setup with CFS (firewall) to automatically block IPs that trigger mod_security rules.

 

CXS emails us alerts as well which has been helpful with blocking and investigating abusive users and IPs.

 

As for securing WHMCS follow these Further Security Steps at http://docs.whmcs.com/Further_Security_Steps

 

We're also routing all traffic for our WHMCS site through a CloudFlare Pro account. If you use cloudflare delete the direct link DNS entry for your domain. Also start making it a habit of blocking the Alerts you see in Threat Control.

 

We also password protected our Sales contact form, added a Register link to the login.tpl template, and monitor new user registrations to see if any look suspicious.

Edited by davet
Link to comment
Share on other sites

We have already done all of that. However we only did the further steps today,

Matt = Ticket ID: 647277

 

Also in CSF (ConfigServer Security & Firewall) go to Check Server security and fix as many warns there that you see.

 

If you have CXS (ConfgServer eXploit Scanner) installed you should not be seeing any nasty scripts in your file system. If you are, they could be new infections that CXS doesn't know about. We did find one of these a few weeks ago on a site and had to create a md5 fingerprint for the infections. Here are instructions from CXS on how to do this:

 

=========================

You will need the actual file(s), but you can create your own md5 fingerprint so that cxs will quarantine it with the M option. Otherwise you will have to also enable quarantining of all regular expression matches, which will most likely give you a lot of false positives.

 

First you should run cxs directly against the file and ensure that it is NOT detected by either the fingerprint or virus option. I.e.:

 

cxs --options Mv /path/to/file

 

If it is not detected, you can submit the files to us using the --wttw option and we will examine them to determine whether they should be added to the fingerprint database. Alternatively, you can create your own fingerprints for them - information is in the cxs documentation under the option --MD5.

 

For example, if you have a file called exploit.php that you want to add to the fingerprints, do the following:

 

md5sum exploit.php

 

You'll get something like this:

 

28f2623f836e5376bbd81782fda1be29 exploit.php

 

Add the following to /etc/cxs/cxs.xtra:

 

md5sum:28f2623f836e5376bbd81782fda1be29

 

And make sure that you add this to your command line in the cxs script files that you are using for scanning (cxsftp.sh, cxscgi.sh, cxswatch.sh):

 

--xtra /etc/cxs/cxs.xtra

=========================

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use & Guidelines and understand your posts will initially be pre-moderated