Mailing List Archive

Google vulnerabilities with PoC
Re: Google vulnerabilities with PoC [ In reply to ]
When did the ability to upload files of arbitrary types become a security
issue? If the file doesn't get executed, it's really not a problem.
(Besides from potentially breaking site layout standpoint.)


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

> Google vulnerabilities uncovered...
>
>
>
> http://news.softpedia.com/news/Expert-Finds-File-Upload-Vulnerability-in-YouTube-Google-Denies-It-s-a-Security-Issue-431489.shtml
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
Re: Google vulnerabilities with PoC [ In reply to ]
Keep in mind that YouTube allows files to be uploaded by definition. What
you have achieved is upload a file for an extension type that is not
allowed.
It is definitely a vulnerability but a low risk one since you haven't
demonstrated if it has any ill effects.

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

Regards
Pedro
On 13 Mar 2014 11:50, "Nicholas Lemonias." <lem.nikolas@googlemail.com>
wrote:

> Google vulnerabilities uncovered...
>
>
>
> http://news.softpedia.com/news/Expert-Finds-File-Upload-Vulnerability-in-YouTube-Google-Denies-It-s-a-Security-Issue-431489.shtml
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
Re: Google vulnerabilities with PoC [ In reply to ]
Here is your answer.
https://www.owasp.org/index.php/Unrestricted_File_Upload


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

> When did the ability to upload files of arbitrary types become a security
> issue? If the file doesn't get executed, it's really not a problem.
> (Besides from potentially breaking site layout standpoint.)
>
>
> 2014-03-13 12:43 GMT+02:00 Nicholas Lemonias. <lem.nikolas@googlemail.com>
> :
>
>> Google vulnerabilities uncovered...
>>
>>
>>
>> http://news.softpedia.com/news/Expert-Finds-File-Upload-Vulnerability-in-YouTube-Google-Denies-It-s-a-Security-Issue-431489.shtml
>>
>> _______________________________________________
>> Full-Disclosure - We believe in it.
>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>> Hosted and sponsored by Secunia - http://secunia.com/
>>
>
>
Re: Google vulnerabilities with PoC [ In reply to ]
*https://www.google.com/settings/takeout
<https://www.google.com/settings/takeout> *

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

<https://www.google.gr/#>


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

> Keep in mind that YouTube allows files to be uploaded by definition. What
> you have achieved is upload a file for an extension type that is not
> allowed.
> It is definitely a vulnerability but a low risk one since you haven't
> demonstrated if it has any ill effects.
>
> Can you somehow find the URL to where the file was uploaded? I would guess
> not, since a well designed service like YouTube should hide those details
> and no leak them in any way. Maybe if you are able to find that you can
> combine with this vulnerability and get them to open their wallet?
>
> Regards
> Pedro
> On 13 Mar 2014 11:50, "Nicholas Lemonias." <lem.nikolas@googlemail.com>
> wrote:
>
>> Google vulnerabilities uncovered...
>>
>>
>>
>> http://news.softpedia.com/news/Expert-Finds-File-Upload-Vulnerability-in-YouTube-Google-Denies-It-s-a-Security-Issue-431489.shtml
>>
>> _______________________________________________
>> Full-Disclosure - We believe in it.
>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>> Hosted and sponsored by Secunia - http://secunia.com/
>>
>
Re: Google vulnerabilities with PoC [ In reply to ]
I suggest you to read on Content Delivery Network Architectures .

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

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


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

> *https://www.google.com/settings/takeout
> <https://www.google.com/settings/takeout> *
>
> *However the only problem would be to get past Content ID filtering. I
> suppose encrypting an uploaded file, and obfuscating file headers may get
> past YouTube's Content ID filtering. Youtube is not a File Transfer
> Protocol... It's there to serve media content. *
>
> <https://www.google.gr/#>
>
>
> On Thu, Mar 13, 2014 at 1:52 PM, Pedro Ribeiro <pedrib@gmail.com> wrote:
>
>> Keep in mind that YouTube allows files to be uploaded by definition. What
>> you have achieved is upload a file for an extension type that is not
>> allowed.
>> It is definitely a vulnerability but a low risk one since you haven't
>> demonstrated if it has any ill effects.
>>
>> Can you somehow find the URL to where the file was uploaded? I would
>> guess not, since a well designed service like YouTube should hide those
>> details and no leak them in any way. Maybe if you are able to find that you
>> can combine with this vulnerability and get them to open their wallet?
>>
>> Regards
>> Pedro
>> On 13 Mar 2014 11:50, "Nicholas Lemonias." <lem.nikolas@googlemail.com>
>> wrote:
>>
>>> Google vulnerabilities uncovered...
>>>
>>>
>>>
>>> http://news.softpedia.com/news/Expert-Finds-File-Upload-Vulnerability-in-YouTube-Google-Denies-It-s-a-Security-Issue-431489.shtml
>>>
>>> _______________________________________________
>>> Full-Disclosure - We believe in it.
>>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>>> Hosted and sponsored by Secunia - http://secunia.com/
>>>
>>
>
Re: Google vulnerabilities with PoC [ In reply to ]
Did you even read that article? (Not that OWASP has any sort of credibility
anyways). From what I saw in your previous post you are both unable to
execute the files or even access them and thus unable to manipulate the
content-type the files are returned with, therefore there is no
vulnerability (According to the article you linked.).

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


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

