Re: hard-to-sell vulnerabilities

You can show to your client the sensitive data (SSN) stored in the Web Server logs.

On 12/22/2010 04:36 PM, Alex Vargas wrote:
> Dan,
>     I would look at it from an audit point of view. Are they
> healthcare? If so it is obvious that they are passing PHI because of
> the bliant use if a variable SSN is going to be obvious for an
> attacker to exploit. Explaining that to a court given that HIPAA
> explicitly states information like that to be encrypted would maybe
> get them to think. Law suits are never nice. Just explain the letter
> of the law and I am sure they will reconsider . ..
> 
> On Tue, Dec 21, 2010 at 8:31 PM, Daniel Lubarov <[email protected]> wrote:
>> Visit the page in FireFox, close FF, navigate to the user's FF profile
>> in a shell, then run
>>
>> egrep -oa SSN=.{9} places.sqlite
>>
>> Is this not convincing enough?
>>
>> On Tue, Dec 21, 2010 at 4:21 PM, Brad Causey <[email protected]> wrote:
>>>
>>> It sounds like you are trying to create a vulnerability where there is
>>> an information disclosure issue. Is the fact that sensitive data is
>>> being passed in a url parameter not enough of an issue?
>>>
>>> On 12/21/10, Martín <[email protected]> wrote:
>>>> Hi,
>>>>
>>>> During the course of a pen-test or a simple bug-hunt on a web
>>>> application one may discover certain vulnerabilities or bad practices
>>>> on the target that may be common knowledge for us sec professionals
>>>> but can be tricky to "sell" to a non-technical client (manager).
>>>> Writing a PoC displaying the potential attack the application is
>>>> exposed to suffer may be a mandatory task in the documentation or
>>>> presentation phase. That's my case and I'm needing some help here
>>>> please.
>>>>
>>>> Case in hand: Found web script on some client's machine. Same URL for
>>>> all users which after being loaded redirects using js to another URL
>>>> with confidential information in GET parameters. For example:
>>>>
>>>> 1- User requests http://domain.com/script.php
>>>> 2- script.php contains this javascript code: location.href =
>>>> 'http://domain.com/anotherscript.php?SSN=xxx-xxxx-xxxx';
>>>> 3- The user visits
>>>> http://domain.com/anotherscript.php?SSN=xxx-xxxx-xxxx after that js
>>>> line is executed.
>>>>
>>>> Obviously script.php is first getting the social security number of
>>>> the authenticated user and apending it to the javascript code. We all
>>>> know how wrong is to include CSRF tokens or any other kind of secret
>>>> into any GET parameter (even worse something as confidential as some
>>>> user social security number), but... how can I write a PoC to convice
>>>> the client of this huge HUGE bad script.
>>>>
>>>>
>>>>
>>>> This is what I've tried so far:
>>>>
>>>> ** Finding some XSS in the app to show the client how can I get his
>>>> SSN after he clicks on a specially crafted link.
>>>>
>>>> As susprising as it may sound, I wasn't able to found any XSS for the
>>>> domain hosting the script. Application is fairly simple and there's
>>>> only a couple user inputs to work with, both of them properly escaped
>>>> :(
>>>>
>>>> ** Using CSS Browser History Hack to retrieve the URL the user visited
>>>> with the SSN appended
>>>>
>>>> Despite some recent browser updates begin to protect users from this
>>>> hack, there's still a huge userbase out there with vulnerable browsers
>>>> so this could be a plausible solution if it weren't for the huge key
>>>> space of a SSN (or any other long token). Still no luck.
>>>>
>>>> ** Some Javascript Kung-Fu (out of hope)
>>>>
>>>> Tried embedding vulnerable url into an iframe and overriding
>>>> Location.prototype to capture the new href value (after it loads) via
>>>> __defineSetter__ without luck. Reading the src attribute of an iframe
>>>> after it navigates away to the target url is prohibited too due to
>>>> browser security restrictions.
>>>>
>>>>
>>>> So guys, any other hints on how to market the problem to a client?
>>>> Having your SSN in your browser history or in server logs is not a
>>>> good thing.
>>>>
>>>> thanks
>>>>
>>>>
>>>>
>>>> This list is sponsored by Cenzic
>>>> --------------------------------------
>>>> Let Us Hack You. Before Hackers Do!
>>>> It's Finally Here - The Cenzic Website HealthCheck. FREE.
>>>> Request Yours Now!
>>>> http://www.cenzic.com/2009HClaunch_Securityfocus
>>>> --------------------------------------
>>>>
>>>>
>>>
>>> --
>>> Sent from my mobile device
>>>
>>> -Brad Causey
>>> CISSP, MCSE, C|EH, CIFI, CGSP
>>>
>>> http://www.owasp.org
>>> --
>>> "Si vis pacem, para bellum"
>>> --
>>>
>>>
>>>
>>> This list is sponsored by Cenzic
>>> --------------------------------------
>>> Let Us Hack You. Before Hackers Do!
>>> It's Finally Here - The Cenzic Website HealthCheck. FREE.
>>> Request Yours Now!
>>> http://www.cenzic.com/2009HClaunch_Securityfocus
>>> --------------------------------------
>>>
>>
>>
>>
>> This list is sponsored by Cenzic
>> --------------------------------------
>> Let Us Hack You. Before Hackers Do!
>> It's Finally Here - The Cenzic Website HealthCheck. FREE.
>> Request Yours Now!
>> http://www.cenzic.com/2009HClaunch_Securityfocus
>> --------------------------------------
>>
>>
> 
> 
> 



This list is sponsored by Cenzic
--------------------------------------
Let Us Hack You. Before Hackers Do!
It's Finally Here - The Cenzic Website HealthCheck. FREE.
Request Yours Now! 
http://www.cenzic.com/2009HClaunch_Securityfocus
--------------------------------------