Jump to content
Latest News: (loading..)

Archived

This topic is now archived and is closed to further replies.

Taipo

Validating SSL Certificates in Non-Browser Software

Recommended Posts

In most of the osCommerce payment modules CURLOPT_SSL_VERIFYPEER is boolean disabled and CURLOPT_SSL_VERIFYHOST is non-existent (should be set to integer 2).

 

Being the settings in third party payment modules, this should be discussed for all versions of osCommerce that use them. (I probably should have posted this in the addons section....)

 

This is a whitepaper on the issue:

 

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

 

The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software

 

ABSTRACT

SSL (Secure Sockets Layer) is the de facto standard for secure Internet communications. Security of SSL connections against an active network attacker depends on correctly validating public-key certificates presented when the connection is established.

 

We demonstrate that SSL certificate validation is completely broken in many security-critical applications and libraries. Vulnerable software includes Amazon’s EC2 Java library and all cloud clients based on it; Amazon’s and PayPal’s merchant SDKs responsible for transmitting payment details from e-commerce sites to payment gateways; integrated shopping carts such as osCommerce, ZenCart, Ubercart, and PrestaShop; AdMob code used by mobile websites; Chase mobile banking and several other Android apps and libraries; Java Web-services middleware—including Apache Axis, Axis 2, Codehaus XFire, and Pusher library for Android—and all applications employing this middleware. Any SSL connection from any of these programs is insecure against a man-in-the-middle attack.

 

The root causes of these vulnerabilities are badly designed APIs of SSL implementations (such as JSSE, OpenSSL, and GnuTLS) and data-transport libraries (such as cURL) which present devel- opers with a confusing array of settings and options. We analyze perils and pitfalls of SSL certificate validation in software based on these APIs and present our recommendations.

 

https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html

shmat_ccs12.pdf


- Stop Oscommerce hacks dead in their tracks with osC_Sec (see discussion here)
- Another discussion about infected files ::here::
- A discussion on file permissions ::here::
- Site hacked? Should you upgrade or not, some thoughts ::here::
- Fix the admin login bypass exploit here
- Pareto Security: New security addon I am developing, a remake of osC_Sec in PHP 5 with a number of fixes
- BTC:1LHiMXedmtyq4wcYLedk9i9gkk8A8Hk7qX

Share this post


Link to post
Share on other sites

Sounds nasty. I scanned for CURL and it appears that everything of interest is in third-party-supplied payment modules. Is this correct, or did osC write some of them? Would it be better for an official representative of osC (e.g., Harald) to contact each supplier and point them to the paper, and wait for them to correct these problems, or should osC go ahead and fix them immediately? I wonder which way could open up osC and its developers to more legal problems -- appearing to ignore the problem by passing the buck to third parties, or risking not fixing it correctly and exposing users to even worse security problems? It would also take a fair amount of testing just to make sure the current function hasn't been broken by these fixes.


If you are running the "official" osC 2.3.4 or 2.3.4.1 download, your installation is obsolete! Get the latest community-supported responsive "Edge" release

Share this post


Link to post
Share on other sites

Some of the payment module addons were probably coded intentionally in that manner and others would have merely being relying on the standards and methods of other payment module developers. To developers it is often about trying to make their wares work anywhere, anytime striking that faux balance between security and functionality. So for example the question might be asked, 'if no CURL then fsockopen' as a means of continuing the transaction on a webserver that really should just have the data transport rapper CURL installed.

 

The root cause stated is this: "The root cause of most of these vulnerabilities is the terrible design of the APIs to the underlying SSL libraries. Instead of expressing high-level security properties of network tunnels such as confidentiality and authentication, these APIs expose low-level details of the SSL protocol to application developers."

 

Followed by: "The primary cause of these vulnerabilities is the developers’ misunderstanding of the numerous options, parameters, and return values of SSL libraries."

 

