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

[Jason Testart <jatestart () UWATERLOO CA>]

If your pentest discovered this, then I would think a real BadGuy could
discover it too.  I can't see how the vendor has a leg to stand on.
Obviously the security is insufficient if it was defeated by a pentest.
That's the whole point of pentesting!!!

Your decision on option #1 really depends on the level of risk you are
willing to accept.  What's the impact if a real BadGuy got hold of the
information?  Would your institution be comfortable with that outcome?
It sounds like the answer is no.  Do you have some way of mitigating the
risk?

I agree with you, the vendor has no business accepting the risk.  If the
vendor refuses to acknowledge this as a security issue, then the vendor
shouldn't have a problem if you shared the issue with other
institutions.  Right?

jt

--
Jason A. Testart, BMath               | Voice: +1-519-888-4567 x38393
Manager, IT Security                  | Fax: +1-519-884-4398
Information Systems and Technology    | http://ist.uwaterloo.ca/security
University of Waterloo, Waterloo, Ontario  N2L 3G1 CANADA

David Shettler 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.