> Here is your answer.
> https://www.owasp.org/index.php/Unrestricted_File_Upload
>
>
> On Thu, Mar 13, 2014 at 1:39 PM, Julius Kivimäki <
> julius.kivimaki@gmail.com> wrote:
>
>> When did the ability to upload files of arbitrary types become a security
>> issue? If the file doesn't get executed, it's really not a problem.
>> (Besides from potentially breaking site layout standpoint.)
>>
>>
>> 2014-03-13 12:43 GMT+02:00 Nicholas Lemonias. <lem.nikolas@googlemail.com
>> >:
>>
>>> Google vulnerabilities uncovered...
>>>
>>>
>>>
>>> http://news.softpedia.com/news/Expert-Finds-File-Upload-Vulnerability-in-YouTube-Google-Denies-It-s-a-Security-Issue-431489.shtml
>>>
>>> _______________________________________________
>>> Full-Disclosure - We believe in it.
>>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>>> Hosted and sponsored by Secunia - http://secunia.com/
>>>
>>
>>
>
Re: Google vulnerabilities with PoC [ In reply to ]
*You are wrong about accessing the files. What has not been confirmed is
remote code execution. We are working on it.*
*And please, OWASP is recognised worldwide... *

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

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




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

> Did you even read that article? (Not that OWASP has any sort of
> credibility anyways). From what I saw in your previous post you are both
> unable to execute the files or even access them and thus unable to
> manipulate the content-type the files are returned with, therefore there is
> no vulnerability (According to the article you linked.).
>
> BTW, you should look for more cool vulnerabilities in amazons EC2, I'm
> sure you will find some "Unrestricted File Upload" holes.
>
>
> 2014-03-13 16:18 GMT+02:00 Nicholas Lemonias. <lem.nikolas@googlemail.com>
> :
>
> Here is your answer.
>> https://www.owasp.org/index.php/Unrestricted_File_Upload
>>
>>
>> On Thu, Mar 13, 2014 at 1:39 PM, Julius Kivimäki <
>> julius.kivimaki@gmail.com> wrote:
>>
>>> When did the ability to upload files of arbitrary types become a
>>> security issue? If the file doesn't get executed, it's really not a
>>> problem. (Besides from potentially breaking site layout standpoint.)
>>>
>>>
>>> 2014-03-13 12:43 GMT+02:00 Nicholas Lemonias. <
>>> lem.nikolas@googlemail.com>:
>>>
>>>> Google vulnerabilities uncovered...
>>>>
>>>>
>>>>
>>>> http://news.softpedia.com/news/Expert-Finds-File-Upload-Vulnerability-in-YouTube-Google-Denies-It-s-a-Security-Issue-431489.shtml
>>>>
>>>> _______________________________________________
>>>> Full-Disclosure - We believe in it.
>>>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>>>> Hosted and sponsored by Secunia - http://secunia.com/
>>>>
>>>
>>>
>>
>
Re: Google vulnerabilities with PoC [ In reply to ]
OWASP is recognized worldwide, so is CEH and a bunch of other morons. That
doesn't mean their publications are worth anything. Now tell me, why would
arbitrary file upload on a CDN lead to code execution (Besides for HTML,
which you have been unable to confirm)?


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