So I assume that in not giving developers a complete range of settings to work with for solutions to validation errors for example, and being provided with incomplete documentation, they are left with being in the position of being between a rock and a hard place so to speak, and so opt for functionality over security based on the perceived list of settings that appears to be available to them.

 

Keep in mind too that the so called man-in-the-middle attack 'was' not the easiest attack to pull off either until the mass movement of users to mobile and WiFi devices, and is not known to be a prevalent attack yet...on SSL systems, and so many developers whose security threat models are based on known and used exploits, would probably put the MITM attack as outside of their scope of influence and probably wouldn't concede their application was broken if it was exploited by a successful MITM attack.

 

In some cases the SSL libraries need rewriting, and in all cases, all the payment modules need at least addressing to make them implement SSL in the most secure manner.


- Stop Oscommerce hacks dead in their tracks with osC_Sec (see discussion here)
- Another discussion about infected files ::here::
- A discussion on file permissions ::here::
- Site hacked? Should you upgrade or not, some thoughts ::here::
- Fix the admin login bypass exploit here
- Pareto Security: New security addon I am developing, a remake of osC_Sec in PHP 5 with a number of fixes
- BTC:1LHiMXedmtyq4wcYLedk9i9gkk8A8Hk7qX

Share this post


Link to post
Share on other sites

We can't do anything about third party SSL libraries and wrappers (except nudge their owners into fixing them), but to answer my question, what is osC's responsibility towards getting the osC-specific payment modules fixed? Is it something we should do, hoping that we correctly understand the (poorly documented) workings of SSL and Curl, or is it something that is the sole responsibility of whoever provided a payment module to us? See, fixing it ourselves could open us up to liability if it's done incorrectly (even if we don't break existing function), or even copyright/license violations if the license it's provided under doesn't allow us to touch it. However, if the owner/author is in no hurry to fix it, are we in even worse shape by letting it sit there unfixed, giving osC users a false sense of security?

 

Any modules provided (and owned) by osC should certainly be fixed ASAP, by someone who really understands the situation and how to do it correctly. Modules provided by others, and whose licenses allow osC to fix them, could be fixed by osC as an interim measure until the owners get around to fixing them. Modules provided by others, and whose licenses forbid us from touching the code (are there any?) -- all we could do is mark them "do not use" if we suspect they need fixing, and pressure the owners to fix them.

 

Are there any payment modules not provided with osC, but available only from a payment gateway? It wouldn't hurt to point them to this subject and paper, and ask them to review their code.

 

Are these problems only with payment gateways where your PCI-DSS compliant server collects the credit card information and sends it off to the payment processor? Would any of this apply to third party payment systems that take a customer to their site (e.g., most PayPal plans) to handle the credit cards?


If you are running the "official" osC 2.3.4 or 2.3.4.1 download, your installation is obsolete! Get the latest community-supported responsive "Edge" release

Share this post


Link to post
Share on other sites
See, fixing it ourselves could open us up to liability if it's done incorrectly (even if we don't break existing function), or even copyright/license violations if the license it's provided under doesn't allow us to touch it...

 

It is a bit of a quandary, but only if you do not consider the current status quo to be already broken.

 

This paper was written a year ago (so it seems) and I am not sure, but at least some of the big players listed in there patched their code, and others oppose such an idea (at their peril), others again have applied what they call a fix, but in fact it is not so.

 

The major web browsers have patched their systems at least after Chrome was hit by an attempted MITM attack back in mid 2011. So the fallback on all of this is that a patched browser would hopefully pop an SSL warning if a MITM attack was launched on a 3rd party payment processor.

 

I would suggest if osCommerce community deems this a serious enough threat then they formally contact the payment module license holders and give them the ultimatum to upgrade or have their services cut. Otherwise let sleeping dogs lie and let web browsers do the security and cross your fingers etc etc etc.

 

It is better fixed in my opinion.

 

Here is that Chrome MITM attack I mentioned earlier:

 

