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

Please stop changing hats, it's embarrasing.


On Sat, Mar 15, 2014 at 7:36 PM, T Imbrahim timbra...@techemail.com wrote:

 Is this treated with the same way that says that Remote File Inclusion is
 not a security issue ?

 You don't follow? Implying ?

 I understand why nobody likes Google. If I 've found a vulnerability and
 been treated like that for trying to help, I would rather sell it to the
 black market or to some government.

 The NSA maybe is happy to buy a RFI on Google, im sure they could make
 good use of that. Google is very deceptive in security matters.

 --- lcam...@coredump.cx wrote:

 From: Michal Zalewski lcam...@coredump.cx
 To: timbra...@techemail.com
 Cc: pr...@yahoo.co.uk, full-disclosure full-disclosure@lists.grok.org.uk
 Subject: Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
 Date: Sat, 15 Mar 2014 10:59:40 -0700

  A hacker exploits a JSON (javascript) object that has information of
 interest for example holding some values for cookies. A lot of times that
 exploits the same policy origin. The JSON object returned from a server can
 be forged over writing javascript function that create the object. This
 happens because of the same origin policy problem in browsers that cannot
 say if js execution it different for two different sites.

 To be honest, I'm not sure I follow, but I'm fairly confident that my
 original point stands. If you believe that well-formed JSON objects
 without padding can be read across origins within the browser, I would
 love to see more information about that. (In this particular case, it
 still wouldn't matter because the response doesn't contain secrets,
 but it would certainly break a good chunk of the Internet.) JSONP is a
 different animal.

 /mz




 _
 Are you a Techie? Get Your Free Tech Email Address Now! Visit
 http://www.TechEmail.com

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




-- 
“There's a reason we separate military and the police: one fights the enemy
of the state, the other serves and protects the people. When the military
becomes both, then the enemies of the state tend to become the people.”
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC

ROFL

[image: Inline image 1]


On Mon, Mar 17, 2014 at 11:07 AM, T Imbrahim timbra...@techemail.comwrote:

 What drugs are you on Pedro Ribeiro I wonder ...?

 I express my views, if you don't like don't watch them. You responses so
 far have only been assy speculations so don't tell me Im wrong , and please
 don't say thing like that. I don't know who the other people is,  but what
 is true in security I support. Why you would Google my name ... ?

  Is the English language causing you ill effects?

 --- ped...@gmail.com wrote:

 From: Pedro Ribeiro ped...@gmail.com
 To: timbra...@techemail.com
 Cc: full-disclosure@lists.grok.org.uk, Michal Zalewski 
 lcam...@coredump.cx, mvi...@gmail.com, gynv...@coldwind.pl

 Subject: Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
 Date: Mon, 17 Mar 2014 09:24:08 +


 On 16 Mar 2014 23:36, T Imbrahim timbra...@techemail.com wrote:
 
  The thread read Google vulnerabilities with PoC. From my understanding
  it was a RFI vulnerability on YouTube, and I voiced my support that this
 is a vulnerability.
 
  I also explained a JSON Hijacking case as a follow up, and you said you
 didn't follow.  So I am just saying that treating security that way, there
 are other parties like NSA who welcome them happily.
 

 I think these guys - Alfred, Kirschbaum and Imbrahim are the OP's sock
 puppets.

 They are all first time posters from unusual free email providers jumping
 to defend the OP out of nowhere. If you search Google for their emails you
 only find references to this thread.

 They present similar (false and /or incorrect) arguments, talk about their
 extensive work experience, bash Google and its security team and send
 repeated emails with exactly the same text.

 This is turning into a madhouse... I hope this guy doesn't have access to
 a gun.

 Regards
 Pedro


 --
 Are you a Techie? Get Your Free Tech Email Address Now! Visit
 http://www.TechEmail.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.”
inline: 10iceb6.jpg___
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] Fwd: Google vulnerabilities with PoC

2014-03-17 Thread T Imbrahim

What drugs are you on Pedro RibeiroI wonder...?I express myviews, if you don't like don't watch them. You responses so farhave only been assy speculations so don't tell me Im wrong, and please don't say thing like that. I don't know who the other peopleis,but what is true in security I support. Why you would Google my name ... ?Is the English language causing you ill effects? --- ped...@gmail.com wrote:From: Pedro Ribeiro ped...@gmail.comTo: timbra...@techemail.comCc: full-disclosure@lists.grok.org.uk, Michal Zalewski lcam...@coredump.cx, mvi...@gmail.com, gynv...@coldwind.plSubject: Re: [Full-disclosure] Fwd: Google vulnerabilities with PoCDate: Mon, 17 Mar 2014 09:24:08 +
On 16 Mar 2014 23:36, "T Imbrahim" timbra...@techemail.com wrote:

The thread read Google vulnerabilities with PoC. From my understanding it was a RFI vulnerability on YouTube, and I voiced my support that this is a vulnerability.

I also explained a JSON Hijacking case as a follow up, and you said you didn't follow. So I am just saying that treating security that way, there are other parties like NSA who welcome them happily.

I think these guys - Alfred, Kirschbaum and Imbrahim are the OP's sock puppets.
They are all first time posters from unusual free email providers jumping to defend the OP out of nowhere.If you search Google for their emails you only find references to this thread.
They present similar (false and /or incorrect) arguments, talk about their extensive work experience, bash Google and its security team and send repeated emails with exactly the same text.
This is turning into a madhouse... I hope this guy doesn't have access to a gun.
Regards
Pedro

Are you a Techie? Get Your Free Tech Email Address Now! Visit http://www.TechEmail.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] Fwd: Google vulnerabilities with PoC

2014-03-17 Thread Gichuki John Chuksjonia

Ooh goodie, where and what happened to N3td3v, he used to crack me up :D :D








On 3/17/14, Mario Vilas mvi...@gmail.com wrote:
 ROFL

 [image: Inline image 1]


 On Mon, Mar 17, 2014 at 11:07 AM, T Imbrahim
 timbra...@techemail.comwrote:

 What drugs are you on Pedro Ribeiro I wonder ...?

 I express my views, if you don't like don't watch them. You responses so
 far have only been assy speculations so don't tell me Im wrong , and
 please
 don't say thing like that. I don't know who the other people is,  but
 what
 is true in security I support. Why you would Google my name ... ?

  Is the English language causing you ill effects?

 --- ped...@gmail.com wrote:

 From: Pedro Ribeiro ped...@gmail.com
 To: timbra...@techemail.com
 Cc: full-disclosure@lists.grok.org.uk, Michal Zalewski 
 lcam...@coredump.cx, mvi...@gmail.com, gynv...@coldwind.pl

 Subject: Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
 Date: Mon, 17 Mar 2014 09:24:08 +


 On 16 Mar 2014 23:36, T Imbrahim timbra...@techemail.com wrote:
 
  The thread read Google vulnerabilities with PoC. From my understanding
  it was a RFI vulnerability on YouTube, and I voiced my support that this
 is a vulnerability.
 
  I also explained a JSON Hijacking case as a follow up, and you said you
 didn't follow.  So I am just saying that treating security that way,
 there
 are other parties like NSA who welcome them happily.
 

 I think these guys - Alfred, Kirschbaum and Imbrahim are the OP's sock
 puppets.

 They are all first time posters from unusual free email providers jumping
 to defend the OP out of nowhere. If you search Google for their emails
 you
 only find references to this thread.

 They present similar (false and /or incorrect) arguments, talk about
 their
 extensive work experience, bash Google and its security team and send
 repeated emails with exactly the same text.

 This is turning into a madhouse... I hope this guy doesn't have access to
 a gun.

 Regards
 Pedro


 --
 Are you a Techie? Get Your Free Tech Email Address Now! Visit
 http://www.TechEmail.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.



-- 
-- 
Gichuki John Ndirangu, C.E.H , C.P.T.P, O.S.C.P
I.T Security Analyst and Penetration Tester
jgichuki at inbox d0t com

{FORUM}http://lists.my.co.ke/pipermail/security/
http://chuksjonia.blogspot.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] Fwd: Google vulnerabilities with PoC

2014-03-17 Thread Joxean Koret

Hi,

The only probable way of exploiting it I can see would be if the servers
at Google where the files are uploaded would perform some specific tasks
with such files that could result in exploiting a vulnerability in any
of the used software (and this is something the discoverer failed to
probe). An example: Google malware scans the uploaded file with some AV
engine and the file is actually an exploit targeting one or more AV
products. I don't think this is the case and, even in this case, there
wouldn't be any Google's vulnerability but, rather, a vulnerability in
another product from another company.

So, in short: this conversation is stupid. There is no vulnerability we
can see here and, if there is, it cannot be probed by the discoverer and
he and his buddies attach to either ad hominem arguments or to
statements like I am XXX with YYY years of experience doing ZZZ
mistakenly thinking it could back any of their paranoias.

What else do we need to discuss here? I think it's time to stop this
conversation. And, yes, I know that sending an e-mail to ask for
stopping a conversation on FD is stupid too.

Regards,
Joxean Koret



signature.asc
Description: This is a digitally signed message part
___
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] Fwd: Google vulnerabilities with PoC

2014-03-17 Thread T Imbrahim

Hey,

At least to me I am security paranoid. Remote File Inclusion of files to a 
trusted network, seems like a well backed up vulnerability. I think we are 
talking about Google here not your favourite's pizza website. I personally 
congratulate to the author for finding it, whether probing it or not. And I 
have nothing to do with the authors, just supporting what is right. 

I definitely would patch my computer if I discovered that somebody could upload 
files to my computer, even thought if couldn't 'probe' them.
 


--- joxeanko...@yahoo.es wrote:

From: Joxean Koret joxeanko...@yahoo.es
To: full-disclosure@lists.grok.org.uk
Subject: Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
Date: Mon, 17 Mar 2014 12:27:27 +0100

Hi,

The only probable way of exploiting it I can see would be if the servers
at Google where the files are uploaded would perform some specific tasks
with such files that could result in exploiting a vulnerability in any
of the used software (and this is something the discoverer failed to
probe). An example: Google malware scans the uploaded file with some AV
engine and the file is actually an exploit targeting one or more AV
products. I don't think this is the case and, even in this case, there
wouldn't be any Google's vulnerability but, rather, a vulnerability in
another product from another company.

So, in short: this conversation is stupid. There is no vulnerability we
can see here and, if there is, it cannot be probed by the discoverer and
he and his buddies attach to either ad hominem arguments or to
statements like I am XXX with YYY years of experience doing ZZZ
mistakenly thinking it could back any of their paranoias.

What else do we need to discuss here? I think it's time to stop this
conversation. And, yes, I know that sending an e-mail to ask for
stopping a conversation on FD is stupid too.

Regards,
Joxean Koret



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



_
Are you a Techie? Get Your Free Tech Email Address Now! Visit 
http://www.TechEmail.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] Fwd: Google vulnerabilities with PoC

2014-03-17 Thread Źmicier Januszkiewicz

Especially considering that all three use Tor to post on the list. I wonder why.
Other header/content details can be interesting as well...


2014-03-17 10:24 GMT+01:00 Pedro Ribeiro ped...@gmail.com:

 On 16 Mar 2014 23:36, T Imbrahim timbra...@techemail.com wrote:

 The thread read Google vulnerabilities with PoC. From my understanding  it
 was a RFI vulnerability on YouTube, and I voiced my support that this is a
 vulnerability.

 I also explained a JSON Hijacking case as a follow up, and you said you
 didn't follow.  So I am just saying that treating security that way, there
 are other parties like NSA who welcome them happily.


 I think these guys - Alfred, Kirschbaum and Imbrahim are the OP's sock
 puppets.

 They are all first time posters from unusual free email providers jumping to
 defend the OP out of nowhere. If you search Google for their emails you only
 find references to this thread.

 They present similar (false and /or incorrect) arguments, talk about their
 extensive work experience, bash Google and its security team and send
 repeated emails with exactly the same text.

 This is turning into a madhouse... I hope this guy doesn't have access to a
 gun.

 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/

___
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] Fwd: Google vulnerabilities with PoC

On Mon, Mar 17, 2014 at 2:25 PM, T Imbrahim timbra...@techemail.com wrote:

 I definitely would patch my computer if I discovered that somebody could
 upload files to my computer, even thought if couldn't 'probe' them.


1) I don't think you understood the meaning of the word probe in this
context, Nikolas,
2) Does that mean you believe Dropbox is vulnerable to remote file upload
too?


-- 
“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] Fwd: Google vulnerabilities with PoC

