subject:"Re\: \[Full\-disclosure\] Google vulnerabilities with PoC"

On Thu, Mar 13, 2014 at 10:30 PM, Nicholas Lemonias. 
lem.niko...@googlemail.com wrote:

 We confirm this to be a valid vulnerability for the following reasons.

 The access control subsystem is defeated, resulting to arbitrary write
 access of any file of choice.

 1. You Tube defines which file types are permitted to be uploaded.


And...?



 2. Exploitation is achieved by circumvention of web-based security
 controls (namely http forms, which is a weak security measure). However,
 exploitation of the issue results to unrestricted file uploads (any file of
 choice ). Remote code execution may be possible either through social
 engineering , or by stochastically rewriting an existing file-structure in
 the CDN.


So in ohter words, you haven't proven it. The upload in itself is not a
vulnerability (and if you understood that it is, please read again that
OWASP document).



 3. This directly impacts the integrity of the service since modification
 of information occurs by circumvention. Renaming the uploaded files can be
 achieved through YouTube's inherent video manager.


How does it impact the integrity? Again, unexpected functionality does not
necessarily equal exploitation.



 4. Denial of Service  attacks are feasible since we bypass all security
 restrictions. This directly impacts the availability of the service.


Not proven either. At this point I feel you're just making stuff up. All
you did was upload stuff you can't download afterwards.



 5. Malware propagation is possible, if the planted code get's executed
 through social engineering or by re-writing a valid file system structure.



Again, you need to be able to download the stuff you uploaded, and have it
executed directly. Otherwise you could do the same thing more efficiently
with Google Drive.



 6) All uploaded files can be downloaded through Google Take Out, if past
 the Content ID filtering algorithm (through file header obfuscation and
 encryption).


You need to explain how that is an attack vector.




 Best Regards,
 Nicholas Lemonias
 Advanced Information Security Corp.






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

Re: [Full-disclosure] Google vulnerabilities with PoC

2014-03-14 Thread Julius Kivimäki

Look, you keep calling it a vulnerability with 0 evidence that it's even
exploitable. Until you can prove otherwise this is like speculating the
potential security repercussions of uploading files to EC2 (Which would
probably have potential to be much more severe than what you're discussing
here since javascript uploaded to ec2 could actually get executed by
someones browser)

You keep throwing around keywords like OWASP, OSI, security best
practices as if they actually make a difference here. Truth is there's no
reason to believe that what you have discovered here is exploitable. This
mostly seems like a desperate attempt of getting money off of google and
your name in some publication shitty enough to not do any fact checking
(eg. softpedia) .


2014-03-13 21:48 GMT+02:00 Nicholas Lemonias. lem.niko...@googlemail.com:

 Julius Kivimaki, your disbelief in OWASP, CEH, Journalists and anything
 you may, or may not be qualified to question amazes. But everyone's opinion
 is of course respected.

 I normally don't provide security lessons via e-mail and full-disclosure,
 however you seem not to understand the security report fully and some core
 principles. If you can't see what information security best practises, the
 OSI/network model and self-automata propagation has anything to do with
 arbitrary write permissions to a remote network leveraging from the
 application layer, then me and you have nothing to talk about.

 As for the exploitability of this vulnerability, you will never know until
 you try. And we have tried it , and seem to know better.

 I suggest you read the report again.

 Thank you.


 -- Forwarded message --
 From: Nicholas Lemonias. lem.niko...@googlemail.com
 Date: Thu, Mar 13, 2014 at 7:47 PM
 Subject: Re: [Full-disclosure] Google vulnerabilities with PoC
 To: Julius Kivimäki julius.kivim...@gmail.com


 Julius Kivimaki, your disbelief in OWASP, CEH, Journalists and anything
 you may, or may not be qualified to question amazes. But everyone's opinion
 is of course respected.

 I normally don't provide security lessons via e-mail and full-disclosure,
 however you seem not to understand the security report fully and some core
 principles. If you can't see what information security best practises, the
 OSI/network model and self-automata propagation has anything to do with
 arbitrary write permissions to a remote network leveraging from the
 application layer, then me and you have nothing to talk about.

 As for the exploitability of this vulnerability, you will never know until
 you try. And we have tried it , and seem to know better.

 I suggest you read the report again.

 Thank you.



 On Thu, Mar 13, 2014 at 7:02 PM, Julius Kivimäki 
 julius.kivim...@gmail.com wrote:

 I don't see what OSI model has to do with anything here. Why is arbitrary
 file upload to youtube CDN any worse than to google drive CDN? And how will
 your self-executing encrypted virus like Cryptolocker end up getting
 executed anyways? And cryptolocker was definitely not self-executing, but
 spread via email attachments (excluding the boring USB spread
 functionality).

 What you have here is not a vulnerability, just give up. And stop trying
 to get journalists like Eduard Kovacs to spread your BS.

 2014-03-13 19:10 GMT+02:00 Nicholas Lemonias. lem.niko...@googlemail.com
 :

 Hello Julius,

 I appreciate your interest to learn more. OWASP is quite credible, and
 has gained some international recognition. It is a benchmark for many
 vendors. I suggest you to read on OSI/7-Layer Model. A website may disallow
 uploads of certain file types for security reasons, and let's assume at the
 application layer. If we manage to get past the security controls, that
 means  we can write unrestrictedly any type of file to the remote network.
 That also means that we get past their firewall, since the communication is
 through HTTP (port 80). CDN nodes are deployed to multiple colocation
 (thousands of nodes and thousands of servers across the world). The files
 (let's say a self-executing encrypted virus like Cryptolocker? ) are cached
 deeply in the network across thousands of servers.


 On Thu, Mar 13, 2014 at 5:07 PM, Nicholas Lemonias. 
 lem.niko...@googlemail.com wrote:

 Hello Julius,

 I appreciate your interest to learn more. OWASP is quite credible, and
 has gained some international recognition. It is a benchmark for many
 vendors. I suggest you to read on OSI/7-Layer Model. A website may disallow
 uploads of certain file types for security reasons, and let's assume at the
 application layer. If we manage to get past the security controls, that
 means  we can write unrestrictedly any type of file to the remote network.
 That also means that we get past their firewall, since the communication is
 through HTTP (port 80). CDN nodes are deployed to multiple colocation
 (thousands of nodes and thousands of servers across the world). The files
 are cached deep in the network structures to thousands

Re: [Full-disclosure] Google vulnerabilities with PoC

We confirm this to be a valid vulnerability for the following reasons.

The access control subsystem is defeated, resulting to arbitrary write
access of any file of choice.

1. You Tube defines which file types are permitted to be uploaded.

2. Exploitation is achieved by circumvention of web-based security controls
(namely http forms, which is a weak security measure). However,
exploitation of the issue results to unrestricted file uploads (any file of
choice ). Remote code execution may be possible either through social
engineering , or by stochastically rewriting an existing file-structure in
the CDN.

3. This directly impacts the integrity of the service since modification of
information occurs by circumvention. Renaming the uploaded files can be
achieved through YouTube's inherent video manager.

4. Denial of Service  attacks are feasible since we bypass all security
restrictions. This directly impacts the availability of the service.

5. Malware propagation is possible, if the planted code get's executed
through social engineering or by re-writing a valid file system structure.


6) All uploaded files can be downloaded through Google Take Out, if past
the Content ID filtering algorithm (through file header obfuscation and
encryption).


It is pertinent to note that all publications are made to help mature the
practise and we application security.

Best Regards,
Nicholas Lemonias
Advanced Information Security Corp.

EOF


