Php 5.4.16 Exploit

[Blossom Stemmer]

TheExploit Database is maintained by OffSec, an information security training company that provides various Information Security Certifications as well as high end penetration testing services. The Exploit Database is a non-profit project that is provided as a public service by OffSec.

The Exploit Database is a CVE compliant archive of public exploits and corresponding vulnerable software, developed for use by penetration testers and vulnerability researchers. Our aim is to serve the most comprehensive collection of exploits gathered through direct submissions, mailing lists, as well as other public sources, and present them in a freely-available and easy-to-navigate database. The Exploit Database is a repository for exploits and proof-of-concepts rather than advisories, making it a valuable resource for those who need actionable data right away.

The Google Hacking Database (GHDB) is a categorized index of Internet search engine queries designed to uncover interesting, and usually sensitive, information made publicly available on the Internet. In most cases, this information was never meant to be made public but due to any number of factors this information was linked in a web document that was crawled by a search engine that subsequently followed that link and indexed the sensitive information.

After nearly a decade of hard work by the community, Johnny turned the GHDB over to OffSec in November 2010, and it is now maintained as an extension of the Exploit Database. Today, the GHDB includes searches for other online search engines such as Bing, and other online repositories like GitHub, producing different, yet equally valuable results.

When run as a CGI, PHP up to version 5.3.12 and 5.4.2 is vulnerable to an argument injection vulnerability. This module takes advantage of the -d flag to set php.ini directives to achieve code execution. From the advisory: "if there is NO unescaped '=' in the query string, the string is split on '+' (encoded space) characters, urldecoded, passed to a function that escapes shell metacharacters (the "encoded in a system-defined manner" from the RFC) and then passes them to the CGI binary." This module can also be used to exploit the plesk 0day disclosed by kingcope and exploited in the wild on June 2013.

Since Issabel is a fork of Elastix 2.5 and 4.0 that still uses the core programming of the former project and also FreePBX 2.11.0.26 this is something that could potentially happen to Issabel users and I wanted to share it with you all:

I have seen a couple of posts where users complain about a blank screen after they click on the PBX Configuration tab. Well, I have experienced the same on my server and I have all updates applied to the server both for CentOS 5.11 (defunct now according to Centos.org) and also the remaining Elastix repos on the internet.

The problem is fixed by running "yum reinstall freePBX" but sadly, it is only temporal. It looks like there is some php injection or exploit hackers have found to mess up with freePBX 2.11.0.26 (the latest Elastix installs). The intruders DELETE all php files of the freePBX GUI leaving it unusable and broken. Thank god they do not mess with the databases hence your PBX will still operate, take calls, make calls, record calls, transfer calls, register extensions and more but you won't be able to reach the GUI for further configuration until you reinstall freePBX again.

I have found myself reinstalling freePBX every single day and quite frankly this is getting on my nerves. I even set the firewall to block everything except the local network and the public IP of my customers but regardless, the intruder finds a way to break into the system and delete all php files of FreePBX.

What I found is in the /tmp folder a file called "magnito23.php" "magnito.php" or "MesSI.php" They are base64 encoded but by decoding them I realize they are obtaining admin access by retrieving the password. In addition, in the /var/www/html/_asterisk folder you will also find this "magnito.php" file which clearly means someone is injecting that code.

I have searched for solutions on the internet to no avail. Question is... Has someone found this threat and eliminated it for good? If so, please do share because I am TIRED to reinstall FreePBX in all my servers. Oh, and it happens on Elastix 4.0 with CentOS 7 as well. I have a mix of Elastix 2.5 and 4.0 servers and the same happens on both platforms.

If you already close all the external ports the the attacker left a script in your system to trigger an script or reverse connection. Check crontab and folders for unwanted scripts. Also monitor your network and log files to know what is triggered at which time.

navaismo Reading that post thoroughly I can tell you that the reason of the problem does not apply to me because I have NO business with Sangoma or FreePBX directly. I've always been an Elastix certified Engineer and the few times (2 to be precise) I needed paid support it was through Elastix and not the Sangoma technicians which kills the possibility of any admin / ssh password leak that hackers captured from their database..

I have seen hacks with the magnito.php file injected in systems. Analyzing logs, it appears the attack was done to a2billing (on its version 2.2.0). We decided to not install a2billing by default as the issue we discovered is still under investigation as it seems its a non reported exploit.

I used yum remove elastix-a2billing and made sure that nothing was left on /var/www/html related to A2Billing. Are there any other remnants of A2Billing that I probably have to look into? Because it seems that the hackers are either gaining access from the Elastix php code or FreePBX 2.11.0.26

venturinog No, I'll explain again.. the page goes either blank or shows "HTTP ERROR 500 - internal Server error" AFTER the intruders gain access to the system and delete FreePBX code because if you run "amportal restart" it says it cannot find the directory where the files are located and the start process FAILS.

After you perform "yum update elastix-freePBX" and you refresh your browser screen you will see everything back. Curiously, this intruder's script also disables the anti hacker module and you have to re-upload the license file, fill in the required fields and start the anti-hacker module once more.

hello, sorry for me english,

Hello, I usually put on all servers protected by htaccess to at least thus prevent anyone accessing the web part. I copy what they have to do to ask user and password when accessing issabel (or old elastix), I put it in Spanish because I do not know English well, but I hope you understand.

I hope it helps

hola, yo suelo poner en todos los servidores protegidos por htaccess para al menos asi evitar que acceda cualquiera a la parte web. les copio lo que deben hacer para que pida usuario y clave al acceder a issabel ( o antiguo elastix), lo pongo en espaol porque en ingles no se bien, pero espero se entienda.

hgmnetwork Gracias por tu consejo, hice lo que recomendaste pero igual pas lo mismo con tu sugerencia. Parece que es algn script que ya est dentro del sistema que est haciendo esto pero no puedo determinar dnde est an.

English version: Thank you for your advice, i did what you suggested but the same happened nonetheless. It looks there it is a script that is already on the server that is running and doing this but I can't determine where it is yet.

Knowing the users table structure, I could use the MySQL -e option to retrieve the contents of column name and column pass from the users table. This returns a password hash of brucetherealadmin, and I will have to crack this.

The current snap version is not vulnerable (patched with regex) to Dirty Sock. But, since the goal here is to install a malicious snap package with administrative privilege, I can steal the payload (trojan snap code) from the PoC exploit v2 and revert it back to a snap package.

The malicious.snap file now can be installed with --devmode option to skip digital signatures check. If the exploit success, there will be a new user added called dirty_sock (default from the payload).

Networked was an easy box that starts off with a classic insecure upload vulnerability in an image gallery web application. The Apache server is misconfigured and let me use a double extension to get remote code execution through my PHP script. To escalate to root, we have to find a command injection vulnerability in the script that checks for web application attacks, then exploit another script running as root that changes the ifcfg file.

3a8082e126