> *You are wrong about accessing the files. What has not been confirmed is
> remote code execution. We are working on it.*
> *And please, OWASP is recognised worldwide... *
>
> *Files can be accessed through Google Take out with a little bit of
> skills.*
>
> *https://www.google.com/settings/takeout
> <https://www.google.com/settings/takeout> *
>
>
>
>
> On Thu, Mar 13, 2014 at 4:09 PM, Julius Kivimäki <
> julius.kivimaki@gmail.com> wrote:
>
>> Did you even read that article? (Not that OWASP has any sort of
>> credibility anyways). From what I saw in your previous post you are both
>> unable to execute the files or even access them and thus unable to
>> manipulate the content-type the files are returned with, therefore there is
>> no vulnerability (According to the article you linked.).
>>
>> BTW, you should look for more cool vulnerabilities in amazons EC2, I'm
>> sure you will find some "Unrestricted File Upload" holes.
>>
>>
>> 2014-03-13 16:18 GMT+02:00 Nicholas Lemonias. <lem.nikolas@googlemail.com
>> >:
>>
>> Here is your answer.
>>> https://www.owasp.org/index.php/Unrestricted_File_Upload
>>>
>>>
>>> On Thu, Mar 13, 2014 at 1:39 PM, Julius Kivimäki <
>>> julius.kivimaki@gmail.com> wrote:
>>>
>>>> When did the ability to upload files of arbitrary types become a
>>>> security issue? If the file doesn't get executed, it's really not a
>>>> problem. (Besides from potentially breaking site layout standpoint.)
>>>>
>>>>
>>>> 2014-03-13 12:43 GMT+02:00 Nicholas Lemonias. <
>>>> lem.nikolas@googlemail.com>:
>>>>
>>>>> Google vulnerabilities uncovered...
>>>>>
>>>>>
>>>>>
>>>>> http://news.softpedia.com/news/Expert-Finds-File-Upload-Vulnerability-in-YouTube-Google-Denies-It-s-a-Security-Issue-431489.shtml
>>>>>
>>>>> _______________________________________________
>>>>> Full-Disclosure - We believe in it.
>>>>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>>>>> Hosted and sponsored by Secunia - http://secunia.com/
>>>>>
>>>>
>>>>
>>>
>>
>
Re: Google vulnerabilities with PoC [ In reply to ]
Hello Julius,

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


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

> Hello Julius,
>
> I appreciate your interest to learn more. OWASP is quite credible, and has
> gained some international recognition. It is a benchmark for many vendors.
> I suggest you to read on OSI/7-Layer Model. A website may disallow uploads
> of certain file types for security reasons, and let's assume at the
> application layer. If we manage to get past the security controls, that
> means we can write unrestrictedly any type of file to the remote network.
> That also means that we get past their firewall, since the communication is
> through HTTP (port 80). CDN nodes are deployed to multiple colocation
> (thousands of nodes and thousands of servers across the world). The files
> are cached deep in the network structures to thousands of servers.
>
>
> On Thu, Mar 13, 2014 at 4:20 PM, Julius Kivimäki <
> julius.kivimaki@gmail.com> wrote:
>
>> OWASP is recognized worldwide, so is CEH and a bunch of other morons.
>> That doesn't mean their publications are worth anything. Now tell me, why
>> would arbitrary file upload on a CDN lead to code execution (Besides for
>> HTML, which you have been unable to confirm)?
>>
>>
>> 2014-03-13 18:16 GMT+02:00 Nicholas Lemonias. <lem.nikolas@googlemail.com
>> >:
>>
>> *You are wrong about accessing the files. What has not been confirmed is
>>> remote code execution. We are working on it.*
>>> *And please, OWASP is recognised worldwide... *
>>>
>>> *Files can be accessed through Google Take out with a little bit of
>>> skills.*
>>>
>>> *https://www.google.com/settings/takeout
>>> <https://www.google.com/settings/takeout> *
>>>
>>>
>>>
>>>
>>> On Thu, Mar 13, 2014 at 4:09 PM, Julius Kivimäki <
>>> julius.kivimaki@gmail.com> wrote:
>>>
>>>> Did you even read that article? (Not that OWASP has any sort of
>>>> credibility anyways). From what I saw in your previous post you are both
>>>> unable to execute the files or even access them and thus unable to
>>>> manipulate the content-type the files are returned with, therefore there is
>>>> no vulnerability (According to the article you linked.).
>>>>
>>>> BTW, you should look for more cool vulnerabilities in amazons EC2, I'm
>>>> sure you will find some "Unrestricted File Upload" holes.
>>>>
>>>>
>>>> 2014-03-13 16:18 GMT+02:00 Nicholas Lemonias. <
>>>> lem.nikolas@googlemail.com>:
>>>>
>>>> Here is your answer.
>>>>> https://www.owasp.org/index.php/Unrestricted_File_Upload
>>>>>
>>>>>
>>>>> On Thu, Mar 13, 2014 at 1:39 PM, Julius Kivimäki <
>>>>> julius.kivimaki@gmail.com> wrote:
>>>>>
>>>>>> When did the ability to upload files of arbitrary types become a
>>>>>> security issue? If the file doesn't get executed, it's really not a
>>>>>> problem. (Besides from potentially breaking site layout standpoint.)
>>>>>>
>>>>>>
>>>>>> 2014-03-13 12:43 GMT+02:00 Nicholas Lemonias. <
>>>>>> lem.nikolas@googlemail.com>:
>>>>>>
>>>>>>> Google vulnerabilities uncovered...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> http://news.softpedia.com/news/Expert-Finds-File-Upload-Vulnerability-in-YouTube-Google-Denies-It-s-a-Security-Issue-431489.shtml
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Full-Disclosure - We believe in it.
>>>>>>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>>>>>>> Hosted and sponsored by Secunia - http://secunia.com/
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Google vulnerabilities with PoC [ In reply to ]
I think Adam was right replying that way, so that it's not a security bug.
You haven't found anything exploitable.

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

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