2014-03-17 Thread Pedro Ribeiro

On 17 Mar 2014 13:39, Źmicier Januszkiewicz ga...@tut.by wrote:

Especially considering that all three use Tor to post on the list. I
wonder why.
Other header/content details can be interesting as well...

Good catch, I didn't even remember checking the headers.
Have a look at the comments posted in the softpedia article - I can smell
more dirty socks in there.

And for even more fun read his interview:
http://m.softpedia.com/softpedia-interview-nicholas-lemonias-on-satellite-communication-vulnerabilities-420589.html

He even posted it to this list but no one noticed it:
http://marc.info/?l=full-disclosurem=139076233105401w=2

2014-03-17 10:24 GMT+01:00 Pedro Ribeiro ped...@gmail.com:

On 16 Mar 2014 23:36, T Imbrahim timbra...@techemail.com wrote:

The thread read Google vulnerabilities with PoC. From my understanding
it
was a RFI vulnerability on YouTube, and I voiced my support that this
is a
vulnerability.

I also explained a JSON Hijacking case as a follow up, and you said you
didn't follow. So I am just saying that treating security that way,
there
are other parties like NSA who welcome them happily.

I think these guys - Alfred, Kirschbaum and Imbrahim are the OP's sock
puppets.

They are all first time posters from unusual free email providers
jumping to
defend the OP out of nowhere. If you search Google for their emails you
only
find references to this thread.

They present similar (false and /or incorrect) arguments, talk about
their
extensive work experience, bash Google and its security team and send
repeated emails with exactly the same text.

This is turning into a madhouse... I hope this guy doesn't have access
to a
gun.

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/
___
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] Fwd: Google vulnerabilities with PoC

2014-03-17 Thread Ulisses Montenegro

Let's try some scenarios and if those can be pulled out then I'd say it's
safe to assume this is an issue:

1. Upload a webshell (in a war, php, asp[x], jsp or similar file) and have
it executed by YouTube;
2. Upload a malicious file (pdf, swf, jar or similar file which exploits a
known or unknown vulnerability in the respective aps) and have it served by
YouTube;
3. Upload a file which alters the behavior of the YouTube application
(i.e., a configuration file, HTML or Javascript template, even a UI image).

Otherwise you just uploaded a file which went into a bitbucket, but you
have no way of pulling this file out of said bitbucket in a way that can
cause harm to either the application or its users.

Should YouTube restrict file uploads to known valid mime types? Sure, but
that's only how you got the data in there to begin with. It's what happens
after the data is in that will make all the difference.



On Mon, Mar 17, 2014 at 10:47 AM, Mario Vilas mvi...@gmail.com wrote:


 On Mon, Mar 17, 2014 at 2:25 PM, T Imbrahim timbra...@techemail.comwrote:

 I definitely would patch my computer if I discovered that somebody could
 upload files to my computer, even thought if couldn't 'probe' them.


 1) I don't think you understood the meaning of the word probe in this
 context, Nikolas,
 2) Does that mean you believe Dropbox is vulnerable to remote file upload
 too?


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




-- 
“If debugging is the process of removing software bugs, then programming
must be the process of putting them in.” - *Edsger Dijkstra*
___
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] Fwd: Google vulnerabilities with PoC

On Mon, Mar 17, 2014 at 3:11 PM, Ulisses Montenegro 
ulisses.montene...@gmail.com wrote:

 Should YouTube restrict file uploads to known valid mime types? Sure, but
 that's only how you got the data in there to begin with. It's what happens
 after the data is in that will make all the difference.


At this point I'm not even sure the data isn't being restricted - it just
may be that the data type is checked again after it gets pulled out of the
queue for processing, and if it's not a video it gets discarded.


-- 
“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] Fwd: Google vulnerabilities with PoC

2014-03-16 Thread T Imbrahim

Hello,

I am a security professional and risk manager in UAE. I support that the remote 
file upload on YouTube is a vulnerability, and I am sure about this. Not the 
slightest doubts... 

There is a different between a vulnerability and an exploit. The vulnerability 
here is the lack of any file extension checks, content type verification 
“$_FILES['uploadedfile']['type']” holds the value of the MIME type. A hacker 
can easily upload files using a script that allows the sending or tampering of 
HTTP POST requests.

e.g:

?php
 //Demo1.php
 if($_FILES['uploadedfile']['type'] != image/gif) {
 echo Sorry, we only allow uploading GIF images;
 exit;
 }
 $uploaddir = 'uploads/';
 $uploadfile = $uploaddir . basename($_FILES['uploadedfile']['name']);
 if (move_uploaded_file($_FILES['uploadedfile']['tmp_name'], $uploadfile)) {
 echo File is valid, and was successfully uploaded.n;
 } else {
 echo File uploading failed.n;
 }
 ?
Read this for more info if you like: 
http://resources.infosecinstitute.com/file-upload-vulnerabilities/

if not (rwx) and only (w) to a temporary file even, the spread of malware is 
real no matter if the file is executed at the time is upload.

For the JSON reply:

A hacker exploits a JSON (javascript) object that has information of interest 
for example holding some values for cookies. A lot of times that exploits the 
same policy origin. The JSON object returned from a server can be forged over 
writing javascript function that create the object. This happens because of the 
same origin policy problem in browsers that cannot say if js execution it 
different for two different sites.


Sincerely ,
T. Imbrahim


--- lcam...@coredump.cx wrote:

From: Michal Zalewski lcam...@coredump.cx
To: M Kirschbaum pr...@yahoo.co.uk
Cc: full-disclosure@lists.grok.org.uk full-disclosure@lists.grok.org.uk
Subject: Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
Date: Sat, 15 Mar 2014 09:46:27 -0700

 As a professional penetration tester, [...]
 The JSON service responds to GET requests , and there is a good chance that
 the service is also vulnerable to JSON Hijacking attacks.

That's... not how XSSI works.

To have a script inclusion vulnerability, you need to have a vanilla
GET response that contains some user-specific secrets that are
returned to the caller based on HTTP cookies (or, less likely, other
ambient credentials). For example, a script response that discloses
the contents of your mailbox or the list of private contacts would be
of concern.

Further, the response must be in a format that can be not only loaded,
but also inspected by another site opened in your browser; most types
of JSONP fall into this category, but JSON generally does not,
essentially because of how the meaning of { is overloaded in JS
depending on where it appears in a block of code.

Last but not least, the final piece of the puzzle is that the response
must be served at a URL that can be guessed by third parties who don't
have access to your account.

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




_
Are you a Techie? Get Your Free Tech Email Address Now! Visit 
http://www.TechEmail.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] Fwd: Google vulnerabilities with PoC

2014-03-16 Thread T Imbrahim

Is this treated with the same way that says that Remote File Inclusion is not a 
security issue ? 

You don't follow? Implying ? 

I understand why nobody likes Google. If I 've found a vulnerability and been 
treated like that for trying to help, I would rather sell it to the black 
market or to some government.

The NSA maybe is happy to buy a RFI on Google, im sure they could make good use 
of that. Google is very deceptive in security matters. 

--- lcam...@coredump.cx wrote:

From: Michal Zalewski lcam...@coredump.cx
To: timbra...@techemail.com
Cc: pr...@yahoo.co.uk, full-disclosure full-disclosure@lists.grok.org.uk
Subject: Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
Date: Sat, 15 Mar 2014 10:59:40 -0700

 A hacker exploits a JSON (javascript) object that has information of interest 
 for example holding some values for cookies. A lot of times that exploits the 
 same policy origin. The JSON object returned from a server can be forged over 
 writing javascript function that create the object. This happens because of 
 the same origin policy problem in browsers that cannot say if js execution it 
 different for two different sites.

To be honest, I'm not sure I follow, but I'm fairly confident that my
original point stands. If you believe that well-formed JSON objects
without padding can be read across origins within the browser, I would
love to see more information about that. (In this particular case, it
still wouldn't matter because the response doesn't contain secrets,
but it would certainly break a good chunk of the Internet.) JSONP is a
different animal.

/mz




_
Are you a Techie? Get Your Free Tech Email Address Now! Visit 
http://www.TechEmail.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] Fwd: Google vulnerabilities with PoC

2014-03-16 Thread T Imbrahim

The thread read Google vulnerabilities with PoC. From my understanding  it was 
a RFI vulnerability on YouTube, and I voiced my support that this is a 
vulnerability. 

I also explained a JSON Hijacking case as a follow up, and you said you didn't 
follow.  So I am just saying that treating security that way, there are other 
parties like NSA who welcome them happily.



--- lcam...@coredump.cx wrote:

From: Michal Zalewski lcam...@coredump.cx
To: timbra...@techemail.com
Cc: M Kirschbaum pr...@yahoo.co.uk, full-disclosure 
full-disclosure@lists.grok.org.uk
Subject: Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
Date: Sat, 15 Mar 2014 11:47:19 -0700

 Is this treated with the same way that says that Remote File Inclusion is not 
 a security issue ?

I'm not sure how RFI came into play on this thread - the original
report wasn't about RFI.

I don't have an agenda here; I'm just trying to get to the bottom of
it and make sure that we converge on a common understanding of the
issue. As in any argument, it's fairly likely that one of us is wrong,
and I accept that it could very well be me - I have been wrong quite a
few times in my life, and it's always a valuable learning opportunity.

I think it's unfortunate that the thread has devolved into various
accusations and credential-slinging, because it reduces the likelihood
of such a productive outcome. Please feel free to ping me directly any
time, though - I'm happy to chat.

Cheers,
/mz




_
Are you a Techie? Get Your Free Tech Email Address Now! Visit 
http://www.TechEmail.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] Fwd: Google vulnerabilities with PoC

2014-03-15 Thread Nicholas Lemonias.

You are so incompetent.. If you want proof why don't you do it yourself?

https://www.youtube.com/watch?v=G4EkgJtjDvU - Here is proof that the file
is saved and processed. If you want to question it come up with your real
name, stop hiding behind fake emails. Are you a Google employee? What's
your motive?

Best

On Fri, Mar 14, 2014 at 8:39 PM, R D rd.secli...@gmail.com wrote:

You are trying to execute an sh script through a video player. That's an
exec() command.
No, it's not. That's an HTTP GET. Do you have such a poor understanding of
how web applications work? Or did you just not read what I said?

So its the wrong way about accessing the file.
This way, which is the standard way to access files on youtube, tells me
the file doesn't exist. You have yet to prove the file you uploaded can be
accessed or executed by anyone. For that matter, you have still to prove it
can be discovered by anyone. That URL is hard to guess.
And you have still to answer all my other questions, and most of the
questions asked to you on this list.
The burden of proof is on you, and you are making a fool of yourself by
answering all the questions here with the same statements, and links to
your PoC that doesn't proves anything, while everybody asks you for more
evidence.
Keep on the (good?) work,
--Rob'

On Fri, Mar 14, 2014 at 9:22 PM, Nicholas Lemonias.
lem.niko...@googlemail.com wrote:

You are trying to execute an sh script through a video player. That's an
exec() command. So its the wrong way about accessing the file.

On Fri, Mar 14, 2014 at 8:20 PM, R D rd.secli...@gmail.com wrote:

{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}}
And what do we get when we browse to
https://youtube.com/watch?v=KzKDtijwHFI ?
Nothing.
Can you send me a link where I can access the file content of the
arbitrary file you uploaded?
Are you sure this json response, or this file, will be there in a month?
Or in a year? Is the fact that this json response exists a threat to
youtube? Can you quantify how of a threat? How much, in dollars, does it
hurt their business?

--Rob

On Fri, Mar 14, 2014 at 9:08 PM, Nicholas Lemonias.
lem.niko...@googlemail.com wrote:

My claim is now verified

Cheers!

On Fri, Mar 14, 2014 at 8:04 PM, Nicholas Lemonias.
lem.niko...@googlemail.com wrote:

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

That information can be queried from the db, where the metadata are
saved. The files are being saved persistently , as per the above example.

On Fri, Mar 14, 2014 at 8:04 PM, Nicholas Lemonias.
lem.niko...@googlemail.com wrote:

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

That information can be queried from the db, where the metadata are
saved. The files are being saved persistently , as per the above example.

On Fri, Mar 14, 2014 at 8:00 PM, Chris Thompson
christhom7...@gmail.com wrote:

Hi Nikolas,

Please do read (and understand) my entire email before responding -
I understand your frustration trying to get your message across but
maybe
this will help.

Please put aside professional pride for the time being - I know how
it feels to be passionate about something yet have others simply not
understand.

