|
Full Disclosure
mailing list archives
Re: Fwd: Google vulnerabilities with PoC
From: antisnatchor <antisnatchor () gmail com>
Date: Fri, 14 Mar 2014 18:07:43 +0000
LOL I don't work for Google and you can easily verify that.
Also, your XSS PoCs suck, they don't even trigger automatically but the
victim needs to
go with the mouse over the element LOL:
http://packetstormsecurity.com/files/125135/Visa-Europe-Cross-Site-Scripting.html
Lame
Nicholas Lemonias. wrote:
Quite funnily, most erratic comments originate from a @gmail.com
<http://gmail.com/> host. Does that mean that Google and Co are
attacking the researcher ?
On Fri, Mar 14, 2014 at 6:06 PM, Nicholas Lemonias.
<lem.nikolas () googlemail com <mailto:lem.nikolas () googlemail com>> wrote:
Quite funnily, most erratic comments originate from a @gmail.com
<http://gmail.com> host. Does that mean that Google and Co are
attacking the researcher ?
On Fri, Mar 14, 2014 at 6:04 PM, Mike Hale
<eyeronic.design () gmail com <mailto:eyeronic.design () gmail com>> wrote:
No, you're saying something's a vulnerability without showing any
indication of how it can be abused.
On Fri, Mar 14, 2014 at 11:00 AM, Nicholas Lemonias.
<lem.nikolas () googlemail com
<mailto:lem.nikolas () googlemail com>> wrote:
> The full-disclosure mailing list has really changed. It's
full of lamers
> nowdays aiming high.
>
>
>
>
>
> On Fri, Mar 14, 2014 at 5:58 PM, Nicholas Lemonias.
> <lem.nikolas () googlemail com
<mailto:lem.nikolas () googlemail com>> wrote:
>>
>> Says the script kiddie... Beg for some publicity. My
customers are FTSE
>> 100.
>>
>> ---------- Forwarded message ----------
>> From: Nicholas Lemonias. <lem.nikolas () googlemail com
<mailto:lem.nikolas () googlemail com>>
>> Date: Fri, Mar 14, 2014 at 5:58 PM
>> Subject: Re: [Full-disclosure] Fwd: Google vulnerabilities
with PoC
>> To: antisnatchor <antisnatchor () gmail com
<mailto:antisnatchor () gmail com>>
>>
>>
>> Says the script kiddie... Beg for some publicity. My
customers are FTSE
>> 100.
>>
>>
>>
>>
>> On Fri, Mar 14, 2014 at 5:55 PM, antisnatchor
<antisnatchor () gmail com <mailto:antisnatchor () gmail com>>
>> wrote:
>>>
>>> LOL you're hopeless.
>>> Good luck with your business. Brave customers!
>>>
>>> Cheers
>>> antisnatchor
>>>
>>> Nicholas Lemonias. wrote:
>>>
>>>
>>> People can read the report if they like. Can't you even do
basic things
>>> like reading a vulnerability report?
>>>
>>> Can't you see that the advisory is about writing arbitrary
files. If I
>>> was your boss I would fire you.
>>> ---------- Forwarded message ----------
>>> From: Nicholas Lemonias. <lem.nikolas () googlemail com
<mailto:lem.nikolas () googlemail com>>
>>> Date: Fri, Mar 14, 2014 at 5:43 PM
>>> Subject: Re: [Full-disclosure] Google vulnerabilities with PoC
>>> To: Mario Vilas <mvilas () gmail com <mailto:mvilas () gmail com>>
>>>
>>>
>>> People can read the report if they like. Can't you even do
basic things
>>> like reading a vulnerability report?
>>>
>>> Can't you see that the advisory is about writing arbitrary
files. If I
>>> was your boss I would fire you, with a good kick outta the
door.
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Mar 14, 2014 at 3:55 PM, Mario Vilas
<mvilas () gmail com <mailto:mvilas () gmail com>> wrote:
>>>>
>>>> On Fri, Mar 14, 2014 at 12:38 PM, Nicholas Lemonias.
>>>> <lem.nikolas () googlemail com
<mailto:lem.nikolas () googlemail com>> wrote:
>>>>>
>>>>> Jerome of Mcafee has made a very valid point on
revisiting separation
>>>>> of duties in this security instance.
>>>>>
>>>>> Happy to see more professionals with some skills. Some
others have
>>>>> also mentioned the feasibility for Denial of Service
attacks. Remote code
>>>>> execution by Social Engineering is also a prominent
scenario.
>>>>
>>>>
>>>> Actually, people have been pointing out exactly the
opposite. But if you
>>>> insist on believing you can DoS an EC2 by uploading
files, good luck to you
>>>> then...
>>>>
>>>>>
>>>>>
>>>>> If you can't tell that that is a vulnerability (probably
coming from a
>>>>> bunch of CEH's), I feel sorry for those consultants.
>>>>
>>>>
>>>> You're the only one throwing around certifications here.
I can no longer
>>>> tell if you're being serious or this is a massive prank.
>>>>
>>>>>
>>>>>
>>>>> Nicholas.
>>>>>
>>>>>
>>>>> On Fri, Mar 14, 2014 at 10:45 AM, Nicholas Lemonias.
>>>>> <lem.nikolas () googlemail com
<mailto:lem.nikolas () googlemail com>> wrote:
>>>>>>
>>>>>> We are on a different level perhaps. We do certainly
disagree on those
>>>>>> points.
>>>>>> I wouldn't hire you as a consultant, if you can't tell
if that is a
>>>>>> valid vulnerability..
>>>>>>
>>>>>>
>>>>>> Best Regards,
>>>>>> Nicholas Lemonias.
>>>>>>
>>>>>> On Fri, Mar 14, 2014 at 10:10 AM, Mario Vilas
<mvilas () gmail com <mailto:mvilas () gmail com>>
>>>>>> wrote:
>>>>>>>
>>>>>>> But do you have all the required EH certifications?
Try this one from
>>>>>>> the Institute for
>>>>>>> Certified Application Security Specialists:
http://www.asscert.com/
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Mar 14, 2014 at 7:41 AM, Nicholas Lemonias.
>>>>>>> <lem.nikolas () googlemail com
<mailto:lem.nikolas () googlemail com>> wrote:
>>>>>>>>
>>>>>>>> Thanks Michal,
>>>>>>>>
>>>>>>>> We are just trying to improve Google's security and
contribute to
>>>>>>>> the research community after all. If you are still on
EFNet give me a shout
>>>>>>>> some time.
>>>>>>>>
>>>>>>>> We have done so and consulted to hundreds of clients
including
>>>>>>>> Microsoft, Nokia, Adobe and some of the world's
biggest corporations. We are
>>>>>>>> also strict supporters of the ACM code of conduct.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Nicholas Lemonias.
>>>>>>>> AISec
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Mar 14, 2014 at 6:29 AM, Nicholas Lemonias.
>>>>>>>> <lem.nikolas () googlemail com
<mailto:lem.nikolas () googlemail com>> wrote:
>>>>>>>>>
>>>>>>>>> Hi Jerome,
>>>>>>>>>
>>>>>>>>> Thank you for agreeing on access control, and
separation of duties.
>>>>>>>>>
>>>>>>>>> However successful exploitation permits arbitrary
write() of any
>>>>>>>>> file of choice.
>>>>>>>>>
>>>>>>>>> I could release an exploit code in C Sharp or Python
that permits
>>>>>>>>> multiple file uploads of any file/types, if the
Google security team feels
>>>>>>>>> that this would be necessary. This is unpaid work,
so we are not so keen on
>>>>>>>>> that job.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Mar 14, 2014 at 6:04 AM, Jerome Athias
>>>>>>>>> <athiasjerome () gmail com
<mailto:athiasjerome () gmail com>> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi
>>>>>>>>>>
>>>>>>>>>> I concur that we are mainly discussing a
terminology problem.
>>>>>>>>>>
>>>>>>>>>> In the context of a Penetration Test or WAPT, this
is a Finding.
>>>>>>>>>> Reporting this finding makes sense in this context.
>>>>>>>>>>
>>>>>>>>>> As a professional, you would have to explain if/how
this finding
>>>>>>>>>> is a
>>>>>>>>>> Weakness*, a Violation (/Regulations, Compliance,
Policies or
>>>>>>>>>> Requirements[1])
>>>>>>>>>> * I would say Weakness + Exposure = Vulnerability.
Vulnerability +
>>>>>>>>>> Exploitability (PoC) = Confirmed Vulnerability that
needs Business
>>>>>>>>>> Impact and Risk Analysis
>>>>>>>>>>
>>>>>>>>>> So I would probably have reported this Finding as a
Weakness (and
>>>>>>>>>> not
>>>>>>>>>> Vulnerability. See: OWASP, WASC-TC, CWE),
explaining that it is
>>>>>>>>>> not
>>>>>>>>>> Best Practice (your OWASP link and Cheat Sheets),
and even if
>>>>>>>>>> mitigative/compensative security controls (Ref
Orange Book),
>>>>>>>>>> security
>>>>>>>>>> controls like white listing (or at least black
listing. see also
>>>>>>>>>> ESAPI) should be 1) part of the [1]security
requirements of a
>>>>>>>>>> proper
>>>>>>>>>> SDLC (Build security in) as per Defense-in-Depth
security
>>>>>>>>>> principles
>>>>>>>>>> and 2) used and implemented correctly.
>>>>>>>>>> NB: A simple Threat Model (i.e. list of CAPEC)
would be a solid
>>>>>>>>>> support to your report
>>>>>>>>>> This would help to evaluate/measure the risk (e.g.
CVSS).
>>>>>>>>>> Helping the decision/actions around this risk
>>>>>>>>>>
>>>>>>>>>> PS: interestingly, in this case, I'm not sure that
the Separation
>>>>>>>>>> of
>>>>>>>>>> Duties security principle was applied correctly by
Google in term
>>>>>>>>>> of
>>>>>>>>>> Risk Acceptance (which could be another Finding)
>>>>>>>>>>
>>>>>>>>>> So in few words, be careful with the terminology.
(don't always
>>>>>>>>>> say
>>>>>>>>>> vulnerability like the media say hacker, see
RFC1392) Use a CWE ID
>>>>>>>>>> (e.g. CWE-434, CWE-183, CWE-184 vs. CWE-616)
>>>>>>>>>>
>>>>>>>>>> My 2 bitcents
>>>>>>>>>> Sorry if it is not edible :)
>>>>>>>>>> Happy Hacking!
>>>>>>>>>>
>>>>>>>>>> /JA
>>>>>>>>>> https://github.com/athiasjerome/XORCISM
>>>>>>>>>>
>>>>>>>>>> 2014-03-14 7:19 GMT+03:00 Michal Zalewski
<lcamtuf () coredump cx <mailto:lcamtuf () coredump cx>>:
>>>>>>>>>> > Nicholas,
>>>>>>>>>> >
>>>>>>>>>> > I remember my early years in the infosec
community - and sadly,
>>>>>>>>>> > so do
>>>>>>>>>> > some of the more seasoned readers of this list
:-) Back then, I
>>>>>>>>>> > thought that the only thing that mattered is the
ability to find
>>>>>>>>>> > bugs.
>>>>>>>>>> > But after some 18 years in the industry, I now
know that there's
>>>>>>>>>> > an
>>>>>>>>>> > even more important and elusive skill.
>>>>>>>>>> >
>>>>>>>>>> > That skill boils down to having a robust mental
model of what
>>>>>>>>>> > constitutes a security flaw - and being able to
explain your
>>>>>>>>>> > thinking
>>>>>>>>>> > to others in a precise and internally consistent
manner that
>>>>>>>>>> > convinces
>>>>>>>>>> > others to act. We need this because the security
of a system
>>>>>>>>>> > can't be
>>>>>>>>>> > usefully described using abstract terms: even the
academic
>>>>>>>>>> > definitions
>>>>>>>>>> > ultimately boil down to saying "the system is
secure if it
>>>>>>>>>> > doesn't do
>>>>>>>>>> > the things we *really* don't want it to do".
>>>>>>>>>> >
>>>>>>>>>> > In this spirit, the term "vulnerability" is
generally reserved
>>>>>>>>>> > for
>>>>>>>>>> > behaviors that meet all of the following criteria:
>>>>>>>>>> >
>>>>>>>>>> > 1) The behavior must have negative consequences
for at least one
>>>>>>>>>> > of
>>>>>>>>>> > the legitimate stakeholders (users, service
owners, etc),
>>>>>>>>>> >
>>>>>>>>>> > 2) The consequences must be widely seen as
unexpected and
>>>>>>>>>> > unacceptable,
>>>>>>>>>> >
>>>>>>>>>> > 3) There must be a realistic chance of such a
negative outcome,
>>>>>>>>>> >
>>>>>>>>>> > 4) The behavior must introduce substantial new
risks that go
>>>>>>>>>> > beyond
>>>>>>>>>> > the previously accepted trade-offs.
>>>>>>>>>> >
>>>>>>>>>> > If we don't have that, we usually don't have a
case, no matter
>>>>>>>>>> > how
>>>>>>>>>> > clever the bug is.
>>>>>>>>>> >
>>>>>>>>>> > Cheers (and happy hunting!),
>>>>>>>>>> > /mz
>>>>>>>>>> >
>>>>>>>>>> > _______________________________________________
>>>>>>>>>> > Full-Disclosure - We believe in it.
>>>>>>>>>> > Charter:
http://lists.grok.org.uk/full-disclosure-charter.html
>>>>>>>>>> > Hosted and sponsored by Secunia - http://secunia.com/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Full-Disclosure - We believe in it.
>>>>>>>> Charter:
http://lists.grok.org.uk/full-disclosure-charter.html
>>>>>>>> Hosted and sponsored by Secunia - http://secunia.com/
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> "There's a reason we separate military and the police:
one fights the
>>>>>>> enemy of the state, the other serves and protects the
people. When the
>>>>>>> military becomes both, then the enemies of the state
tend to become the
>>>>>>> people."
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Full-Disclosure - We believe in it.
>>>>>>> Charter:
http://lists.grok.org.uk/full-disclosure-charter.html
>>>>>>> Hosted and sponsored by Secunia - http://secunia.com/
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> "There's a reason we separate military and the police:
one fights the
>>>> enemy of the state, the other serves and protects the
people. When the
>>>> military becomes both, then the enemies of the state tend
to become the
>>>> people."
>>>
>>>
>>>
>>> _______________________________________________
>>> Full-Disclosure - We believe in it.
>>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>>> Hosted and sponsored by Secunia - http://secunia.com/
>>>
>>>
>>> --
>>> Cheers
>>> Michele
>>>
>>
>>
>
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
--
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
--
Cheers
Michele
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
 By Date 
By Thread
Current thread:
(Thread continues...)
|