Cheers
antisnatchor

Nicholas Lemonias. wrote:
> Google vulnerabilities uncovered...
>
>
> http://news.softpedia.com/news/Expert-Finds-File-Upload-Vulnerability-in-YouTube-Google-Denies-It-s-a-Security-Issue-431489.shtml
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/

--
Cheers
Michele

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: Google vulnerabilities with PoC [ In reply to ]
> The only reasonable way to 'exploit' the bug is using youtube as a
> "personal storage" uploading non-video files to your own profile: so what?

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

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

/mz

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: Google vulnerabilities with PoC [ In reply to ]
If you were evil, you could upload huge blobs and just take up space on the google servers. Who knows what will happen if you upload a couple hundred gigs of files. They dont disappear, they are just unretrievable afaict. It is a security risk in the sense that untrusted data is being persisted *somewhere*.

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

Sent from a computer

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

>> The only reasonable way to 'exploit' the bug is using youtube as a
>> "personal storage" uploading non-video files to your own profile: so what?
>
> That would require a way to retrieve the stored data, which - as I
> understand - isn't possible here (although the report seems a bit
> hard-to-parse). From what I recall, you can just upload a blob of data
> and essentially see it disappear.
>
> We do have quite a few services where you can legitimately upload and
> share nearly-arbitrary content, though. Google Drive is a good
> example.
>
> /mz
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: Google vulnerabilities with PoC [ In reply to ]
> If you were evil, you could upload huge blobs and just take up space on the google servers.

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

/mz

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: Google vulnerabilities with PoC [ In reply to ]
hahahaha

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


On Thu, Mar 13, 2014 at 2:33 PM, Brandon Perry <bperry.volatile@gmail.com>wrote:

> If you were evil, you could upload huge blobs and just take up space on
> the google servers. Who knows what will happen if you upload a couple
> hundred gigs of files. They dont disappear, they are just unretrievable
> afaict. It is a security risk in the sense that untrusted data is being
> persisted *somewhere*.
>
> Upload a couple terabytes, cause a DoS because some hdd in the DC fills
> up. Who knows.
>
> Sent from a computer
>
> On Mar 13, 2014, at 12:28 PM, Michal Zalewski <lcamtuf@coredump.cx> wrote:
>
> >> The only reasonable way to 'exploit' the bug is using youtube as a
> >> "personal storage" uploading non-video files to your own profile: so
> what?
> >
> > That would require a way to retrieve the stored data, which - as I
> > understand - isn't possible here (although the report seems a bit
> > hard-to-parse). From what I recall, you can just upload a blob of data
> > and essentially see it disappear.
> >
> > We do have quite a few services where you can legitimately upload and
> > share nearly-arbitrary content, though. Google Drive is a good
> > example.
> >
> > /mz
> >
> > _______________________________________________
> > Full-Disclosure - We believe in it.
> > Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> > Hosted and sponsored by Secunia - http://secunia.com/
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>



--
Grato,

J. Tozo
_
°v°
/(S)\ SLACKWARE
^ ^ Linux
_____________________
because it works
Re: Google vulnerabilities with PoC [ In reply to ]
: you could upload huge blobs and just take up space on the google servers.
How many people upload gigabytes of crappy videos on google servers,
hourly? So far, the DDoS didn't happen for some reason, even
considering the amount of users. There is a small potential to exploit
this via a botnet, but what's the gain? YT upload breaks? Wow, so much
win.

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


