CF 7 PCI compliance issue

[Guest]

There is a security flaw in the wildcard ISAPI DLL in CF7 - Documented here:

http://blogs.msdn.com/asiatech/archive/2009/03/13/why-private-ip-address-is-still-leaked-on-iis-serv...

Is there an update to this ISAPI DLL that fixes this issue?

Thanks.

[SilentBob_secretfusion]

This seems like an IIS issue.

Out of curiousity, how does PCI compliance relate to this issue?

[Guest]

This DLL:

C:\JRun4\lib\wsconfig\1\jrun_iis6_wildcard.dll

Violates PCI compliance by leaking the private IP address.  This is an issue with the DLL in question, not an IIS issue.  I was hoping to discover if there was an update to this DLL.  If not, I will have to redevelop the appplication that is dependent upon this DLL in .NET.

[SilentBob_secretfusion]

Interesting regarding the PCI compliance.

As for the security issue with JRun.  Adobe is falling apart.  This week the head of SANS came out and said you should use ADOBE products as little as possible because of the mulitiple on going security issues.

I cannot even get through to technical support any longer, I have been in queue for two days now.

[SilentBob_secretfusion]

I was wondering what type of training you underwent to understand PCI compliance?  I am interested in learning the basics.  Does a certification exist for PCI?  Thanks.

[Guest]

TBH I don't know.  The infrastructure group here was tasked with PCI compliance for our 6 public facing servers.  This issue arose out of that process.

[Guest]

You are using an outdated version of Cold Fusion, released about 5 years ago.  Adobe are in the next few months, about to release the second major update to the product since the one you have was released.

The most recent release ( version 8 ) is unlikely to exhibit the problem you have observed, but it isn't documented.

Anyway, who do you think you are threatening by suggesting that you'll move this app to .Net if Adobe dont fix this obsolete version of their product ?

I'd suggest a different tactical approach might be called for if you want sympathy and help from either Adobe or any of the helpers on this forum.

[SilentBob_secretfusion]

I am annoyed at Adobe right now for letting things fall apart currently, however I would stick with Coldfusion.  It is the fastest web development language.

Then again, I have seen .net used for job stability and increased billing purposes.  It is funny when .net programmers/java developers pull the wool over management eyes with longer development times and huge development costs.

[Guest]

I agree with you  in regards .net (although its off topic of course)

I spent time in UK a couple of years ago working for a major corporation, called in to maintain a CF 5 application written with MVC design pattern and Fusebox 3 framework.

It had some coding issues (50 of them) which I fixed, but they refused to consider moving up to CF6/7 (current at the time) and refactoring to use a better framework.  They even owned a CF6 licence.

It was deemed too hard/expensive to migrate the several CF applications they had working on a single platform.

Instead they had made a central corporate decision to move to the .Net platform.

Whilst I worked there for 2 years keeping the legacy CF code working (and extending it) they paid a team of 10 .Net programmers (for 18 months) to redevelop the application.

Now 2 years after I left I've heard they've let go all of the UK support team (.net) and outsourced to India.  So the .Net guys are all out on the street.

In CF terms I've heard there is now a big CF presence in Turkey and India, no doubt some jobs being exported there too.  A turkey CFUG has apparently been formed.

So the threat to our livelihood isn't just .Net, its also this outsourcing trend.

But all the while there seems to have been an upsurge in the number of CF jobs advertised in UK.

Its really hard to discern what is happening in real terms.

One reason for Adobe dropping the ball a bit is likely the upsurge in demand and interest for the (several) open source CF engines (Railo and Blue Dragon) because of course this will lead to a drop in revenue for their CF engine.

Cheers,

Bryn

[Guest]

I am not threatening or looking for sympathy.  The reality is this:  There is legacy CF code in our system.  There are no CF developers here anymore.  Our systems have all been redeveloped in .NET and we have this single legacy CF component.  I also am fully aware that we are using a legacy version of CF.  My question was regarding any update the the wildcard DLL to fix this issue.  If no update exists for it, that's fine.  That tells me I need to rebuild the CF component in .NET.  SImple.  It's not worth it to us to upgrade CF especially since it is not clear that the current version would resolve the PCI compliance issue.

Thank you all for your input here.

[TLC-IT]

Let's be realistic:  there is no "silver bullet."  It ain't Cold Fusion, and it ain't dot-Net.

If the issue of PCI Compliance is that "an internal IP-address is being leaked," first make sure that your software is up-to-date (i.e. convert to the latest ColdFusion and Windows versions and service-packs), then make sure that, even if an internal IP address is leaked, it cannot be accessed from the outside.  (I have never quite understood some of the "requirements," including this one. IP addresses can always be 'port-scanned' if you can get to the subnet, and they're quite useless if you can't.)

Nevertheless, whether or not you agree with Adobe or ColdFusion, "it's what you got," and any substantial conversion of any tool to another platform is always tantamount to "starting over from scratch."  You're just not gonna get that through the bean-counters (if they are any good at all at bean counting).  You've got millions of dollars invested in whatever you've got.  Scrapping it all, in pursuit of closing some very-tiny "hole" that it might not be possible for any real-world intruder to pass through, is just not gonna happen.

There are very fundamental reasons for "what all the fuss is about" vis-a-vis ColdFusion:  the total cost of ownership is much less than with other tools including dot-Net because of its declarative syntax and efficient, just-in-time implementation.  Maintaining a "web site" with most tools is actually a task of maintaining hundreds of hand-crafted computer programs, whereas ColdFusion uses a clever and transparent code-generator to give you the same "bang" for a lot less "buck."

[SilentBob_secretfusion]

Yes, no silver bullet exists, however coldfusion is the superior rapid development tool, hands down.

I am watching a project now flop and fail.  Millions poured into the project. Seven developers, hundreds of thousands in consultants, multiple OS and langagues later, and they still will not swallow their pride and admit they are clueless. Just pour more resources into the project. LOL.  I don't know who is funnier, management or the project team.

That is interesting regarding PCI and internal IP address requirements.  You are correct, if the security people are doing their jobs, it really doesn't matter.  If all ports and unrequired protocols are blocks, it shouldn't be a problem.  However, you can see how well PCI worked in the Homeland Credit Card processing situation.  Millions of credit cards stolen.

[Guest]

The guts of this particular issue is that If the internal IP addresses are disclosed to the outside world, then the well equipped hacker can break open the firewall/router and wreak havoc.  The problem appesars to be exposed on the platform concerned when a hacker sends in a request for an unspecified file type (one that iiS6 is not expressly configured to handle.).

In regards what the original guy indicated, the culprit appears to be this jrun wildcard DLL, and it just strikes me that I wonder what that is doing there anyway ?

My simplistic understanding is that CF consists essentially of an isapi filter that picks out all requests to .cfm and .cfc files and proceeds to process them

(by compiling them into java class files and then giving them to the JVM to execute)

In my (Vista - iis6) setup, I find there are several 'Handler Mappings' of type AboMapperCustom that direct execution to an IsAPIModule.  Most requests in which a file extension is specified  such as .cfm, .cfc, .jsp etc are directed to jrun_iis6.dll, and only one ( '*') is directed to jrun_iis6_wildcard.dll.

So this issue may still be a live one in the case of CF 8, unless of course, Adobe have boosted security in those handlers.

You have to ask what is that wildcard thing all about anyway ?  Why does it have to be there, and is it safe to remove it ?

Is it intended to support an isapi-redirector perhaps ?

[Guest]

If I remove the DLL, the CF process fails.  I have no idea what the dependency is with regard to that DLL.

[TLC-IT]

PCI is a standard that was created by the industry, and it shows clearly that the people who helped to devise it were not extraordinarily technical people.  They identified a laundry-list of "every possible vulnerability they could think of," but there really isn't a sense of what is more crucial or less.  There also is no sense of a management strategy.

In contrast, I would recommend that you should spend some time studying, of all things, the HIPAA Act, which of course concerns healthcare.  My point is that this was an extremely well-reasoned piece of legislation in most respects, and the available material does talk quite extensively about the fact that security is an ongoing process as well as a thing that must now-and-forever be properly managed.

I don't know whether the retailer in question, in the recent mass-theft, was "PCI compliant" or not.  They may well could have been!  Yet they obviously were not secure.  Or maybe a better way to put it is, "whether or not they were 'secure,' the sensitive data nevertheless was successfully misappropriated in a felonious way."

"Your job isn't to mind or mend the fences.  Your job is to make sure that the horse-thieves don't get in and out with my prize race-horse."  To achieve that, you can't be staring mindlessly at fences all day.  You have to regard the entire farm, and you have to have a very comprehensive and manageable plan which can be second-nature even to the stable-boy who's not getting paid much more than minimum wage.  That guy with a magnifying glass is gonna find a defect in every single fence, but... the horse is still there, and the horse-thieves are not.

