Kryptronic Software Support Forum

You are viewing this forum as a guest. Login to an existing account, or create a new account, to reply to topics and to create new topics.

#1 12-15-2008 16:26:40

Blitzen
Member
From: USA
Registered: 01-01-2005
Posts: 935

PCI Failure - Please help.

I am getting a PCI failure due to the call to msySQL db being vulnerable to an injection attack. This is in the CCP5 software somewhere.

Where/how do I address this error?

Here is what they reported. Please help.

Possible SQL injection database error on http://www.mysite.com/cgi-bin/cp-app.cgi
Use the following commands to verify this:
wp --inject "http://www.mysite.com/cgi-bin/cp-app.cgi?searchstr=&searchrpp=20%22%3E%3Cscript %3Ealert%28123%29%3C%2Fscript%3E&searchtyp =ALL&rrc=N&rnd=6637862&pg=ste_search_resul ts" POST curl -L -d "searchstr=&searchrpp=20%22%3E%3Cscript%3 Ealert%28123%29%3C%2Fscript%3E&searchtyp=A LL&rrc=N&rnd=6637862&pg=ste_search_results" ; "http://www.mysiite.com/cgi-bin/cp-app. cgi"| grep "You have an error in your SQL syntax"
This website may have other injection related vulnerabilities.

Last edited by Blitzen (12-15-2008 16:27:38)

Offline

 

#2 12-15-2008 17:11:25

rachaelseven
Member
From: Massachusetts, USA
Registered: 01-23-2006
Posts: 3169
Website

Re: PCI Failure - Please help.

I have no idea.  I had to do a few things on ours to get PCI compliance, but nothing that seemed even remotely like that.  When I try to use that command on my site, all I get is an error message that GET is not implemented on cp-app.cgi.  Perhaps our server runs tighter security or something.  At any rate, I'd say this deserves the services of a professional, and since Kryptronic will no longer support v5.1, I'd say you need to get in touch with Stephen at CartMod.com.  Good luck!


Rachael Katz
- Custom Focusing Screens for DSLR Cameras

Offline

 

#3 12-29-2008 15:08:05

Blitzen
Member
From: USA
Registered: 01-01-2005
Posts: 935

Re: PCI Failure - Please help.

Can you tell me where the field inputs are first parsed? Exactly where in the program are the input fields from the form elements read?