2014-03-13 18:33 GMT+01:00 Brandon Perry <bperry.volatile@gmail.com>:
> If you were evil, you could upload huge blobs and just take up space on the google servers. Who knows what will happen if you upload a couple hundred gigs of files. They dont disappear, they are just unretrievable afaict. It is a security risk in the sense that untrusted data is being persisted *somewhere*.
>
> Upload a couple terabytes, cause a DoS because some hdd in the DC fills up. Who knows.
>
> Sent from a computer
>
> On Mar 13, 2014, at 12:28 PM, Michal Zalewski <lcamtuf@coredump.cx> wrote:
>
>>> The only reasonable way to 'exploit' the bug is using youtube as a
>>> "personal storage" uploading non-video files to your own profile: so what?
>>
>> That would require a way to retrieve the stored data, which - as I
>> understand - isn't possible here (although the report seems a bit
>> hard-to-parse). From what I recall, you can just upload a blob of data
>> and essentially see it disappear.
>>
>> We do have quite a few services where you can legitimately upload and
>> share nearly-arbitrary content, though. Google Drive is a good
>> example.
>>
>> /mz
>>
>> _______________________________________________
>> Full-Disclosure - We believe in it.
>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>> Hosted and sponsored by Secunia - http://secunia.com/
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: Google vulnerabilities with PoC [ In reply to ]
Yes, these are legitimate points.

Sent from a computer

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

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: Google vulnerabilities with PoC [ In reply to ]
I don't see what OSI model has to do with anything here. Why is arbitrary
file upload to youtube CDN any worse than to google drive CDN? And how will
your "self-executing encrypted virus like Cryptolocker" end up getting
executed anyways? And cryptolocker was definitely not "self-executing", but
spread via email attachments (excluding the boring USB spread
functionality).

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

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

> Hello Julius,
>
> I appreciate your interest to learn more. OWASP is quite credible, and has
> gained some international recognition. It is a benchmark for many vendors.
> I suggest you to read on OSI/7-Layer Model. A website may disallow uploads
> of certain file types for security reasons, and let's assume at the
> application layer. If we manage to get past the security controls, that
> means we can write unrestrictedly any type of file to the remote network.
> That also means that we get past their firewall, since the communication is
> through HTTP (port 80). CDN nodes are deployed to multiple colocation
> (thousands of nodes and thousands of servers across the world). The files
> (let's say a self-executing encrypted virus like Cryptolocker? ) are cached
> deeply in the network across thousands of servers.
>
>
> On Thu, Mar 13, 2014 at 5:07 PM, Nicholas Lemonias. <
> lem.nikolas@googlemail.com> wrote:
>
>> Hello Julius,
>>
>> I appreciate your interest to learn more. OWASP is quite credible, and
>> has gained some international recognition. It is a benchmark for many
>> vendors. I suggest you to read on OSI/7-Layer Model. A website may disallow
>> uploads of certain file types for security reasons, and let's assume at the
>> application layer. If we manage to get past the security controls, that
>> means we can write unrestrictedly any type of file to the remote network.
>> That also means that we get past their firewall, since the communication is
>> through HTTP (port 80). CDN nodes are deployed to multiple colocation
>> (thousands of nodes and thousands of servers across the world). The files
>> are cached deep in the network structures to thousands of servers.
>>
>>
>> On Thu, Mar 13, 2014 at 4:20 PM, Julius Kivimäki <
>> julius.kivimaki@gmail.com> wrote:
>>
>>> OWASP is recognized worldwide, so is CEH and a bunch of other morons.
>>> That doesn't mean their publications are worth anything. Now tell me, why
>>> would arbitrary file upload on a CDN lead to code execution (Besides for
>>> HTML, which you have been unable to confirm)?
>>>
>>>
>>> 2014-03-13 18:16 GMT+02:00 Nicholas Lemonias. <
>>> lem.nikolas@googlemail.com>:
>>>
>>> *You are wrong about accessing the files. What has not been confirmed is
>>>> remote code execution. We are working on it.*
>>>> *And please, OWASP is recognised worldwide... *
>>>>
>>>> *Files can be accessed through Google Take out with a little bit of
>>>> skills.*
>>>>
>>>> *https://www.google.com/settings/takeout
>>>> <https://www.google.com/settings/takeout> *
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Mar 13, 2014 at 4:09 PM, Julius Kivimäki <
>>>> julius.kivimaki@gmail.com> wrote:
>>>>
>>>>> Did you even read that article? (Not that OWASP has any sort of
>>>>> credibility anyways). From what I saw in your previous post you are both
>>>>> unable to execute the files or even access them and thus unable to
>>>>> manipulate the content-type the files are returned with, therefore there is
>>>>> no vulnerability (According to the article you linked.).
>>>>>
>>>>> BTW, you should look for more cool vulnerabilities in amazons EC2, I'm
>>>>> sure you will find some "Unrestricted File Upload" holes.
>>>>>
>>>>>
>>>>> 2014-03-13 16:18 GMT+02:00 Nicholas Lemonias. <
>>>>> lem.nikolas@googlemail.com>:
>>>>>
>>>>> Here is your answer.
>>>>>> https://www.owasp.org/index.php/Unrestricted_File_Upload
>>>>>>
>>>>>>
>>>>>> On Thu, Mar 13, 2014 at 1:39 PM, Julius Kivimäki <
>>>>>> julius.kivimaki@gmail.com> wrote:
>>>>>>
>>>>>>> When did the ability to upload files of arbitrary types become a
>>>>>>> security issue? If the file doesn't get executed, it's really not a
>>>>>>> problem. (Besides from potentially breaking site layout standpoint.)
>>>>>>>
>>>>>>>
>>>>>>> 2014-03-13 12:43 GMT+02:00 Nicholas Lemonias. <
>>>>>>> lem.nikolas@googlemail.com>:
>>>>>>>
>>>>>>>> Google vulnerabilities uncovered...
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> http://news.softpedia.com/news/Expert-Finds-File-Upload-Vulnerability-in-YouTube-Google-Denies-It-s-a-Security-Issue-431489.shtml
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Full-Disclosure - We believe in it.
>>>>>>>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>>>>>>>> Hosted and sponsored by Secunia - http://secunia.com/
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Google vulnerabilities with PoC [ In reply to ]
So in terms of permissions. What's the different between
admin.youtube.comand a normal youtube user?

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

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



On Thu, Mar 13, 2014 at 5:28 PM, Michal Zalewski <lcamtuf@coredump.cx>wrote:

> > The only reasonable way to 'exploit' the bug is using youtube as a
> > "personal storage" uploading non-video files to your own profile: so
> what?
>
> That would require a way to retrieve the stored data, which - as I
> understand - isn't possible here (although the report seems a bit
> hard-to-parse). From what I recall, you can just upload a blob of data
> and essentially see it disappear.
>
> We do have quite a few services where you can legitimately upload and
> share nearly-arbitrary content, though. Google Drive is a good
> example.
>
> /mz
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
Re: Google vulnerabilities with PoC [ In reply to ]
Hello Zalewski,

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

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

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



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

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