On Thu, Mar 13, 2014 at 11:06 PM, Julius Kivimäki julius.kivim...@gmail.com
 wrote:

 Look, you keep calling it a vulnerability with 0 evidence that it's even
 exploitable. Until you can prove otherwise this is like speculating the
 potential security repercussions of uploading files to EC2 (Which would
 probably have potential to be much more severe than what you're discussing
 here since javascript uploaded to ec2 could actually get executed by
 someones browser)

 You keep throwing around keywords like OWASP, OSI, security best
 practices as if they actually make a difference here. Truth is there's no
 reason to believe that what you have discovered here is exploitable. This
 mostly seems like a desperate attempt of getting money off of google and
 your name in some publication shitty enough to not do any fact checking
 (eg. softpedia) .


 2014-03-13 21:48 GMT+02:00 Nicholas Lemonias. lem.niko...@googlemail.com
 :

 Julius Kivimaki, your disbelief in OWASP, CEH, Journalists and anything
 you may, or may not be qualified to question amazes. But everyone's opinion
 is of course respected.

 I normally don't provide security lessons via e-mail and full-disclosure,
 however you seem not to understand the security report fully and some core
 principles. If you can't see what information security best practises, the
 OSI/network model and self-automata propagation has anything to do with
 arbitrary write permissions to a remote network leveraging from the
 application layer, then me and you have nothing to talk about.

 As for the exploitability of this vulnerability, you will never know
 until you try. And we have tried it , and seem to know better.

 I suggest you read the report again.

 Thank you.


 -- Forwarded message --
 From: Nicholas Lemonias. lem.niko...@googlemail.com
 Date: Thu, Mar 13, 2014 at 7:47 PM
 Subject: Re: [Full-disclosure] Google vulnerabilities with PoC
 To: Julius Kivimäki julius.kivim...@gmail.com


 Julius Kivimaki, your disbelief in OWASP, CEH, Journalists and anything
 you may, or may not be qualified to question amazes. But everyone's opinion
 is of course respected.

 I normally don't provide security lessons via e-mail and full-disclosure,
 however you seem not to understand the security report fully and some core
 principles. If you can't see what information security best practises, the
 OSI/network model and self-automata propagation has anything to do with
 arbitrary write permissions to a remote network leveraging from the
 application layer, then me and you have nothing to talk about.

 As for the exploitability of this vulnerability, you will never know
 until you try. And we have tried it , and seem to know better.

 I suggest you read the report again.

 Thank you.



 On Thu, Mar 13, 2014 at 7:02 PM, Julius Kivimäki 
 julius.kivim...@gmail.com wrote:

 I don't see what OSI model has to do with anything here. Why is
 arbitrary file upload to youtube CDN any worse than to google drive CDN?
 And how will your self-executing encrypted virus like Cryptolocker
 end up getting executed anyways? And cryptolocker was definitely not
 self-executing, but spread via email attachments (excluding the boring
 USB spread functionality).

 What you have here is not a vulnerability, just give up. And stop trying
 to get journalists like Eduard Kovacs to spread your BS.

 2014-03-13 19:10 GMT+02:00 Nicholas Lemonias. 
 lem.niko...@googlemail.com:

 Hello Julius,

 I appreciate your interest to learn more. OWASP is quite credible, and
 has gained

Re: [Full-disclosure] Google vulnerabilities with PoC

Here's my evidence.

Live Proof Of Concept
==
http://upload.youtube.com/?authuser=0upload_id=AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aworigin=CiNodHRwOi8vd3d3LnlvdXR1YmUuY29tL3VwbG9hZC9ydXBpbxINdmlkZW8tdXBsb2Fkcw

{sessionStatus:{state:FINALIZED,externalFieldTransfers:[{name:file,status:COMPLETED,bytesTransferred:113,bytesTotal:113,formPostInfo:{url:
http://www.youtube.com/upload/rupio?authuser=0\u0026upload_id=AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw\u0026file_id=000
,cross_domain_url:
http://upload.youtube.com/?authuser=0\u0026upload_id=AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw\u0026origin=CiNodHRwOi8vd3d3LnlvdXR1YmUuY29tL3VwbG9hZC9ydXBpbxINdmlkZW8tdXBsb2Fkcw},content_type:text/x-sh}],additionalInfo:{uploader_service.GoogleRupioAdditionalInfo:{completionInfo:{status:SUCCESS,customerSpecificInfo:{status:
ok, video_id:
KzKDtijwHFI,upload_id:AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw}}

The above proof of concept demonstrates :

1. We have bypassed the security controls in Youtube and uploaded an
unexpected file type.
2. The file is persistent and has not been deleted by YouTube.
3. It can be queried for information since it is assigned a unique
upload_id.
4. It's successfully uploaded to youtube.com As you can see it give out
the total bytes written to the remote network.
5. content_type:text/x-sh}] --- The file is a shell
script script named 'file'
6. It can be enumerated by a non-authenticated user, remotely.

On Fri, Mar 14, 2014 at 2:40 AM, Nicholas Lemonias.
lem.niko...@googlemail.com wrote:

Are you a Google employee...I wonder?

There is nothing else to be said regarding this. Our research for remote
code execution continues and will let you and Google know once that is
confirmed; through the coordinated security program.

And please OWASP, is recognised worldwide.

Best Regards,
Nicholas Lemonias

On Thu, Mar 13, 2014 at 11:06 PM, Julius Kivimäki
julius.kivim...@gmail.com wrote:

Look, you keep calling it a vulnerability with 0 evidence that it's
even exploitable. Until you can prove otherwise this is like speculating
the potential security repercussions of uploading files to EC2 (Which would
probably have potential to be much more severe than what you're discussing
here since javascript uploaded to ec2 could actually get executed by
someones browser)

You keep throwing around keywords like OWASP, OSI, security best
practices as if they actually make a difference here. Truth is there's no
reason to believe that what you have discovered here is exploitable. This
mostly seems like a desperate attempt of getting money off of google and
your name in some publication shitty enough to not do any fact checking
(eg. softpedia) .

2014-03-13 21:48 GMT+02:00 Nicholas Lemonias. lem.niko...@googlemail.com
:

Julius Kivimaki, your disbelief in OWASP, CEH, Journalists and anything
you may, or may not be qualified to question amazes. But everyone's opinion
is of course respected.

I normally don't provide security lessons via e-mail and
full-disclosure, however you seem not to understand the security report
fully and some core principles. If you can't see what information security
best practises, the OSI/network model and self-automata propagation has
anything to do with arbitrary write permissions to a remote network
leveraging from the application layer, then me and you have nothing to talk
about.

As for the exploitability of this vulnerability, you will never know
until you try. And we have tried it , and seem to know better.

I suggest you read the report again.

Thank you.

-- Forwarded message --
From: Nicholas Lemonias. lem.niko...@googlemail.com
Date: Thu, Mar 13, 2014 at 7:47 PM
Subject: Re: [Full-disclosure] Google vulnerabilities with PoC
To: Julius Kivimäki julius.kivim...@gmail.com

Julius Kivimaki, your disbelief in OWASP, CEH, Journalists and anything
you may, or may not be qualified to question amazes. But everyone's opinion
is of course respected.

As for the exploitability of this vulnerability, you will never know
until you try. And we have tried it , and seem to know better.

I suggest you read the report again.

Thank you.

On Thu, Mar 13, 2014 at 7:02 PM, Julius Kivimäki
julius.kivim...@gmail.com wrote:

I don't see what OSI model has

Re: [Full-disclosure] Google vulnerabilities with PoC

Zakewski,

Thank you for your e-mail. I welcome all opinions, that are backed up by
evidences.

I am not just a security researcher, I am also an academic in the field and
lecturer.

However, from an academic perspective, when it comes to certain
security designs the mere existence of unvalidated requests is symptomatic
of deeper code problems. Thus, in academia such definitions are vague,
unless they are either backed-up by original, incisive research, or by
existing subject matter literature which is widely accepted.

In terms of what constitutes a security vulnerability, it is a weakness in
a product or service that may allow an attacker to compromise the (C-I-A)
Confidentiality, Integrity and Availability of that same service, and I bet
you 've heard this many times before. Adequate security requirements entail
properties of 1) confidentiality, 2) integrity, 3) availability
 but also 4) authorization , 5) non-repudiation and 6) authentication.

Integrity: Integrity refers to the trustworthiness of a resource. An
attacker exploits a weakness in a service to modify it silently and without
authorization means is compromising the integrity of that service.

 Example: A weakness that allows an administrator to change the permission
sets on a file , that is not a security vulnerability because an
administrator already has this capability. However if a weakness allowed an
unprivileged user to do the same thing (say to write arbitrary files to a
remote service), that would constitute to a security vulnerability.

Availability*:* Availability refers to the ability to access a resource. An
attacker that exploits a weakness in a service, denying appropriate user
access to it, is thus compromising the availability of that particular
service. In our case a Denial of Service is feasible, because the uploaded
files are persistent and can  lead to resource exhaustion.

Example: A weakness that enables an attacker  to cause a server to fail
would constitute a vulnerability, since the attacker denies resources
pertinent to that service. Resource exhaustion is possible.

Confidentiality: Confidentiality refers to the disclosure of information,
to unauthorised parties. However this is by no means the only property
required for security. In this case just because we haven't accessed some
files, that does not mean that the service is secure.

Authorization: Refers to the process of determining which 'principals' have
access and to which 'objects'. Access control is a type of authorization,
hence its name. In case of the API upload functionality, a script is loaded
and somewhere a write() function is called. The access control was weak
since it was web-based. We could arbitrary write() any file of choice to
the system as a result, something that only an administrator with full
permission sets should be able to do.

admin.youtube.com is the admin login.


On Fri, Mar 14, 2014 at 4:19 AM, Michal Zalewski lcam...@coredump.cxwrote:

 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/

Re: [Full-disclosure] Google vulnerabilities with PoC

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 athiasjer...@gmail.comwrote:

 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 lcam...@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/

Re: [Full-disclosure] Google vulnerabilities with PoC

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.niko...@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 athiasjer...@gmail.comwrote:

 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 lcam...@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/

Re: [Full-disclosure] Google vulnerabilities with PoC

Are you a Google employee...I wonder?

There is nothing else to be said regarding this. Our research for remote
code execution continues and will let you and Google  know once that is
confirmed; through the coordinated security program.

And please OWASP, is recognised worldwide.


Best Regards,
Nicholas Lemonias