/*********************************************************/

 

Diginotar issues dodgy SSL certificates for Google services after break-in

 

Diginotar doesn't seem to mind much

By Lawrence Latif

Tue Aug 30 2011, 17:23

ONLINE GIANT Google was the target of a man-in-the-middle SSL attack as a firm issued certificates for some of its services without authorisation.

Google announced that some users - mostly those located in Iran - were served false SSL certificates issued by Diginotar in order to hijack SSL sessions with Google's services. Diginotar, a recognised and trusted certificate authority, revealed that the certificates were issued during an intrusion into its certificate authority systems.

Full Article: http://www.theinquirer.net/inquirer/news/2105321/diginotar-issues-dodgy-ssl-certificates-google-services-break

 

/*********************************************************/

 

Using fsockopen() with 'ssl://' needs investigating too since from what I can see, fsockopen requests do not ask for certificate verifications as well.


- Stop Oscommerce hacks dead in their tracks with osC_Sec (see discussion here)
- Another discussion about infected files ::here::
- A discussion on file permissions ::here::
- Site hacked? Should you upgrade or not, some thoughts ::here::
- Fix the admin login bypass exploit here
- Pareto Security: New security addon I am developing, a remake of osC_Sec in PHP 5 with a number of fixes
- BTC:1LHiMXedmtyq4wcYLedk9i9gkk8A8Hk7qX

Share this post


Link to post
Share on other sites

OK, I can't see anything wrong with prominently listing, with each payment module, whether or not we believe it has been fixed. In any case, all should be clearly marked USE AT YOUR *OWN* RISK. Those we're pretty sure have not been properly fixed, could be marked WE RECOMMEND THAT YOU DO *NOT* USE THIS PAYMENT SYSTEM, BECAUSE IT APPEARS TO BE VULNERABLE TO THE FOLLOWING TYPE OF ATTACK... We formally tell the provider that while we're still offering their module, we have expressed concern because we believe that it is still vulnerable to specific attack(s). That should cover us both ways -- we have warned osC users that certain payment systems are known to have security exposures, AND we haven't done anything libelous towards the module providers and haven't cut them off. Those that appear to have been adequately fixed, would still have OWN RISK warning, but we can say "WE ARE NOT AT THIS TIME AWARE OF ANY SECURITY RISKS WITH THIS SYSTEM". What think ye?


If you are running the "official" osC 2.3.4 or 2.3.4.1 download, your installation is obsolete! Get the latest community-supported responsive "Edge" release

Share this post


Link to post
Share on other sites

Which one of the available payment processors is configured correctly? From the quick look I had into 2.3.3's payment processor list, I could not see any at all, unless I missed something. That being the case if they were all marked with a do not use sign, you would not be left with any formal payment module for osCommerce users to safely implement.

 

Wouldn't the right thing to do be to 1/ put out a formal statement warning osCommerce web application users of the risks, then 2/ immediately contact the addon providers and give them a chance to be the first to patch their addon within a specified period of time warning them what will happen if they do not take action to fix their stuff.

 

The ones that do patch them in the allocated timeframe get the recommendation, and the rest that cannot be bother or do not think this serious enough, get the do not use warning added to the addons.oscommerce.com site and pulled from the stock release of osCommerce altogether.

 

The next question then has to be asked what should osCommerce do if the server indicates that an SSL connection attempt failed due to verifypeer and verifyhost returning failed responses. If osCommerce is not going to depend on the web browser warnings, and on the end user obeying that small address bar warning that by far the majority of web users ignore, then it needs a response mechanism that takes that verification failure seriously...

 

I also note that this is just you and me Phil having this discussion...


- Stop Oscommerce hacks dead in their tracks with osC_Sec (see discussion here)
- Another discussion about infected files ::here::
- A discussion on file permissions ::here::
- Site hacked? Should you upgrade or not, some thoughts ::here::
- Fix the admin login bypass exploit here
- Pareto Security: New security addon I am developing, a remake of osC_Sec in PHP 5 with a number of fixes
- BTC:1LHiMXedmtyq4wcYLedk9i9gkk8A8Hk7qX