Let me try and bring some sanity to the discussion and explain to
you why people maybe not agreeing with you.

Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC

2014-03-15 Thread M Kirschbaum

The thread starter is right about this. It is a vulnerability, and I think 
Google should start considering this.
 
The JSON service responds to GET requests , and there is a good chance that the 
service is also vulnerable to JSON Hijacking attacks.
 
As a professional penetration tester , I believe that Google was false not to 
award this.___
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] Fwd: Google vulnerabilities with PoC

2014-03-15 Thread Colette Chamberland

Same here... It's like a train wreck, you know you shouldn't watch but it's 
just so damned entertaining at this point that I can't stop...



Sent from my iPhone

 On Mar 14, 2014, at 2:46 PM, Yvan Janssens i...@yvanj.me wrote:
 
 Does anybody still have some popcorn left? 
 
 They ran out of it in the tax free zone in here due to this thread...
 
 Kind regards,
 
 Yvan Janssens
 
 Sent from my PDA - excuse me for my brevity
 
 On 14 Mar 2014, at 18:40, Nicholas Lemonias. lem.niko...@googlemail.com 
 wrote:
 
 We have many PoC's including video clips. We may upload for the security 
 world to see.
  
 However, this is not the way to treat security vulnerabilities. Attacking 
 the researcher and bringing you friends to do aswell, won't mitigate the 
 problem.
  
  
 ___
 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] Fwd: Google vulnerabilities with PoC

2014-03-15 Thread William Scott Lockwood III

It's amazing how much dumber I feel for having read your drivel.
Please for the love of $diety stop posting to this list.

--
W. Scott Lockwood III
AMST Tech (SPI)
GWB2009033817
http://www.shadowplayinternational.org/
There are four boxes to be used in defense of liberty: soap, ballot,
jury, and ammo. Please use in that order. -Ed Howdershelt (Author)

On Fri, Mar 14, 2014 at 9:48 PM, Nicholas Lemonias.
lem.niko...@googlemail.com wrote:
Go to sleep. You have absolutely no understanding of the vulnerability, nor
you have the facts.

If you want a full report ask Softpedia, because we aint releasing them.

On Fri, Mar 14, 2014 at 8:39 PM, R D rd.secli...@gmail.com wrote:

So its the wrong way about accessing the file.
This way, which is the standard way to access files on youtube, tells me
the file doesn't exist. You have yet to prove the file you uploaded can be
accessed or executed by anyone. For that matter, you have still to prove it
can be discovered by anyone. That URL is hard to guess.
And you have still to answer all my other questions, and most of the
questions asked to you on this list.
The burden of proof is on you, and you are making a fool of yourself by
answering all the questions here with the same statements, and links to your
PoC that doesn't proves anything, while everybody asks you for more
evidence.
Keep on the (good?) work,
--Rob'

On Fri, Mar 14, 2014 at 9:22 PM, Nicholas Lemonias.
lem.niko...@googlemail.com wrote:

You are trying to execute an sh script through a video player. That's an
exec() command. So its the wrong way about accessing the file.

On Fri, Mar 14, 2014 at 8:20 PM, R D rd.secli...@gmail.com wrote:

{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}}
And what do we get when we browse to
https://youtube.com/watch?v=KzKDtijwHFI ?
Nothing.
Can you send me a link where I can access the file content of the
arbitrary file you uploaded?
Are you sure this json response, or this file, will be there in a month?
Or in a year? Is the fact that this json response exists a threat to
youtube? Can you quantify how of a threat? How much, in dollars, does it
hurt their business?

--Rob

On Fri, Mar 14, 2014 at 9:08 PM, Nicholas Lemonias.
lem.niko...@googlemail.com wrote:

My claim is now verified

Cheers!

On Fri, Mar 14, 2014 at 8:04 PM, Nicholas Lemonias.
lem.niko...@googlemail.com wrote:

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

That information can be queried from the db, where the metadata are
saved. The files are being saved persistently , as per the above example.

On Fri, Mar 14, 2014 at 8:04 PM, Nicholas Lemonias.
lem.niko...@googlemail.com wrote:

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

That information can be queried from the db, where the metadata are
saved. The files are being saved persistently , as per the above
example.

On Fri, Mar 14, 2014 at 8:00 PM, Chris Thompson
christhom7...@gmail.com wrote:

Hi Nikolas,

Please do read (and understand) my entire email before responding -
I understand your frustration trying to get your message across but
maybe
this will help.

Please put aside professional pride for the time being - I know how
it feels to be passionate about something yet have others simply not
understand.

Let me try and bring some sanity to the discussion

Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC

2014-03-15 Thread Colette Chamberland

Omg please for the love of all things human STFU!!!

Sent from my iPhone

 On Mar 15, 2014, at 12:43 AM, Nicholas Lemonias. 
 lem.niko...@googlemail.com wrote:
 
 If you wish to talk seriously about the problem, please send me an email 
 privately. And we can talk about what we have found so far, and perhaps 
 present some more proof of concepts for this on going research. This is 
 between the researcher and Google.
  
 People who do not have the facts have been, trying to attack the arguer, on 
 the basis of their personal beliefs. We are not speaking from experience, but 
 based on our findings which includes PoC media, images, codes - and based on 
 academic literature and recognised practise. Please bear in mind that a lot 
 of research is conducted in academia (those old papers you say) before 
 finally released to the commercial markets.
  
 Regards, 
  
 Nicholas Lemonias
 Information Security Expert
 Advanced Information Security Corp.
 
  
 On Fri, Mar 14, 2014 at 10:49 PM, Mario Vilas mvi...@gmail.com wrote:
 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

Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC

2014-03-15 Thread Brian M. Waters

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 03/15/2014 02:26, Nicholas Lemonias. wrote:
 https://www.youtube.com/watch?v=G4EkgJtjDvU - Here is proof that 
 the file is saved and processed.

disclaimer
Compared to probably most of the folks on this list, I have absolutely
no idea what I'm doing.
/disclaimer

However, at the time I accessed your latest URL (around 2:51 AM EST, or
6:51 GMT), I got a message saying The video is currently being
processed.

So, for all we know, the file is in some queue, waiting for Google to
notice that it's invalid, at which point it will be deleted.

Please get back to us when we are able to download your invalid file,
via YouTube, on our various machines scattered across the globe.

Also, please stop sending so many damn short emails in a row.
Consolidation is nice.

Thank you,

BW

- -- 
Brian M. Waters
+1 (908) 380-8214
br...@brianmwaters.net

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (FreeBSD)

iQEcBAEBCgAGBQJTI/v3AAoJEEYNFaEjEsGopDwH/R8q9+1wWsKg0j8Wg5zIdZZr
tVNT0IIh9vyjC57WxxQ2SamKoEWsCSt4A8aQ60gup2ImT+XoRpSYMZKWAyKOwz//
yiDjKKI9fsRRdXaBT3r8uWLftWA8WzASrMqrqMhayj06HNXjRXhyonJVdxxgrg/6
h+FaZYGlYdmrGtb02pve5i7in6OoYBQj4m85KVzq+Pnvfowqo6VHzlLwfK3vaD4a
8sEm+i63N02VT6ItO9y7fCcv52pU0sjepGIoYV2aTHkIR3BaNmyxSEVaOZclDY37
6HFSdkWZP0rvkQefNY6QcUvMfBszxFfecQ5cGfIcbScx35iLChXQMYJpH9dmPao=
=Ngjk
-END PGP SIGNATURE-

___
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] Fwd: Google vulnerabilities with PoC

2014-03-15 Thread David H

Just curious; what universities have hired you as a lecturer?


On Sat, Mar 15, 2014 at 1:09 AM, Nicholas Lemonias. 
lem.niko...@googlemail.com wrote:

 You are too vague. Please keep this to a level.

 Thank you.


 *Best Regards,*
 *Nicholas Lemonias*

 *Advanced Information Security Corporation.*


 On Sat, Mar 15, 2014 at 5:06 AM, Colette Chamberland 
 cjchamberl...@gmail.com wrote:

 Omg please for the love of all things human STFU!!!

 Sent from my iPhone

 On Mar 15, 2014, at 12:43 AM, Nicholas Lemonias. 
 lem.niko...@googlemail.com wrote:

 If you wish to talk seriously about the problem, please send me an email
 privately. And we can talk about what we have found so far, and perhaps
 present some more proof of concepts for this on going research. This is
 between the researcher and Google.

 People who do not have the facts have been, trying to attack the arguer,
 on the basis of their personal beliefs. We are not speaking from
 experience, but based on our findings which includes PoC media, images,
 codes - and based on academic literature and recognised practise. Please
 bear in mind that a lot of research is conducted in academia (those old
 papers you say) before finally released to the commercial markets.

 Regards,

 *Nicholas Lemonias*
 *Information Security Expert*
 *Advanced Information Security Corp.*


 On Fri, Mar 14, 2014 at 10:49 PM, Mario Vilas mvi...@gmail.com wrote:

 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.comwrote:

 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

Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC

2014-03-15 Thread antisnatchor

Btw, not sure if someone already mentioned it, but you are really
reaching the level
of MustLive. That's actually a big achievement. Congratz.

I'm not sure if you got what lcamtuf is saying (I'm impressed he still
takes time to reply to you),
apparently not. You're still trying to convince us that you're right.

Maybe you can create the next LOIC specifically tailored to DoS Youtube
with this serious bug, ROFL!

Cheers
antisnatchor

Nicholas Lemonias. wrote:
 If you wish to talk seriously about the problem, please send me an email
 privately. And we can talk about what we have found so far, and perhaps
 present some more proof of concepts for this on going research. This is
 between the researcher and Google.

 People who do not have the facts have been, trying to attack the arguer, on
 the basis of their personal beliefs. We are not speaking from experience,
 but based on our findings which includes PoC media, images, codes - and
 based on academic literature and recognised practise. Please bear in mind
 that a lot of research is conducted in academia (those old papers you
 say) before finally released to the commercial markets.

 Regards,

 *Nicholas Lemonias*
 *Information Security Expert*
 *Advanced Information Security Corp.*


 On Fri, Mar 14, 2014 at 10:49 PM, Mario Vilas mvi...@gmail.com wrote:

 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.comwrote:

 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

Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC

2014-03-15 Thread Mario Vilas

On Sat, Mar 15, 2014 at 5:43 AM, Nicholas Lemonias. 
lem.niko...@googlemail.com wrote:

 People who do not have the facts have been, trying to attack the arguer,
 on the basis of their personal beliefs.


Wow. I seriously can't tell if you're trolling or unbelievably narcissistic.

Your work has serious flaws, and have been pointed out with facts over and
over - but you think they're ad-hominem attacks based on the tone of their
replies. Zalewski here is just trying to be nice and patient with you - but
you somehow seem to believe he agrees with you based on the tone of his
replies.

You're either faking it and pulling a massive prank on all of us, or you're
so self absorbed you can't get past your own emotional responses to people
pointing out your mistakes. The actual contents of what they tell you are
irrelevant to you, all that matters is if people praise or criticize you.

I'm beginning to think you may have issues and we should all back off for a
while.

-- 
“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] Fwd: Google vulnerabilities with PoC

2014-03-15 Thread Mario Vilas

That is not what this email says. You can't reply correct to criticism
and pretend it's praise.

On Sat, Mar 15, 2014 at 6:11 AM, Nicholas Lemonias.
lem.niko...@googlemail.com wrote:

Correct.

The mime type can be circumvented. We can confirm this to be a valid
vulnerability.

For the PoC's :

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

On Fri, Mar 14, 2014 at 8:40 PM, Krzysztof Kotowicz
kkotowicz...@gmail.com wrote:

2014-03-14 20:28 GMT+01:00 Nicholas Lemonias. lem.niko...@googlemail.com
:

Then that also means that firewalls and IPS systems are worthless. Why
spend so much time protecting the network layers if a user can send any
file of choice to a remote network through http...

No, they are not worthless per se, but of course for an user content
publishing service they need to allow file upload over HTTP/s. How far
those files are inspected and later processed is another question - and
that could lead to a vulnerability that you DIDN'T demonstrate.

You just uploaded a .sh file. There's no harm in that as nowhere did you
prove that that file is being executed. Similarly (and that has been
pointed out in this thread) you could upload a PHP-GIF polyglot file to a
J2EE application - no vulnerability in this. Prove something by overwriting
a crucial file, tricking other user's browser to execute the file as HTML
from an interesting domain (XSS), popping a shell, triggering XXE when the
file is processed as XML, anything. Then that is a vulnerability. So far -
sorry, it is not, and you've been told it repeatedly.

