lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <532349E1.70404@tmacuk.co.uk>
Date: Fri, 14 Mar 2014 18:26:41 +0000
From: Thomas MacKenzie <thomas@...cuk.co.uk>
To: "Nicholas Lemonias." <lem.nikolas@...glemail.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Fwd: Google vulnerabilities with PoC


You have a Googlemail account. How do we know you don't work for Google
too...

Inception type stuff going on here.
> Nicholas Lemonias. <mailto:lem.nikolas@...glemail.com>
> 14 March 2014 18:17
> 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. 
>
>
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
> Nicholas Lemonias. <mailto:lem.nikolas@...glemail.com>
> 14 March 2014 18:16
> 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. 
>  
>  
>
>
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
> Nicholas Lemonias. <mailto:lem.nikolas@...glemail.com>
> 14 March 2014 18:13
> Security vulnerabilities need to be published and reported. That's the
> spirit.
>  
> Attacking the researcher, won't make it go away.
>
>
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
> Mario Vilas <mailto:mvilas@...il.com>
> 14 March 2014 15:55
> On Fri, Mar 14, 2014 at 12:38 PM, Nicholas Lemonias.
> <lem.nikolas@...glemail.com <mailto:lem.nikolas@...glemail.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@...glemail.com <mailto:lem.nikolas@...glemail.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@...il.com <mailto:mvilas@...il.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@...glemail.com
>             <mailto:lem.nikolas@...glemail.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@...glemail.com
>                 <mailto:lem.nikolas@...glemail.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@...il.com
>                     <mailto:athiasjerome@...il.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@...edump.cx
>                         <mailto:lcamtuf@...edump.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/
> Nicholas Lemonias. <mailto:lem.nikolas@...glemail.com>
> 14 March 2014 11:38
> 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.
>  
> If you can't tell that that is a vulnerability (probably coming from a
> bunch of CEH's), I feel sorry for those consultants.
>  
> Nicholas.
>
>
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/

Content of type "text/html" skipped

Download attachment "compose-unknown-contact.jpg" of type "image/jpeg" (770 bytes)

Download attachment "postbox-contact.jpg" of type "image/jpeg" (1295 bytes)

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