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] [thread-next>] [day] [month] [year] [list]
Message-ID: <53234288.2020901@gmail.com>
Date: Fri, 14 Mar 2014 17:55:20 +0000
From: antisnatchor <antisnatchor@...il.com>
To: "Nicholas Lemonias." <lem.nikolas@...glemail.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Fwd:  Google vulnerabilities with PoC

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@...glemail.com
> <mailto:lem.nikolas@...glemail.com>>
> Date: Fri, Mar 14, 2014 at 5:43 PM
> Subject: Re: [Full-disclosure] Google vulnerabilities with PoC
> To: Mario Vilas <mvilas@...il.com <mailto:mvilas@...il.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@...il.com
> <mailto:mvilas@...il.com>> wrote:
>
>     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/

-- 
Cheers
Michele


Content of type "text/html" skipped

_______________________________________________
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