On Thu, Mar 13, 2014 at 5:28 PM, Michal Zalewski <lcamtuf@coredump.cx>wrote:

> > The only reasonable way to 'exploit' the bug is using youtube as a
> > "personal storage" uploading non-video files to your own profile: so
> what?
>
> That would require a way to retrieve the stored data, which - as I
> understand - isn't possible here (although the report seems a bit
> hard-to-parse). From what I recall, you can just upload a blob of data
> and essentially see it disappear.
>
> We do have quite a few services where you can legitimately upload and
> share nearly-arbitrary content, though. Google Drive is a good
> example.
>
> /mz
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
Re: Google vulnerabilities with PoC [ In reply to ]
The YouTube service is there to serve harmless media files. The upload
functionality is there to upload files legitimately. But what type of
files, and who can write those files?

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

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



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

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


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

> Hello Zalewski,
>
> The YouTube service is there to serve harmless media files. The upload
> functionality is there to upload files legitimately. But what type of
> files, and who can write those files?
>
> What's the difference between a Youtube admin and a Youtube user in terms
> of permissions sets ?
>
> Why does Youtube accepts only a certain type of media-files? Isn't it
> because that's the scope of its function .... ?
>
>
>
> A good point made, however based on recognised practise and core
> principles of Information Security and not just 'experience' or personal
> belief, once the information security flow of a design is tampered - that
> constitutes to a security issue.
>
> Second point - a security vulnerability is present when the
> confidentiality, integrity and availability of data is affected. In this
> case the integrity of the service is impacted.
>
>
>
> On Thu, Mar 13, 2014 at 5:28 PM, Michal Zalewski <lcamtuf@coredump.cx>wrote:
>
>> > The only reasonable way to 'exploit' the bug is using youtube as a
>> > "personal storage" uploading non-video files to your own profile: so
>> what?
>>
>> That would require a way to retrieve the stored data, which - as I
>> understand - isn't possible here (although the report seems a bit
>> hard-to-parse). From what I recall, you can just upload a blob of data
>> and essentially see it disappear.
>>
>> We do have quite a few services where you can legitimately upload and
>> share nearly-arbitrary content, though. Google Drive is a good
>> example.
>>
>> /mz
>>
>> _______________________________________________
>> Full-Disclosure - We believe in it.
>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>> Hosted and sponsored by Secunia - http://secunia.com/
>>
>
>
Re: Google vulnerabilities with PoC [ In reply to ]
We confirm this to be a valid vulnerability for the following reasons.

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

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

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

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

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

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


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


