Search This Blog

Powered by Blogger.

Blog Archive

Labels

Showing posts with label Open Source System. Show all posts

Attackers Can Still Exploit Log4j Vulnerability to Track Activities

 

Countless digital goods and services have been affected internationally since December 1, 2021, as a vulnerability related to the open-source logging framework Apache Log4j 2 has been aggressively abused. 

The researchers claim that the flaw is still present in an excessive number of systems around the world and that attackers will continue to successfully exploit it for years. 

Every year, a number of urgently needed fixes for severe vulnerabilities are found, but Log4Shell stood out because it was so simple to exploit wherever it was found and offered little to no room for attackers to maneuver. Logging tools are used by developers to keep track of activity within a certain application. 

To take advantage of Log4Shell, all attackers have to do is trick the system into logging a unique piece of code. They can then take over their target's computer and install malware or launch other types of online attacks. Because log-makers are going to log in, adding the malicious snippet to an email or account username is an easy way to introduce it. 

“Logging is fundamental to essentially any computer software or hardware operation. Whether it’s a phlebotomy machine or an application server, logging is going to be present,” stated David Nalley, president of the nonprofit Apache Software Foundation. “We knew Log4j was widely deployed, we saw the download numbers, but it is hard to fully grasp since in open source you're not selling a product and tracking contracts. 

 “I don’t think you fully appreciate it until you have a full accounting of where software is, everything it's doing, and who's using it. And I think the fact that it was so incredibly ubiquitous was a factor in everyone reacting so immediately. It's a little humbling, frankly.” 

The topic is relevant to more general discussions about the software supply chain and how it is more challenging to find and fix vulnerable code because many firms do not have a complete accounting of all the software they use in their systems. However, even if a company has a record of all the software it has purchased or installed, such programmes may still contain additional software parts, especially open-source libraries and tools like Log4j, that the end user is not directly aware of and did not choose. 

As a result, companies become exposed to vulnerabilities like Log4Shell and experience the long tail of patching, where they are either unaware that they are exposed or fail to see the urgency of making changes. 

Attackers are still actively using Log4Shell everywhere, from criminal hackers looking for a way into targets' systems to attackers with the support of the Chinese and Iranian governments who use the exploit in their espionage operations. 

“Log4Shell is one that’s going to show up in data breaches for the next decade as part of the root cause—all it takes is one instance of Log4Shell to be vulnerable. Thankfully, most consumers didn’t feel an impact last year, because the severity of it was so high that folks scrambled over that terrible weekend and throughout the holidays in a race with attackers. But there's an economic impact to that, a massive effort cost to do that remediation. And we’re not going to be able to scramble everybody for something that is even slightly less severe,” stated Dan Lorenc, CEO of the software supply-chain security firm Chainguard. 

When Apache made the issue public on December 9 of last year, Apache had to work quickly to be prepared to deliver updates for Log4Shell. Researchers soon discovered workarounds and edge cases for the changes as a result, and Apache was compelled to release additional revisions, which exacerbated the uncertainty. 

However, according to researchers, Apache's overall response was good. Nalley continues, "In response to the Log4Shell story, Apache has made changes and improvements and hired dedicated employees to expand the security support it can provide to open-source projects in order to discover problems before they are shipped in code and respond to incidents as necessary." 

The fact that even a year later, around a quarter or more of the Log4j downloads from the Apache repository Maven Central and other repository servers are still full of susceptible versions of Log4j illustrates the situation's most worrying future development. In other words, software developers continue to actively support computers running vulnerable utility versions or even create new insecure software. 

According to Brian Fox, cofounder and chief technology officer of the software supply-chain firm Sonatype, version downloads in Maven Central and other repositories reached a plateau where about 60% of the downloads were of patched versions and 40% were still of vulnerable versions following the initial rush to resolve Log4Shell. Fox and Apache's Nalley claims that over the past three months or so, the numbers have dropped to about a 75/25 split for the first time. Nevertheless, according to Fox, "a year later, a fourth of the downloads is still very poor."

A 15-Year-Old Bug Affected Over 350,000 Open-Source Projects

 

Trellix, an advanced research centre rediscovered a 15-year-old vulnerability in Python programming language that is still being exploited and has affected over 350,000 projects. 

The threat researchers at Trellix considered claimed to have found a zero-day vulnerability, it is a 15-year-old security flaw in the Python module, that has remained unpatched, and is now exposing around 350,000 open as well as closed source projects to the risk of supply chain cyberattacks. 

The Trellix estimate indicates that many of the affected repositories are used by machine learning tools that help developers to complete the project as soon as possible. 

In of one of the articles, Kasimir Schulz mentioned that the vulnerability was a form of routed traversal attack in the “extract and extractall functions of the tarfile module,” which is contained within the TAR file module itself. These open-source projects cover a wide range of areas including web development, media, IT management, software development, artificial intelligence, machine learning, and security. 

The vulnerability, tracked as “CVE-2007-4559”, permits the threat actor linked with a user, to execute the code and overlap the arbitrary files by using filenames with dedicated sequenced filenames in the TAR archive. This allows the attacker to acquire control of the targeted device. 

It is similar to the vulnerability named, CVE-2022-30333, which was recently found in RARIab’s UnRAR, which also allows the attacker to execute the code remotely. 

The CVE-2007-4559 was first discovered in 2007 when it was declared as a vulnerability of low importance by Red Hat, one of the world’s leading solution providers of enterprise open-source software. 