[newfields2]

I have run across this exact same issue as bscenefilms

Assuming for the moment that there is no fix to that wildcard DLL, does anyone know how to create an "ISAPI filter that blocks and rejects any incoming HTTP requests that do not include an HTTP:Host header".

That appears to be the only work around I have come across after hours of tracking this down.

[Jochem van Dieten]

1. The article you link already has the answer:

We can either ensure the HTTP client application includes a HTTP:Host header value in its request. (Actually HTTP:Host headers are required by the HTTP/1.1 specifications (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.23) or write an ISAPI filter that blocks and rejects any incoming HTTP requests that do not include an HTTP:Host header.

So configure a Host header in your IIS website.

2. I fail to see where the PCI specifiction says said behaviour is non-compliant.

[newfields2]

Jochem,

You wrote:

>So configure a Host header in your IIS website.

I wish it was easy as that.

Doing that works fine without the wildcard dll enabled. Unfortunately without it enabled, the CF process fails.

Enable the DLL and the private IP headers are leaked.

>2. I fail to see where the PCI specifiction says said behaviour is non-compliant.

That link is no where near a full compilation of the reasons that a site would fail PCI compliancy.

It makes sense that one would fail under the circumstances that the private IP address is being leaked. That does present some potential issues for hackers to try and take advantage of.

The specific PCI rejection is below. The article that they quote in their rejection does not correct the issue as it is specifically related to the DLL.  As mentioned in the link in the very first post of this thread, the issue is readily evident by turning on/off the DLL requirement. Unfortunately our sites require it.

"Synopsis :  This web server leaks a private IP address through its HTTP headers.   Description :  This may expose internal IP addresses that are usually hidden or masked behind a Network Address Translation (NAT) Firewall or proxy server.   There is a known issue with IIS 4.0 doing this in its default configuration. This may also affect other web servers, especially on a misconfigured redirection.  See also :  http://support.microsoft.com/support/kb/     articles/Q218/1/80.ASP See the Bugtraq reference for a full discussion.  Risk Factor:  Medium  / CVSS Base Score : 5.0 (CVSS2#AV:N/AC:L/Au:N/C:P/I:N/A:N) CVE : CVE-2000-0649 BID : 1499 Other references : OSVDB:630   " [More]

[Jochem van Dieten]

newfields2 wrote:

>So configure a Host header in your IIS website.

I wish it was easy as that.

Doing that works fine without the wildcard dll enabled. Unfortunately without it enabled, the CF process fails.

Enable the DLL and the private IP headers are leaked.

[More]

So you are saying that with both a host header configured and the wildcard dll enabled, there is a leak. Can you show me the whole IIS configuration XML file?

The specific PCI rejection is below. [More]

That is not a PCI rejection. That is the output of some scanning tool. That output requires human interpretation.

If you were to run that scanning tool against our infrastructure you would see some IP addresses too. IP addresses that in reality are located on an entirely different continent.

[lleshf]

We are running into this exact same issue with CF9.

We did this on our Windows 2003 server

http://support.microsoft.com/kb/834141

and when I ran the PCI scan it still came up with the private IP in the HTTP headers. So I kept searching for a solution and found this.

http://blogs.msdn.com/asiatech/archive/2009/03/13/why-private-ip-addre  ss-is-still-leaked-on-iis-se...

So it looks like CF is intercepting the HTTP GET command and displaying the HTTP header with the private IP address.

We can't delete the "wildcard ISAPI DLL" from IIS6 because CF will stop working. Did anyone ever come up with a solution to this huge problem? Thanks.

[brian428]

Did you try adding a default HTTP:Host header value in IIS, as the article

suggests?

[lleshf]

Yes I did that part and I tested it by deleting the jrun_iis_wildcard.dll from IIS6 and CF stopped working on the server. I ran the PCI scan and it came out fine I think because IIS then takes the request and since I configured it to display the server name it did display it instead of the IP.

I wish there was a setting in CF9 that tells it to display the server name instead of the IP for the GET HTTP command OR if it could just pass the GET HTTP request to IIS. Any other ideas would be greatly appreciated. Thanks!

[brian428]

I'm pretty sure what they're saying is leave the ISAPI filter as it is, and

just make sure you add a default HTTP:Host header.

[lleshf]

Sorry to sound lame but how do I do that? I'm running Windows 2003, IIS6 and CF9. Again any help is greatly appreciated. Thanks.

[brian428]

I would try it by editing the properties for the web site, in the HTTP

Headers tab.