Best Regards,
Nicholas Lemonias
Advanced Information Security Corp.
Re: Google vulnerabilities with PoC [ In reply to ]
On Mar 13, 2014, at 10:33, Brandon Perry <bperry.volatile@gmail.com> wrote:
> If you were evil, you could upload huge blobs and just take up space on the google servers. Who knows what will happen if you upload a couple hundred gigs of files. They dont disappear, they are just unretrievable afaict. It is a security risk in the sense that untrusted data is being persisted *somewhere*.

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

The comments on the Softpedia article are painfully stupid, by the way. I recommend not reading them. :)
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: Google vulnerabilities with PoC [ In reply to ]
On 2014-03-14 10:56, andfarm wrote:
> On Mar 13, 2014, at 10:33, Brandon Perry <bperry.volatile@gmail.com>
> wrote:
>> If you were evil, you could upload huge blobs and just take up space
>> on the google servers. Who knows what will happen if you upload a
>> couple hundred gigs of files. They dont disappear, they are just
>> unretrievable afaict. It is a security risk in the sense that
>> untrusted data is being persisted *somewhere*.
>
> It's not even clear at this point that the uploaded data is even being
> persisted! Since the uploaded file is not made available for download,
> it's entirely possible that it is being deleted as soon as Google's
> video transcoding systems discover it isn't a supported video format.

In the email reply from google they confirmed that it was stored, but
you can't get it out so kind of a moot point :D

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

_______________________________________________
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: Google vulnerabilities with PoC [ In reply to ]
Look, you keep calling it a "vulnerability" with 0 evidence that it's even
exploitable. Until you can prove otherwise this is like speculating the
potential security repercussions of uploading files to EC2 (Which would
probably have potential to be much more severe than what you're discussing
here since javascript uploaded to ec2 could actually get executed by
someones browser)

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


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