As for the uploaded files being persistent, there is evidence of that.
For instance a remote admin could be tricked to execute some of
the uploaded files (Social Engineering).

Come on, seriously? Social Engineering can make him download this file
from pastebin just as well. That's a real stretch.

IMHO it is not a security issue. You're uploading a file to some kind of
processing queue that does not validate a file type, but nevertheless only
processes those files as video - there is NO reason to suspect otherwise,
and I'd like to be proven wrong here. Proven as in PoC.

___
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] Fwd: Google vulnerabilities with PoC

2014-03-15 Thread Alfred Beese

Some of the replies in this thread are very unfair to the original poster.I have read the news story and have thoroughly read the proof of concepts which in my opinion indicate that this is surely a security vulnerability. I have worked for Lumension as a security consultant for more than a decade. I have never thought that Google would have gone that far. Quite scary if you ask me... Do notbe discouraged, as a security researcher I have also been getting that. I can certainly certify that this is a security problem, no doubts about that.Big AlGet your free email @http://www.xtcmail.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] Fwd: Google vulnerabilities with PoC

 As a professional penetration tester, [...]
 The JSON service responds to GET requests , and there is a good chance that
 the service is also vulnerable to JSON Hijacking attacks.

That's... not how XSSI works.

To have a script inclusion vulnerability, you need to have a vanilla
GET response that contains some user-specific secrets that are
returned to the caller based on HTTP cookies (or, less likely, other
ambient credentials). For example, a script response that discloses
the contents of your mailbox or the list of private contacts would be
of concern.

Further, the response must be in a format that can be not only loaded,
but also inspected by another site opened in your browser; most types
of JSONP fall into this category, but JSON generally does not,
essentially because of how the meaning of { is overloaded in JS
depending on where it appears in a block of code.

Last but not least, the final piece of the puzzle is that the response
must be served at a URL that can be guessed by third parties who don't
have access to your account.

/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] Fwd: Google vulnerabilities with PoC

 A hacker exploits a JSON (javascript) object that has information of interest 
 for example holding some values for cookies. A lot of times that exploits the 
 same policy origin. The JSON object returned from a server can be forged over 
 writing javascript function that create the object. This happens because of 
 the same origin policy problem in browsers that cannot say if js execution it 
 different for two different sites.

To be honest, I'm not sure I follow, but I'm fairly confident that my
original point stands. If you believe that well-formed JSON objects
without padding can be read across origins within the browser, I would
love to see more information about that. (In this particular case, it
still wouldn't matter because the response doesn't contain secrets,
but it would certainly break a good chunk of the Internet.) JSONP is a
different animal.

/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] Fwd: Google vulnerabilities with PoC

 Is this treated with the same way that says that Remote File Inclusion is not 
 a security issue ?

I'm not sure how RFI came into play on this thread - the original
report wasn't about RFI.

I don't have an agenda here; I'm just trying to get to the bottom of
it and make sure that we converge on a common understanding of the
issue. As in any argument, it's fairly likely that one of us is wrong,
and I accept that it could very well be me - I have been wrong quite a
few times in my life, and it's always a valuable learning opportunity.

I think it's unfortunate that the thread has devolved into various
accusations and credential-slinging, because it reduces the likelihood
of such a productive outcome. Please feel free to ping me directly any
time, though - I'm happy to chat.

Cheers,
/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] Fwd: Google vulnerabilities with PoC

 The thread read Google vulnerabilities with PoC. From my understanding  it 
 was a RFI vulnerability on YouTube, and I voiced my support that this is a 
 vulnerability.

I don't think this is accurate, at least based on the standard
definition of RFI: a server-side scripting language - usually PHP -
accidentally executing a script fetched from a remote server because
it passed an attacker-controlled string to an API that allows both
local file paths and remote URLs.

The report talks about a different behavior: the ability for users to
upload video and non-video content using legitimate functionality of
the site, without a way to make the server do anything interesting
with the received data. This may or may not be interesting on its own
merit, but I think it's pretty far from RFI.

 I also explained a JSON Hijacking case as a follow up, and you said you 
 didn't follow.

Yup, I am genuinely not familiar with the attack vector that *I think*
you are describing, or why it would matter in this context. My earlier
message in this thread explains my reasoning (in essence, there are
certain conditions that have to be met for a typical XSSI bug, and I
don't think they are met here), but if my understanding is wrong, I'd
really like to learn about the proposed attack.

/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] Fwd: Google vulnerabilities with PoC

2014-03-14 Thread Sergio 'shadown' Alvarez

I will, it's late here, but I'm enjoying the show way too much. xD

Instead of discussing why don't you show a client side attack with that thing 
that you call a vulnerability and make every one shut up?, oh wait...because 
you can't! ;-)

A fail has thousand excuses, but success doesn't require any explaination.

In this context a working client side exploit or a Server Shell proof is a 
success, any other thing is crap.

Talking, complaining and showing certification don't work against a computer, a 
working exploit that gives you a shell does.

Cheers,
-- Sergio

On Mar 14, 2014, Nicholas Lemonias. lem.niko...@googlemail.com wrote:
Go to sleep.
-- Forwarded message --
From: Nicholas Lemonias. lem.niko...@googlemail.com
Date: Fri, Mar 14, 2014 at 2:16 PM
Subject: Re: [Full-disclosure] Google vulnerabilities with PoC
To: Sergio 'shadown' Alvarez shad...@gmail.com


Go to sleep


On Fri, Mar 14, 2014 at 1: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

Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC

Enough with this thread.


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

 I am too buy researching satellite security. Been doing that since the
 times of TESO, probably before you were born.

 Have a good night's sleep.


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

 I will, it's late here, but I'm enjoying the show way too much. xD

 Instead of discussing why don't you show a client side attack with that
 thing that you call a vulnerability and make every one shut up?, oh
 wait...because you can't! ;-)

 A fail has thousand excuses, but success doesn't require any
 explaination.

 In this context a working client side exploit or a Server Shell proof is
 a success, any other thing is crap.

 Talking, complaining and showing certification don't work against a
 computer, a working exploit that gives you a shell does.

 Cheers,

 -- Sergio

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


 Go to sleep.
 -- Forwarded message --
 From: Nicholas Lemonias. lem.niko...@googlemail.com
 Date: Fri, Mar 14, 2014 at 2:16 PM
 Subject: Re: [Full-disclosure] Google vulnerabilities with PoC
 To: Sergio 'shadown' Alvarez shad...@gmail.com


 Go to sleep


 On Fri, Mar 14, 2014 at 1: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.comwrote:

 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

Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC

2014-03-14 Thread antisnatchor

LOL you're hopeless.
Good luck with your business. Brave customers!

Cheers
antisnatchor

Nicholas Lemonias. wrote:

 People can read the report if they like. Can't you even do basic
 things like reading a vulnerability report?
  
 Can't you see that the advisory is about writing arbitrary files. If I
 was your boss I would fire you.
 -- Forwarded message --
 From: *Nicholas Lemonias.* lem.niko...@googlemail.com
 mailto: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 mailto: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
 mailto:mvi...@gmail.com wrote:

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

 Hi

 I concur that we are mainly discussing a
 terminology

Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC

The full-disclosure mailing list has really changed. It's full of lamers
nowdays aiming high.





On Fri, Mar 14, 2014 at 5:58 PM, Nicholas Lemonias. 
lem.niko...@googlemail.com wrote:

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

 -- Forwarded message --
 From: Nicholas Lemonias. lem.niko...@googlemail.com
 Date: Fri, Mar 14, 2014 at 5:58 PM
 Subject: Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
 To: antisnatchor antisnatc...@gmail.com


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




 On Fri, Mar 14, 2014 at 5:55 PM, antisnatchor antisnatc...@gmail.comwrote:

 LOL you're hopeless.
 Good luck with your business. Brave customers!

 Cheers
 antisnatchor

 Nicholas Lemonias. wrote:


 People can read the report if they like. Can't you even do basic things
 like reading a vulnerability report?

 Can't you see that the advisory is about writing arbitrary files. If I
 was your boss I would fire you.
 -- Forwarded message --
 From: Nicholas Lemonias. lem.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.comwrote:

 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

Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC

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

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


On Fri, Mar 14, 2014 at 6:00 PM, Nicholas Lemonias. 
lem.niko...@googlemail.com wrote:

 The full-disclosure mailing list has really changed. It's full of lamers
 nowdays aiming high.





 On Fri, Mar 14, 2014 at 5:58 PM, Nicholas Lemonias. 
 lem.niko...@googlemail.com wrote:

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

 -- Forwarded message --
 From: Nicholas Lemonias. lem.niko...@googlemail.com
  Date: Fri, Mar 14, 2014 at 5:58 PM
 Subject: Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
 To: antisnatchor antisnatc...@gmail.com


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




 On Fri, Mar 14, 2014 at 5:55 PM, antisnatchor antisnatc...@gmail.comwrote:

 LOL you're hopeless.
 Good luck with your business. Brave customers!

 Cheers
 antisnatchor

 Nicholas Lemonias. wrote:


 People can read the report if they like. Can't you even do basic things
 like reading a vulnerability report?

 Can't you see that the advisory is about writing arbitrary files. If I
 was your boss I would fire you.
 -- Forwarded message --
 From: Nicholas Lemonias. lem.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.comwrote:

 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

Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC

2014-03-14 Thread antisnatchor

Ahah, I don't want to loose my time with public bug bounties, it's not
even cost-effective.

Sei proprio un nabbo

Nicholas Lemonias. wrote:
 You can't even find a cross site scripting on google.
  
 Find a vuln on Google seems like a dream to some script kiddies.


 On Fri, Mar 14, 2014 at 6:00 PM, Nicholas Lemonias.
 lem.niko...@googlemail.com mailto:lem.niko...@googlemail.com wrote:

 The full-disclosure mailing list has really changed. It's full of
 lamers nowdays aiming high.
  
  
  


 On Fri, Mar 14, 2014 at 5:58 PM, Nicholas Lemonias.
 lem.niko...@googlemail.com mailto:lem.niko...@googlemail.com
 wrote:

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

 -- Forwarded message --
 From: *Nicholas Lemonias.* lem.niko...@googlemail.com
 mailto:lem.niko...@googlemail.com
 Date: Fri, Mar 14, 2014 at 5:58 PM
 Subject: Re: [Full-disclosure] Fwd: Google vulnerabilities
 with PoC
 To: antisnatchor antisnatc...@gmail.com
 mailto:antisnatc...@gmail.com


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


 On Fri, Mar 14, 2014 at 5:55 PM, antisnatchor
 antisnatc...@gmail.com mailto:antisnatc...@gmail.com wrote:

 LOL you're hopeless.
 Good luck with your business. Brave customers!

 Cheers
 antisnatchor

 Nicholas Lemonias. wrote:

 People can read the report if they like. Can't you even
 do basic things like reading a vulnerability report?
  
 Can't you see that the advisory is about writing
 arbitrary files. If I was your boss I would fire you.
 -- Forwarded message --
 From: *Nicholas Lemonias.* lem.niko...@googlemail.com
 mailto: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 mailto: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 mailto:mvi...@gmail.com wrote:

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

 But do you have all the required EH
 certifications? Try this one

Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC

2014-03-14 Thread Ulisses Montenegro

This is one of the most fun threads I've read in fd, and that's no small
feat. Thanks for the laughs.


On Fri, Mar 14, 2014 at 3:00 PM, Nicholas Lemonias. 
lem.niko...@googlemail.com wrote:

 The full-disclosure mailing list has really changed. It's full of lamers
 nowdays aiming high.





 On Fri, Mar 14, 2014 at 5:58 PM, Nicholas Lemonias. 
 lem.niko...@googlemail.com wrote:

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

 -- Forwarded message --
 From: Nicholas Lemonias. lem.niko...@googlemail.com
  Date: Fri, Mar 14, 2014 at 5:58 PM
 Subject: Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
 To: antisnatchor antisnatc...@gmail.com


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




 On Fri, Mar 14, 2014 at 5:55 PM, antisnatchor antisnatc...@gmail.comwrote:

 LOL you're hopeless.
 Good luck with your business. Brave customers!

 Cheers
 antisnatchor

 Nicholas Lemonias. wrote:


 People can read the report if they like. Can't you even do basic things
 like reading a vulnerability report?

 Can't you see that the advisory is about writing arbitrary files. If I
 was your boss I would fire you.
 -- Forwarded message --
 From: Nicholas Lemonias. lem.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.comwrote:

 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

Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC

2014-03-14 Thread Mike Hale

No, you're saying something's a vulnerability without showing any
indication of how it can be abused.

On Fri, Mar 14, 2014 at 11:00 AM, Nicholas Lemonias.
lem.niko...@googlemail.com wrote:
 The full-disclosure mailing list has really changed. It's full of lamers
 nowdays aiming high.





 On Fri, Mar 14, 2014 at 5:58 PM, Nicholas Lemonias.
 lem.niko...@googlemail.com wrote:

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

 -- Forwarded message --
 From: Nicholas Lemonias. lem.niko...@googlemail.com
 Date: Fri, Mar 14, 2014 at 5:58 PM
 Subject: Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
 To: antisnatchor antisnatc...@gmail.com


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




 On Fri, Mar 14, 2014 at 5:55 PM, antisnatchor antisnatc...@gmail.com
 wrote:

 LOL you're hopeless.
 Good luck with your business. Brave customers!

 Cheers
 antisnatchor

 Nicholas Lemonias. wrote:


 People can read the report if they like. Can't you even do basic things
 like reading a vulnerability report?

 Can't you see that the advisory is about writing arbitrary files. If I
 was your boss I would fire you.
 -- Forwarded message --
 From: Nicholas Lemonias. lem.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

Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC

Quite funnily, most erratic comments originate from a @gmail.com host. Does
that mean that Google and Co are attacking the researcher ?


On Fri, Mar 14, 2014 at 6:06 PM, Nicholas Lemonias. 
lem.niko...@googlemail.com wrote:

 Quite funnily, most erratic comments originate from a @gmail.com host.
 Does that mean that Google and Co are attacking the researcher ?




 On Fri, Mar 14, 2014 at 6:04 PM, Mike Hale eyeronic.des...@gmail.comwrote:

 No, you're saying something's a vulnerability without showing any
 indication of how it can be abused.

 On Fri, Mar 14, 2014 at 11:00 AM, Nicholas Lemonias.
 lem.niko...@googlemail.com wrote:
  The full-disclosure mailing list has really changed. It's full of lamers
  nowdays aiming high.
 
 
 
 
 
  On Fri, Mar 14, 2014 at 5:58 PM, Nicholas Lemonias.
  lem.niko...@googlemail.com wrote:
 
  Says the script kiddie... Beg for some publicity. My customers are FTSE
  100.
 
  -- Forwarded message --
  From: Nicholas Lemonias. lem.niko...@googlemail.com
  Date: Fri, Mar 14, 2014 at 5:58 PM
  Subject: Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
  To: antisnatchor antisnatc...@gmail.com
 
 
  Says the script kiddie... Beg for some publicity. My customers are FTSE
  100.
 
 
 
 
  On Fri, Mar 14, 2014 at 5:55 PM, antisnatchor antisnatc...@gmail.com
  wrote:
 
  LOL you're hopeless.
  Good luck with your business. Brave customers!
 
  Cheers
  antisnatchor
 
  Nicholas Lemonias. wrote:
 
 
  People can read the report if they like. Can't you even do basic
 things
  like reading a vulnerability report?
 
  Can't you see that the advisory is about writing arbitrary files. If I
  was your boss I would fire you.
  -- Forwarded message --
  From: Nicholas Lemonias. lem.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

Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC

2014-03-14 Thread antisnatchor

LOL I don't work for Google and you can easily verify that.

Also, your XSS PoCs suck, they don't even trigger automatically but the
victim needs to
go with the mouse over the element LOL:
http://packetstormsecurity.com/files/125135/Visa-Europe-Cross-Site-Scripting.html

Lame

Nicholas Lemonias. wrote:
 Quite funnily, most erratic comments originate from a @gmail.com
 http://gmail.com/ host. Does that mean that Google and Co are
 attacking the researcher ?


 On Fri, Mar 14, 2014 at 6:06 PM, Nicholas Lemonias.
 lem.niko...@googlemail.com mailto:lem.niko...@googlemail.com wrote:

 Quite funnily, most erratic comments originate from a @gmail.com
 http://gmail.com host. Does that mean that Google and Co are
 attacking the researcher ?
  
  


 On Fri, Mar 14, 2014 at 6:04 PM, Mike Hale
 eyeronic.des...@gmail.com mailto:eyeronic.des...@gmail.com wrote:

 No, you're saying something's a vulnerability without showing any
 indication of how it can be abused.

 On Fri, Mar 14, 2014 at 11:00 AM, Nicholas Lemonias.
 lem.niko...@googlemail.com
 mailto:lem.niko...@googlemail.com wrote:
  The full-disclosure mailing list has really changed. It's
 full of lamers
  nowdays aiming high.
 
 
 
 
 
  On Fri, Mar 14, 2014 at 5:58 PM, Nicholas Lemonias.
  lem.niko...@googlemail.com
 mailto:lem.niko...@googlemail.com wrote:
 
  Says the script kiddie... Beg for some publicity. My
 customers are FTSE
  100.
 
  -- Forwarded message --
  From: Nicholas Lemonias. lem.niko...@googlemail.com
 mailto:lem.niko...@googlemail.com
  Date: Fri, Mar 14, 2014 at 5:58 PM
  Subject: Re: [Full-disclosure] Fwd: Google vulnerabilities
 with PoC
  To: antisnatchor antisnatc...@gmail.com
 mailto:antisnatc...@gmail.com
 
 
  Says the script kiddie... Beg for some publicity. My
 customers are FTSE
  100.
 
 
 
 
  On Fri, Mar 14, 2014 at 5:55 PM, antisnatchor
 antisnatc...@gmail.com mailto:antisnatc...@gmail.com
  wrote:
 
  LOL you're hopeless.
  Good luck with your business. Brave customers!
 
  Cheers
  antisnatchor
 
  Nicholas Lemonias. wrote:
 
 
  People can read the report if they like. Can't you even do
 basic things
  like reading a vulnerability report?
 
  Can't you see that the advisory is about writing arbitrary
 files. If I
  was your boss I would fire you.
  -- Forwarded message --
  From: Nicholas Lemonias. lem.niko...@googlemail.com
 mailto: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 mailto: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 mailto:mvi...@gmail.com wrote:
 
  On Fri, Mar 14, 2014 at 12:38 PM, Nicholas Lemonias.
  lem.niko...@googlemail.com
 mailto: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
 mailto:lem.niko

Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC

That's why its called proof of concept, you lamer. Google and Co on the
counter attack. hahaha


On Fri, Mar 14, 2014 at 6:07 PM, antisnatchor antisnatc...@gmail.comwrote:

 LOL I don't work for Google and you can easily verify that.

 Also, your XSS PoCs suck, they don't even trigger automatically but the
 victim needs to
 go with the mouse over the element LOL:

 http://packetstormsecurity.com/files/125135/Visa-Europe-Cross-Site-Scripting.html

 Lame


 Nicholas Lemonias. wrote:

 Quite funnily, most erratic comments originate from a @gmail.com host.
 Does that mean that Google and Co are attacking the researcher ?


 On Fri, Mar 14, 2014 at 6:06 PM, Nicholas Lemonias. 
 lem.niko...@googlemail.com wrote:

 Quite funnily, most erratic comments originate from a @gmail.com host.
 Does that mean that Google and Co are attacking the researcher ?




 On Fri, Mar 14, 2014 at 6:04 PM, Mike Hale eyeronic.des...@gmail.comwrote:

 No, you're saying something's a vulnerability without showing any
 indication of how it can be abused.

 On Fri, Mar 14, 2014 at 11:00 AM, Nicholas Lemonias.
 lem.niko...@googlemail.com wrote:
  The full-disclosure mailing list has really changed. It's full of
 lamers
  nowdays aiming high.
 
 
 
 
 
  On Fri, Mar 14, 2014 at 5:58 PM, Nicholas Lemonias.
  lem.niko...@googlemail.com wrote:
 
  Says the script kiddie... Beg for some publicity. My customers are
 FTSE
  100.
 
  -- Forwarded message --
  From: Nicholas Lemonias. lem.niko...@googlemail.com
  Date: Fri, Mar 14, 2014 at 5:58 PM
  Subject: Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
  To: antisnatchor antisnatc...@gmail.com
 
 
  Says the script kiddie... Beg for some publicity. My customers are
 FTSE
  100.
 
 
 
 
  On Fri, Mar 14, 2014 at 5:55 PM, antisnatchor antisnatc...@gmail.com
 
  wrote:
 
  LOL you're hopeless.
  Good luck with your business. Brave customers!
 
  Cheers
  antisnatchor
 
  Nicholas Lemonias. wrote:
 
 
  People can read the report if they like. Can't you even do basic
 things
  like reading a vulnerability report?
 
  Can't you see that the advisory is about writing arbitrary files. If
 I
  was your boss I would fire you.
  -- Forwarded message --
  From: Nicholas Lemonias. lem.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

Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC

Too bad the findings were manual.. no tools used. raw http communication.

Took me less than 2 minutes to find, following an initial conv I had with
Google Sec Team.


On Fri, Mar 14, 2014 at 6:02 PM, Nicholas Lemonias. 
lem.niko...@googlemail.com wrote:

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

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


 On Fri, Mar 14, 2014 at 6:00 PM, Nicholas Lemonias. 
 lem.niko...@googlemail.com wrote:

 The full-disclosure mailing list has really changed. It's full of lamers
 nowdays aiming high.





 On Fri, Mar 14, 2014 at 5:58 PM, Nicholas Lemonias. 
 lem.niko...@googlemail.com wrote:

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

 -- Forwarded message --
 From: Nicholas Lemonias. lem.niko...@googlemail.com
  Date: Fri, Mar 14, 2014 at 5:58 PM
 Subject: Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
 To: antisnatchor antisnatc...@gmail.com


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




 On Fri, Mar 14, 2014 at 5:55 PM, antisnatchor antisnatc...@gmail.comwrote:

 LOL you're hopeless.
 Good luck with your business. Brave customers!

 Cheers
 antisnatchor

 Nicholas Lemonias. wrote:


 People can read the report if they like. Can't you even do basic things
 like reading a vulnerability report?

 Can't you see that the advisory is about writing arbitrary files. If I
 was your boss I would fire you.
 -- Forwarded message --
 From: Nicholas Lemonias. lem.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.comwrote:

 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

Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC

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

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


On Fri, Mar 14, 2014 at 6:12 PM, Julius Kivimäki
julius.kivim...@gmail.comwrote:

 Dude, seriously. Just stop.


 2014-03-14 20:02 GMT+02:00 Nicholas Lemonias. lem.niko...@googlemail.com
 :

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

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


 On Fri, Mar 14, 2014 at 6:00 PM, Nicholas Lemonias. 
 lem.niko...@googlemail.com wrote:

 The full-disclosure mailing list has really changed. It's full of lamers
 nowdays aiming high.





 On Fri, Mar 14, 2014 at 5:58 PM, Nicholas Lemonias. 
 lem.niko...@googlemail.com wrote:

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

 -- Forwarded message --
 From: Nicholas Lemonias. lem.niko...@googlemail.com
  Date: Fri, Mar 14, 2014 at 5:58 PM
 Subject: Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
 To: antisnatchor antisnatc...@gmail.com


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




 On Fri, Mar 14, 2014 at 5:55 PM, antisnatchor 
 antisnatc...@gmail.comwrote:

 LOL you're hopeless.
 Good luck with your business. Brave customers!

 Cheers
 antisnatchor

 Nicholas Lemonias. wrote:


 People can read the report if they like. Can't you even do basic
 things like reading a vulnerability report?

 Can't you see that the advisory is about writing arbitrary files. If I
 was your boss I would fire you.
 -- Forwarded message --
 From: Nicholas Lemonias. lem.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.comwrote:

 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

Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC

Google is a great service, but according to our proof of concepts (images,
poc's, codes) presented to Softpedia, and verified
by a couple of recognised experts including OWASP - that was a serious
vulnerability.

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




On Fri, Mar 14, 2014 at 6:13 PM, Nicholas Lemonias. 
lem.niko...@googlemail.com wrote:

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

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


 On Fri, Mar 14, 2014 at 6:12 PM, Julius Kivimäki 
 julius.kivim...@gmail.com wrote:

 Dude, seriously. Just stop.


 2014-03-14 20:02 GMT+02:00 Nicholas Lemonias. lem.niko...@googlemail.com
 :

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

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


 On Fri, Mar 14, 2014 at 6:00 PM, Nicholas Lemonias. 
 lem.niko...@googlemail.com wrote:

 The full-disclosure mailing list has really changed. It's full of
 lamers nowdays aiming high.





 On Fri, Mar 14, 2014 at 5:58 PM, Nicholas Lemonias. 
 lem.niko...@googlemail.com wrote:

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

 -- Forwarded message --
 From: Nicholas Lemonias. lem.niko...@googlemail.com
  Date: Fri, Mar 14, 2014 at 5:58 PM
 Subject: Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
 To: antisnatchor antisnatc...@gmail.com


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




 On Fri, Mar 14, 2014 at 5:55 PM, antisnatchor 
 antisnatc...@gmail.comwrote:

 LOL you're hopeless.
 Good luck with your business. Brave customers!

 Cheers
 antisnatchor

 Nicholas Lemonias. wrote:


 People can read the report if they like. Can't you even do basic
 things like reading a vulnerability report?

 Can't you see that the advisory is about writing arbitrary files. If
 I was your boss I would fire you.
 -- Forwarded message --
 From: Nicholas Lemonias. lem.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.comwrote:

 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.comwrote:

 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

Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC

Google is a great service, but according to our proof of concepts (images,
poc's, codes) presented to Softpedia, and verified
by a couple of recognised experts including OWASP - that was a serious
vulnerability.

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


On Fri, Mar 14, 2014 at 6:16 PM, Nicholas Lemonias. 
lem.niko...@googlemail.com wrote:

 Google is a great service, but according to our proof of concepts (images,
 poc's, codes) presented to Softpedia, and verified
 by a couple of recognised experts including OWASP - that was a serious
 vulnerability.

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




 On Fri, Mar 14, 2014 at 6:13 PM, Nicholas Lemonias. 
 lem.niko...@googlemail.com wrote:

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

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


 On Fri, Mar 14, 2014 at 6:12 PM, Julius Kivimäki 
 julius.kivim...@gmail.com wrote:

 Dude, seriously. Just stop.


 2014-03-14 20:02 GMT+02:00 Nicholas Lemonias. 
 lem.niko...@googlemail.com:

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

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


 On Fri, Mar 14, 2014 at 6:00 PM, Nicholas Lemonias. 
 lem.niko...@googlemail.com wrote:

 The full-disclosure mailing list has really changed. It's full of
 lamers nowdays aiming high.





 On Fri, Mar 14, 2014 at 5:58 PM, Nicholas Lemonias. 
 lem.niko...@googlemail.com wrote:

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

 -- Forwarded message --
 From: Nicholas Lemonias. lem.niko...@googlemail.com
  Date: Fri, Mar 14, 2014 at 5:58 PM
 Subject: Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
 To: antisnatchor antisnatc...@gmail.com


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




 On Fri, Mar 14, 2014 at 5:55 PM, antisnatchor antisnatc...@gmail.com
  wrote:

 LOL you're hopeless.
 Good luck with your business. Brave customers!

 Cheers
 antisnatchor

 Nicholas Lemonias. wrote:


 People can read the report if they like. Can't you even do basic
 things like reading a vulnerability report?

 Can't you see that the advisory is about writing arbitrary files. If
 I was your boss I would fire you.
 -- Forwarded message --
 From: Nicholas Lemonias. lem.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.comwrote:

 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.comwrote:

 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

Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC

Jerome of MacAfee has made a very valid point on revisiting separation of
duties in this security instance.

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, whether employed by
Google or other companies. It's usual for incompetent consultants to cover
up each others asses - speaking from experience.





On Fri, Mar 14, 2014 at 6:30 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.

 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, whether employed by
 Google or other companies.

 Nicholas.


 On Fri, Mar 14, 2014 at 6:26 PM, Thomas MacKenzie tho...@tmacuk.co.ukwrote:


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

 Inception type stuff going on here.

   Nicholas Lemonias. lem.niko...@googlemail.com
  14 March 2014 18:17
 Google is a great service, but according to our proof of concepts
 (images, poc's, codes) presented to Softpedia, and verified
 by a couple of recognised experts including OWASP - that was a serious
 vulnerability.

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



 ___
 Full-Disclosure - We believe in it.
 Charter: http://lists.grok.org.uk/full-disclosure-charter.html
 Hosted and sponsored by Secunia - http://secunia.com/
   Nicholas Lemonias. lem.niko...@googlemail.com
  14 March 2014 18:16
 Google is a great service, but according to our proof of concepts
 (images, poc's, codes) presented to Softpedia, and verified
 by a couple of recognised experts including OWASP - that was a serious
 vulnerability.

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





 ___
 Full-Disclosure - We believe in it.
 Charter: http://lists.grok.org.uk/full-disclosure-charter.html
 Hosted and sponsored by Secunia - http://secunia.com/
   Nicholas Lemonias. lem.niko...@googlemail.com
  14 March 2014 18:13
 Security vulnerabilities need to be published and reported. That's the
 spirit.

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



 ___
 Full-Disclosure - We believe in it.
 Charter: http://lists.grok.org.uk/full-disclosure-charter.html
 Hosted and sponsored by Secunia - http://secunia.com/
   Mario Vilas mvi...@gmail.com
  14 March 2014 15:55
 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

Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC


   Laughing at the incompetency of some people, who wish to discredit
 OWASP and their reports. Say that to any serious professional, and they
 will laugh at you. Writing arbitrary files to a remote network is a serious
 risk, irrelevantly of how good and reputable that service is.


Best,
___
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] Fwd: Google vulnerabilities with PoC

We have many PoC's including video clips. We may upload for the security
world to see.

However, this is not the way to treat security vulnerabilities. Attacking
the researcher and bringing you friends to do aswell, won't mitigate the
problem.
___
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] Fwd: Google vulnerabilities with PoC

Google research not awarded.

http://www.techworm.net/2014/03/security-research-finds-flaws-in.html
___
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] Fwd: Google vulnerabilities with PoC

You are wrong, because we do have proof of concepts. If we didn't have
them, then there would be no case.

But if there are video clips, images demonstrating impact - in which case
arbitrary file uploads (which is a write() call ) to a remote network, then
it is a vulnerability. It is not about the bounty, but rather about not
defying academic literature and widely recognised practise.

Attacking the arguer, won't make the bug to go away.

Best,

Nicholas.


On Fri, Mar 14, 2014 at 7:01 PM, Krzysztof Kotowicz
kkotowicz...@gmail.comwrote:

 Nicholas, seriously, just stop.

 You have found an 'arbitrary file upload' in a file hosting service and
 claim it is a serious vulnerability. With no proof that your 'arbitrary
 file' is being used anywhere in any context that would lead to code
 execution - on server or client side. You cite OWASP documents (which are
 unrelated to the case), academia papers from 1975 just to find a reason
 it's theoretically serious, not paying any attention to what service you're
 actually attacking and what have you really achieved in that (which is
 demonstrating a filtering weakness at best, low risk).

 Everyone on this list so far explains why you're wrong, but you just won't
 stop. So you start throwing out certificates, your academia experience and
 your respected company. Then - name calling everyone else. Seriously, it's
 just a good laugh for most of us.

 Dude, please, just because you did not qualify for a bounty, there's no
 point in launching a whole campaign like you are. You're essentially
 following the path of Khalil Shreateh (the guy who posted on Zuckerberg FB
 wall) - he DID find a vuln though. Do you really want that? Go ahead, start
 a crowdsourcing campaign!





 2014-03-14 19:40 GMT+01:00 Nicholas Lemonias. lem.niko...@googlemail.com
 :

 We have many PoC's including video clips. We may upload for the security
 world to see.

 However, this is not the way to treat security vulnerabilities. Attacking
 the researcher and bringing you friends to do aswell, won't mitigate the
 problem.



 ___
 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] Fwd: Google vulnerabilities with PoC

We are not asking for a payment. But at least a thank you for our efforts
would do.

Saying that it is not an issue, to upload remotely any file of choice, that
is ridiculous for the organisation they represent.


On Fri, Mar 14, 2014 at 7:09 PM, Nicholas Lemonias. 
lem.niko...@googlemail.com wrote:

 You are wrong, because we do have proof of concepts. If we didn't have
 them, then there would be no case.

 But if there are video clips, images demonstrating impact - in which case
 arbitrary file uploads (which is a write() call ) to a remote network, then
 it is a vulnerability. It is not about the bounty, but rather about not
 defying academic literature and widely recognised practise.

 Attacking the arguer, won't make the bug to go away.

 Best,

 Nicholas.


 On Fri, Mar 14, 2014 at 7:01 PM, Krzysztof Kotowicz 
 kkotowicz...@gmail.com wrote:

 Nicholas, seriously, just stop.

 You have found an 'arbitrary file upload' in a file hosting service and
 claim it is a serious vulnerability. With no proof that your 'arbitrary
 file' is being used anywhere in any context that would lead to code
 execution - on server or client side. You cite OWASP documents (which are
 unrelated to the case), academia papers from 1975 just to find a reason
 it's theoretically serious, not paying any attention to what service you're
 actually attacking and what have you really achieved in that (which is
 demonstrating a filtering weakness at best, low risk).

 Everyone on this list so far explains why you're wrong, but you just
 won't stop. So you start throwing out certificates, your academia
 experience and your respected company. Then - name calling everyone else.
 Seriously, it's just a good laugh for most of us.

 Dude, please, just because you did not qualify for a bounty, there's no
 point in launching a whole campaign like you are. You're essentially
 following the path of Khalil Shreateh (the guy who posted on Zuckerberg FB
 wall) - he DID find a vuln though. Do you really want that? Go ahead, start
 a crowdsourcing campaign!





 2014-03-14 19:40 GMT+01:00 Nicholas Lemonias. lem.niko...@googlemail.com
 :

 We have many PoC's including video clips. We may upload for the security
 world to see.

 However, this is not the way to treat security vulnerabilities.
 Attacking the researcher and bringing you friends to do aswell, won't
 mitigate the problem.



 ___
 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] Fwd: Google vulnerabilities with PoC

And I am not referring just to Google. But for those people who support
that remote uploads to a trusted network is not an issue.  Then that also
means that firewalls and IPS systems are worthless. Why spend so much time
protecting the network layers if a user can send any file of choice to a
remote network...




On Fri, Mar 14, 2014 at 7:15 PM, Krzysztof Kotowicz
kkotowicz...@gmail.comwrote:

 Care to report the same to Dropbox and Pastebin? It's a gold mine, you
 know...


 2014-03-14 20:09 GMT+01:00 Nicholas Lemonias. lem.niko...@googlemail.com
 :

 You are wrong, because we do have proof of concepts. If we didn't have
 them, then there would be no case.

 But if there are video clips, images demonstrating impact - in which case
 arbitrary file uploads (which is a write() call ) to a remote network, then
 it is a vulnerability. It is not about the bounty, but rather about not
 defying academic literature and widely recognised practise.

 Attacking the arguer, won't make the bug to go away.

 Best,

 Nicholas.


 On Fri, Mar 14, 2014 at 7:01 PM, Krzysztof Kotowicz 
 kkotowicz...@gmail.com wrote:

 Nicholas, seriously, just stop.

 You have found an 'arbitrary file upload' in a file hosting service and
 claim it is a serious vulnerability. With no proof that your 'arbitrary
 file' is being used anywhere in any context that would lead to code
 execution - on server or client side. You cite OWASP documents (which are
 unrelated to the case), academia papers from 1975 just to find a reason
 it's theoretically serious, not paying any attention to what service you're
 actually attacking and what have you really achieved in that (which is
 demonstrating a filtering weakness at best, low risk).

 Everyone on this list so far explains why you're wrong, but you just
 won't stop. So you start throwing out certificates, your academia
 experience and your respected company. Then - name calling everyone else.
 Seriously, it's just a good laugh for most of us.

 Dude, please, just because you did not qualify for a bounty, there's no
 point in launching a whole campaign like you are. You're essentially
 following the path of Khalil Shreateh (the guy who posted on Zuckerberg FB
 wall) - he DID find a vuln though. Do you really want that? Go ahead, start
 a crowdsourcing campaign!





 2014-03-14 19:40 GMT+01:00 Nicholas Lemonias. 
 lem.niko...@googlemail.com:

 We have many PoC's including video clips. We may upload for the
 security world to see.

 However, this is not the way to treat security vulnerabilities.
 Attacking the researcher and bringing you friends to do aswell, won't
 mitigate the problem.



 ___
 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] Fwd: Google vulnerabilities with PoC

And I am not referring just to Google. But for those people who support
that remote uploads to a trusted network is not an issue.  Then that also
means that firewalls and IPS systems are worthless. Why spend so much time
protecting the network layers if a user can send any file of choice to a
remote network through http.