On Thu, Mar 13, 2014 at 11:06 PM, Julius Kivimäki julius.kivim...@gmail.com
 wrote:

 Look, you keep calling it a vulnerability with 0 evidence that it's even
 exploitable. Until you can prove otherwise this is like speculating the
 potential security repercussions of uploading files to EC2 (Which would
 probably have potential to be much more severe than what you're discussing
 here since javascript uploaded to ec2 could actually get executed by
 someones browser)

 You keep throwing around keywords like OWASP, OSI, security best
 practices as if they actually make a difference here. Truth is there's no
 reason to believe that what you have discovered here is exploitable. This
 mostly seems like a desperate attempt of getting money off of google and
 your name in some publication shitty enough to not do any fact checking
 (eg. softpedia) .


 2014-03-13 21:48 GMT+02:00 Nicholas Lemonias. lem.niko...@googlemail.com
 :

 Julius Kivimaki, your disbelief in OWASP, CEH, Journalists and anything
 you may, or may not be qualified to question amazes. But everyone's opinion
 is of course respected.

 I normally don't provide security lessons via e-mail and full-disclosure,
 however you seem not to understand the security report fully and some core
 principles. If you can't see what information security best practises, the
 OSI/network model and self-automata propagation has anything to do with
 arbitrary write permissions to a remote network leveraging from the
 application layer, then me and you have nothing to talk about.

 As for the exploitability of this vulnerability, you will never know
 until you try. And we have tried it , and seem to know better.

 I suggest you read the report again.

 Thank you.


 -- Forwarded message --
 From: Nicholas Lemonias. lem.niko...@googlemail.com
 Date: Thu, Mar 13, 2014 at 7:47 PM
 Subject: Re: [Full-disclosure] Google vulnerabilities with PoC
 To: Julius Kivimäki julius.kivim...@gmail.com


 Julius Kivimaki, your disbelief in OWASP, CEH, Journalists and anything
 you may, or may not be qualified to question amazes. But everyone's opinion
 is of course respected.

 I normally don't provide security lessons via e-mail and full-disclosure,
 however you seem not to understand the security report fully and some core
 principles. If you can't see what information security best practises, the
 OSI/network model and self-automata propagation has anything to do with
 arbitrary write permissions to a remote network leveraging from the
 application layer, then me and you have nothing to talk about.

 As for the exploitability of this vulnerability, you will never know
 until you try. And we have tried it , and seem to know better.

 I suggest you read the report again.

 Thank you.



 On Thu, Mar 13, 2014 at 7:02 PM, Julius Kivimäki 
 julius.kivim...@gmail.com wrote:

 I don't see what OSI model has to do with anything here. Why is
 arbitrary file upload to youtube CDN any worse than to google drive CDN?
 And how will your self-executing encrypted virus like Cryptolocker
 end up getting executed anyways? And cryptolocker was definitely not
 self-executing, but spread via email attachments (excluding the boring
 USB spread functionality).

 What you have here is not a vulnerability, just give up. And stop trying
 to get journalists like Eduard Kovacs to spread your BS.

 2014-03-13 19:10 GMT+02:00 Nicholas Lemonias. 
 lem.niko...@googlemail.com:

 Hello Julius,

 I appreciate your interest to learn more. OWASP is quite credible, and
 has gained some international recognition. It is a benchmark for many
 vendors. I suggest you to read on OSI/7-Layer Model. A website may disallow
 uploads of certain file types for security reasons, and let's assume at the
 application layer. If we manage to get past the security controls, that
 means  we can write unrestrictedly any type of file to the remote network.
 That also means that we get past their firewall, since the communication is
 through HTTP (port 80). CDN nodes are deployed to multiple colocation
 (thousands of nodes and thousands of servers across the world). The files
 (let's say a self-executing encrypted virus like Cryptolocker? ) are cached
 deeply in the network across thousands of servers.


 On Thu, Mar 13, 2014 at 5:07 PM, Nicholas Lemonias. 
 lem.niko...@googlemail.com wrote:

 Hello Julius,

 I appreciate your interest to learn more. OWASP is quite credible, and
 has gained some international recognition. It is a benchmark for many
 vendors. I suggest you to read on OSI/7-Layer Model. A website may 
 disallow
 uploads of certain file types for security reasons, and let's assume

Re: [Full-disclosure] Google vulnerabilities with PoC

You're still missing the attack vector (and the point of the discussion
too, but that's painfully obvious).

On Fri, Mar 14, 2014 at 4:21 AM, Nicholas Lemonias.
lem.niko...@googlemail.com wrote:

Here's my evidence.

Live Proof Of Concept
==

http://upload.youtube.com/?authuser=0upload_id=AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aworigin=CiNodHRwOi8vd3d3LnlvdXR1YmUuY29tL3VwbG9hZC9ydXBpbxINdmlkZW8tdXBsb2Fkcw

The above proof of concept demonstrates :

On Fri, Mar 14, 2014 at 2:40 AM, Nicholas Lemonias.
lem.niko...@googlemail.com wrote:

Are you a Google employee...I wonder?

There is nothing else to be said regarding this. Our research for remote
code execution continues and will let you and Google know once that is
confirmed; through the coordinated security program.

And please OWASP, is recognised worldwide.

Best Regards,
Nicholas Lemonias

On Thu, Mar 13, 2014 at 11:06 PM, Julius Kivimäki
julius.kivim...@gmail.com wrote:

2014-03-13 21:48 GMT+02:00 Nicholas Lemonias.
lem.niko...@googlemail.com:

Julius Kivimaki, your disbelief in OWASP, CEH, Journalists and anything
you may, or may not be qualified to question amazes. But everyone's opinion
is of course respected.

As for the exploitability of this vulnerability, you will never know
until you try. And we have tried it , and seem to know better.

I suggest you read the report again.

Thank you.

Julius Kivimaki, your disbelief in OWASP, CEH, Journalists and anything
you may, or may not be qualified to question amazes. But everyone's opinion
is of course respected.

As for the exploitability of this vulnerability, you will never know
until you

Re: [Full-disclosure] Google vulnerabilities with PoC

2014-03-14 Thread Pedro Ribeiro

On 13 Mar 2014 14:30, Nicholas Lemonias. lem.niko...@googlemail.com
wrote:

 I suggest you to read on Content Delivery Network Architectures .

  YouTube.com populates and distributes stored files to multiple servers
 through a CDN (Content Delivery Architecture), where each video uses more
 than one machine (hosted by a cluster). Less populated video files are
 normally stored in various colocation sites. The YouTube architecture uses
 databases for storing metadata information of all uploaded files.

 https://www.owasp.org/index.php/Unrestricted_File_Upload


Being a CDN means it is very hard to find out where your file went.

I agree with was said on this thread by other people.

As an external penetration testing consultant, I would put this on a client
report as a low risk finding / possible vulnerability and recommend it to
be fixed.

As an internal vulnerability manager I would push the developers to fix it,
but I would give it a low priority and only real press then once all the
higher priority ones have been fixed.

However in the real world it is not a vulnerability, and don't expect
Google to pay you for it.

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

Re: [Full-disclosure] Google vulnerabilities with PoC

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.niko...@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.niko...@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 athiasjer...@gmail.comwrote:

 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 lcam...@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

Re: [Full-disclosure] Google vulnerabilities with PoC

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 mvi...@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.niko...@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.niko...@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 
 athiasjer...@gmail.comwrote:

 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 lcam...@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/




 ___

Re: [Full-disclosure] Google vulnerabilities with PoC

2014-03-14 Thread antisnatchor



Nicholas Lemonias. 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.

LOL you mean 1, maybe 2 hours, you need to write (and test) a
Ruby/Python script.
I don't know your hourly rate, but wouldn't that be like 200$? Is that
really worth?

Also, the point that this 'bug' counts as a valid finding when you do
pentests, well it's a long story.
If you see reports from the big4 companies, you can always notice info
findings as in TRACE enabled
(you can't 'exploit' that through XHR from years anyways), but simply
you wouldn't expect Google to pay you
for such a bug. Same with this bug.

Cheers
antisnatchor



 On Fri, Mar 14, 2014 at 6:04 AM, Jerome Athias athiasjer...@gmail.comwrote:

 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 lcam...@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/

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

Re: [Full-disclosure] Google vulnerabilities with PoC

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.


On Fri, Mar 14, 2014 at 10:45 AM, Nicholas Lemonias. 
lem.niko...@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 mvi...@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.niko...@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.niko...@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 
 athiasjer...@gmail.comwrote:

 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 lcam...@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

Re: [Full-disclosure] Google vulnerabilities with PoC

Live Proof Of Concept
==
http://upload.youtube.com/?authuser=0upload_id=
AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--
uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aworigin=
CiNodHRwOi8vd3d3LnlvdXR1YmUuY29tL3VwbG9hZC9ydXBpbxINdmlkZW8tdXBsb2Fkcw

{sessionStatus:{state:FINALIZED,externalFieldTransfers:[{name:file,status:COMPLETED,bytesTransferred:113,bytesTotal:113,formPostInfo:{url:
http://www.youtube.com/upload/rupio?authuser=0\u0026upload_id=
AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--
uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw\u0026file_id=000
,cross_domain_url:http://upload.youtube.com/?authuser=0\u0026upload_id=
AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--
uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw\u0026origin=
CiNodHRwOi8vd3d3LnlvdXR1YmUuY29tL3VwbG9hZC9ydXBpbxINdmlkZW8tdXBsb2Fkcw},content_type:text/x-sh}],additionalInfo:{uploader_service.GoogleRupioAdditionalInfo:{completionInfo:{status:SUCCESS,customerSpecificInfo:{status:
ok, video_id:
KzKDtijwHFI,upload_id:AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw}}

The above proof of concept demonstrates :

So that is a proof that the data are persistent.

On Fri, Mar 14, 2014 at 10:45 AM, Nicholas Lemonias.
lem.niko...@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 mvi...@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.niko...@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.niko...@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 athiasjer...@gmail.com
wrote:

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!

Re: [Full-disclosure] Google vulnerabilities with PoC

2014-03-14 Thread Sergio 'shadown' Alvarez

Dear Nicholas Lemonias,

I don't use to get in these scrapy discussions, but yeah you are in a 
completetly different level if you compare yourself with Mario.
You are definitely a Web app/metasploit-user guy and pick up a discussion with 
a binary and memory corruption ninja exploit writter like Mario. You should 
know your place and shut up. Period.

Btw, if you dare discussing with a beast like lcamtuf, you are definitely out 
of your mind.

Cheers,
  Sergio.
-- Sergio

On Mar 14, 2014, Nicholas Lemonias. lem.niko...@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 mvi...@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.niko...@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.niko...@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
athiasjer...@gmail.comwrote:

 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 lcam...@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

Re: [Full-disclosure] Google vulnerabilities with PoC

On Fri, Mar 14, 2014 at 12:38 PM, Nicholas Lemonias. 
lem.niko...@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.niko...@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 mvi...@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.niko...@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.niko...@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 athiasjer...@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 lcam...@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

Re: [Full-disclosure] Google vulnerabilities with PoC

LOL, thanks for the undeserved praise! xD


On Fri, Mar 14, 2014 at 2:50 PM, Sergio 'shadown' Alvarez shad...@gmail.com
 wrote:

 Dear Nicholas Lemonias,

 I don't use to get in these scrapy discussions, but yeah you are in a
 completetly different level if you compare yourself with Mario.
 You are definitely a Web app/metasploit-user guy and pick up a discussion
 with a binary and memory corruption ninja exploit writter like Mario. You
 should know your place and shut up. Period.

 Btw, if you dare discussing with a beast like lcamtuf, you are definitely
 out of your mind.

 Cheers,
   Sergio.
 -- Sergio


 On Mar 14, 2014, Nicholas Lemonias. lem.niko...@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 mvi...@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.niko...@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.niko...@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 athiasjer...@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 lcam...@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

Re: [Full-disclosure] Google vulnerabilities with PoC

Try learning how to properly send emails before critizicing anyone, pal. ;)


On Fri, Mar 14, 2014 at 6:44 PM, Nicholas Lemonias. 
lem.niko...@googlemail.com 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.niko...@googlemail.com
  Date: Fri, Mar 14, 2014 at 5:43 PM
 Subject: Re: [Full-disclosure] Google vulnerabilities with PoC
 To: Mario Vilas mvi...@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 mvi...@gmail.com wrote:

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

Re: [Full-disclosure] Google vulnerabilities with PoC

2014-03-14 Thread Alfredo Ortega

Mario has years of experience (more than 10 in fact) in exploit writing
and vulnerability assessment. I would consider his position on the subject.

If you don't believe me, Argentina extended me certifications that
proves that I can tell who has vulnerability assesment skills and who
does not.

If you don't believe in Argentina, you should know the ONU accepts it as
a sovereign independent country.

That is the complete certificate chain proving you that Mario is not an
idiot as you inferred.

Best regards,

Alfred


On 03/14/2014 10:50 AM, Sergio 'shadown' Alvarez wrote:
 Dear Nicholas Lemonias,
 
 I don't use to get in these scrapy discussions, but yeah you are in a 
 completetly different level if you compare yourself with Mario.
 You are definitely a Web app/metasploit-user guy and pick up a discussion 
 with a binary and memory corruption ninja exploit writter like Mario. You 
 should know your place and shut up. Period.
 
 Btw, if you dare discussing with a beast like lcamtuf, you are definitely out 
 of your mind.
 
 Cheers,
   Sergio.
 -- Sergio
 
 On Mar 14, 2014, Nicholas Lemonias. lem.niko...@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 mvi...@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.niko...@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.niko...@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
 athiasjer...@gmail.comwrote:

 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 lcam...@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.

Re: [Full-disclosure] Google vulnerabilities with PoC

2014-03-14 Thread Alfredo Ortega

Oh and this guy Shadown seems pretty knowledgeable too.

BTW now I have to read what is this about,lets see...

Alright, from TFA:

That means that a door was open for anyone to upload any file of
choice. Whether this is a security vulnerability or not, I will leave
that to your discretion

Not even you are sure this is a real vulnerability. It is not.



On 03/14/2014 03:36 PM, Alfredo Ortega wrote:
 Mario has years of experience (more than 10 in fact) in exploit writing
 and vulnerability assessment. I would consider his position on the subject.
 
 If you don't believe me, Argentina extended me certifications that
 proves that I can tell who has vulnerability assesment skills and who
 does not.
 
 If you don't believe in Argentina, you should know the ONU accepts it as
 a sovereign independent country.
 
 That is the complete certificate chain proving you that Mario is not an
 idiot as you inferred.
 
 Best regards,
 
 Alfred
 
 
 On 03/14/2014 10:50 AM, Sergio 'shadown' Alvarez wrote:
 Dear Nicholas Lemonias,

 I don't use to get in these scrapy discussions, but yeah you are in a 
 completetly different level if you compare yourself with Mario.
 You are definitely a Web app/metasploit-user guy and pick up a discussion 
 with a binary and memory corruption ninja exploit writter like Mario. You 
 should know your place and shut up. Period.

 Btw, if you dare discussing with a beast like lcamtuf, you are definitely 
 out of your mind.

 Cheers,
   Sergio.
 -- Sergio

 On Mar 14, 2014, Nicholas Lemonias. lem.niko...@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..


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

Re: [Full-disclosure] Google vulnerabilities with PoC

2014-03-14 Thread Alfredo Ortega

If he can change the mime type, then he indeed may have an attack
vector, e.g. he could upload a complete youtube-lookalike site and
snatch credentials. If you can access the fake site via HTTPS with a
youtube cert, it's an obvious vulnerability.



On 03/14/2014 07:05 AM, Mario Vilas wrote:
 You're still missing the attack vector (and the point of the discussion
 too, but that's painfully obvious).
 
 
 On Fri, Mar 14, 2014 at 4:21 AM, Nicholas Lemonias. 
 lem.niko...@googlemail.com wrote:
 

 Here's my evidence.

 Live Proof Of Concept
 ==

 http://upload.youtube.com/?authuser=0upload_id=AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aworigin=CiNodHRwOi8vd3d3LnlvdXR1YmUuY29tL3VwbG9hZC9ydXBpbxINdmlkZW8tdXBsb2Fkcw



 {sessionStatus:{state:FINALIZED,externalFieldTransfers:[{name:file,status:COMPLETED,bytesTransferred:113,bytesTotal:113,formPostInfo:{url:
 http://www.youtube.com/upload/rupio?authuser=0\u0026upload_id=AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw\u0026file_id=000
 ,cross_domain_url:
 http://upload.youtube.com/?authuser=0\u0026upload_id=AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw\u0026origin=CiNodHRwOi8vd3d3LnlvdXR1YmUuY29tL3VwbG9hZC9ydXBpbxINdmlkZW8tdXBsb2Fkcw},content_type:text/x-sh}],additionalInfo:{uploader_service.GoogleRupioAdditionalInfo:{completionInfo:{status:SUCCESS,customerSpecificInfo:{status:
 ok, video_id:
 KzKDtijwHFI,upload_id:AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw}}

 The above proof of concept demonstrates :

 1. We have bypassed the security controls in Youtube and uploaded an
 unexpected file type.
 2. The file is persistent and has not been deleted by YouTube.
 3. It can be queried for information since it is assigned a unique
 upload_id.
 4. It's successfully uploaded to youtube.com  As you can see it give out
 the total bytes written to the remote network.
 5. content_type:text/x-sh}]   --- The file is a shell
 script script named 'file'
 6. It can be enumerated by a non-authenticated user, remotely.


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

Re: [Full-disclosure] Google vulnerabilities with PoC

2014-03-13 Thread antisnatchor

I think Adam was right replying that way, so that it's not a security bug.
You haven't found anything exploitable.

The only reasonable way to 'exploit' the bug is using youtube as a
personal storage uploading non-video files to your own profile: so what?

It's like saying that you have a normal file upload functionality in a
PHP application on Apache that expects files with extension .png only,
and you manage to upload an .asp file. Security-wise that's not a risk.

Cheers
antisnatchor

Nicholas Lemonias. wrote:
 Google vulnerabilities uncovered...


 http://news.softpedia.com/news/Expert-Finds-File-Upload-Vulnerability-in-YouTube-Google-Denies-It-s-a-Security-Issue-431489.shtml

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

Re: [Full-disclosure] Google vulnerabilities with PoC

2014-03-13 Thread Michal Zalewski

 The only reasonable way to 'exploit' the bug is using youtube as a
 personal storage uploading non-video files to your own profile: so what?

That would require a way to retrieve the stored data, which - as I
understand - isn't possible here (although the report seems a bit
hard-to-parse). From what I recall, you can just upload a blob of data
and essentially see it disappear.

We do have quite a few services where you can legitimately upload and
share nearly-arbitrary content, though. Google Drive is a good
example.

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

Re: [Full-disclosure] Google vulnerabilities with PoC

2014-03-13 Thread Brandon Perry

If you were evil, you could upload huge blobs and just take up space on the 
google servers. Who knows what will happen if you upload a couple hundred gigs 
of files. They dont disappear, they are just unretrievable afaict. It is a 
security risk in the sense that untrusted data is being persisted *somewhere*.

Upload a couple terabytes, cause a DoS because some hdd in the DC fills up. Who 
knows.

Sent from a computer

On Mar 13, 2014, at 12:28 PM, Michal Zalewski lcam...@coredump.cx wrote:

 The only reasonable way to 'exploit' the bug is using youtube as a
 personal storage uploading non-video files to your own profile: so what?
 
 That would require a way to retrieve the stored data, which - as I
 understand - isn't possible here (although the report seems a bit
 hard-to-parse). From what I recall, you can just upload a blob of data
 and essentially see it disappear.
 
 We do have quite a few services where you can legitimately upload and
 share nearly-arbitrary content, though. Google Drive is a good
 example.
 
 /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/

Re: [Full-disclosure] Google vulnerabilities with PoC

2014-03-13 Thread Michal Zalewski

 If you were evil, you could upload huge blobs and just take up space on the 
 google servers.

Keep in mind that the upload functionality is there legitimately: you
can upload gigabytes of data to Youtube, Drive, Gmail, etc.

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

Re: [Full-disclosure] Google vulnerabilities with PoC

2014-03-13 Thread Źmicier Januszkiewicz

: you could upload huge blobs and just take up space on the google servers.
How many people upload gigabytes of crappy videos on google servers,
hourly? So far, the DDoS didn't happen for some reason, even
considering the amount of users. There is a small potential to exploit
this via a botnet, but what's the gain? YT upload breaks? Wow, so much
win.

By the way, why not just upload some valid, generated on the fly MPEG
stream? The effect is the same if you consider the data amount, but
without all the unrestricted shouts and academic vulnerabilities.


2014-03-13 18:33 GMT+01:00 Brandon Perry bperry.volat...@gmail.com:
 If you were evil, you could upload huge blobs and just take up space on the 
 google servers. Who knows what will happen if you upload a couple hundred 
 gigs of files. They dont disappear, they are just unretrievable afaict. It is 
 a security risk in the sense that untrusted data is being persisted 
 *somewhere*.

 Upload a couple terabytes, cause a DoS because some hdd in the DC fills up. 
 Who knows.

 Sent from a computer

 On Mar 13, 2014, at 12:28 PM, Michal Zalewski lcam...@coredump.cx wrote:

 The only reasonable way to 'exploit' the bug is using youtube as a
 personal storage uploading non-video files to your own profile: so what?

 That would require a way to retrieve the stored data, which - as I
 understand - isn't possible here (although the report seems a bit
 hard-to-parse). From what I recall, you can just upload a blob of data
 and essentially see it disappear.

 We do have quite a few services where you can legitimately upload and
 share nearly-arbitrary content, though. Google Drive is a good
 example.

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

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

Re: [Full-disclosure] Google vulnerabilities with PoC

2014-03-13 Thread Brandon Perry

Yes, these are legitimate points.

Sent from a computer

 On Mar 13, 2014, at 12:43 PM, Źmicier Januszkiewicz ga...@tut.by wrote:
 
 : you could upload huge blobs and just take up space on the google servers.
 How many people upload gigabytes of crappy videos on google servers,
 hourly? So far, the DDoS didn't happen for some reason, even
 considering the amount of users. There is a small potential to exploit
 this via a botnet, but what's the gain? YT upload breaks? Wow, so much
 win.
 
 By the way, why not just upload some valid, generated on the fly MPEG
 stream? The effect is the same if you consider the data amount, but
 without all the unrestricted shouts and academic vulnerabilities.
 
 
 2014-03-13 18:33 GMT+01:00 Brandon Perry bperry.volat...@gmail.com:
 If you were evil, you could upload huge blobs and just take up space on the 
 google servers. Who knows what will happen if you upload a couple hundred 
 gigs of files. They dont disappear, they are just unretrievable afaict. It 
 is a security risk in the sense that untrusted data is being persisted 
 *somewhere*.
 
 Upload a couple terabytes, cause a DoS because some hdd in the DC fills up. 
 Who knows.
 
 Sent from a computer
 
 On Mar 13, 2014, at 12:28 PM, Michal Zalewski lcam...@coredump.cx wrote:
 
 The only reasonable way to 'exploit' the bug is using youtube as a
 personal storage uploading non-video files to your own profile: so what?
 
 That would require a way to retrieve the stored data, which - as I
 understand - isn't possible here (although the report seems a bit
 hard-to-parse). From what I recall, you can just upload a blob of data
 and essentially see it disappear.
 
 We do have quite a few services where you can legitimately upload and
 share nearly-arbitrary content, though. Google Drive is a good
 example.
 
 /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/

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

Re: [Full-disclosure] Google vulnerabilities with PoC

2014-03-13 Thread andfarm

On Mar 13, 2014, at 10:33, Brandon Perry bperry.volat...@gmail.com wrote:
 If you were evil, you could upload huge blobs and just take up space on the 
 google servers. Who knows what will happen if you upload a couple hundred 
 gigs of files. They dont disappear, they are just unretrievable afaict. It is 
 a security risk in the sense that untrusted data is being persisted 
 *somewhere*.

It's not even clear at this point that the uploaded data is even being 
persisted! Since the uploaded file is not made available for download, it's 
entirely possible that it is being deleted as soon as Google's video 
transcoding systems discover it isn't a supported video format.

The comments on the Softpedia article are painfully stupid, by the way. I 
recommend not reading them. :)
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Google vulnerabilities with PoC

When did the ability to upload files of arbitrary types become a security
issue? If the file doesn't get executed, it's really not a problem.
(Besides from potentially breaking site layout standpoint.)


2014-03-13 12:43 GMT+02:00 Nicholas Lemonias. lem.niko...@googlemail.com:

 Google vulnerabilities uncovered...



 http://news.softpedia.com/news/Expert-Finds-File-Upload-Vulnerability-in-YouTube-Google-Denies-It-s-a-Security-Issue-431489.shtml

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

Re: [Full-disclosure] Google vulnerabilities with PoC

2014-03-13 Thread Pedro Ribeiro

Keep in mind that YouTube allows files to be uploaded by definition. What
you have achieved is upload a file for an extension type that is not
allowed.
It is definitely a vulnerability but a low risk one since you haven't
demonstrated if it has any ill effects.

Can you somehow find the URL to where the file was uploaded? I would guess
not, since a well designed service like YouTube should hide those details
and no leak them in any way. Maybe if you are able to find that you can
combine with this vulnerability and get them to open their wallet?

Regards
Pedro
On 13 Mar 2014 11:50, Nicholas Lemonias. lem.niko...@googlemail.com
wrote:

 Google vulnerabilities uncovered...



 http://news.softpedia.com/news/Expert-Finds-File-Upload-Vulnerability-in-YouTube-Google-Denies-It-s-a-Security-Issue-431489.shtml

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

Re: [Full-disclosure] Google vulnerabilities with PoC

Here is your answer.
https://www.owasp.org/index.php/Unrestricted_File_Upload


On Thu, Mar 13, 2014 at 1:39 PM, Julius Kivimäki
julius.kivim...@gmail.comwrote:

 When did the ability to upload files of arbitrary types become a security
 issue? If the file doesn't get executed, it's really not a problem.
 (Besides from potentially breaking site layout standpoint.)


 2014-03-13 12:43 GMT+02:00 Nicholas Lemonias. lem.niko...@googlemail.com
 :

 Google vulnerabilities uncovered...



 http://news.softpedia.com/news/Expert-Finds-File-Upload-Vulnerability-in-YouTube-Google-Denies-It-s-a-Security-Issue-431489.shtml

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

Re: [Full-disclosure] Google vulnerabilities with PoC

*https://www.google.com/settings/takeout
https://www.google.com/settings/takeout *

*However the only problem would be to get past Content ID filtering. I
suppose encrypting an uploaded file, and obfuscating file headers may get
past YouTube's Content ID filtering. Youtube is not a File Transfer
Protocol... It's there to serve media content. *

https://www.google.gr/#

On Thu, Mar 13, 2014 at 1:52 PM, Pedro Ribeiro ped...@gmail.com wrote:

Keep in mind that YouTube allows files to be uploaded by definition. What
you have achieved is upload a file for an extension type that is not
allowed.
It is definitely a vulnerability but a low risk one since you haven't
demonstrated if it has any ill effects.

Can you somehow find the URL to where the file was uploaded? I would guess
not, since a well designed service like YouTube should hide those details
and no leak them in any way. Maybe if you are able to find that you can
combine with this vulnerability and get them to open their wallet?

Regards
Pedro
On 13 Mar 2014 11:50, Nicholas Lemonias. lem.niko...@googlemail.com
wrote:

Google vulnerabilities uncovered...

http://news.softpedia.com/news/Expert-Finds-File-Upload-Vulnerability-in-YouTube-Google-Denies-It-s-a-Security-Issue-431489.shtml

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

Re: [Full-disclosure] Google vulnerabilities with PoC

I suggest you to read on Content Delivery Network Architectures .

YouTube.com populates and distributes stored files to multiple servers
through a CDN (Content Delivery Architecture), where each video uses more
than one machine (hosted by a cluster). Less populated video files are
normally stored in various colocation sites. The YouTube architecture uses
databases for storing metadata information of all uploaded files.

https://www.owasp.org/index.php/Unrestricted_File_Upload

On Thu, Mar 13, 2014 at 2:22 PM, Nicholas Lemonias.
lem.niko...@googlemail.com wrote:

*https://www.google.com/settings/takeout
https://www.google.com/settings/takeout *

https://www.google.gr/#

On Thu, Mar 13, 2014 at 1:52 PM, Pedro Ribeiro ped...@gmail.com wrote:

Can you somehow find the URL to where the file was uploaded? I would
guess not, since a well designed service like YouTube should hide those
details and no leak them in any way. Maybe if you are able to find that you
can combine with this vulnerability and get them to open their wallet?

Regards
Pedro
On 13 Mar 2014 11:50, Nicholas Lemonias. lem.niko...@googlemail.com
wrote:

Google vulnerabilities uncovered...

http://news.softpedia.com/news/Expert-Finds-File-Upload-Vulnerability-in-YouTube-Google-Denies-It-s-a-Security-Issue-431489.shtml

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

Re: [Full-disclosure] Google vulnerabilities with PoC

Did you even read that article? (Not that OWASP has any sort of credibility
anyways). From what I saw in your previous post you are both unable to
execute the files or even access them and thus unable to manipulate the
content-type the files are returned with, therefore there is no
vulnerability (According to the article you linked.).

BTW, you should look for more cool vulnerabilities in amazons EC2, I'm sure
you will find some Unrestricted File Upload holes.


2014-03-13 16:18 GMT+02:00 Nicholas Lemonias. lem.niko...@googlemail.com:

 Here is your answer.
 https://www.owasp.org/index.php/Unrestricted_File_Upload


 On Thu, Mar 13, 2014 at 1:39 PM, Julius Kivimäki 
 julius.kivim...@gmail.com wrote:

 When did the ability to upload files of arbitrary types become a security
 issue? If the file doesn't get executed, it's really not a problem.
 (Besides from potentially breaking site layout standpoint.)


 2014-03-13 12:43 GMT+02:00 Nicholas Lemonias. lem.niko...@googlemail.com
 :

 Google vulnerabilities uncovered...



 http://news.softpedia.com/news/Expert-Finds-File-Upload-Vulnerability-in-YouTube-Google-Denies-It-s-a-Security-Issue-431489.shtml

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

Re: [Full-disclosure] Google vulnerabilities with PoC

*You are wrong about accessing the files. What has not been confirmed is
remote code execution. We are working on it.*
*And please, OWASP is recognised worldwide... *

*Files can be accessed through Google Take out with a little bit of skills.*

*https://www.google.com/settings/takeout
https://www.google.com/settings/takeout *

On Thu, Mar 13, 2014 at 4:09 PM, Julius Kivimäki
julius.kivim...@gmail.comwrote:

Did you even read that article? (Not that OWASP has any sort of
credibility anyways). From what I saw in your previous post you are both
unable to execute the files or even access them and thus unable to
manipulate the content-type the files are returned with, therefore there is
no vulnerability (According to the article you linked.).

BTW, you should look for more cool vulnerabilities in amazons EC2, I'm
sure you will find some Unrestricted File Upload holes.

2014-03-13 16:18 GMT+02:00 Nicholas Lemonias. lem.niko...@googlemail.com
:

Here is your answer.
https://www.owasp.org/index.php/Unrestricted_File_Upload

On Thu, Mar 13, 2014 at 1:39 PM, Julius Kivimäki
julius.kivim...@gmail.com wrote:

When did the ability to upload files of arbitrary types become a
security issue? If the file doesn't get executed, it's really not a
problem. (Besides from potentially breaking site layout standpoint.)

2014-03-13 12:43 GMT+02:00 Nicholas Lemonias.
lem.niko...@googlemail.com:

Google vulnerabilities uncovered...

http://news.softpedia.com/news/Expert-Finds-File-Upload-Vulnerability-in-YouTube-Google-Denies-It-s-a-Security-Issue-431489.shtml

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

Re: [Full-disclosure] Google vulnerabilities with PoC

OWASP is recognized worldwide, so is CEH and a bunch of other morons. That
doesn't mean their publications are worth anything. Now tell me, why would
arbitrary file upload on a CDN lead to code execution (Besides for HTML,
which you have been unable to confirm)?

2014-03-13 18:16 GMT+02:00 Nicholas Lemonias. lem.niko...@googlemail.com:

*You are wrong about accessing the files. What has not been confirmed is
remote code execution. We are working on it.*
*And please, OWASP is recognised worldwide... *

*Files can be accessed through Google Take out with a little bit of
skills.*

*https://www.google.com/settings/takeout
https://www.google.com/settings/takeout *

On Thu, Mar 13, 2014 at 4:09 PM, Julius Kivimäki
julius.kivim...@gmail.com wrote:

BTW, you should look for more cool vulnerabilities in amazons EC2, I'm
sure you will find some Unrestricted File Upload holes.

2014-03-13 16:18 GMT+02:00 Nicholas Lemonias. lem.niko...@googlemail.com
:

Here is your answer.
https://www.owasp.org/index.php/Unrestricted_File_Upload

On Thu, Mar 13, 2014 at 1:39 PM, Julius Kivimäki
julius.kivim...@gmail.com wrote:

2014-03-13 12:43 GMT+02:00 Nicholas Lemonias.
lem.niko...@googlemail.com:

Google vulnerabilities uncovered...

http://news.softpedia.com/news/Expert-Finds-File-Upload-Vulnerability-in-YouTube-Google-Denies-It-s-a-Security-Issue-431489.shtml

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

Re: [Full-disclosure] Google vulnerabilities with PoC

Hello Julius,

I appreciate your interest to learn more. OWASP is quite credible, and has
gained some international recognition. It is a benchmark for many vendors.
I suggest you to read on OSI/7-Layer Model. A website may disallow uploads
of certain file types for security reasons, and let's assume at the
application layer. If we manage to get past the security controls, that
means we can write unrestrictedly any type of file to the remote network.
That also means that we get past their firewall, since the communication is
through HTTP (port 80). CDN nodes are deployed to multiple colocation
(thousands of nodes and thousands of servers across the world). The files
(let's say a self-executing encrypted virus like Cryptolocker? ) are cached
deeply in the network across thousands of servers.

On Thu, Mar 13, 2014 at 5:07 PM, Nicholas Lemonias.
lem.niko...@googlemail.com wrote:

Hello Julius,

I appreciate your interest to learn more. OWASP is quite credible, and has
gained some international recognition. It is a benchmark for many vendors.
I suggest you to read on OSI/7-Layer Model. A website may disallow uploads
of certain file types for security reasons, and let's assume at the
application layer. If we manage to get past the security controls, that
means we can write unrestrictedly any type of file to the remote network.
That also means that we get past their firewall, since the communication is
through HTTP (port 80). CDN nodes are deployed to multiple colocation
(thousands of nodes and thousands of servers across the world). The files
are cached deep in the network structures to thousands of servers.

On Thu, Mar 13, 2014 at 4:20 PM, Julius Kivimäki
julius.kivim...@gmail.com wrote:

OWASP is recognized worldwide, so is CEH and a bunch of other morons.
That doesn't mean their publications are worth anything. Now tell me, why
would arbitrary file upload on a CDN lead to code execution (Besides for
HTML, which you have been unable to confirm)?

2014-03-13 18:16 GMT+02:00 Nicholas Lemonias. lem.niko...@googlemail.com
:

*You are wrong about accessing the files. What has not been confirmed is
remote code execution. We are working on it.*
*And please, OWASP is recognised worldwide... *

*Files can be accessed through Google Take out with a little bit of
skills.*

*https://www.google.com/settings/takeout
https://www.google.com/settings/takeout *

On Thu, Mar 13, 2014 at 4:09 PM, Julius Kivimäki
julius.kivim...@gmail.com wrote:

BTW, you should look for more cool vulnerabilities in amazons EC2, I'm
sure you will find some Unrestricted File Upload holes.

2014-03-13 16:18 GMT+02:00 Nicholas Lemonias.
lem.niko...@googlemail.com:

Here is your answer.
https://www.owasp.org/index.php/Unrestricted_File_Upload

On Thu, Mar 13, 2014 at 1:39 PM, Julius Kivimäki
julius.kivim...@gmail.com wrote:

2014-03-13 12:43 GMT+02:00 Nicholas Lemonias.
lem.niko...@googlemail.com:

Google vulnerabilities uncovered...

http://news.softpedia.com/news/Expert-Finds-File-Upload-Vulnerability-in-YouTube-Google-Denies-It-s-a-Security-Issue-431489.shtml

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

Re: [Full-disclosure] Google vulnerabilities with PoC

2014-03-13 Thread J. Tozo

hahahaha

you also could send emails to yourself untill fill up the google storages.
of course its not a security issue.


On Thu, Mar 13, 2014 at 2:33 PM, Brandon Perry bperry.volat...@gmail.comwrote:

 If you were evil, you could upload huge blobs and just take up space on
 the google servers. Who knows what will happen if you upload a couple
 hundred gigs of files. They dont disappear, they are just unretrievable
 afaict. It is a security risk in the sense that untrusted data is being
 persisted *somewhere*.

 Upload a couple terabytes, cause a DoS because some hdd in the DC fills
 up. Who knows.

 Sent from a computer

 On Mar 13, 2014, at 12:28 PM, Michal Zalewski lcam...@coredump.cx wrote:

  The only reasonable way to 'exploit' the bug is using youtube as a
  personal storage uploading non-video files to your own profile: so
 what?
 
  That would require a way to retrieve the stored data, which - as I
  understand - isn't possible here (although the report seems a bit
  hard-to-parse). From what I recall, you can just upload a blob of data
  and essentially see it disappear.
 
  We do have quite a few services where you can legitimately upload and
  share nearly-arbitrary content, though. Google Drive is a good
  example.
 
  /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/




-- 
Grato,

J. Tozo
 _
   °v°
  /(S)\SLACKWARE
   ^ ^   Linux
_
 because it works
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Google vulnerabilities with PoC

I don't see what OSI model has to do with anything here. Why is arbitrary
file upload to youtube CDN any worse than to google drive CDN? And how will
your self-executing encrypted virus like Cryptolocker end up getting
executed anyways? And cryptolocker was definitely not self-executing, but
spread via email attachments (excluding the boring USB spread
functionality).

What you have here is not a vulnerability, just give up. And stop trying to
get journalists like Eduard Kovacs to spread your BS.

2014-03-13 19:10 GMT+02:00 Nicholas Lemonias. lem.niko...@googlemail.com:

Hello Julius,

On Thu, Mar 13, 2014 at 5:07 PM, Nicholas Lemonias.
lem.niko...@googlemail.com wrote:

Hello Julius,

I appreciate your interest to learn more. OWASP is quite credible, and
has gained some international recognition. It is a benchmark for many
vendors. I suggest you to read on OSI/7-Layer Model. A website may disallow
uploads of certain file types for security reasons, and let's assume at the
application layer. If we manage to get past the security controls, that
means we can write unrestrictedly any type of file to the remote network.
That also means that we get past their firewall, since the communication is
through HTTP (port 80). CDN nodes are deployed to multiple colocation
(thousands of nodes and thousands of servers across the world). The files
are cached deep in the network structures to thousands of servers.

On Thu, Mar 13, 2014 at 4:20 PM, Julius Kivimäki
julius.kivim...@gmail.com wrote:

OWASP is recognized worldwide, so is CEH and a bunch of other morons.
That doesn't mean their publications are worth anything. Now tell me, why
would arbitrary file upload on a CDN lead to code execution (Besides for
HTML, which you have been unable to confirm)?

2014-03-13 18:16 GMT+02:00 Nicholas Lemonias.
lem.niko...@googlemail.com:

*You are wrong about accessing the files. What has not been confirmed is
remote code execution. We are working on it.*
*And please, OWASP is recognised worldwide... *

*Files can be accessed through Google Take out with a little bit of
skills.*

*https://www.google.com/settings/takeout
https://www.google.com/settings/takeout *

On Thu, Mar 13, 2014 at 4:09 PM, Julius Kivimäki
julius.kivim...@gmail.com wrote:

Did you even read that article? (Not that OWASP has any sort of
credibility anyways). From what I saw in your previous post you are both
unable to execute the files or even access them and thus unable to
manipulate the content-type the files are returned with, therefore there
is
no vulnerability (According to the article you linked.).

BTW, you should look for more cool vulnerabilities in amazons EC2, I'm
sure you will find some Unrestricted File Upload holes.

2014-03-13 16:18 GMT+02:00 Nicholas Lemonias.
lem.niko...@googlemail.com:

Here is your answer.
https://www.owasp.org/index.php/Unrestricted_File_Upload

On Thu, Mar 13, 2014 at 1:39 PM, Julius Kivimäki
julius.kivim...@gmail.com wrote:

2014-03-13 12:43 GMT+02:00 Nicholas Lemonias.
lem.niko...@googlemail.com:

Google vulnerabilities uncovered...

http://news.softpedia.com/news/Expert-Finds-File-Upload-Vulnerability-in-YouTube-Google-Denies-It-s-a-Security-Issue-431489.shtml

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

Re: [Full-disclosure] Google vulnerabilities with PoC

So in terms of permissions. What's the different between
admin.youtube.comand a normal youtube user?

I assume that the admin has a full permission set. If that's the case, that
means it is a valid vulnerability for the reason being that the integrity
of the service is impacted. The youtube user circumvents the design and
gets arbitrary write (w) permissions of any file-type. (The access control
matrix is bypassed here)

Since YouTube by design is not an FTP Service, and even Google drive is a
paid service - Then yes it is a vulnerability. Why are you guys looking for
impact elsewhere? The impact is to the integrity of the service - arbitrary
write permissions.



On Thu, Mar 13, 2014 at 5:28 PM, Michal Zalewski lcam...@coredump.cxwrote:

  The only reasonable way to 'exploit' the bug is using youtube as a
  personal storage uploading non-video files to your own profile: so
 what?

 That would require a way to retrieve the stored data, which - as I
 understand - isn't possible here (although the report seems a bit
 hard-to-parse). From what I recall, you can just upload a blob of data
 and essentially see it disappear.

 We do have quite a few services where you can legitimately upload and
 share nearly-arbitrary content, though. Google Drive is a good
 example.

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

Re: [Full-disclosure] Google vulnerabilities with PoC

Hello Zalewski,

The YouTube service is there to serve harmless media files. The upload
functionality is there to upload files legitimately. But what type of
files, and who can write those files?

What's the difference between a Youtube admin and a Youtube user in terms
of permissions sets ?

Why does Youtube accepts only a certain type of media-files? Isn't it
because that's the scope of its function  ?



A good point made, however based on recognised practise and core principles
of Information Security and not just 'experience' or personal belief, once
the information security flow of a design is tampered - that constitutes to
a security issue.

Second point - a security vulnerability is present when the
confidentiality, integrity and availability of data is affected. In this
case the integrity of the service is impacted.



On Thu, Mar 13, 2014 at 5:28 PM, Michal Zalewski lcam...@coredump.cxwrote:

  The only reasonable way to 'exploit' the bug is using youtube as a
  personal storage uploading non-video files to your own profile: so
 what?

 That would require a way to retrieve the stored data, which - as I
 understand - isn't possible here (although the report seems a bit
 hard-to-parse). From what I recall, you can just upload a blob of data
 and essentially see it disappear.

 We do have quite a few services where you can legitimately upload and
 share nearly-arbitrary content, though. Google Drive is a good
 example.

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

Re: [Full-disclosure] Google vulnerabilities with PoC