> Julius Kivimaki, your disbelief in OWASP, CEH, Journalists and anything
> you may, or may not be qualified to question amazes. But everyone's opinion
> is of course respected.
>
> I normally don't provide security lessons via e-mail and full-disclosure,
> however you seem not to understand the security report fully and some core
> principles. If you can't see what information security best practises, the
> OSI/network model and self-automata propagation has anything to do with
> arbitrary write permissions to a remote network leveraging from the
> application layer, then me and you have nothing to talk about.
>
> As for the exploitability of this vulnerability, you will never know until
> you try. And we have tried it , and seem to know better.
>
> I suggest you read the report again.
>
> Thank you.
>
>
> ---------- Forwarded message ----------
> From: Nicholas Lemonias. <lem.nikolas@googlemail.com>
> Date: Thu, Mar 13, 2014 at 7:47 PM
> Subject: Re: [Full-disclosure] Google vulnerabilities with PoC
> To: Julius Kivimäki <julius.kivimaki@gmail.com>
>
>
> Julius Kivimaki, your disbelief in OWASP, CEH, Journalists and anything
> you may, or may not be qualified to question amazes. But everyone's opinion
> is of course respected.
>
> I normally don't provide security lessons via e-mail and full-disclosure,
> however you seem not to understand the security report fully and some core
> principles. If you can't see what information security best practises, the
> OSI/network model and self-automata propagation has anything to do with
> arbitrary write permissions to a remote network leveraging from the
> application layer, then me and you have nothing to talk about.
>
> As for the exploitability of this vulnerability, you will never know until
> you try. And we have tried it , and seem to know better.
>
> I suggest you read the report again.
>
> Thank you.
>
>
>
> On Thu, Mar 13, 2014 at 7:02 PM, Julius Kivimäki <
> julius.kivimaki@gmail.com> wrote:
>
>> I don't see what OSI model has to do with anything here. Why is arbitrary
>> file upload to youtube CDN any worse than to google drive CDN? And how will
>> your "self-executing encrypted virus like Cryptolocker" end up getting
>> executed anyways? And cryptolocker was definitely not "self-executing", but
>> spread via email attachments (excluding the boring USB spread
>> functionality).
>>
>> What you have here is not a vulnerability, just give up. And stop trying
>> to get "journalists" like Eduard Kovacs to spread your BS.
>>
>> 2014-03-13 19:10 GMT+02:00 Nicholas Lemonias. <lem.nikolas@googlemail.com
>> >:
>>
>> Hello Julius,
>>>
>>> I appreciate your interest to learn more. OWASP is quite credible, and
>>> has gained some international recognition. It is a benchmark for many
>>> vendors. I suggest you to read on OSI/7-Layer Model. A website may disallow
>>> uploads of certain file types for security reasons, and let's assume at the
>>> application layer. If we manage to get past the security controls, that
>>> means we can write unrestrictedly any type of file to the remote network.
>>> That also means that we get past their firewall, since the communication is
>>> through HTTP (port 80). CDN nodes are deployed to multiple colocation
>>> (thousands of nodes and thousands of servers across the world). The files
>>> (let's say a self-executing encrypted virus like Cryptolocker? ) are cached
>>> deeply in the network across thousands of servers.
>>>
>>>
>>> On Thu, Mar 13, 2014 at 5:07 PM, Nicholas Lemonias. <
>>> lem.nikolas@googlemail.com> wrote:
>>>
>>>> Hello Julius,
>>>>
>>>> I appreciate your interest to learn more. OWASP is quite credible, and
>>>> has gained some international recognition. It is a benchmark for many
>>>> vendors. I suggest you to read on OSI/7-Layer Model. A website may disallow
>>>> uploads of certain file types for security reasons, and let's assume at the
>>>> application layer. If we manage to get past the security controls, that
>>>> means we can write unrestrictedly any type of file to the remote network.
>>>> That also means that we get past their firewall, since the communication is
>>>> through HTTP (port 80). CDN nodes are deployed to multiple colocation
>>>> (thousands of nodes and thousands of servers across the world). The files
>>>> are cached deep in the network structures to thousands of servers.
>>>>
>>>>
>>>> On Thu, Mar 13, 2014 at 4:20 PM, Julius Kivimäki <
>>>> julius.kivimaki@gmail.com> wrote:
>>>>
>>>>> OWASP is recognized worldwide, so is CEH and a bunch of other morons.
>>>>> That doesn't mean their publications are worth anything. Now tell me, why
>>>>> would arbitrary file upload on a CDN lead to code execution (Besides for
>>>>> HTML, which you have been unable to confirm)?
>>>>>
>>>>>
>>>>> 2014-03-13 18:16 GMT+02:00 Nicholas Lemonias. <
>>>>> lem.nikolas@googlemail.com>:
>>>>>
>>>>> *You are wrong about accessing the files. What has not been confirmed
>>>>>> is remote code execution. We are working on it.*
>>>>>> *And please, OWASP is recognised worldwide... *
>>>>>>
>>>>>> *Files can be accessed through Google Take out with a little bit of
>>>>>> skills.*
>>>>>>
>>>>>> *https://www.google.com/settings/takeout
>>>>>> <https://www.google.com/settings/takeout> *
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Mar 13, 2014 at 4:09 PM, Julius Kivimäki <
>>>>>> julius.kivimaki@gmail.com> wrote:
>>>>>>
>>>>>>> Did you even read that article? (Not that OWASP has any sort of
>>>>>>> credibility anyways). From what I saw in your previous post you are both
>>>>>>> unable to execute the files or even access them and thus unable to
>>>>>>> manipulate the content-type the files are returned with, therefore there is
>>>>>>> no vulnerability (According to the article you linked.).
>>>>>>>
>>>>>>> BTW, you should look for more cool vulnerabilities in amazons EC2,
>>>>>>> I'm sure you will find some "Unrestricted File Upload" holes.
>>>>>>>
>>>>>>>
>>>>>>> 2014-03-13 16:18 GMT+02:00 Nicholas Lemonias. <
>>>>>>> lem.nikolas@googlemail.com>:
>>>>>>>
>>>>>>> Here is your answer.
>>>>>>>> https://www.owasp.org/index.php/Unrestricted_File_Upload
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Mar 13, 2014 at 1:39 PM, Julius Kivimäki <
>>>>>>>> julius.kivimaki@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> When did the ability to upload files of arbitrary types become a
>>>>>>>>> security issue? If the file doesn't get executed, it's really not a
>>>>>>>>> problem. (Besides from potentially breaking site layout standpoint.)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2014-03-13 12:43 GMT+02:00 Nicholas Lemonias. <
>>>>>>>>> lem.nikolas@googlemail.com>:
>>>>>>>>>
>>>>>>>>>> Google vulnerabilities uncovered...
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> http://news.softpedia.com/news/Expert-Finds-File-Upload-Vulnerability-in-YouTube-Google-Denies-It-s-a-Security-Issue-431489.shtml
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Full-Disclosure - We believe in it.
>>>>>>>>>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>>>>>>>>>> Hosted and sponsored by Secunia - http://secunia.com/
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
>

1 2 3  View All