I know this is bad......

Printable View

September 13th, 2005, 01:54 PM
Tiger Shark

I know this is bad......

The question is, how bad???????

An organization we work with is requiring us to enter certain requests/data through their spiffy new web portal over https. It doesn't work very well for us and it was brought to my attention. Being the good little worker bee that I am I sit down with the user and ask them to run through what they do exactly as they do it. Everything goes swimmingly until she submits her request. The page returned is as follows:-

Code:

Server Error in '/Portal' Application. -------------------------------------------------------------------------------- The system cannot find the path specified. Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. Exception Details: System.Runtime.InteropServices.COMException: The system cannot find the path specified. Source Error: Line 54: userid = context.User.Identity.Name Line 55: oReportSource = New ReportDocument Line 56: oReportSource.Load("c:\inetpub\wwwroot\********\Portal\Reports\Serv_Auth.rpt") Line 57: oLogOnInfo = New TableLogOnInfo Line 58: Source File: C:\Inetpub\wwwroot\Portal\ServAuthRpt.aspx.vb Line: 56 Stack Trace: [COMException (0x80004005): The system cannot find the path specified. ] CrystalDecisions.ReportAppServer.ClientDoc.ReportClientDocumentClass.Open(Object& DocumentPath, Int32 Options) +0 CrystalDecisions.ReportAppServer.ReportClientDocumentWrapper.Open(Object& DocumentPath, Int32 Options) +72 CrystalDecisions.ReportAppServer.ReportClientDocumentWrapper.EnsureDocumentIsOpened() +218 [Exception: Load report failed.] CrystalDecisions.ReportAppServer.ReportClientDocumentWrapper.EnsureDocumentIsOpened() +269 CrystalDecisions.CrystalReports.Engine.ReportDocument.Load(String filename, OpenReportMethod openMethod, Int16 parentJob) +739 CrystalDecisions.CrystalReports.Engine.ReportDocument.Load(String filename) +52 Portal.ServAuthRpt.Page_Load(Object sender, EventArgs e) in C:\Inetpub\wwwroot\Portal\ServAuthRpt.aspx.vb:56 System.Web.UI.Control.OnLoad(EventArgs e) +67 System.Web.UI.Control.LoadRecursive() +35 System.Web.UI.Page.ProcessRequestMain() +731 -------------------------------------------------------------------------------- Version Information: Microsoft .NET Framework Version:1.1.4322.573; ASP.NET Version:1.1.4322.573

Now.... I can see a path disclosure in there, (sanitized due to their naming conventions), I can see the precise versions if .NET and ASP.NET, I can see that the backend is Crystal Reports, I can see how the userID is generated.

I know that this kind of information disclosure is bad..... But how bad is this from the POV of those that could be looking for vulnerable servers?

I'd like to know because my level of ire will be directly proportional to the level of idiocy this organization is displaying _yet again_!!!! On a rating of 0 - 10 with 10 being "Blow a blood vessel" where should I set the steam valve when I call them because this will clearly not be the only information disclosure that could be generated?
September 13th, 2005, 01:59 PM
SirDice

What happens if you try to get the /Portal/ServAuthRpt.aspx.vb file?
September 13th, 2005, 02:07 PM
Tiger Shark

SirDice:

I dunno.... I'm not fsking with the system.... This is a major funding source and, as such, holds confidential client information on thousands of people.... All they need is another excuse to piss with us.

It's bad though if I can get the source of that or any other file... I know that....
September 13th, 2005, 02:29 PM
steve.milner

Can this error be viewed by joe public, or is it an 'internal' thing.

If visible publically then the page error is unprofessional, at the very least.

Steve
September 13th, 2005, 02:35 PM
Tiger Shark

The web site is publicly available though the error above occurs at a page that is username/password protected. It's clear that debug error reporting is turned on so if I could force an error at the login page then similar information disclosure would take place. That aside, if I am a registered user and I want to commit a crime this _has_ to help me elevate my privs to a point where data that I am not supposed to see becomes available.
September 13th, 2005, 02:36 PM
Aspman

Quote:

Can this error be viewed by joe public, or is it an 'internal' thing.

My first thought also.

Any disclosure of enmumerating (right word?) information is bad however.

Does a security failure such as this breach any sort of contract/SLA that your org has with the offending org?
September 13th, 2005, 02:37 PM
Tiger Shark

It's a Major breach of HIPAA..... regardless of whether it is openly available or protected by username/password combo IMO.
September 13th, 2005, 02:40 PM
d0pp

I'd set the steam valve at about 5 if it's only available internally, if it's open to the net, set it to maybe 7. :p

Although there aren't any obvious "holes", the fact that it will give you versions, paths, etc. Gives an attacker enough information to start looking for specific vulnerabilities.

I wouldn't call it unprofessional, so much as amateurish.
September 13th, 2005, 02:42 PM
Tiger Shark

LOL.... Funny you use the word "amateurish"..... They haven't quite reached that lofty height yet....

Ok, I'm calling them..... Let's see how they react to a vulnerability disclosure..... ;)
September 13th, 2005, 02:47 PM
hogfly

I'd have to suggest that you do the following:

1) Alert the proper people. There is no sense in keeping something of this nature under wraps. If HIPAA data is at risk, then you need to practice due diligence.

2) Get approval to find out how deep the rabbit hole goes. You need to know how vulnerable the application is, and furthermore, how vulnerable the server running the app is. Get authorization to run a pen test or hire someone to conduct one for you, specifically for this application.

I'd take this up with the right people with a level of about 6-7
September 13th, 2005, 03:16 PM
Maestr0

Not sure that I would be seriously pissed, it is at least easily remedied. Obviously they need to fix the missing file, and disable "ASP Debugging" and "Send detailed ASP error messages to client" (I'm assuming its IIS 6.0, its in iis.msc) Crystal Reports have had a few vulns (file deletions,and DoS I think) but I think anyone worth their salt could determine the system is using Crystal without the aforementioned leak. The debugging is something that is clearly useful in development but should not be enabled on a production machine, we are all aware that misconfiguration can be just as dangerous as an application vulnerability, but some people just never learn to RTFM

-Maestr0
September 13th, 2005, 03:47 PM
Juridian

Actually, whoever is developing the site is a noob. The asp.net environment should be configured so that it shows friendly error messages only to anyone externally, the stack trace information and so on could easily be caught and emailed to an administrator or logged appropriately with people being notified. This is **** they teach you in the asp.net 101 type of class.

The configuration should be handled via web.config in the web root. The stack trace handling is easy enough to do via maybe 10 lines of code in the global.asax file.

These guys are failing basic web app security and should probably be pointed at owasp.org and msdn.com .

Their inability to do basic error handling and graceful failure is just letting people get their foot in the door and collect info about their web app.
September 14th, 2005, 06:58 AM
codelogman

Hi

Quote:

[Exception: Load report failed.]

this error is consequence of:

Quote:

[COMException (0x80004005): The system cannot find the path specified.]

First, you can generate first the solution with a new web.config file? if yes, you try it..

Second, the CrystalReport assemblies is on the correct path?

Third, the path need to be shared path?

Four, This error (0x80004005) ocurs when the report filename is incorrect (the report result or MS says Crystal Object)

Saludos