p.s. Rachel, Your site should fail because of this. Go to your checkout and enter this in a field (It's benign):

Code:

"><script>alert(123)</script>

Who did your PCI test? They missed it this time.

Last edited by Blitzen (12-29-2008 15:13:41)

Offline

 

#4 12-29-2008 15:15:50

Dave
Member
Registered: 07-05-2003
Posts: 11233

Re: PCI Failure - Please help.

Interesting to say the least.  Putting that in all of the fields except zip code and e-mail address results in the alert sad

Offline

 

#5 12-29-2008 15:19:30

Blitzen
Member
From: USA
Registered: 01-01-2005
Posts: 935

Re: PCI Failure - Please help.

Yes, Dave. That's why my CCP5 site is failing PCI test. They call it an "injection" or "cross-scripting" attack.
The "Search" input fields are vulnerable as well.

Is there one place where the input is inspected?

Last edited by Blitzen (12-29-2008 15:24:09)

Offline

 

#6 12-29-2008 15:19:53

rachaelseven
Member
From: Massachusetts, USA
Registered: 01-23-2006
Posts: 3169
Website

Re: PCI Failure - Please help.

It depends on which form element.  The URLs they provided seem to be heading toward the search results page, I would say you'd be looking at ste_prod.pl.  It would appear that they are trying to inject their SQL into the searchrpp variable, which is pulled from the form field in this line (around line 32 in the original file):

Code:

$fd_searchrpp = $q->param('searchrpp');

It is immediately followed by a formatting line that limits it to a floating point number though, so it should already be safe.  But if you wanted to really lock it down, I suppose you could use a line with a regex somewhere after that to strip out anything dangerous... perhaps script tags.  Something like this maybe?

Code:

$fd_searchrpp =~ s/script//gsi;

Like I said though, it's already formatted by a sprintf command, limiting it to a number, so I really don't see how that SQL injection could work at all.  At any rate, the subroutine ste_prod_disp looks to be the only place those variables are populated, so that's where I'd go to try to lock them down.


Rachael Katz
- Custom Focusing Screens for DSLR Cameras

Offline

 

#7 12-29-2008 15:21:16

Blitzen
Member
From: USA
Registered: 01-01-2005
Posts: 935

Re: PCI Failure - Please help.

Hi Rachel,

That might cover the search box, but we need to sanitize the checkout inputs as well.
Ditto for any product that uses a text box or text area.

We need to sanitize all special characters, not just "script" which was used as xml. Hackers can use other xml synatax for a real attack.

Last edited by Blitzen (12-29-2008 15:22:05)

Offline

 

#8 12-29-2008 15:23:50

rachaelseven
Member
From: Massachusetts, USA
Registered: 01-23-2006
Posts: 3169
Website

Re: PCI Failure - Please help.

Well then we've got several different places to work on.  Text field for the products will be handled in ste_cart.pl and the checkout form fields will be handled in ste_chkout.pl.  Let me see if I can tighten that up a bit and get something back to you.


Rachael Katz
- Custom Focusing Screens for DSLR Cameras

Offline

 

#9 12-29-2008 15:24:15

rachaelseven
Member
From: Massachusetts, USA
Registered: 01-23-2006
Posts: 3169
Website

Re: PCI Failure - Please help.

For the record though, you can't actually inject anything that way... popping up an alert on your own computer is about the worst you can do.


Rachael Katz
- Custom Focusing Screens for DSLR Cameras

Offline

 

#10 12-29-2008 15:24:44

Blitzen
Member
From: USA
Registered: 01-01-2005
Posts: 935

Re: PCI Failure - Please help.

How about if we just write a little parsing routine that we can call?

p.s. The special characters in the page source need to be sanitized. All user input needs to be validated.
"All input from web browsers, such as user data from HTML forms and cookies, must be stripped of special characters and HTML tags as described in the following CERT advisories:

CERT advisory 97.25.CGI
    http://www.cert.org/advisories/CA-1997-25.html
CERT advisory CA-2000-02
    http://www.cert.org/advisories/CA-2000-02.html

This is by far the most common vulnerability in web applications. Everything from directory traversal problems to cross-site scripting problems can usually be traced to the simple lack of proper stripping of user input. "

Offline

 

#11 12-29-2008 15:26:26

Blitzen
Member
From: USA
Registered: 01-01-2005
Posts: 935

Re: PCI Failure - Please help.

rachaelseven wrote:

For the record though, you can't actually inject anything that way... popping up an alert on your own computer is about the worst you can do.

The test was benign. It's xml and can get worse.
http://www.cert.org/tech_tips/malicious_code_FAQ.html
http://www.cert.org/tech_tips/malicious … ation.html
I'm taking the snippet from the above url and putting it at the end of ste_form.pl as
so that you can use dashes in the product/category id.
So far, this is working ... for me ... so far.

Code:

# From http://www.cert.org/tech_tips/malicious_code_mitigation.html
#! Use a list of bad characters to filter the data
sub form_FilterPos {
    local( $fd ) = @_;
    $fd =~ s/[\<\>\"\'\%\;\)\(\&\+]//g;
    return( $fd ) ;
}

Now, as the form data come in, we can apply the above filter something like this where $inputdata is the parameter coming in.

Code:

$inputdata = form_FilterPos($inputdata);

Can we compile a list of where the form elements come in? Rachel has one in the search routine.

Last edited by Blitzen (12-29-2008 15:55:38)

Offline

 

#12 12-29-2008 15:35:11

Dave
Member
Registered: 07-05-2003
Posts: 11233

Re: PCI Failure - Please help.

Like Rachael said, there's very little, if anything, that could be done without cleaning up the input fields some more.

Offline

 

#13 12-29-2008 15:48:07

rachaelseven
Member
From: Massachusetts, USA
Registered: 01-23-2006
Posts: 3169
Website

Re: PCI Failure - Please help.

It can clearly be done with some input filtering - I wouldn't take that particular approach, since you make it impossible to include any punctuation in addresses, which is definitely necessary.  But you could certain strip %,<,>, and & characters without too much trouble.  That should render any script impotent.  It's straightforward enough to implement and I will probably do it on my site, but I am not prepared to accept the liability for providing this particular solution in a public forum.  I'm sorry, but I have to punt on this one.  I advise professional assistance.


Rachael Katz
- Custom Focusing Screens for DSLR Cameras

Offline

 

#14 12-29-2008 16:04:17

rachaelseven
Member
From: Massachusetts, USA
Registered: 01-23-2006
Posts: 3169
Website

Re: PCI Failure - Please help.

I will say, just by way of pointer, that if you have a look at the subroutine ste_usr_check, in ste_usr.pl, you have the opportunity there to sanitize everything related to the user's information (all the stuff that is stored in the cookie) in a single location.  That pretty well takes care of most of the checkout and the contact us forms in one shot.  You'd still need to deal with product text box options, search strings, and a handful of variables in the checkout that aren't stored in the cookie, but ste_usr.pl will get you 90% of the way there.


Rachael Katz
- Custom Focusing Screens for DSLR Cameras

Offline

 

#15 12-29-2008 16:40:34

Blitzen
Member
From: USA
Registered: 01-01-2005
Posts: 935

Re: PCI Failure - Please help.

Thank you for the lead, Rachel. Have you found other places?

Offline

 

#16 12-29-2008 16:58:19

Dave
Member
Registered: 07-05-2003
Posts: 11233

Re: PCI Failure - Please help.

Blitzen, a side question.  Why are you trying to achieve PCI compliance on a CCP site?  CCP does not store any "sensitive" information and never has.

Offline

 

#17 12-29-2008 17:31:29

rachaelseven
Member
From: Massachusetts, USA
Registered: 01-23-2006
Posts: 3169
Website

Re: PCI Failure - Please help.

ste_mail.pl has the contact form information.  Search form we've already covered.  Product options in ste_cart.pl.  And a handful of miscellaneous form variables (additional information, shipping comments, and a few others) in ste_chkout.pl.  Again, I'm not warrantying this as any sort of complete list or solution, but those are the ones I've found so far.

Edit to add dynamic forms in ste_form.pl.

Edit to mention that the only field not checked on the contact form is the actual message itself.  And you might want to think a bit about what you actually want to strip from that, since the data will only be emailed and never displayed in the browser or entered into the database.

Last edited by rachaelseven (12-29-2008 17:50:33)


Rachael Katz
- Custom Focusing Screens for DSLR Cameras

Offline

 

#18 12-29-2008 17:54:18

Blitzen
Member
From: USA
Registered: 01-01-2005
Posts: 935

Re: PCI Failure - Please help.

Hi Rachel,

Thank you. I'm not concerned with password protected areas in Admin. The scans and customer hackers shouldn't have access to those areas. I've disabled the site email a friend and contact us forms because they weren't robust.

I think this should cover it.

Have a wonderful New Year's celebration!

Last edited by Blitzen (12-29-2008 17:56:04)

Offline

 

#19 12-29-2008 18:13:13

Blitzen
Member
From: USA
Registered: 01-01-2005
Posts: 935

Re: PCI Failure - Please help.

Dave wrote:

Blitzen, a side question.  Why are you trying to achieve PCI compliance on a CCP site?  CCP does not store any "sensitive" information and never has.

Dave,
You're right, we don't electronically store it.

So, why is this required? My merchant account requires it and is testing my site right now. They will test my site quarterly.

PCI compliance is required for us because my website does collect credit card data as well as customer data at my domain via SSL. The website doesn't redirect to another website and collect the cc data there (the cc data is collected at my domain). Our website connects directly to the processing site that sends cc data it collected to the cc processing site, and that site returns benign data on whether or not the transaction is okay. (You probably know this but I'm detailing it for others.).

Thus, the forms on my website need to be secure as secure can be. I guess they envision some day a hacker coming in, say through the search form input, laying down a bug (memory or disk), listening in on the connection, and grabbing cc data. Imagine where we were only 3-5 years ago with security. The numbers of ways to hack seem to be exponentially increasing. Think about computer viruses that are only a couple bits large that can do mega damage that we never envisioned 10 years ago.

My merchant account provider needs to confirm that we treat the cc data securely even though it connects directly to the cc website.

We take phone orders and answered a questionnaire about how we treat it for those orders.

It's a pain in the derrière but I support this compliance all the way.

p.s. My CCP6 passed the first round smile. They're re-testing it now.

Last edited by Blitzen (12-29-2008 20:51:24)

Offline

 

#20 12-29-2008 19:35:26

rachaelseven
Member
From: Massachusetts, USA
Registered: 01-23-2006
Posts: 3169
Website

Re: PCI Failure - Please help.

UPDATE: Users with this concern are strongly advised to use the official update released to address this issue.  These failures are false positives on the automated tests, but were nevertheless addressed by Kryptronic in an official update.  The code below is for educational purposes only and the Kryptronic update should be considered the official solution.  The update may be found at:

https://forum.kryptronic.com/viewtopic.php?id=12172

----------------------------------------------------------------------------------------------------

In the interest of sharing with the community and furthering our knowledge of this codebase, I am going to detail what I did with this.  However, I want to make the disclaimers very clear for all who might read this in the future.

1. I am not an employee of Kryptronic.
2. This solution has not been reviewed nor endorsed by Kryptronic.
3. Neither I nor Kryptronic makes any representation as to the completeness, security, or suitability of this mod.
4. In other words, THIS IS AN UNOFFICIAL MOD AND NO ONE WILL TAKE ANY RESPONSIBILITY FOR IT EXCEPT YOU!!!

So please, back up your entire site and check your functionality carefully.  Hopefully this will help get you past the script vulnerability check of the PCI compliance people, but even if it does, please do not let it lull you into any false sense of security.  All I can say is that this seems to work on my site, but I make no claims any further than that.  I am really quite serious about this disclaimer - this is not boilerplate at all.  This mod messes with most of the deepest core files of the software and may or may not have the desired results.  And it could have any amount of unknown side effects.  I am only documenting what I did for posterity here and nothing more.  Make of it what you will.

Here are the changes I made (hat tip to Blitzen for the idea to make a subroutine for the input scrubbing).

1. I added a new subroutine in vars.pl.  I liked it in there, because there are similar URL encoding routines in there.

Code:

#######################################################################
# Vars Scrub                                                          #
#######################################################################

sub vars_scrub {

#########
######### The following routine scrubs user input to eliminate 
######### script injection attacks.
#########

my $return_value = shift;

$return_value =~ s/[\<\>\"\%\;]//gs;

return "$return_value";

} ######### End of subroutine.

2. I called the new routine from two locations in ste_cart.pl to scrub text fields in product options.

a. Line 1720:

Code:

$field_value = $q->param($form_id);
$field_value = vars_scrub($field_value);

b. Line 2304:

Code:

$field_value = $q->param($form_id);
$field_value = vars_scrub($field_value);

3. I called the new routine from 4 locations in ste_chkout.pl to scrub checkout fields other than the main name/address ones.

a. Line 1736:

Code:

$trackitem_shipcomment = $q->param('trackitem_shipcomment');
$trackitem_shipcomment = vars_scrub($trackitem_shipcomment);

b. Line 1740:

Code:

$tracking_discountcode = $q->param('tracking_otherdisc');
$tracking_discountcode = vars_scrub($tracking_discountcode);

c. Line 1914:

Code:

$fd_fd = $q->param($id);
if ($display_type eq "TEXTBOX" || $display_type eq "TEXTAREA") {
  $fd_fd = vars_scrub($fd_fd);
} ## endif

d. Line 2331:

Code:

$trackitem_shipcomment = $q->param('trackitem_shipcomment');
$trackitem_shipcomment = vars_scrub($trackitem_shipcomment);

4. I called the new routine from 1 location in ste_form.pl at line 516 to scrub data input into the dynamic forms:

Code:

$fd_fd = $q->param($id);
$fd_fd = vars_scrub($fd_fd);

5. I called the new routine from 1 location in ste_prod.pl at line 118 to scrub data entered in the search box:

Code:

$fd_searchstr = $q->param('searchstr');
$fd_searchstr = vars_scrub($fd_searchstr);

6. I called the new routine form 2 locations in ste_usr.pl to scrub all the main name/address stuff (everything that's stored in the cookie).

a. Line 540:

Code:

$temp_fd_value = database_format($temp_fd_value);
$temp_fd_value = vars_scrub($temp_fd_value);

b. Line 780:

Code:

$temp_fd_value = database_format($custacct_value);
$temp_fd_value = vars_scrub($temp_fd_value);

That's all the locations I can find for now that seem to need scrubbing.  I decided the content of the contact us form doesn't need scrubbing beyond what I've already done to limit HTML and spam, since there is no vulnerability there from displaying or storing the message contents.  You could reasonably disagree, in which case you'd need to work on ste_mail.pl.  It's also possible that you might need to scrub other search variables, including startrow, searchrpp, and searchtyp from ste_prod.pl.  Other system variables such as fd_pg, fd_rrc, fd_ref, and fd_affiliate also probably share a similar vulnerability (limited as it is), but would need to be dealt with by a somewhat different technique.  To this point, I have only dealt with places that users are  to input things, not everything you could possible do with funky URLs.  And there might very well be some user inputs I've missed besides - again with the big disclaimers - I DO NOT GUARANTEE, NOR EVEN SUGGEST THAT THIS MOD IS SAFE, PROVEN, OR WILL HELP WITH YOUR PCI COMPLIANCE PROBLEM!!  Also, for the record, my files are so hacked up from all my mods that my line numbers were meaningless.  So these line number references are based on the original zip file I downloaded.  If subsequent official or unofficial mods altered your line numbers, you've got a bit of hunting to do.  I can help you find the spots and I'm more than willing to continue the dialogue on the subject, as long as no one assumes that I have any particular expertise here - this is way beyond my pay grade (which again, for the record, is zero as far as CCP is concerned).

Last edited by rachaelseven (12-30-2008 08:44:27)


Rachael Katz
- Custom Focusing Screens for DSLR Cameras

Offline

 

#21 12-29-2008 20:00:24

rachaelseven
Member
From: Massachusetts, USA
Registered: 01-23-2006
Posts: 3169
Website

Re: PCI Failure - Please help.

UPDATE: Users with this concern are strongly advised to use the official update released to address this issue.  These failures are false positives on the automated tests, but were nevertheless addressed by Kryptronic in an official update.  The code below is for educational purposes only and the Kryptronic update should be considered the official solution.  The update may be found at:

https://forum.kryptronic.com/viewtopic.php?id=12172

----------------------------------------------------------------------------------------------------

As a related topic, here is how I dealt with the session variables.  Same disclaimers as above - this is only a report on what I've done on my site and nothing more.  I make no claims as to the suitability, usefulness or safety of this code!

1. I added a new subroutine in vars.pl to HTML encode certain entities that could be maliciously entered into session variables via direct input of a malicious URL string into the browser address bar.  By encoding them with their HTML entity codes, when they appear in the body of a page (in links generated by the script), they won't be interpreted as characters by the browser and therefore can't be used to inject script into the page.  I only took out the < and > characters, since I figure you can't really make a script without them.  It is not the maximum possible security, but the more characters you take out, the more likely you are to affect a product, category or page reference string and make some of your products/categories/pages not work.  So I did the minimum to get past compliance checks.

Code:

#######################################################################
# Vars HTMLencode                                                     #
#######################################################################

sub vars_htmlencode {

#########
######### The following encodes a string for display in HTML.  It 
######### basically inserts HTML entities to ensure data safety.
#########

my $return_value = shift;

$return_value =~ s/</\&lt\;/gs;
$return_value =~ s/>/\&gt\;/gs;

return "$return_value";

} ######### End of subroutine.

2. I then called this subroutine from further up in vars.pl (line 111):

Code:

if ($fd_affiliate eq "") {
$fd_affiliate = $q->param('affl');
} ######### End of if statement.

#########
######### Fix XSS Vulnerability in Session Variables
#########

foreach ($fd_pg, $fd_rrc, $fd_ref, $fd_affiliate) {
  $_ = vars_htmlencode($_);
} ## endforech

At this point, the only other place i have used the subroutine is in ste_seo.pl, which only comes into play if you are using ATS SEO mod.

1. Line 47ish:

Code:

  $fd_ref =~ s/QQA/&/g;
  $fd_ref =~ s/QQS/\//g;
  $fd_ref =~ s/QQP/\%/g;

  $seo_title =~ s/-/ /g;
  $seo_title = vars_htmlencode($seo_title);

2. Line 227ish:

Code:

  $seo_metadescr_text =~ s/<.*?>/ /g;
  $seo_metadescr_text =~ s/  / /g;
  $seo_metadescr_text =~ s/  / /g;
  $seo_metadescr_text =~ s/ $//g;
  $seo_metadescr_text = vars_htmlencode($seo_metadescr_text);

Same disclaimers as above about completeness, usefulness, security, etc - assume none and do your own work - I'm not going out on any limbs with serious security stuff.  I'm just sharing knowledge I've gleaned from helping a couple people past some of these security checks.  Also same disclaimers about line numbers - near meaningless in my codebase - I reported as best I could.

Last edited by rachaelseven (12-30-2008 08:44:05)


Rachael Katz
- Custom Focusing Screens for DSLR Cameras

Offline

 

#22 12-29-2008 20:36:28

Blitzen
Member
From: USA
Registered: 01-01-2005
Posts: 935

Re: PCI Failure - Please help.

Thank you Rachel.
FYI - The CCP5 site passed with this fix. smile

Rachel,
Why didn't you remove the single quote in vars_scrub?

Last edited by Blitzen (12-29-2008 20:37:49)

Offline

 

#23 12-29-2008 21:50:40

rachaelseven
Member
From: Massachusetts, USA
Registered: 01-23-2006
Posts: 3169
Website

Re: PCI Failure - Please help.

You're welcome.  I left the single quote because I don't think it can do much harm by itself and because it could appear in a company name... Joe's Photography or whatever.  Technically that should be an apostrophe, but I think the single quote is used for that purpose on most keyboards.  I also left the ampersand, forward slash, parentheses and plus sign for similar reasons - they show up in legitimate company names, addresses, and phone numbers, and since the same subroutine scrubs all the different types of data, I had to be more lenient in what I left in.  If you wanted to scrub each field separately, you could afford to be a lot more restrictive.  Of course you can be more restrictive with this technique too - that's entirely up to you - this is just the compromise I decided to make between security and functionality.  On balance, it might be better to encode the characters rather than remove them, which is the approach Nick took when he addressed this issue before.  I would seriously consider his approach if you are actually concerned about the security risk, rather than just passing the test.  The official update for dealing with this (released specifically to address these false positives on automated compliance tests) is here:

Last edited by rachaelseven (12-30-2008 07:43:26)


Rachael Katz
- Custom Focusing Screens for DSLR Cameras

Offline

 

#24 12-29-2008 23:21:39

rachaelseven
Member
From: Massachusetts, USA
Registered: 01-23-2006
Posts: 3169
Website

Re: PCI Failure - Please help.

As an aside here, I'm curious as to how this might actually be a meaningful vulnerability.  I don't want malicious code posted in the forum, so let's refrain from posting actual examples.  But hypothetically speaking, what could you possibly do?  Anything you manage to 'inject' this way would not execute on the server side.  As far as I can see, the worst you could really do would be to get some client side script to execute on the same machine from which the injection was done (the attacker's machine) like the benign alert example.  Client side script can't access the server of course, so you aren't going to steal any information that way.  And it's your own machine, so not much point in hacking yourself. 

I suppose there might be a remote chance you could get something into the database that would then be served to another client... maybe.  I'd have to think about the specifics, but there might be a theoretical way to do something like that.  Seems like a real long shot and you'd have to know an awful lot about the scripts and database you were attacking, but that's the only way even at a theoretical fantasy sort of level that I can see actually compromising any information other than your own.  Is there something I'm missing?

And since we're on the subject, aren't there a whole lot of other similar vulnerabilities that take nothing more than the web developer toolbar to reveal?  Modify a few hidden form fields and there's a whole new set of similar vulnerabilities, right?  Edit the cookie on your local machine so that it injects something when the browser reads it back up to the server... possible, right?  So while I realize that passing the PCI compliance is important from a business perspective (my merchant account provider threatens fines if we don't pass), are we really protecting against anything more than nuisance level pre-teen attacks with this effort?

Just wanting to continue the security conversation a bit.  Thanks for listening.


Rachael Katz
- Custom Focusing Screens for DSLR Cameras

Offline

 

#25 12-30-2008 08:23:41

rachaelseven
Member
From: Massachusetts, USA
Registered: 01-23-2006
Posts: 3169
Website

Re: PCI Failure - Please help.

I would like to point out that Kryptronic did release an official update that addressed this issue.  It would appear to be more secure than the method discussed here and is the preferred method.


Rachael Katz
- Custom Focusing Screens for DSLR Cameras

Offline

 

Board footer