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/