The YouTube service is there to serve harmless media files. The upload
functionality is there to upload files legitimately. But what type of
files, and who can write those files?

What's the difference between a Youtube admin (admin.youtube.com) and a
Youtube user in terms of permissions sets ?

Why does Youtube accepts only a certain type of media-files? Isn't it
because that's the scope of its function  ?



A good point made, however based on recognised practise and core principles
of Information Security and not just 'experience' or personal belief, once
the information security flow of a design is tampered - that constitutes to
a security issue.

Second point - a security vulnerability is present when the
confidentiality, integrity and availability of data is affected. In this
case the integrity of the service is impacted.


On Thu, Mar 13, 2014 at 8:00 PM, Nicholas Lemonias. 
lem.niko...@googlemail.com wrote:

 Hello Zalewski,

 The YouTube service is there to serve harmless media files. The upload
 functionality is there to upload files legitimately. But what type of
 files, and who can write those files?

 What's the difference between a Youtube admin and a Youtube user in terms
 of permissions sets ?

 Why does Youtube accepts only a certain type of media-files? Isn't it
 because that's the scope of its function  ?



 A good point made, however based on recognised practise and core
 principles of Information Security and not just 'experience' or personal
 belief, once the information security flow of a design is tampered - that
 constitutes to a security issue.

 Second point - a security vulnerability is present when the
 confidentiality, integrity and availability of data is affected. In this
 case the integrity of the service is impacted.



 On Thu, Mar 13, 2014 at 5:28 PM, Michal Zalewski lcam...@coredump.cxwrote:

  The only reasonable way to 'exploit' the bug is using youtube as a
  personal storage uploading non-video files to your own profile: so
 what?

 That would require a way to retrieve the stored data, which - as I
 understand - isn't possible here (although the report seems a bit
 hard-to-parse). From what I recall, you can just upload a blob of data
 and essentially see it disappear.

 We do have quite a few services where you can legitimately upload and
 share nearly-arbitrary content, though. Google Drive is a good
 example.

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

Re: [Full-disclosure] Google vulnerabilities with PoC