The bug can be leveraged on Linux as well. It includes the specially crafted TAR archive used to overwrite or overlap the existing arbitrary files on the targeted device by just opening the file. It is through this simple overlap that the attacker is able to inject the malicious tarfile in a way that allows him to execute the code by intending that the file be extracted after crossing the directory boundary. 

Reportedly, the patches have been introduced by Trellix for the aforesaid vulnerability. Initially, they are made available for about 11000 projects, but within the next week, they will be available for about 7000 projects.

FBI: Hackers use DeFi Bugs to Steal Cryptocurrency

 


Investors are being warned by the FBI that hackers are increasingly using Decentralized Finance (DeFi) platform security flaws to steal cryptocurrency.

According to the PSA, which was posted on the FBI's Internet Crime Complaint Center (IC3) today, nearly 97% of the $1.3 billion in bitcoin that was stolen between January and March 2022 came via DeFi sites. This represents a big increase from 72% in 2021 and roughly 30% in 2020, according to projections by the FBI.

The FBI urges people to be aware of the hazards, seek professional assistance if they are unsure, and research the security and general business practices of DeFi providers. Additionally, we all refer to DeFi providers as exchanges, markets, and other websites where you may buy, sell, trade, and borrow bitcoins and other digital assets.

The FBI's warning is due to a Chainalysis analysis from April that revealed how, per Q1 2022 statistics, DeFi cryptocurrency platforms are currently more targeted than ever.

In the majority of occurrences, the hackers rely on using security flaws in their platform's code or unauthorized access to drain cryptocurrency to addresses under their command.

According to Chainalysis, the threat actors responsible for these attacks used dangerous laundering services, like unlawful exchanges and coin tumblers on the dark web, to re-launder the majority of the stolen funds in 2022.

The FBI's alert provides investors with guidance that begins with basic cautions about performing due diligence before investing and then suggests the following:

Before investing, research DeFi platforms, protocols, and smart contracts and be aware of the dangers associated with DeFi investments.

Verify whether the DeFi investment platform has undergone one or more code audits done by impartial auditors. A code audit normally entails carefully examining and studying the platform's underlying code to find any flaws or vulnerabilities that might impair the platform's functionality.

Be wary of DeFi investment pools with short join windows and quick smart contract rollouts, especially if they don't perform the advised code audit.

Be mindful of the potential risks crowdsourced solutions pose for finding and patching vulnerabilities. Open source code repositories give anyone, even those with malicious intent, unauthorized access.

This year, no DeFi-taken monies have been reimbursed, indicating that attackers are less interested in protecting their stolen assets than they were in 2021 when almost 25% of all cryptocurrency stolen via DeFi platforms was eventually recovered and given to the victims.

The FBI established a link between the Lazarus and BlueNorOff (also known as APT38) North Korean threat organizations and the April attack of Axie Infinity's Ronin network bridge, now the largest crypto hack ever.

The $611 million breach of the decentralized merge protocols and network Poly System in August 2021 was the most significant cryptocurrency theft to date.




Experts Warn of Unsecured Prometheus Endpoints Leaking Sensitive Data

 

A massive unauthenticated scraping of publicly available and non-secured endpoints from previous versions of the Prometheus event monitoring and alerting service could be used to unintentionally expose critical data, according to the latest research.

JFrog researchers Andrey Polkovnychenko and Shachar Menashe stated in a report, "Due to the fact that authentication and encryption support is relatively new, many organizations that use Prometheus haven't yet enabled these features and thus many Prometheus endpoints are completely exposed to the Internet (e.g. endpoints that run earlier versions), leaking metric and label dat." 

Prometheus is an open-source system monitoring and alerting toolkit that collects and process metrics from various endpoints while also allowing for easy analysis of software metrics such as memory usage, network usage, and software-specific defined metrics such as the number of faulty logins to a web application. 

With the release of version 2.24.0 in January, support for Transport Layer Security (TLS) and basic authentication was added. 

The findings are the result of a methodical movement of publicly exposed Prometheus endpoints that were available on the Internet without any authentication. The metrics discovered were found revealing software versions and hostnames, which the researchers stated could be weaponized by intruders to perform an inspection of a target environment before exploiting a specific server or for post-exploitation methods like lateral movement. 

The following are some of the endpoints and information disclosed: 
  • /api/v1/status/config - Leakage of usernames and passwords provided in URL strings from the loaded YAML configuration file 
  • /api/v1/targets - Leakage of metadata labels, including environment variables as well as user and machine names, added to target machine addresses 
  • /api/v1/status/flags - Leakage of usernames when providing a full path to the YAML configuration file 
An attacker can use the "/api/v1/status/flags" endpoint to request the status of two administration interfaces — "web.enable-admin-api" and "web.enable-lifecycle" — and, if discovered manually enabled, exploit them to discard all saved metrics and, in the worst-case scenario, shut down the monitoring server. It's noteworthy that the two endpoints are disabled by default for security reasons of Prometheus 2.0. 

As per JFrog, around 15% of the Internet-facing Prometheus endpoints had the API management setting activated, and 4% had database management enabled. A total of around 27,000 hosts were found through a search on the IoT search engine Shodan. 

In addition to advising organisations to "query the endpoints [...] to help verify if sensitive data may have been exposed," the researchers stated that advanced users who require stronger authentication or encryption than what Prometheus provides can also set up a different network entity to manage the additional security.