Share this post


Link to post
Share on other sites

Take a faulty payment module, and prop it up with the corrected code, and test it out.

This will help expedite the required changes !

 

curl_setopt($curl, CURLOPT_SSL_VERIFYPEER, 1);
curl_setopt($curl, CURLOPT_SSL_VERIFYHOST, 2);


This is a signature that appears on all my posts.  
IF YOU MAKE A POST REQUESTING HELP...please state the exact version
of osCommerce that you are using. THANKS

 
Get the latest current code (community-supported responsive 2.3.4.1BS Edge) here

 

Share this post


Link to post
Share on other sites

Take a faulty payment module, and prop it up with the corrected code, and test it out.

This will help expedite the required changes !

 

curl_setopt($curl, CURLOPT_SSL_VERIFYPEER, 1);
curl_setopt($curl, CURLOPT_SSL_VERIFYHOST, 2);

CURLOPT_SSL_VERIFYPEER could also be set to Truecurl_setopt($curl, CURLOPT_SSL_VERIFYPEER, true);


- Stop Oscommerce hacks dead in their tracks with osC_Sec (see discussion here)
- Another discussion about infected files ::here::
- A discussion on file permissions ::here::
- Site hacked? Should you upgrade or not, some thoughts ::here::
- Fix the admin login bypass exploit here
- Pareto Security: New security addon I am developing, a remake of osC_Sec in PHP 5 with a number of fixes
- BTC:1LHiMXedmtyq4wcYLedk9i9gkk8A8Hk7qX

Share this post


Link to post
Share on other sites

if ($fsocket == true) {
   $header = 'POST /cgi-bin/webscr HTTP/1.0' . "\r\n" .
             'Host: ' . $server . "\r\n" .
             'Content-Type: application/x-www-form-urlencoded' . "\r\n" .
             'Content-Length: ' . strlen($parameters) . "\r\n" .
             'Connection: close' . "\r\n\r\n";

   @fputs($fp, $header . $parameters);

   $string = '';
   while (!@feof($fp)) {
     $res = @fgets($fp, 1024);
     $string .= $res;

     if ( ($res == 'VERIFIED') || ($res == 'INVALID') ) {
       $result = $res;

       break;
     }
   }

   @fclose($fp);
 } elseif ($curl == true) {
   $ch = curl_init();

   curl_setopt($ch, CURLOPT_URL, 'https://' . $server . '/cgi-bin/webscr');
   curl_setopt($ch, CURLOPT_POST, true);
   curl_setopt($ch, CURLOPT_POSTFIELDS, $parameters);
   curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
   curl_setopt($ch, CURLOPT_HEADER, false);
   curl_setopt($ch, CURLOPT_TIMEOUT, 30);
   curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);

   $result = curl_exec($ch);

   curl_close($ch);
 }

 

This is from Paypals standard ipn. Some payment modules use this method, some do not.

 

As you can see, merely amending the CURL settings will not fix this as it first attempts to use fsockopen to make the ssl connect with Paypal. According to the stanford whitepaper, fsockopen does not validate SSL certificates so at best should be used as a backup to the data transport rapper where curl is installed.

 

Further down the code it checks to see if $result returns 'VERIFIED', which may be fine for fsockopen, but curl_exec() will only return false if there is an error so this code was obviously written to deal only with errors from fsockopen, any errors returned from curl_exec() are ignored ( put that down to CURLOPT_SSL_VERIFYPEER being disabled ).

 

