Full Disclosure mailing list archives

Previous By Date Next
Previous By Thread Next

Re: Fwd: Google vulnerabilities with PoC

From: "Nicholas Lemonias." <lem.nikolas () googlemail com>
Date: Fri, 14 Mar 2014 18:16:38 +0000
Google is a great service, but according to our proof of concepts (images,
poc's, codes) presented to Softpedia, and verified
by a couple of recognised experts including OWASP - that was a serious
vulnerability.

Now you can say whatever you like, and argue about it. You can argue about
the impact and whatsoever , but that's not the way to deal with security
issues.




On Fri, Mar 14, 2014 at 6:13 PM, Nicholas Lemonias. <
lem.nikolas () googlemail com> wrote:


Security vulnerabilities need to be published and reported. That's the
spirit.

Attacking the researcher, won't make it go away.


On Fri, Mar 14, 2014 at 6:12 PM, Julius Kivimäki <
julius.kivimaki () gmail com> wrote:


Dude, seriously. Just stop.


2014-03-14 20:02 GMT+02:00 Nicholas Lemonias. <lem.nikolas () googlemail com

:


You can't even find a cross site scripting on google.


Find a vuln on Google seems like a dream to some script kiddies.


On Fri, Mar 14, 2014 at 6:00 PM, Nicholas Lemonias. <
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> wrote:


Says the script kiddie... Beg for some publicity. My customers are
FTSE 100.

---------- Forwarded message ----------
From: Nicholas Lemonias. <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>


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>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>
Date: Fri, Mar 14, 2014 at 5:43 PM
Subject: Re: [Full-disclosure] Google vulnerabilities with PoC
To: Mario Vilas <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>wrote:


On Fri, Mar 14, 2014 at 12:38 PM, Nicholas Lemonias. <
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> 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>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> 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> 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> 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

:
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/







_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Previous By Date Next
Previous By Thread Next

Current thread: