Re: Vulnerability? Or...not so much?

["Gibson, Nathan J. (HSC)" <Nathan-Gibson () OUHSC EDU>]

Just remember. 60 minutes is an eternity for users who's computers have been compromised with a backdoor/Trojan that 
sends/logs web history and sends that info everywhere. Just imagine one of your users, who regularly visits this site, 
with a Torpig infection (unfortunately Torpig is very common). I personally would make sure my leadership is aware of 
this risk before I let them make a decision on the options you presented.

From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Matthew 
Wollenweber
Sent: Saturday, April 03, 2010 10:55 PM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: Re: [SECURITY] Vulnerability? Or...not so much?

I'd consider pushing the vulnerability over to ZDI. If the software isn't large enough they likely won't mess with it. 
However, you can take a similar approach - contact the vendor. Let them know you plan public disclosure. Set a time 
table. Work with them, but if they're not cooperative disclose under a reasonable time table without their coordination.

The particular flaw seems like you could easily mitigate much of the risk with WAF/IPS/DPI software. Depending on how 
the web app works you can likely limit the rate users can go to URLs matching the vulnerable characteristic. Likewise, 
multiple IPs probably shouldn't access the temporary URLs.
On Sat, Apr 3, 2010 at 9:35 PM, David Shettler <dshettle () holycross edu<mailto:dshettle () holycross edu>> wrote:
During the course of a regularly scheduled pentest of applications, we
uncovered a vulnerability in some document imaging software.

The vulnerability is such that the documents under certain
circumstances are accessible without authentication.

The only security in place, during those circumstances, is that the
url to obtain the documents is, to some degree, randomly generated
(epoch is part of the 'randomization', but the entire url is not fully
guessable).

As is customary, we reported the problem to the vendor.

My chief concern is that most regulations that we're required to
adhere to don't really leave room for security of this nature.  We've
naturally blocked most access to the application since discovering the
issue, but the user community would like to see it restored.

Unfortunately, the vendor refuses to acknowledge that the problem is a
security issue, and thus won't remedy it.  Their opinion is that the
URI randomization, and 60 minute temporary nature of the files is
sufficient 'security'.

I'm left with a handful of options:

 1) decide that their obscurity is good enough, and re-open access to
it.  The URI/filename is not predictable at my skill level (portions
are, but others not), but I'm not exactly a hacker-adept.
 2) tell our users that the application will never be re-opened as before
 3) disclose the issue to 'friend' organizations (you reading this
may be affected, actually....feel free to consider yourself a
'friend'), in hopes that sufficient pressure will get the issue
resolved.
 4) publicly disclose the issue on the internet, which would
undoubtedly get this resolved (bugtraq, osvdb)
 5) suggest to product-owners to find a new product (which,
naturally, won't be well received).

what to do?

On a more theoretical (or theological, I suppose) level, I'm very
perturbed that a company would knowingly adopt risk on behalf of their
customers.  It seems that customers should be afforded the ability to
decide for themselves what is a risk, and what isn't; we are, after
all, paying for the software.  Many, if not MOST of the organizations
utilizing software like this store highly sensitive documents inside
it.  It is unlikely that any groups at our organization would accept
the risk, were it described to them in detail -- not for the type of
data they are accustomed to storing.

I suppose this email is a somewhat vague combination of #3, and #4,
but I'm not sure which option I should pursue in a less-vague manner.

Any advice would be appreciated.  Feel free to reply to me directly,
and not on-list if necessary.  And if you're interested in being a
'friend' organization, and seeing if this issue applies to you, by all
means contact me.  I'd hate to see this issue be escalated into a
breach at any of our respective organizations.



--
Matthew Wollenweber
mjw () cyberwart com<mailto:mjw () cyberwart com>
240-753-0281