👉 🔥 CLICK HERE! 🔥 👈

144881754 story Posted by EditorDavid on Sunday April 11, 2021 @11:34AM from the are-you-being-servered dept. Inside.coms developer newsletter reports: The PHP team no longer believes the git.php.net server was compromised in a recent attack, which prompted PHP to move servers to GitHub and caused the team to temporarily put releases on hold until mid-April... In an update offering further insight into the root cause of the late March attack, the team says because its possible the master.php.net user database was exposed, master.php.net has been moved to main.php.net. The team also reset php.net passwords, and you can visit https:main.php.netforgot.php to set a new password. In addition, git.php.net and svn.php.net are both read-only now. Two malicious commits were pushed to the php-src repo from PHP founder Rasmus Lerdorf and PHP core developer Nikita Popov, Popov announced March 28. After an investigation, the PHP team reassured users these malicious commits never reached end-users. However, the team decided to move to GitHub after determining maintaining its own git infrastructure is an unnecessary security risk. In 2019, the PHP team temporarily shut down its Git server after discovering that an attacker had maliciously replaced the official PHP Extension and Application Repository with a malicious one, reports CPO magazine. But this newer supply chain attack targeted any server that uses PHP ZLib compression when sending data. Most servers use this functionality on almost all content except images and archives that are already size optimized. The supply chain attack would have turned PHP into a remote web shell through which the attackers could execute any command without authentication. This is because the malicious attackers would have the same privileges as the web server running PHP. The backdoor is triggered at the start of a request by checking if the request contains the word zerodium. If this condition was met, PHP executes the code in the User-Agentt request header. The header closely resembles the PHP User-Agent request for checking for browser properties. The rest of the request would thus be treated as a command that could be executed on a PHP server using the servers privileges. This would allow the hackers to run any arbitrary command without the need for further privileges... PHP powers 80% of all websites. Thus, a successful supply chain attack exploiting the language could prove catastrophic. The maintainers of the PHP programming language have provided an update regarding the security breach that took place on March 28. Unknown attackers hacked the official Git server of the PHP programming language and pushed unauthorized updates to insert a backdoor into the source code. On March 28, the attackers pushed two commits to the php-src repository hosted on the git.php.net server, they used the accounts of Rasmus Lerdorf, the PHPs author, and Jetbrains developer Nikita Popov. Below a summary provided by Nikita Popov on what has emerged during the investigation: We no longer believe the git.php.net server has been compromised. However, it is possible that the master.php.net user database leaked. master.php.net has been migrated to a new system main.php.net.All php.net passwords have been reset. Go to https:main.php.netforgot.php to set a new password. git.php.net and svn.php.net are both read-only now, but will remain available for the time being. Popov explained that further investigation into the incident revealed that the commits were also pushed via HTTPS and password-based authentication. Something I was not aware of at the time is that git.php.net (intentionally) supported pushing changes not only via SSH (using the gitolite infrastructure and public key cryptography), but also via HTTPS. The latter did not use gitolite, and instead used git-http-backend behind Apache2 Digest authentication against the master.php.net user database. continues Popov. Im not sure why password-based authentication was supported in the first place, as it is much less secure than pubkey authentication. Based on access logs, we can determine that the commits were indeed pushed using HTTPS and password-based authentication. An excerpt of relevant log entries is shown below Popov pointed out that the attackers only made only a few attempts to guess usernames, and one attempt was successful. At the time of this writing, it is not clear if the credentials of this specific user in the database of master.php.net has been leaked because apparently, the attackers had no reason to guess usernames once compromised the database. The PHP maintainers also noticed that master.php.net system, which is used for authentication and various management tasks, was running very old code and was based on a very old operating system PHP version. Below a list of improvements implemented to secure this system: master.php.net was migrated to a new system (running PHP 8) and renamed to main.php.net at the same time. Among other things, the new system supports TLS 1.2, which means you should no longer see TLS version warnings when accessing this site. The implementation has been moved towards using parameterized queries, to be more confident that SQL injections cannot occur. Passwords are now stored using bcrypt. Existing passwords were reset (use main.php.netforgot.php to generate a new one). The maintainers have already migrated master.php.net to a new main.php.net system which provides support for TLS 1.2, they have also forced password reset and replaced the MD5 hashing function with the bcrypt a password-hashing function. If you want to receive the weekly Security Affairs Newsletter for free subscribe here. Follow me on Twitter: @securityaffairs and Facebook Pierluigi Paganini (SecurityAffairs – hacking, data breach)

Items