You would have to use curl_error() to return an error number, 51 for example would indicate the verify peer had failed, and set the emailer to email the site admin, as well as notify the user that their payment failed and to contact the admin. Also error codes, 35 ( CURLE_SSL_CONNECT_ERROR ), 58 ( CURLE_SSL_CERTPROBLEM ), 59 ( CURLE_SSL_CIPHER ), 60 ( CURLE_SSL_CACERT ) and 83 ( CURLE_SSL_ISSUER_ERROR ) would be the main error numbers to check for.

 

If you wanted a more human read of the error numbers then just use curl_easy_strerror( $errnum ).


- Stop Oscommerce hacks dead in their tracks with osC_Sec (see discussion here)
- Another discussion about infected files ::here::
- A discussion on file permissions ::here::
- Site hacked? Should you upgrade or not, some thoughts ::here::
- Fix the admin login bypass exploit here
- Pareto Security: New security addon I am developing, a remake of osC_Sec in PHP 5 with a number of fixes
- BTC:1LHiMXedmtyq4wcYLedk9i9gkk8A8Hk7qX

Share this post


Link to post
Share on other sites

Here is a bit more information on transport layer security, server certificates and verifying hostnames:

https://datatracker.ietf.org/doc/rfc6125/?include_text=1

 

 

In 1999, [uSINGTLS] specified the following text regarding

application service identity verification in IMAP, POP3, and ACAP:

 

######

 

2.4. Server Identity Check

 

During the TLS negotiation, the client MUST check its understanding

of the server hostname against the server's identity as presented in

the server Certificate message, in order to prevent man-in-the-middle

attacks.

 

In 2000, [HTTP-TLS] specified the following text regarding

application service identity verification in HTTP:

 

######

 

3.1. Server Identity

 

In general, HTTP/TLS requests are generated by dereferencing a URI.

As a consequence, the hostname for the server is known to the client.

If the hostname is available, the client MUST check it against the

server's identity as presented in the server's Certificate message,

in order to prevent man-in-the-middle attacks.

 

In 2000, [LDAP-TLS] specified the following text regarding

application service identity verification in LDAP:

 

######

 

3.6. Server Identity Check

 

The client MUST check its understanding of the server's hostname

against the server's identity as presented in the server's

Certificate message, in order to prevent man-in-the-middle attacks.

 

In 2006, [LDAP-AUTH] specified the following text regarding

application service identity verification in LDAP:

 

######

 

3.1.3. Server Identity Check

 

In order to prevent man-in-the-middle attacks, the client MUST verify

the server's identity (as presented in the server's Certificate

message). In this section, the client's understanding of the

server's identity (typically the identity used to establish the

transport connection) is called the "reference identity"

 

In 2006, [NNTP-TLS] specified the following text regarding

application service identity verification in NNTP:

 

######

 

5. Security Considerations

 

[...]

 

During the TLS negotiation, the client MUST check its understanding

of the server hostname against the server's identity as presented in

the server Certificate message, in order to prevent man-in-the-middle

attacks. Matching is performed according to these rules:

 

In 2010, [GIST] specified the following text regarding application

service identity verification in the General Internet Signalling

Transport:

 

######

 

5.7.3.1. Identity Checking in TLS

 

After TLS authentication, a node MUST check the identity presented by

the peer in order to avoid man-in-the-middle attacks, and verify that

the peer is authorised to take part in signalling at the GIST layer.

The authorisation check is carried out by comparing the presented

identity with each Authorised Peer Database (APD) entry in turn, as

discussed in Section 4.4.2. This section defines the identity

comparison algorithm for a single APD entry.


- Stop Oscommerce hacks dead in their tracks with osC_Sec (see discussion here)
- Another discussion about infected files ::here::
- A discussion on file permissions ::here::
- Site hacked? Should you upgrade or not, some thoughts ::here::
- Fix the admin login bypass exploit here
- Pareto Security: New security addon I am developing, a remake of osC_Sec in PHP 5 with a number of fixes
- BTC:1LHiMXedmtyq4wcYLedk9i9gkk8A8Hk7qX

Share this post


Link to post
Share on other sites

×