Connect with us

Press Release

PHP source code was given backdoors thanks to a compromise of the Git server.

Published

on

PHP source code was given backdoors thanks to a compromise of the Git server.

The official PHP Git repository was breached in the most recent software supply chain attack, and the code base was modified.

Yesterday, two malicious commits were uploaded to the PHP team’s git.php.net server, which hosts the php-src Git repository.

Threat actors had verified these commits as if Rasmus Lerdorf and Nikita Popov, two well-known PHP developers and maintainers, had made them.

PHP Git server has an RCE backdoor installed.
Yesterday, two malicious contributions were uploaded to the official PHP Git repository in an effort to corrupt the PHP code base.

The event is concerning because 79% of websites on the Internet still use PHP as their server-side programming language.

The attackers released a mystery update upstream called “repair typo” in the malicious commits [1, 2] that BleepingComputer saw under the guise of a little typographical patch.

Looking closer at the newly added line 370, where the zend eval string function is used, reveals that the code in fact creates a backdoor for quickly achieving Remote Code Execution (RCE) on a website using this hacked version of PHP.

Developer Jake Birchall for PHP responded to Michael Voek, who had discovered the error originally, with the explanation, “This line executes PHP code from within the useragent HTTP header, if the string starts with ‘zerodium’.”

Nikita Popov, a PHP maintainer, explained the following to us via email:

“During a regular post-commit code review a few hours after the first commit, it was discovered. The modifications were immediately undone because they were blatantly malicious “According to Popov, BleepingComputer.

The malicious commit was also done under Rasmus Lerdorf’s identity, the person who created PHP.

But that should come as no surprise because with source code version control systems like Git, it is possible to sign off a change locally under a different identity [1, 2] and then upload the spoof commit to the remote Git server, where it appears to have been signed off by the person listed on it.

According to PHP maintainers, this malicious activity originated from the compromised git.php.net server rather than from the compromise of an individual’s Git account, despite the fact that a thorough investigation of the incident is still ongoing.

The official PHP codebase has been moved to GitHub.
Following this event, the PHP maintainers have chosen to move the official PHP source code repository to GitHub as a precaution.

We’ve made the decision to stop running the git.php.net server even though our investigation is still ongoing since we believe that keeping our own git infrastructure is an unnecessary security risk.

Popov stated that the GitHub repositories, which were previously merely mirrors, “would become canonical.”

After this modification, Popov demands that any future code updates be uploaded directly to GitHub rather than the git.php.net site.

Anyone who wants to contribute to the PHP project must now join the PHP organisation on GitHub.

The same security alert includes advice for doing that.

You would need to have two-factor authentication (2FA) set on your GitHub account in order to join the organisation.

Beyond the two commits that were mentioned, “We’re investigating the repositories for any corruption,” says Popov.

In order to learn the full scope of this attack and whether any code was transmitted downstream before the fraudulent commits were discovered, BleepingComputer contacted Popov and the PHP security team.

Although it might have been cloned or forked in the interim, no tags or release artefacts reflect the changes.

Popov added to BleepingComputer, “The changes were in the development branch for PHP 8.1, which is scheduled for release at the end of the year.

The PHP team has confirmed to BleepingComputer that they want to decommission their git server ultimately and switch to GitHub permanently in the coming days.

Continue Reading

Press Release

Microsoft fumbles supply chain and acknowledges signing rootkit malware.

Published

on

Microsoft fumbles supply chain and acknowledges signing rootkit malware.

As of right now, Microsoft has admitted to signing a malicious driver that is disseminated in gaming contexts.

This “Netfilter”-named driver is actually a rootkit that has been seen interacting with Chinese C2 IP addresses.

Last week, the whole infosec. community joined G Data malware specialist Karsten Hahn in tracking down and analysing the malicious drivers that bore the Microsoft logo.

This incident exposed vulnerabilities to software supply-chain security once more, but this time it was caused by a flaw in the code-signing procedure used by Microsoft.

Rootkit “Netfilter” driver is Microsoft-signed.
A Microsoft signed driver dubbed “Netfilter” was detected last week by G Data’s cybersecurity alert systems as what at first glance appeared to be a false positive, but wasn’t.

The driver in question was observed interacting with C&C IPs based in China, which had no valid functionality and raised red flags.

This is when Karsten Hahn, a malware analyst at G Data, disclosed this publicly and contacted Microsoft at the same time:

Since Windows Vista, all code that operates in kernel mode must be tested and certified before being made available to the public in order to maintain the stability of the operating system.

According to Hahn, “Drivers without a Microsoft certificate cannot be deployed by default.”

At that time, BleepingComputer started tracking C2 URL behaviour and approached Microsoft for a comment.

A list of further routes (URLs), denoted by the pipe (“|”) symbol, are returned by the first C2 URL:

Each of these, in Hahn’s opinion, has a function:

The URL that ends in “/p” refers to proxy settings, “/s” offers encoded redirection IPs, “/h?” is for getting CPU-ID, “/c” offered a root certificate, and “/v?” refers to the malware’s self-updating capabilities.
For instance, as observed by BleepingComputer, the malicious Netfilter driver in question (residing at “/d3”) was accessible via the “/v?” path at the following URL:

After thoroughly examining the driver, the G Data researcher came to the conclusion that it was malware.

In a thorough blog post, the researcher examined the driver, its ability to self-update, and Indicators of Compromise (IOCs).

According to Hahn, the sample features a self-update routine that transmits its own MD5 hash to the server via the URL hxxp:/110.42.4.180:2081/v?v=6&m=.

An illustration of a request would be as follows:

hxxp:/110.42.4.180:2081/v?v=6&m=921fa8a5442e9bf3fe727e770cded4ab
“The server then replies with either ‘OK’ if the sample is current or the URL for the most recent sample, such as hxxp:/110.42.4.180:2081/d6. As a result, the malware replaces its own file “further information from the researcher

Other malware specialists like Johann Aydinbas, Takahiro Haruyama, and Florian Roth worked with Hahn during his analysis.

Roth has offered YARA rules for recognising them in your network environments after being able to compile the list of samples in a spreadsheet.

Microsoft is looking at a bad actor who spreads harmful drivers inside of gaming environments.

“In order to be certified by the Windows Hardware Compatibility Program, the actor supplied drivers. A third party created the drivers.”

Microsoft stated yesterday, “We have stopped the account and checked their uploads for additional indicators of malware.”

Microsoft claims that the threat actor primarily targeted the gaming industry in China with these malicious drivers and that there is currently no evidence that enterprise environments have been impacted.

Microsoft is waiting before blaming nation-state actors for this incident.

Sophisticated threat actors may take advantage of falsely signed binaries to help launch extensive software supply-chain attacks.

A well-known event in which code-signing certificates were taken from Realtek and JMicron to assist the comprehensive Stuxnet attack on Iran’s nuclear programme.

However, this specific instance has shown flaws in a reliable code-signing procedure, which threat actors have exploited to obtain Microsoft-signed code without jeopardising any certifications.

Continue Reading

Press Release

By plugging in a mouse, Razer Bug enables you to access Windows 10 administration.

Published

on

By plugging in a mouse, Razer Bug enables you to access Windows 10 administration.

By just putting in a Razer mouse or keyboard, a Razer Synapse zero-day vulnerability that has been publicly published on Twitter enables you to take control of Windows as an administrator.

A well-known maker of computer accessories, Razer is well recognised for their gaming keyboards and mice.

The Razer Synapse programme will immediately download and start installing on a computer when a Razer device is plugged into Windows 10 or Windows 11. Users can set up macros, map buttons, and modify their gear using the software Razer Synapse.

Over 100 million people use Razer Synapse, according to Razer, who claims that number.

The plug-and-play Razer Synapse installation contains a zero-day vulnerability that, when exploited, allows users to swiftly gain SYSTEM access on a Windows system. This vulnerability was found by security researcher jonhat.

The greatest user rights in Windows, known as SYSTEM privileges, provide users the ability to run any command on the operating system. Basically, if a user has Windows’ SYSTEM capabilities, they have total control over the system and are able to install anything they want, including malicious software.

Razer had yet to respond, so yesterday jonhat revealed the zero-day vulnerability on Twitter and provided a little video explaining how the flaw operates.

Using a mouse while plugged in to gain access to the SYSTEM
We chose to test the flaw as BleepingComputer has a Razer mouse handy. We can confirm that it took us roughly two minutes to get SYSTEM rights in Windows 10 after plugging in our mouse.

It should be emphasised that this is a local privilege escalation (LPE) vulnerability, requiring physical access to a computer and a Razer device. To exploit the problem, all you need to do is purchase a $20 Razer mouse from Amazon and plug it into a Windows 10 computer.

On one of our Windows 10 machines, we set up a temporary ‘Test’ user with ordinary, non-administrator capabilities to test this flaw.

When we connected the Razer device to Windows 10, the operating system downloaded and set up both the driver and the Razer Synapse application automatically.

The Razer installation application got SYSTEM access as a result of the RazerInstaller.exe executable being started by a Windows process with SYSTEM privileges, as demonstrated below.

The setup procedure lets you choose the folder where the Razer Synapse software will be installed when you install it. Everything goes wrong when you have the choice of where to install your software.

The “Choose a Folder” window will show up when you move your folder. When you right-click the dialogue while holding down Shift, you will be given the option to “Open PowerShell window here,” which will launch a PowerShell prompt in the folder displayed in the dialogue.

This PowerShell prompt will inherit the same rights as the process that launched it because it was run with SYSTEM permissions.

As you can see in the screenshot below, after typing the “whoami” command at the PowerShell prompt, it became clear that the console has SYSTEM capabilities, enabling us to execute whatever command we like.

According to Will Dormann, a Vulnerability Analyst at the CERT/CC, other applications installed by the Windows plug-and-play mechanism is likely to include similar flaws.

Razer will address the flaw
Razer has contacted the security researcher to let them know that they will be delivering a remedy after this zero-day issue attracted significant notice on Twitter.

Despite the fact that the vulnerability was made public, Razer also informed the researcher that he would be getting a bug bounty payment.

Continue Reading

Press Release

The New York Times reports that investigators are investigating whether solarwinds has been hacked via offices in Czech, Polish, and Belorussia, where many of the company’s engineering has taken place (NEW YORK TIMES).

Published

on

solarwinds

Sources: investigators are checking if SolarWinds was hacked via its offices in Czechia, Poland, and Belarus, where the company moved much of its engineering  —  Those behind the widespread intrusion into government and corporate networks exploited seams in U.S. defenses and gave away nothing to American monitoring of their systems.

Continue Reading

Trending