[Full-disclosure] CVE-2014-1214 - Remote Code Execution in Projoom NovaSFH Plugin
Vulnerability title: Remote Code Execution in Projoom NovaSFH Plugin CVE: CVE-2014-1214 Vendor: Projoom Product: NovaSFH Plugin Version: 3.0.3 Reported by: Yuri Kramarz Details: The PHP executable which is responsible for handling file upload functionality allows arbitrary files to be uploaded to any directory specified by the attackers as the file upload function does not does not verify file type or origin when processing the request. Further details at: http://www.portcullis-security.com/security-research-and-downloads/secur ity-advisories/cve-2014-1214/ Copyright: Copyright (c) Portcullis Computer Security Limited 2014, All rights reserved worldwide. Permission is hereby granted for the electronic redistribution of this information. It is not to be edited or altered in any way without the express written consent of Portcullis Computer Security Limited. Disclaimer: The information herein contained may change without notice. Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties, implied or otherwise, with regard to this information or its use. Any use of this information is at the user's risk. In no event shall the author/distributor (Portcullis Computer Security Limited) be held liable for any damages whatsoever arising out of or in connection with the use or spread of this information. ### This email originates from the systems of Portcullis Computer Security Limited, a Private limited company, registered in England in accordance with the Companies Act under number 02763799. The registered office address of Portcullis Computer Security Limited is: The Grange Barn, Pikes End, Pinner, MIDDX, United Kingdom, HA5 2EX. The information in this email is confidential and may be legally privileged. It is intended solely for the addressee. Any opinions expressed are those of the individual and do not represent the opinion of the organisation. Access to this email by persons other than the intended recipient is strictly prohibited. If you are not the intended recipient, any disclosure, copying, distribution or other action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. When addressed to our clients any opinions or advice contained in this email is subject to the terms and conditions expressed in the applicable Portcullis Computer Security Limited terms of business. ### # This e-mail message has been scanned for Viruses and Content and cleared by MailMarshal. # ___ 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] [CVE-2014-1860] PHP object insertion / possible RCE in Contao CMS = 3.2.4
Hello again,
today a little bird known as i0n1c twitted something about me [1],
claiming that I was wrong, and that CVE-2014-1860 could actually be
exploited, because there is S: which allows encoded NUL bytes [2], and
that's true in part. So, instead of using a string like this:
O:9:ZipWriter:1:{s:10:\0*\0strTemp;s:11:/etc/passwd;}
An attacker might be able to bypass the filter implemented within the
Input::xssClean() method because she can also use a string like this:
O:9:ZipWriter:1:{S:10:\00*\00strTemp;s:11:/etc/passwd;}
The Input::xssClean() method removes not only NULL bytes, but also the
string \0, meaning that the above string will be converted to:
O:9:ZipWriter:1:{S:10:0*0strTemp;s:11:/etc/passwd;}
Of course this could easily be bypassed using a string like this:
O:9:ZipWriter:1:{S:10:\\000*\\000strTemp;s:11:/etc/passwd;}
However, in such case there's another filter which doesn't allow to
inject *protected* or *private* objects' properties, and that is
implemented within the Input::encodeSpecialChars() method [3], which
converts backslashes into #92;, meaning that the above string will be
converted to:
O:9:ZipWriter:1:{S:10:#92;00*#92;00strTemp;s:11:/etc/passwd;}
Therefore, unless somebody (like Pedro Ribeiro or Mr. Stefan Esser)
provides a working Proof of Concept, I will continue to believe that
CVE-2014-1860 should be rejected as non-vulnerability.
References:
[1] https://twitter.com/i0n1c/status/431367715941400576
[2] https://twitter.com/i0n1c/status/431368722624704512
[3] http://git.io/DFkxDQ
Kind Regards,
Egidio Romano
On Wed, Feb 05, 2014 at 11:13:29PM +0100, Egidio Romano wrote:
Hello,
I believe this CVE should be rejected, because the vulnerabilities
actually don't exist, at least the ones mentioned in this report.
The reason is that user input is passed to the unserialize() function
through the Contao Input class, in which the Input::xssClean() method
removes all the NULL bytes from user input, meaning that an attacker can
be able to manipulate only the *public* properties of the injected
objects, because *protected* and *private* properties of a serialized
object are encoded with NULL bytes.
I haven't found any exploitable magic method in Contao which uses only
*public* properties, and the ones mentioned in the original report are
exploitable only through *protected* properties.
Therefore, unless someone provides a working Proof of Concept, I think
these shouldn't be considered actual security vulnerabilities.
Best Ragards,
Egidio Romano
Hi,
I have discovered a vulnerability that might lead to code execution in
Contao CMS = 3.2.4
Contao CMS = 3.2.4 does not properly validate user input in several
locations which is then passed directly into PHP's unserialize.
This has been fixed in Contao 3.2.5 as per commit:
https://github.com/contao/core/commit/8c9cb044bdc887a8202bb65a64545c025664f957
and
https://github.com/contao/core/commit/1717336598fdcf1ed3f4ad488e140147cb31516d
Announcements can be found at
https://contao.org/en/news/contao-3_2_5.html
https://contao.org/en/news/contao-2_11_14.html
Thanks to the Contao developers for being so responsive.
The full report can be found at my repo in
https://github.com/pedrib/PoC/blob/master/contao-3.2.4.txt
Regards,
Pedro Ribeiro
Agile Information Security
___
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] Information on recently-fixed Oracle VM VirtualBox vulnerabilities
Hi there, Recently I found a few vulnerabilities in Oracle VM VirtualBox, the open-source virtualization product. These have already been reported to the project, fixed and disclosed in the form of the recent January 2014 Oracle Critical Patch Update (at http://www.oracle.com/technetwork/topics/security/cpujan2014-1972949.html). The purpose of this mail is simply to provide a few more specifics about each vulnerability to allow distributors, packagers and other users of the software to better classify them (and, of course, for the sake of freely sharing information!) (Most of the rest of this message is a hacked-up version of the initial private disclosure to Oracle; please excuse any messed-up tenses or similar. Also, I've tried to clarify any VBox-specific terminology but it still might be lacking in places.) These vulnerabilities were tested on both 32-bit and 64-bit versions of VirtualBox, namely: 32-bit: 4.2.16_Debianr86992 ((what was) the current Debian jessie VirtualBox package) 64-bit: 4.2.51_OSEr47061 (compiled from SVN) The SVN trunk at the time was also inspected to ensure fixes hadn't been made since these versions. The exploitability of some of the vulnerabilities depends on the architectural width of the host; where this is the case it is explicitly mentioned. When an exploitation attempt is performed on a host not of the correct width the attempt usually leads to DOS instead. The first two vulnerabilities are in the VMMDev device's HGCM interface, the third is in the Windows Guest Additions' Shared Folder driver and the final two are in the handling of other VMMDev request types. * Vuln. #1: VMMDev HGCM argument size overflow (CVE-2013-5892) The first step in processing a HGCM (Host-Guest Communication Manager) call VMMDev request is to calculate the total size of the call's arguments. This is so the correct amount of space can be allocated for the arguments whose types (linear in/out addresses and page lists) need buffer space for transferring between guest and host memory. This calculation is performed using the cbCmdSize variable. The problem lies in the fact that this calculation can easily overflow and hence the check afterward to see whether the amount of space required is too large or not will mistakenly pass. This leads to a smaller-than-actually-required amount of memory being allocated for the host-side VBOXHGCMCMD structure. This structure holds host-side HGCM call information including information on each argument (type, pointer to host buffer space, size) and the buffers themselves. This is obviously an exploitable heap overflow, but we can do better. The aforementioned host-side buffer pointers which are then assigned to the arguments which need them can, via careful argument size choice, be lead to point to arbitrary host memory instead of within the third part of the VBOXHGCMCMD structure where they are supposed to point. Notably, one can craft the individual argument sizes so that the buffer pointer placement routine wraps around the address space and sets the buffers to point to the head of the VBOXHGCMCMD structure, allowing one to cleanly write to the other parts of the structure, including the other argument types and host-side buffer pointers. Using this, one can write to one of these host-side buffer pointers so that the resulting HGCM call output for that argument is sent elsewhere in the address space - a write-(almost-)what-where vulnerability of arbitrary length which is not affected by the heap/ASLR moving the HGCM structure around in memory (since the method of exploitation uses distances relative to the head of the HGCM structure itself). This can be exploited to allow host ring 3 code execution from guest ring 0 (assuming a guest IOPL of 0). A POC exploit in the form of a Linux kernel module which takes addr and val arguments to specify where and what to write into host ring 3 memory was created (and sent in the full report): mattd@debian:~$ /sbin/modinfo vmmdev_vuln_oflow.ko filename: /home/mattd/vmmdev_vuln_oflow.ko license:Dual BSD/GPL depends: vermagic: 3.2.0-4-486 mod_unload modversions 486 parm: addr:Host-ring3 address to write to (ulong) parm: val:Value to write (UTF-8 hex) (string) Here is an example exploitation session: - Start a VM $ VBoxManage startvm foo4 --type headless Waiting for VM foo4 to power on... VM foo4 has been successfully started. - Demonstrate that there is nothing written at this arbitrarily-chosen location in the host-side VBox process memory $ sudo dd if=/proc/`pidof VBoxHeadless`/mem bs=1 skip=$((0x804eff0)) count=16 2 /dev/null | hd 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || 0010 - Run the exploit in the guest VM, specifying what to write and where $ ssh -p root@foo4 'insmod vmmdev_vuln_oflow.ko addr=0x804eff0 val=`echo -n Hi from guest! | hexdump -e /1 \%x\`' - Demonstrate that the string was successfully written
[Full-disclosure] Visa (Europe) XSS Vulnerability
Visa (Europe) Website Vulnerability == Published Report: 07/02/2014 Credits: Advanced Information Security Corporation, USA Severity: High/Critical (OWASP TOP 10) Type: Web Application / Cross-Site Scripting Attack. Author: Nicholas Lemonias. (Information Security Expert) Vendor Overview === Visa Europe Ltd is a membership association and cooperative of over 3,700 European banks and other payment service providers that operate Visa branded products and services within Europe. Visa Europe provides electronic payment services for cardholders, businesses, and retailers. The company offers debit, credit, virtual and prepaid credit-cards. The business has developed to provide consulting and analytics services for merchant agents and service providers. The business also offers payment security knowledge to business and government. The company is headquartered in London with satellite offices in Austria, Belgium, Bulgaria, Czech Republic, Finland, France, Germany, Greece, Hungary, Ireland, Israel, Italy, the Netherlands, Norway, Poland, Portugal, Romania, Spain, Sweden, Switzerland and Turkey. Coordinated Vulnerability Disclosure Timeline 25th of November, 2013 - Contacted Vendor regarding the security realisation. 26th of November, 2013 - Vendor acknowledgement of the problem. 2nd of December, 2013 -Problem verification. 3rd of December, 2013 - Problem mitigation. Proof of Concept / Affected Services = http://www.visaeurope.com/en/viewpoints.aspx?author=3%22%20onmouseover%3dprompt%28990207%29%20abc%3d%22category=32date= Affected directory: /en/viewpoints Injected Code to path fragment: /en/viewpoints.aspx?author=3%22%20onmouseover%3dprompt%28990207%29%20abc%3d%22category=32date= 1. Escaping previous fragment function: 2. Injection: onmouseover=onmouseover%3dprompt%2831337%29%20abc%3d%22category=32date= Description: On mouse over the affected link, and the injected code will be executed. In this Proof-of-concept a prompt will alter the user's normal execution flow. Proof-Of-Concept 2 http://www.visaeurope.com/en/viewpoints.aspx?author=3%22%20onmouseover%3dalert%28990207%29%20abc%3d%22category=32date= Proof-Of-Concept 3 http://www.visaeurope.com/en/viewpoints.aspx?author=3%22%20onmouseover%3dalert%28document.cookie%29%20bxc%3d%22category=32date= * This realisation was reported to the relevant security teams which acted immediately to remediate the issues. Recommendations provided for Quality of Service == A. The recommendations that have been made to Visa Europe Inc. is to consider encrypting the view state of the application. Furthermore to implement a stronger Cross-Site Scripting protection. Apparently XSS filtering is not properly applied, and metacharacter filtering allows data input over the HTTP protocol to inject third-party untrusted code, in Java-Script, Active-X and Visual Basic Script. Please note that malicious users could take advantage of such a bug, as we have seen in malware and virus propagation instances. B. Our consultation to Visa Europe was therefore, for an immediate risk assessment and thus immediate review of upper-level security policies in accordance to ISO 27001 and ISO 27002 which was followed kindly by the team. Full review of ISMS policy scope and the SDLC of the vulnerable application and other subsidiary pages. Appendices A. Suggested the filtering of metacharacters. B. Suggested the utilisation User-server encoding of and to lt; and gt; in application output. C. An XSS attack could embrace mass user and product attacks, phishing theft of private and confidential information such as credit cards, passwords, and stored accounts. D. Suggested Filtering and and using appropriate encoding. ( and ) filtered and encoded to #40; and #41;, Example: # and converted to #35 (#) and #38 (). References OWASP. 2013. Cross Site Scripting (XSS) attacks, [ONLINE] https://www.owasp.org/index.php/Cross-site_Scripting_(XSS), 2011 OWASP. 2013. XSS Filter Evasion Cheat-Sheet, [ONLINE] https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet?, 2013. Microsoft. 2011. Protecting against XSS attacks. [ONLINE] Available at: http://msdn.microsoft.com/en-us/library/ff649310.aspx. ** This vulnerability report is posted for the wider benefit of the security community, as is and without any warranties, including the warranty of merchantability and capability fit for a particular purpose. The information is posted under the FOI as per best security practises. *Copyright Advanced Information Security Corp ©, 2014* ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia -
Re: [Full-disclosure] [CVE-2014-1860] PHP object insertion / possible RCE in Contao CMS = 3.2.4
I haven't read the whole thread, so I apologize in advance for commenting
on it. But I think it's important to mention that not a vulnerability and
not exploitable are entirely different concepts. Since conclusively
proving that a vulnerability is 100% not exploitable for all code paths in
all possible environments is difficult at best (if not downright
impossible), you can still consider something a vulnerability even if you
don't have a proof of concept - you can assign it lower risk, of course,
but it doesn't disappear, because there's at least a theoretical
possibility that it may be exploited.
So, let's not get into a flame war yet. :)
On Fri, Feb 7, 2014 at 12:15 AM, Egidio Romano resea...@karmainsecurity.com
wrote:
Hello again,
today a little bird known as i0n1c twitted something about me [1],
claiming that I was wrong, and that CVE-2014-1860 could actually be
exploited, because there is S: which allows encoded NUL bytes [2], and
that's true in part. So, instead of using a string like this:
O:9:ZipWriter:1:{s:10:\0*\0strTemp;s:11:/etc/passwd;}
An attacker might be able to bypass the filter implemented within the
Input::xssClean() method because she can also use a string like this:
O:9:ZipWriter:1:{S:10:\00*\00strTemp;s:11:/etc/passwd;}
The Input::xssClean() method removes not only NULL bytes, but also the
string \0, meaning that the above string will be converted to:
O:9:ZipWriter:1:{S:10:0*0strTemp;s:11:/etc/passwd;}
Of course this could easily be bypassed using a string like this:
O:9:ZipWriter:1:{S:10:\\000*\\000strTemp;s:11:/etc/passwd;}
However, in such case there's another filter which doesn't allow to
inject *protected* or *private* objects' properties, and that is
implemented within the Input::encodeSpecialChars() method [3], which
converts backslashes into #92;, meaning that the above string will be
converted to:
O:9:ZipWriter:1:{S:10:#92;00*#92;00strTemp;s:11:/etc/passwd;}
Therefore, unless somebody (like Pedro Ribeiro or Mr. Stefan Esser)
provides a working Proof of Concept, I will continue to believe that
CVE-2014-1860 should be rejected as non-vulnerability.
References:
[1] https://twitter.com/i0n1c/status/431367715941400576
[2] https://twitter.com/i0n1c/status/431368722624704512
[3] http://git.io/DFkxDQ
Kind Regards,
Egidio Romano
On Wed, Feb 05, 2014 at 11:13:29PM +0100, Egidio Romano wrote:
Hello,
I believe this CVE should be rejected, because the vulnerabilities
actually don't exist, at least the ones mentioned in this report.
The reason is that user input is passed to the unserialize() function
through the Contao Input class, in which the Input::xssClean() method
removes all the NULL bytes from user input, meaning that an attacker can
be able to manipulate only the *public* properties of the injected
objects, because *protected* and *private* properties of a serialized
object are encoded with NULL bytes.
I haven't found any exploitable magic method in Contao which uses only
*public* properties, and the ones mentioned in the original report are
exploitable only through *protected* properties.
Therefore, unless someone provides a working Proof of Concept, I think
these shouldn't be considered actual security vulnerabilities.
Best Ragards,
Egidio Romano
Hi,
I have discovered a vulnerability that might lead to code execution in
Contao CMS = 3.2.4
Contao CMS = 3.2.4 does not properly validate user input in several
locations which is then passed directly into PHP's unserialize.
This has been fixed in Contao 3.2.5 as per commit:
https://github.com/contao/core/commit/8c9cb044bdc887a8202bb65a64545c025664f957
and
https://github.com/contao/core/commit/1717336598fdcf1ed3f4ad488e140147cb31516d
Announcements can be found at
https://contao.org/en/news/contao-3_2_5.html
https://contao.org/en/news/contao-2_11_14.html
Thanks to the Contao developers for being so responsive.
The full report can be found at my repo in
https://github.com/pedrib/PoC/blob/master/contao-3.2.4.txt
Regards,
Pedro Ribeiro
Agile Information Security
___
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] gpEasy v4.3.x CMS - Multiple Web Vulnerabilities
Document Title: === gpEasy v4.3.x CMS - Multiple Web Vulnerabilities References (Source): http://www.vulnerability-lab.com/get_content.php?id=1189 Release Date: = 2014-02-06 Vulnerability Laboratory ID (VL-ID): 1189 Common Vulnerability Scoring System: 6.1 Product Service Introduction: === gpEasy 4.3 is a complete content management system that lets users create rich and flexible Web sites with a simple and easy-to-use interface. The embedded design of the admin interface allows users to instantly see changes in a single browser window. gpEasy has many qualities, but if we had to pick three adjectives to describe our CMS, it would have to be fast, easy and free. These three small words represent big ideas for us and embody the principles that drive gpEasy development. (Copy of the Vendor Homepage: http://www.gpeasy.com/Fast_Easy_and_Free ) Abstract Advisory Information: == The Vulnerability Laboratory Research Team discovered multiple web vulnerabilities in the official gpEasy v4.3 content management system. Vulnerability Disclosure Timeline: == 2013-02-06:Public Disclosure (Vulnerability Laboratory) Discovery Status: = Published Affected Product(s): gpEasy Product: gpEasy Content Management System (Web Application) 4.3 Exploitation Technique: === Remote Severity Level: === High Technical Details Description: 1.1 A file include and arbitrary file upload web vulnerability has been discovered in the official gpEasy v4.3 content management system. The local file include web vulnerability allows remote attackers to unauthorized include local file/path requests or system specific path commands to compromise the web-application. The arbitrary file upload issue allows remote attackers to upload files with multiple extensions to bypass the web-server or system validation. The vulnerability is located in the `file- and folder` name values of the `upload files` module. Attackers can tamper the POST method request to upload own malicious script codes or web shells. The validation does also not support filter mechanism for multiple file extension which can result in a prepared combined attack to include a file and upload/execute arbitrary codes. The security risk of the local and remote vulnerability is estimated as high with a cvss (common vulnerability scoring system) count of 6.1(-). Exploitation of the local file include and arbitrary file upload web vulnerability requires no user interaction but a privileged web-application user account. Successful exploitation of the local web vulnerability results in application or dbms compromise by combined lfi/afu web attacks. Request Method(s): [+] POST Vulnerable Module(s): [+] Home Administration Uploaded Files Vulnerable Parameter(s): [+] file- and folder name Vulnerable Module(s): [+] Upload File Manager 1.2 Multiple client-side cross site scripting web vulnerabilities has been discovered in the official gpEasy v4.3 content management system. A non-persistent cross site vulnerability allows remote attackers to manipulate client-side browser requests through the affected web-application. The vulnerability is located in the `mount network volume` function of the `content upload files` module. The vulnerable input field values are `host`,`port`,`path`,`user` and `pass`. Remote attackers can manipulate the GET method request of the `mount network volume` function to provoke a wrong encoded exception which executes the injected script code. The code executes in the invalid error message exception of the mount network volume function. The security risk of the remote xss web vulnerability is estimated as medium with a cvss (common vulnerability scoring system) count of 2.9(+). Request Method(s): [+] GET Vulnerable Module(s): [+] Home Administration Uploaded Files Mount Network Volume Vulnerable Parameter(s): [+] host [+] port [+] path [+] user [+] pass Affected Module(s): [+] Error invalid Content Exception Proof of Concept (PoC): === 1.1 The file include and arbitrary file upload web vulnerability can be exploited by local attacker with privileged user account and without user interaction. For security demonstration or to reproduce the vulnerability follow the provided steps and information
[Full-disclosure] Facebook Bug Bounty #12 - Client Side Exception Web Vulnerability
Document Title: === Facebook Bug Bounty #12 - Client Side Exception Web Vulnerability References (Source): http://www.vulnerability-lab.com/get_content.php?id=1190 Facebook Security ID: 186072579 Release Date: = 2014-02-07 Vulnerability Laboratory ID (VL-ID): 1190 Common Vulnerability Scoring System: 3 Product Service Introduction: === Facebook is an online social networking service, whose name stems from the colloquial name for the book given to students at the start of the academic year by some university administrations in the United States to help students get to know each other. It was founded in February 2004 by Mark Zuckerberg with his college roommates and fellow Harvard University students Eduardo Saverin, Andrew McCollum, Dustin Moskovitz and Chris Hughes. The website`s membership was initially limited by the founders to Harvard students, but was expanded to other colleges in the Boston area, the Ivy League, and Stanford University. It gradually added support for students at various other universities before opening to high school students, and eventually to anyone aged 13 and over. Facebook now allows any users who declare themselves to be at least 13 years old to become registered users of the site. Users must register before using the site, after which they may create a personal profile, add other users as friends, and exchange messages, including automatic notifications when they update their profile. Additionally, users may join common-interest user groups, organized by workplace, school or college, or other characteristics, and categorize their friends into lists such as `People From Work` or `Close Friends`. As of September 2012, Facebook has over one billion active users, of which 8.7% are fake. According to a May 2011 Consumer Reports survey, there are 7.5 million children under 13 with accounts and 5 million under 10, violating the site`s terms of service. In May 2005, Accel partners invested $12.7 million in Facebook, and Jim Breyer added $1 million of his own money to the pot. A January 2009 Compete.com study ranked Facebook as the most used social networking service by worldwide monthly active users. Entertainment Weekly included the site on its end-of-the-decade `best-of` list, saying, `How on earth did we stalk our exes, remember our co-workers` birthdays, bug our friends, and play a rousing game of Scrabulous before Facebook?` Facebook eventually filed for an initial public offering on February 1, 2012, and was headquartered in Menlo Park, California. Facebook Inc. began selling stock to the public and trading on the NASDAQ on May 18, 2012. Based on its 2012 income of USD 5.1 Billion, Facebook joined the Fortune 500 list for the first time, being placed at position of 462 on the list published in 2013. (Copy of the Homepage: http://en.wikipedia.org/wiki/Facebook ) Abstract Advisory Information: == The Vulnerability Laboratory Research Team discovered a client-side web vulnerability in the official Facebook Stories web-application api. Vulnerability Disclosure Timeline: == 2014-01-06: Researcher Notification Coordination (Benjamin Kunz Mejri - Vulnerability Lab) 2014-01-07: Vendor Notification (Facebook Security Team - WhiteHat Program) 2014-01-09: Vendor Response/Feedback (Facebook Security Team - WhiteHat Program) 2014-01-31: Vendor Fix/Patch (Facebook Developer Team) 2014-02-06: Public Disclosure (Vulnerability Laboratory) Discovery Status: = Published Affected Product(s): Facebook Product: FB Stories - Web Application (API) 2014 Q1 Exploitation Technique: === Remote Severity Level: === Medium Technical Details Description: A non-persistent input validation filter vulnerability has been discovered in the official FacebookStories Online-Service web-application. The vulnerability allows remote attackers to inject own script code via POST method request on the client-side of the affected application. The vulnerability is located in the filename value of the photos module. The execute occurs in the exception-handling output of the upload image post method request. Remote attacker are able to provoke the application exception-handling to execute client-side script-code in the error message context itself. The encoding of the error message after an unsuccessful upload has is not the same way encoded like the other input fields of the formular. In our example pictures we show how the first injected code got parsed and why the secound client-side script code has in the error message been successful executed. The error output of the upload form exception does not encode the values of an invalid file name. The result is the client-side execute of the
[Full-disclosure] New vulnerabilities in Google Maps plugin for Joomla
Hello list! Last year I wrote about multiple vulnerabilities in Google Maps plugin. After my informing the developer fixed them, but this year I found new vulnerabilities. These are Denial of Service and Insufficient Anti-automation vulnerabilities in Google Maps plugin for Joomla. - Affected products: - Vulnerable are Google Maps plugin v3.2 for Joomla and previous versions. Except versions 2.19, 2.20 and 3.1 of the plugin where proxy functionality was removed. I've informed the developer about these holes. Now he is working on a new version of the plugin. He hasn't released Google Maps v3.2 yet, only put it on his site. And after fixing all reported vulnerabilities, he will release it to the public. - Affected vendors: - Mike Reumer http://extensions.joomla.org/extensions/maps-a-weather/maps-a-locations/maps/1147 -- Details: -- Denial of Service (WASC-10): It's possible to conduct attacks on target sites, where domain of web site with Google Maps plugin is used as subdomain. For old versions of the plugin plugin_googlemap2_proxy.php is used and for new versions of the plugin plugin_googlemap3_kmlprxy.php is used. E.g. request for attack on site wordpress.com via script at web site site: http://site/plugins/system/plugin_googlemap2_proxy.php?url=site.wordpress.com http://site/plugins/system/plugin_googlemap3/plugin_googlemap3_kmlprxy.php?url=site.wordpress.com It's needed by bypass security filter (domain restriction) if it's turned on. Thus it's possible to attack web sites, which allow arbitrary subdomains. Besides conducting DoS attack manually, it's also possible to conduct automated DoS and DDoS attacks with using of DAVOSET (http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/2013-July/008879.html). Insufficient Anti-automation (WASC-21): Last year in Google Maps plugin v3.2 the developer made protection from automated attacks, but it's not effective. And use of above-mentioned domain check can be bypassed. In this functionality there is no reliable protection from automated requests. To bypass protection for accessing this script (appeared in version 3.2) it's needed to set referer, cookie and token. The referer is current site, the cookie is set by the site (Joomla) itself and the token can be found at page which uses plugin of the site (and it's setting in URL). This data can be taken from the site automatically. Referer: http://site Cookie: dc9023a0ff4f8a00f9b2f4e7600c17f4=69c59f0263b70f9343e0a75a93bd44a0 I have disclosed it at my site (http://websecurity.com.ua/6987/). Best wishes regards, MustLive Administrator of Websecurity web site http://websecurity.com.ua ___ 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 2856-1] libcommons-fileupload-java security update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - - Debian Security Advisory DSA-2856-1 secur...@debian.org http://www.debian.org/security/Florian Weimer February 07, 2014 http://www.debian.org/security/faq - - Package: libcommons-fileupload-java Vulnerability : denial of service Problem type : remote Debian-specific: no CVE ID : CVE-2014-0050 It was discovered that the Apache Commons FileUpload package for Java could enter an infinite loop while processing a multipart request with a crafted Content-Type, resulting in a denial-of-service condition. For the oldstable distribution (squeeze), this problem has been fixed in version 1.2.2-1+deb6u2. For the stable distribution (wheezy), this problem has been fixed in version 1.2.2-1+deb7u2. For the unstable distribution (sid), this problem has been fixed in version 1.3.1-1. We recommend that you upgrade your libcommons-fileupload-java 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.4.12 (GNU/Linux) iQEcBAEBAgAGBQJS9WToAAoJEL97/wQC1SS+IcIH/18AS3UkkZtLgZcEGpBeBEM+ OX00IRYPc3emFQcB3ZUUeiYGtq3aAEKYTW5wd8tAA04K4wUMdcV70oUxnFEeUcLl ir0b4rIM/ozB86iBN95jmgQzY7pdx703tvhA7CQlNdC0WTEPFHW7yrGksrAk5rTv zw5NlN3Hi9McYH+kigp6ULoNavWfByNM7i7xNb7tPCulF0MnIyhfg0ewxgg+QfYj RB0V5U/jSW77n0E/Ft9MX5cthViwaCxYREJoXgSIDid/OYyNIE3aZuB+KKFDwPGw /dkC+QIE6Zbeesx73YBo+oCEKulGE1UOutjrHy/vnV+mvZklmvChyZEyaGjIG5w= =noFV -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] Bank of the West security contact?
Anyone have security contact at Bank of the West? -- Kristian Erik Hermansen https://www.linkedin.com/in/kristianhermansen https://profiles.google.com/kristian.hermansen ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