On Fri, Mar 14, 2014 at 7:20 PM, Nicholas Lemonias. 
lem.niko...@googlemail.com wrote:

 And I am not referring just to Google. But for those people who support
 that remote uploads to a trusted network is not an issue.  Then that also
 means that firewalls and IPS systems are worthless. Why spend so much time
 protecting the network layers if a user can send any file of choice to a
 remote network...




 On Fri, Mar 14, 2014 at 7:15 PM, Krzysztof Kotowicz 
 kkotowicz...@gmail.com wrote:

 Care to report the same to Dropbox and Pastebin? It's a gold mine, you
 know...


 2014-03-14 20:09 GMT+01:00 Nicholas Lemonias. lem.niko...@googlemail.com
 :

 You are wrong, because we do have proof of concepts. If we didn't have
 them, then there would be no case.

 But if there are video clips, images demonstrating impact - in which
 case arbitrary file uploads (which is a write() call ) to a remote network,
 then it is a vulnerability. It is not about the bounty, but rather about
 not defying academic literature and widely recognised practise.

 Attacking the arguer, won't make the bug to go away.

 Best,

 Nicholas.


 On Fri, Mar 14, 2014 at 7:01 PM, Krzysztof Kotowicz 
 kkotowicz...@gmail.com wrote:

 Nicholas, seriously, just stop.

 You have found an 'arbitrary file upload' in a file hosting service and
 claim it is a serious vulnerability. With no proof that your 'arbitrary
 file' is being used anywhere in any context that would lead to code
 execution - on server or client side. You cite OWASP documents (which are
 unrelated to the case), academia papers from 1975 just to find a reason
 it's theoretically serious, not paying any attention to what service you're
 actually attacking and what have you really achieved in that (which is
 demonstrating a filtering weakness at best, low risk).

 Everyone on this list so far explains why you're wrong, but you just
 won't stop. So you start throwing out certificates, your academia
 experience and your respected company. Then - name calling everyone else.
 Seriously, it's just a good laugh for most of us.

 Dude, please, just because you did not qualify for a bounty, there's no
 point in launching a whole campaign like you are. You're essentially
 following the path of Khalil Shreateh (the guy who posted on Zuckerberg FB
 wall) - he DID find a vuln though. Do you really want that? Go ahead, start
 a crowdsourcing campaign!





 2014-03-14 19:40 GMT+01:00 Nicholas Lemonias. 
 lem.niko...@googlemail.com:

 We have many PoC's including video clips. We may upload for the
 security world to see.

 However, this is not the way to treat security vulnerabilities.
 Attacking the researcher and bringing you friends to do aswell, won't
 mitigate the problem.



 ___
 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] Fwd: Google vulnerabilities with PoC

Then that also means that firewalls and IPS systems are worthless. Why
spend so much time protecting the network layers if a user can send any
file of choice to a remote network through http...

As for the uploaded files being persistent, there is evidence of that.  For
instance a remote admin could be tricked to execute some of the uploaded
files (Social Engineering).

So our report sent as part of Google's security program, should not be
treated as a non-security issue.


Thanks,


On Fri, Mar 14, 2014 at 7:23 PM, R D rd.secli...@gmail.com wrote:

 I'm going to try to spell it out clearly.

 You don't have unrestricted file upload[1]. Keep in mind you're trying to
 abuse youtube, which is essentially a video file upload service. So the
 fact that you can upload files is not surprising.
 Now you're uploading non-video files. Cool. But not earth-shattering.
 They are not accessible to anyone but you, as far as I can tell, and I
 don't even think you can access the file contents on the remote server, but
 please prove me wrong on both points.
 You are still, as far as I can tell, bound by the per-file and per-account
 quota on disk occupation, so you don't have a DoS by resource exhaustion.
 You can't force server-side file path, so you don't have RFI or DoS by
 messing with the remote file system. You can't execute the files you
 uploaded, so you don't have arbitrary code execution.

 But you are right about what your PoC does. You bypassed a security
 control, you uploaded crap on youtube servers, and by that you exhausted
 their resources by a fraction of the quota they allow you when signing up.
 BTW, I don't think they keep invalid video files for an indefinite period
 of time in a user account, but I might be wrong.

 The burden of proof is still on your side as to whether or not the bug you
 found has any impact that was not already accepted by youtube allowing
 registered users to upload whatever crap they see fit as long as it is
 video. You failed to provide this proof, and please be sure the audience of
 fulldisclosure is not attacking the researcher but working with you to
 have a better understanding of the bug you found, even though you kinda
 acted like a fool in this thread.

 Please keep on searching and finding vulns, please keep on publishing
 them, and use this as a learning experience that not all bugs or control
 bypasses are security vulnerabilities.

 --Rob'

 [1] As per OWASP (https://www.owasp.org/index.php/Unrestricted_File_Upload
 ):

 There are really two classes of problems here. The first is with the file
 metadata, like the path and file name. These are generally provided by the
 transport, such as HTTP multi-part encoding. This data may trick the
 application into overwriting a critical file or storing the file in a bad
 location. You must validate the metadata extremely carefully before using
 it.

 Your POC doesn't demonstrate that.

 The other class of problem is with the file size or content. The range of
 problems here depends entirely on what the file is used for. See the
 examples below for some ideas about how files might be misused. To protect
 against this type of attack, you should analyze everything your application
 does with files and think carefully about what processing and interpreters
 are involved.

 Your POC kinda does that, but you didn't provide proof it's possible to
 execute what you uploaded, either using social engineering or any other
 method.

 Also, please don't say verified by a couple of recognised experts
 including OWASP unless you actually spoke with someone @owasp and she
 validated your findings.


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

 We have many PoC's including video clips. We may upload for the security
 world to see.

 However, this is not the way to treat security vulnerabilities. Attacking
 the researcher and bringing you friends to do aswell, won't mitigate the
 problem.



 ___
 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] Fwd: Google vulnerabilities with PoC

It is an example, citing that there has been a security hole on Youtube
that needs patching. End of Story.


On Fri, Mar 14, 2014 at 7:32 PM, Julius Kivimäki
julius.kivim...@gmail.comwrote:

 Wait, so remote code execution by social engineering wasn't a troll? I'm
 confused.


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

 Then that also means that firewalls and IPS systems are worthless. Why
 spend so much time protecting the network layers if a user can send any
 file of choice to a remote network through http...

 As for the uploaded files being persistent, there is evidence of that.
 For instance a remote admin could be tricked to execute some of
 the uploaded files (Social Engineering).

 So our report sent as part of Google's security program, should not be
 treated as a non-security issue.


 Thanks,


 On Fri, Mar 14, 2014 at 7:23 PM, R D rd.secli...@gmail.com wrote:

 I'm going to try to spell it out clearly.

 You don't have unrestricted file upload[1]. Keep in mind you're trying
 to abuse youtube, which is essentially a video file upload service. So the
 fact that you can upload files is not surprising.
 Now you're uploading non-video files. Cool. But not earth-shattering.
 They are not accessible to anyone but you, as far as I can tell, and I
 don't even think you can access the file contents on the remote server, but
 please prove me wrong on both points.
 You are still, as far as I can tell, bound by the per-file and
 per-account quota on disk occupation, so you don't have a DoS by resource
 exhaustion.
 You can't force server-side file path, so you don't have RFI or DoS by
 messing with the remote file system. You can't execute the files you
 uploaded, so you don't have arbitrary code execution.

 But you are right about what your PoC does. You bypassed a security
 control, you uploaded crap on youtube servers, and by that you exhausted
 their resources by a fraction of the quota they allow you when signing up.
 BTW, I don't think they keep invalid video files for an indefinite period
 of time in a user account, but I might be wrong.

 The burden of proof is still on your side as to whether or not the bug
 you found has any impact that was not already accepted by youtube allowing
 registered users to upload whatever crap they see fit as long as it is
 video. You failed to provide this proof, and please be sure the audience of
 fulldisclosure is not attacking the researcher but working with you to
 have a better understanding of the bug you found, even though you kinda
 acted like a fool in this thread.

 Please keep on searching and finding vulns, please keep on publishing
 them, and use this as a learning experience that not all bugs or control
 bypasses are security vulnerabilities.

 --Rob'

 [1] As per OWASP (
 https://www.owasp.org/index.php/Unrestricted_File_Upload):

 There are really two classes of problems here. The first is with the
 file metadata, like the path and file name. These are generally provided by
 the transport, such as HTTP multi-part encoding. This data may trick the
 application into overwriting a critical file or storing the file in a bad
 location. You must validate the metadata extremely carefully before using
 it.

 Your POC doesn't demonstrate that.

 The other class of problem is with the file size or content. The range
 of problems here depends entirely on what the file is used for. See the
 examples below for some ideas about how files might be misused. To protect
 against this type of attack, you should analyze everything your application
 does with files and think carefully about what processing and interpreters
 are involved.

 Your POC kinda does that, but you didn't provide proof it's possible to
 execute what you uploaded, either using social engineering or any other
 method.

 Also, please don't say verified by a couple of recognised experts
 including OWASP unless you actually spoke with someone @owasp and she
 validated your findings.


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

 We have many PoC's including video clips. We may upload for the
 security world to see.

 However, this is not the way to treat security vulnerabilities.
 Attacking the researcher and bringing you friends to do aswell, won't
 mitigate the problem.



 ___
 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] Fwd: Google vulnerabilities with PoC

That information can be queried from the db, where the metadata are saved.
The files are being saved persistently , as per the above example.

On Fri, Mar 14, 2014 at 8:04 PM, Nicholas Lemonias.
lem.niko...@googlemail.com wrote:

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

That information can be queried from the db, where the metadata are saved.
The files are being saved persistently , as per the above example.

On Fri, Mar 14, 2014 at 8:00 PM, Chris Thompson
christhom7...@gmail.comwrote:

Hi Nikolas,

Please do read (and understand) my entire email before responding - I
understand your frustration trying to get your message across but maybe
this will help.

Please put aside professional pride for the time being - I know how it
feels to be passionate about something yet have others simply not
understand.

Let me try and bring some sanity to the discussion and explain to you why
people maybe not agreeing with you.

You (rightly so) highlighted what you believe to be an issue in a Youtube
whereby it appears (to you) than you can upload an arbitrary file. If you
can indeed do this as you suspect then your points are valid and you may
be able to cause various issues associated with it such as DOS etc -
especially if the uploaded files cannot or are not tracked.

However...

Consider than you are talking to an API and what you are getting back
(the JSON response) in your example is simply a response from the API to
say the file you uploaded has been received and saved.

Now, as you no doubt know, when you upload a regular movie to YouTube,
once uploaded it goes away and does some post-processing, converting it to
flash for example. What's to say that there isn't some verification aspect
to this post-processing that checks if the file is intact a valid movie and
if not removes it.

If you could for example demonstrate that the file was indeed persistent,
by being able to retrieve it for example then again, you would have solid
ground to claim an issue however your claims at this point are based on an
assumption Let me explain.

1. You have demonstrated than you can send any file to an API and the
API returned an acknowledgment of receiving (and saving) the file.

2. You / we don't know what Google do with files once they have been
received from the API - maybe they process them and validate them - we
simply don't know.

3. You have hypothesized that you can retrieve the file by manipulating
tokens etc and you may be right, but you have not demonstrated it as such.

Because of this, you seem to have made a CLAIM that you can upload
arbitrary files to Google however SHOWN that you can simply send files to
an API and an API responds in a certain way.

I am NOT saying you haven't found an issue, what I am saying is that you
need to demonstrate that the issue is real and thus can be abused. If the
Google service simply verifies all uploaded files once they are uploaded
and discards them if invalid, then you haven't really found anything.

If you were to prove that you were able to retrieve this uploaded file
then how could anyone dispute your bug.

Hope this helps

Cheers!

___
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] Fwd: Google vulnerabilities with PoC

My claim is now verified

Cheers!

On Fri, Mar 14, 2014 at 8:04 PM, Nicholas Lemonias.
lem.niko...@googlemail.com wrote:

That information can be queried from the db, where the metadata are saved.
The files are being saved persistently , as per the above example.

On Fri, Mar 14, 2014 at 8:04 PM, Nicholas Lemonias.
lem.niko...@googlemail.com wrote:

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

That information can be queried from the db, where the metadata are
saved. The files are being saved persistently , as per the above example.

On Fri, Mar 14, 2014 at 8:00 PM, Chris Thompson
christhom7...@gmail.comwrote:

Hi Nikolas,

Please do read (and understand) my entire email before responding - I
understand your frustration trying to get your message across but maybe
this will help.

Please put aside professional pride for the time being - I know how it
feels to be passionate about something yet have others simply not
understand.

Let me try and bring some sanity to the discussion and explain to you
why people maybe not agreeing with you.

You (rightly so) highlighted what you believe to be an issue in a
Youtube whereby it appears (to you) than you can upload an arbitrary file.
If you can indeed do this as you suspect then your points are valid and you
may be able to cause various issues associated with it such as DOS etc -
especially if the uploaded files cannot or are not tracked.

However...

Consider than you are talking to an API and what you are getting back
(the JSON response) in your example is simply a response from the API to
say the file you uploaded has been received and saved.

If you could for example demonstrate that the file was indeed
persistent, by being able to retrieve it for example then again, you would
have solid ground to claim an issue however your claims at this point are
based on an assumption Let me explain.

1. You have demonstrated than you can send any file to an API and the
API returned an acknowledgment of receiving (and saving) the file.

2. You / we don't know what Google do with files once they have been
received from the API - maybe they process them and validate them - we
simply don't know.

3. You have hypothesized that you can retrieve the file by manipulating
tokens etc and you may be right, but you have not demonstrated it as such.

Because of this, you seem to have made a CLAIM that you can upload
arbitrary files to Google however SHOWN that you can simply send files to
an API and an API responds in a certain way.

If you were to prove that you were able to retrieve this uploaded file
then how could anyone dispute your bug.

Hope this helps

Cheers!

___
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] Fwd: Google vulnerabilities with PoC

So you can query a file that I uploaded, and you can see that is uploaded
successfully and saved. That information does not require the user to be
logged in.

On Fri, Mar 14, 2014 at 8:08 PM, Nicholas Lemonias.
lem.niko...@googlemail.com wrote:

My claim is now verified

Cheers!

On Fri, Mar 14, 2014 at 8:04 PM, Nicholas Lemonias.
lem.niko...@googlemail.com wrote:

That information can be queried from the db, where the metadata are
saved. The files are being saved persistently , as per the above example.

On Fri, Mar 14, 2014 at 8:04 PM, Nicholas Lemonias.
lem.niko...@googlemail.com wrote:

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

That information can be queried from the db, where the metadata are
saved. The files are being saved persistently , as per the above example.

On Fri, Mar 14, 2014 at 8:00 PM, Chris Thompson christhom7...@gmail.com
wrote:

Hi Nikolas,

Please do read (and understand) my entire email before responding - I
understand your frustration trying to get your message across but maybe
this will help.

Please put aside professional pride for the time being - I know how it
feels to be passionate about something yet have others simply not
understand.

Let me try and bring some sanity to the discussion and explain to you
why people maybe not agreeing with you.

You (rightly so) highlighted what you believe to be an issue in a
Youtube whereby it appears (to you) than you can upload an arbitrary file.
If you can indeed do this as you suspect then your points are valid and you
may be able to cause various issues associated with it such as DOS etc -
especially if the uploaded files cannot or are not tracked.

However...

Consider than you are talking to an API and what you are getting back
(the JSON response) in your example is simply a response from the API to
say the file you uploaded has been received and saved.

If you could for example demonstrate that the file was indeed
persistent, by being able to retrieve it for example then again, you would
have solid ground to claim an issue however your claims at this point are
based on an assumption Let me explain.

1. You have demonstrated than you can send any file to an API and the
API returned an acknowledgment of receiving (and saving) the file.

2. You / we don't know what Google do with files once they have been
received from the API - maybe they process them and validate them - we
simply don't know.

3. You have hypothesized that you can retrieve the file by manipulating
tokens etc and you may be right, but you have not demonstrated it as such.

Because of this, you seem to have made a CLAIM that you can upload
arbitrary files to Google however SHOWN that you can simply send files to
an API and an API responds in a certain way.

I am NOT saying you haven't found an issue, what I am saying is that
you need to demonstrate that the issue is real and thus can be abused. If
the Google service simply verifies all uploaded files once they are
uploaded and discards them if invalid, then you haven't really found
anything.

If you were to prove that you were able to retrieve this uploaded file
then how could anyone dispute your bug.

Hope this helps

Cheers!

___
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] Fwd: Google vulnerabilities with PoC

You are trying to execute an sh script through a video player. That's an
exec() command. So its the wrong way about accessing the file.

On Fri, Mar 14, 2014 at 8:20 PM, R D rd.secli...@gmail.com wrote:

--Rob

On Fri, Mar 14, 2014 at 9:08 PM, Nicholas Lemonias.
lem.niko...@googlemail.com wrote:

My claim is now verified

Cheers!

On Fri, Mar 14, 2014 at 8:04 PM, Nicholas Lemonias.
lem.niko...@googlemail.com wrote:

That information can be queried from the db, where the metadata are
saved. The files are being saved persistently , as per the above example.

On Fri, Mar 14, 2014 at 8:04 PM, Nicholas Lemonias.
lem.niko...@googlemail.com wrote:

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

That information can be queried from the db, where the metadata are
saved. The files are being saved persistently , as per the above example.

On Fri, Mar 14, 2014 at 8:00 PM, Chris Thompson
christhom7...@gmail.com wrote:

Hi Nikolas,

Please do read (and understand) my entire email before responding - I
understand your frustration trying to get your message across but maybe
this will help.

Please put aside professional pride for the time being - I know how it
feels to be passionate about something yet have others simply not
understand.

Let me try and bring some sanity to the discussion and explain to you
why people maybe not agreeing with you.

You (rightly so) highlighted what you believe to be an issue in a
Youtube whereby it appears (to you) than you can upload an arbitrary file.
If you can indeed do this as you suspect then your points are valid and
you
may be able to cause various issues associated with it such as DOS etc -
especially if the uploaded files cannot or are not tracked.

However...

Consider than you are talking to an API and what you are getting back
(the JSON response) in your example is simply a response from the API to
say the file you uploaded has been received and saved.

If you could for example demonstrate that the file was indeed
persistent, by being able to retrieve it for example then again, you would
have solid ground to claim an issue however your claims at this point are
based on an assumption Let me explain.

1. You have demonstrated than you can send any file to an API and
the API returned an acknowledgment of receiving (and saving) the file.

2. You / we don't know what Google do with files once they have been
received from the API - maybe they process them and validate them - we
simply don't know.

3. You have hypothesized that you can retrieve the file by
manipulating tokens etc and you may be right, but you have not
demonstrated
it as such.

Because of this, you seem to have

Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC

Are you sure this json response, or this file, will be there in a month? Or
in a year? Is the fact that this json response exists a threat to youtube?
Can you quantify how of a threat? How much, in dollars, does it hurt their
business?

This file may be here if the admins don't delete it. Now they may do ;@)

So where do you think that information is coming from? The metadata and
tags, and headers are contained in a database.

The files are stored persistently , since they can be quoted. So the API
works both ways. The main thing here is that the files are there, otherwise
there metadata information would be deleted from the db aswell.

http://gdata.youtube.com/demo/index.html?utm_source=
twitterfeedutm_medium=twitter

Youtube DATA API is unique.. the commands can be send through that
interface... So we do definitely know that that is coming from a database.

On Fri, Mar 14, 2014 at 8:22 PM, Nicholas Lemonias.
lem.niko...@googlemail.com wrote:

You are trying to execute an sh script through a video player. That's an
exec() command. So its the wrong way about accessing the file.

On Fri, Mar 14, 2014 at 8:20 PM, R D rd.secli...@gmail.com wrote:

--Rob

On Fri, Mar 14, 2014 at 9:08 PM, Nicholas Lemonias.
lem.niko...@googlemail.com wrote:

My claim is now verified

Cheers!

On Fri, Mar 14, 2014 at 8:04 PM, Nicholas Lemonias.
lem.niko...@googlemail.com wrote:

That information can be queried from the db, where the metadata are
saved. The files are being saved persistently , as per the above example.

On Fri, Mar 14, 2014 at 8:04 PM, Nicholas Lemonias.
lem.niko...@googlemail.com wrote:

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

That information can be queried from the db, where the metadata are
saved. The files are being saved persistently , as per the above example.

On Fri, Mar 14, 2014 at 8:00 PM, Chris Thompson
christhom7...@gmail.com wrote:

Hi Nikolas,

Please do read (and understand) my entire email before responding - I
understand your frustration trying to get your message across but maybe
this will help.

Please put aside professional pride for the time being - I know how
it feels to be passionate about something yet have others simply not
understand.

Let me try and bring some sanity to the discussion and explain to you
why people maybe not agreeing with you.

You (rightly so) highlighted what you believe to be an issue in a
Youtube whereby it appears (to you) than you can upload an arbitrary
file.
If you can indeed do this as you suspect then your points are valid and
you
may be able to cause various issues associated with it such as DOS etc
-
especially if the uploaded files cannot or are not tracked.

However...

Consider than you are talking to an API and what you are getting back
(the JSON response) in your example is simply a response from the API to
say the file you uploaded has been received and saved.

Now, as you no doubt know, when you upload a regular movie to
YouTube, once uploaded it goes away and

Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC

So where do you think that information is coming from? The metadata and
tags, and headers are contained in a database.

http://gdata.youtube.com/demo/index.html?utm_source=
twitterfeedutm_medium=twitter

Youtube DATA API is unique.. the commands can be send through that
interface... So we do definitely know that that is coming from a database.
That same video id can be queried through the above link. Having done so, I
confirmed that the information originate from a direct connection to the
db, where the data are stored.

On Fri, Mar 14, 2014 at 8:20 PM, Nicholas Lemonias.
lem.niko...@googlemail.com wrote:

So where do you think that information is coming from? The metadata and
tags, and headers are contained in a database.

http://gdata.youtube.com/demo/index.html?utm_source=twitterfeedutm_medium=twitter

Youtube DATA API is unique.. the commands can be send through that
interface... So we do definitely know that that is coming from a database.

On Fri, Mar 14, 2014 at 8:16 PM, Chris Thompson
christhom7...@gmail.comwrote:

Hi Nicholas,

Again, you hypothesize that you are getting a response from the database,
but you really don't know that. You have no idea when the code is doing
behind the endpoint.

upload.youtube.com is simple an endpoint that you are sending a request
to and getting a response from -

Can you upload a ZIP file for example and then get that same ZIP file
from another machine? If you can do that, then who can question your bug.

Again, i'm not trying to be a dick - just trying to help!

Cheers...

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

My claim is now verified

Cheers!

On Fri, Mar 14, 2014 at 8:04 PM, Nicholas Lemonias.
lem.niko...@googlemail.com wrote:

That information can be queried from the db, where the metadata are
saved. The files are being saved persistently , as per the above example.

On Fri, Mar 14, 2014 at 8:04 PM, Nicholas Lemonias.
lem.niko...@googlemail.com wrote:

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

That information can be queried from the db, where the metadata are
saved. The files are being saved persistently , as per the above example.

On Fri, Mar 14, 2014 at 8:00 PM, Chris Thompson
christhom7...@gmail.com wrote:

Hi Nikolas,

Please do read (and understand) my entire email before responding - I
understand your frustration trying to get your message across but maybe
this will help.

Please put aside professional pride for the time being - I know how
it feels to be passionate about something yet have others simply not
understand.

Let me try and bring some sanity to the discussion and explain to you
why people maybe not agreeing with you.

You (rightly so) highlighted what you believe to be an issue in a
Youtube whereby it appears (to you) than you can upload an arbitrary
file.
If you can indeed do this as you suspect then your points are valid and
you
may be able to cause various issues associated with it such as DOS etc
-
especially if the uploaded files cannot or are not tracked.

However...

Consider than you are talking to an API and what you are getting back
(the JSON response) in your example is simply a response from the API to
say the file you uploaded has been received and saved.

Now, as you no doubt know, when you upload a regular movie to
YouTube, once uploaded it goes away and does some post-processing,
converting it to flash for example. What's to say that there isn't some
verification aspect to this post-processing that checks if the file is
intact a valid movie and if not removes it.

If you could for example demonstrate that the file was indeed
persistent, by being able to retrieve it for example then again, you
would
have solid ground to claim an issue however your claims at this point are
based on an assumption Let me explain.

1. You have demonstrated than you can send any file to an API and
the API returned an acknowledgment of receiving (and saving) the file.

2. You / we don't know what Google do with files once they have been
received from the API - maybe they process

Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC