It’s been approximately 100 days since the disclosure of the attack on the SolarWinds Orion platform, and we are in a better place to understand what happened. It’s been pretty eye-opening to learn how ill-equipped prominent industry players, including cybersecurity experts, were when it came to finding, preventing and defending themselves against an attack like this.
The CEOs from FireEye, Microsoft, SolarWinds, and CrowdStrike appeared in front of a U.S. Senate panel to layout the unfolding of events, defend their conduct in the data breach (blamed on Russian hackers) and sought to shift responsibility elsewhere. Notably missing was Amazon, even though its AWS cloud platform was a contributing factor in how the cyber attack was executed and spread.
During the testimony, it was outlined how the SolarWinds software was hijacked and used to break into a host of other organizations, and that the hackers had been able to read Microsoft’s source code for user authentication. This exposure and subsequent manipulation of the source code led to the hack of about 100 U.S. companies and nine federal agencies. CrowdStrike went so far as to say of Microsoft’s antiquated and complicated approaches – “The threat actor took advantage of systemic weaknesses in the Windows authentication architecture, allowing it to move laterally within the network” and that “if a different methodology had been used this particular threat vector would be eliminated.”
Even if the Senate panel pushed for a security solution for future prevention they wouldn’t have gotten one. These organizations are too ingrained in what they know and the tools/systems they have designed, or use. In this blog we’ll recount details of the hearing, but at the end, we’ll lay out why with our ARIA ADR solution, why the attack on Orion never would have happened; thus we would not have the cascading consequences that are coming to light in its wake.
Enjoy and see you at the end….
Your vendors and partners may be your biggest cybersecurity risk
The attack was discovered by FireEye and only by chance, as they noticed simultaneous log-ins. He spoke that his company had pen test tools stolen as a…
The PHP programming language maintainers averted a software supply chain attack when unknown threat actors compromised the self-managed Git server and inserted a backdoor.
The malicious commits were made on May 28, 2021 to a Git repository of a still-in-development version of PHP.
However, PHP contributors Markus Staab, Jake Birchallf, and Michael Voříšek noticed the changes during the post-commit code review.
Supply chain attack targeted Zlib library, turned PHP into a remote web shell
The 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 server’s privileges. This would allow the hackers to run any arbitrary command without the need for further privileges.
Zerodium, the company mentioned in the hack, is a vulnerability broker that buys zero-day vulnerabilities and sells them to government agencies. However, it denied any involvement in the PHP Git server compromise.
Zerodium CEO Chaouki Bekrar accused the researchers of introducing the backdoor and trying to sell it, only to disclose the vulnerability after failing to secure buyers. However, the accusation is preposterous given the lifetime of the backdoor.
The malicious commits were pushed using Rasmus Lerdorf, the PHP project author, and Nikita Popov, a major PHP contributor working at JetBrains names. The attackers described the commits as intended to fix typo on…
A newly discovered cryptomining worm is stepping up its targeting of Windows and Linux devices with a batch of new exploits and capabilities, a researcher said.
Research company Juniper started monitoring what it’s calling the Sysrv botnet in December. One of the botnet’s malware components was a worm that spread from one vulnerable device to another without requiring any user action. It did this by scanning the Internet for vulnerable devices and, when found, infecting them using a list of exploits that has increased over time.
The malware also included a cryptominer that uses infected devices to create the Monero digital currency. There was a separate binary file for each component.
Constantly growing arsenal
By March, Sysrv developers had redesigned the malware to combine the worm and miner into a single binary. They also gave the script that loads the malware the ability to add SSH keys, most likely as a way to make it better able to survive reboots and to have more sophisticated capabilities. The worm was exploiting six vulnerabilities in software and frameworks used in enterprises, including Mongo Express, XXL-Job, XML-RPC, Saltstack, ThinkPHP, and Drupal Ajax.
“Based on the binaries we have seen and the time when we have seen them, we found that the threat actor is constantly updating its exploit arsenal,” Juniper researcher Paul Kimayong said in a Thursday blog post.
Thursday’s post listed more than a dozen exploits that are under attack by the malware. They are:
|CVE-2019-3396||Widget Connector macro in Atlassian Confluence Server|
|CVE-2017-12149||Jboss Application Server|
|Apache Hadoop Unauthenticated Command Execution via YARN ResourceManager (No CVE)||Apache Hadoop|
|Brute force Jenkins||Jenkins|
|Jupyter Notebook Command Execution (No CVE)||Jupyter Notebook Server|
|CVE-2019-7238||Sonatype Nexus Repository Manager|
|Tomcat Manager Unauth Upload…|