Search This Blog
Powered by Blogger.

Blog Archive

Labels

Load More
Trendy Right Now

Popular Posts

Showing posts with label Log4j. Show all posts
Vulnerabilities and Exploits
Log4j Log4Shell Logging Tool Open Source System Vulnerabilities and Exploits

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."
Read more »
MySQL
Cyber Security FBI Iranian hackers Log4j MySQL

FBI Warns of Hack Operations From Iranian Hackers

The FBI cautions that the Iranian threat group Emennet Pasargad may conduct hack-and-leak activities against US interests, precisely the November midterm elections, despite the group's primary focus on attacking Israeli leaders.

The US Treasury announced penalties over five Iranians and Emennet Pasargad, the firm they worked for, in November 2021 after the US issued a warning in November 2020 that Iranian hackers had taken advantage of known weaknesses to acquire voter registration data.

According to the information from the FBI, Emennet has been targeting organizations, primarily in Israel, with cyber-enabled information operations since at least 2020. These operations included an initial intrusion, data theft, and subsequent leak, followed by attenuation through online and social media forums, and in some cases, the implementation of destructive encryption malware.

The gang also targets businesses with PHP-powered websites or MySQL databases that can be accessed from the outside. The FBI claims hackers frequently launch attacks using open-source software for penetration testing.

The Bureau claims that Emennet executes false-flag attacks against Israel using online personas like hacktivists or cybercriminal groups. It warns that the company may use the same strategies to target US entities. The majority of the measures mentioned in the report were ones the group employed in the 2020 U.S. Presidential election.

The FBI issued a warning, stating that the gang would 'probably' target popular content-management tools like Drupal and WordPress. The infamous Log4j vulnerability has also been used by Emennet in cyberattacks on at least one U.S.-based company.

Seyyed Mohammad Hosein Musa Kazemi and Sajjad Kashian, two Iranian consultants who started working for Emennet Pasargad, initiated several operations intended to sow discord and undermine voters' confidence in the American electoral process, were the subject of a $10 million reward offered by the U.S. State Department in February.

Although still at large, Kazemi and Kashian are thought to be in Iran. The FBI's list of cyber criminals wanted now includes the two as well. The FBI also provides organizations with advice on how to reduce the risk posed by Emennet and a list of tactics, methods, and procedures (TTPs) related to the group.


Read more »
Vulnerabilities and Exploits
Bugs Flaws Hackers Log4j North Korea Security Researchers Threat Intelligence Vulnerabilities and Exploits

Lazarus Hackers are Using Log4j to Hack US Energy Companies

 

A new cyber espionage campaign targeting US, Canadian, and Japanese energy providers has been linked to the North Korean state-sponsored Lazarus hacking group, according to security researchers.

Cisco Talos, a threat intelligence company, announced Thursday that Lazarus, also known as APT38, was observed targeting unidentified energy providers in the United States, Canada, and Japan between February and July of this year. 

According to Cisco's findings, the hackers exploited a year-old Log4j vulnerability known as Log4Shell to compromise internet-exposed VMware Horizon servers in order to gain an initial foothold on a victim's enterprise network before deploying bespoke malware known as "VSingle" and "YamaBot" to gain long-term persistent access. 

Japan's national cyber emergency response team, known as CERT, recently linked YamaBot to the Lazarus APT. Symantec first disclosed information of this espionage campaign in April of this year, attributing the operation to "Stonefly," another North Korean hacking group with some overlaps with Lazarus.

However, Cisco Talos discovered a previously unknown remote access trojan (RAT) called "MagicRAT," which is attributed to the Lazarus Group and is used by hackers for reconnaissance and credential theft.

Talos researchers Jung soo An, Asheer Malhotra, and Vitor Ventura, “The main goal of these attacks was likely to establish long-term access into victim networks to conduct espionage operations in support of North Korean government objectives. This activity aligns with historical Lazarus intrusions targeting critical infrastructure and energy companies to establish long-term access to siphon off proprietary intellectual property.”

However, in recent months, the group has shifted its focus to blockchain and cryptocurrency organisations. It has been associated with the recent thefts of $100 million in cryptocurrency from Harmony's Horizon Bridge and $625 million in cryptocurrency from the Ronin Network, an Ethereum-based sidechain created for the popular play-to-earn game Axie Infinity.

Pyongyang has long used stolen cryptocurrency and information theft to finance its nuclear weapons programme. In July, the United States offered a $10 million reward for data on members of state-sponsored North Korean threat groups, including Lazarus, more than doubling the amount previously offered. The State Department made the announcement in April.

The Lazarus Group is a North Korean-backed hacking organisation best known for the high-profile Sony hack in 2016 and the WannaCry ransomware attack in 2017. Lazarus is also motivated by efforts to support North Korea's state objectives, such as military R&D and evasion of international sanctions.
Read more »
Vulnerabilities and Exploits
attacks CISO Log4j Report Research Risk Vulnerabilities and Exploits

Homeland Security Warns Log4j’s 'Endemic' Threats for Years to Come

 

The US Department of Homeland Security (DHS) published the Cyber Safety Review Board's (CSRB) first report into the December 2021 Log4j incident, when a variety of vulnerabilities with this Java-based logging framework were revealed, this week. 

The report's methodology comprised 90 days of interviews and information requests with around 80 organisations and individuals, including software developers, end users, security specialists, and businesses. 

This was done to ensure that the board met with a wide range of representatives and understand the complexities of how different attack surfaces are constructed and defended. According to the report, although standardised and reusable "building blocks" are essential for developing and expanding software, they also allow any possible vulnerability to be mistakenly included in multiple software packages, putting any organization that uses those programs at risk. 

According to the report, while Log4j remains dangerous, the government-wide approach helped tone down the vulnerability. The board also noted the need for extra financing to help the open-source software security community, which is primarily comprised of volunteers. 

Industry experts, such as Michael Skelton, senior director of security operations at Bugcrowd, said of Log4J: “Dealing with it is a marathon, one that will take years to resolve. Java and Log4j are prevalent everywhere, not only in core projects but in dependencies that other projects rely on, making detection and mitigation not as simple an exercise as it may be with other vulnerabilities.” 

John Bambenek, the principal threat hunter at Netenrich, was more critical of the report’s timing, believing that “anyone still vulnerable is highly unlikely to read this report or in much of a position to do anything about it if they did. Most of the American economy is small to medium businesses that almost always never have a CISO and likely not even a CIO. Until we find ways to make the public without security budgets safe, no high-level list of best practices will move the ball significantly.” 

The CSRB report went on to state that, thankfully, it is unaware of any large Log4j-based attacks on critical infrastructure assets or systems, and that efforts to hack Log4j happened at a lesser level than many experts expected. 

The paper, however, emphasises that the Log4j incident is "not over" and will continue to be an "endemic vulnerability" for many years, with considerable risk persisting. The research concluded with 19 actionable recommendations for government and business, which were divided into four divisions. They were as follows:
  • Address Continued Risks of Log4j
  • Drive Existing Best Practices for Security Hygiene
  • Build a Better Software Ecosystem
  • Investments in the Future
Read more »
Vulnerabilities and Exploits
Apache Vulnerability Flaws Log4j Log4Shell Microsoft Exchange phishing Security vulnerability Vulnerabilities and Exploits

Phishing Attack Emerges as a Primary Threat Vector in X-Force Threat Intelligence Index 2022

 

IBM published its tenth X-Force Threat Intelligence Index last week unveiling phishing attacks as the primary threat vector in the past year, with manufacturing emerging as the most targeted sector. IBM security analysts spotted a 33% surge in attacks caused by vulnerability exploitation of Log4Shell, a point of entry that malicious actors relied on more than any other to launch their assaults in 2021, representing the cause of 44% of ransomware attacks. 

The 2022 Threat Intelligence Index was compiled from billions of data points, ranging from network and endpoint detection devices, incident response engagements, phishing kits, and domain name tracking. It was revealed that threat actors employed phishing in 41% of attacks, surging from 2020 when it was responsible for 33% of attacks. Interestingly, click rates for the average targeted phishing campaign surged nearly three-fold, from 18% to 53% when phone phishing (vishing) was also employed by malicious actors. 

The X-Force report highlights the record-high number of vulnerabilities unearthed in 2021, including a vulnerability in the Kaseya monitoring software that was exploited by REvil in July, and the Log4j (or Log4Shell) vulnerability in Apache’s popular logging library. Cybercriminals from across the globe were so quick to exploit Log4j that it occupied the number two spot on the X-Force top 10 lists of most exploited vulnerabilities in 2021, despite only being discovered in December last year. The top vulnerability was a flaw in Microsoft Exchange that allowed attackers to bypass authentication to impersonate an administrator. 

Additionally in the UK, nearly 80% of users received a malicious call or text last year. To counter the threat, regulator Ofcom published new guidelines this week which will require more proactive work from operators to root out the use of spoofed numbers. 

“X-Force observed actors leveraging multiple known vulnerabilities, such as CVE-2021-35464 (a Java deserialization vulnerability) and CVE-2019-19781 (a Citrix path traversal flaw), to gain initial access to networks of interest. In addition, we observed threat actors leverage zero-day vulnerabilities in major attacks like the Kaseya ransomware attack and Microsoft Exchange Server incidents to access victim networks and devices,” researchers explained. 

To mitigate the risks, researchers advised organizations to update their vulnerability management system, identify security loopholes, and prioritize vulnerabilities based on the likelihood they will be abused.
Read more »
zero Day vulnerability
Bugs Exploits Flaws Log4j PoC Vulnerabilities and Exploits Vulnerability management Vulnerable Systems zero Day vulnerability

The Log4j Incident Demonstrated Again That Publicly Disclosing 0-day Vulnerabilities Only Aids Intruders

 

On December 9, 2021, a (now-deleted) tweet pointing to a 0-day proof of concept (PoC) exploit for the Log4Shell vulnerability on GitHub set the internet ablaze, sending businesses rushing to mitigate, patch, and patch again as other PoCs surfaced. 

Public vulnerability disclosure – that is, revealing to the world the existence of a bug in a piece of software, a library, an extension, or another piece of software, and releasing a proof-of-concept (PoC) that exploits it – occurs frequently for vulnerabilities in a wide range of software, from the most esoteric to the most mundane (and widely used). 

Threat actors are the only ones who benefit from the public disclosure of 0-day PoCs, as per research and experience, because it puts enterprises in the awkward position of needing to remediate the issue without having anything solid to mitigate it with (i.e., a vendor's patch). 

There are several different types of responsible vulnerability disclosure systems available today. Some companies have an official vulnerability disclosure programme while others arrange and operate it through crowdsourced platforms. Companies typically offer money for information concerning flaws in their products (also known as "bug bounties"). 

Those disclosures usually follow a set of steps, and vendor patches have clearly stated release dates so that users have plenty of time to install them (90 days is the accepted standard for this). 

When the Log4Shell vulnerability was announced publicly, the disclosure procedure was already underway (as evidenced by the pull request on GitHub that appeared on November 30). The following is the timeline of the disclosure, according to information provided by the Apache Software Foundation:
  • November 24: The Log4j maintainers were informed 
  • November 25: The maintainers accepted the report, reserved the CV, and began researching a fix November 26: The maintainers communicated with the vulnerability reporter 
  • November 29: The maintainers communicated with the vulnerability reporter December 4: Changes were committed 
  • December 5: Changes were committed 
  • December 7: First release candidate created 
  • December 8: The maintainers communicated with the vulnerability reporter, made additional fixes, created a second release candidate 
  • December 9: Patch released 
While user comments on the Apache Log4j GitHub project page expressed dissatisfaction with the timeliness of the update, this is to be expected when it comes to patching vulnerabilities - as everyone keeps pointing out, after all, the patch was developed by volunteers. 

Probable reasons for releasing PoC 

There could be valid and logical reasons for releasing a 0-day proof-of-concept. The most prevalent of these is the breakdown of the vulnerability disclosure process: the vendor may not be or cease to be responsive, may judge the vulnerability to be minor enough to warrant a repair, or may take too long to fix it – or any combination of the above. 

In situations like these, security researchers frequently decide to make the PoC public for the "common good," i.e. to force vendors to release a patch quickly. Other factors could include publicity (especially if the researcher is associated with a security vendor) – nothing attracts more press attention than zero-day proof-of-concept exploits for a widely used piece of software, especially if no patch is available. 

However, it should be noted that the evidence against publishing proof-of-concept exploits is now substantial and overwhelming. According to a study conducted by Kenna Security, sharing proof-of-concept attacks mostly assists attackers. A presentation at Black Hat several years ago walked through the lifecycle of zero-days and how they were released and exploited, demonstrating that if proof-of-concept exploits aren't publicly disclosed, the vulnerabilities in question aren't discovered for an average of 7 years by anyone else (threat actors included).

Unfortunately, during the log4j scramble, this was discovered a little too late. Although the initial tweets and disclosures were quickly withdrawn, the harm had already been done. Even the most recent revelation, which resulted in the release of patch 2.17.1, generated so much criticism from the security community that the researcher apologized publicly for the publication's bad timing. 

It's encouraging to see that public disclosure of PoC exploits is becoming more common. Researchers who choose to jump the gun need to be criticized, but all must all work together to ensure that more rigorous disclosure mechanisms are in place for everyone so that the public PoC scenario is avoided the next time a vulnerability like Log4Shell is uncovered.
Read more »
User Privacy
Customer Data Data Breach Flaws hack Log4j Sensitive data User Data User Information User Privacy

FinTech Company Struck by Log4j Says "No" to Paying the Ransom

 

ONUS, one of the largest Vietnamese crypto trading platforms, was recently hit by a cyberattack. Hackers aimed for the company's payment system, which was running a vulnerable version of Log4j. 

Following the cyberattack, extortion began, with hackers apparently blackmailing the company into paying a $5 million ransom, or user data would be made public. According to BleepingComputer, the corporation refused to pay, and as a result, information of about nearly 2 million ONUS users showed up for sale on forums. 

Around December 9, a Proof of Concept (POC) exploit for the well-known and presently making headlines Log4j vulnerability, CVE-2021-44228, appeared on Github. Threat actors have spotted a chance to substantially exploit it since then. ONUS's Cyclos server, which used a vulnerable version of Log4Shell, was one of their targets. 

Between December 11 and December 13, the hackers were able to successfully exploit it. They also installed backdoors to increase the access's power. On December 13, a Cyclos alert apparently informed ONUS that its systems needed to be fixed; nevertheless, even if the Cyclos instance was patched, it appeared to be a late response. Threat actors had plenty of time to steal important data. According to BleepingComputer, the databases held nearly 2 million customer records, including E-KYC (Know Your Customer) information, hashed passwords, and personal information. It's worth noting that the Log4Shell flaw was discovered on a sandbox server used "for programming purposes only." 

However, hackers were able to get access to other storage sites, such as Amazon S3 buckets, where production data was stored, due to a system misconfiguration. The threat actors reportedly demanded a $5 million ransom from ONUS, which the business refused and instead decided to inform customers about the cyberattack through a closed Facebook group. 

Chien Tran, the CEO from ONUS declared that “As a company that puts safety first, we are committed to providing our customers with transparency and integrity in business operations. (…) That is why, after careful consideration, the right thing we need to do now is to inform the entire ONUS community about this incident.” 

According to an ONUS announcement on the subject, hackers were able to obtain the following consumer data from the fintech firm: 
• Name, phone number, and email address; 
• Address; 
• KYC data (procedures used by Fintech enterprises to get identification documents and customers’ proofs along with “video selfie” for an automated check); 
• Encrypted history; 
• Transaction history; 
• Other encrypted data. 

The Misconfiguration in the Amazon S3 Buckets 

Besides Log4j, which facilitated an entry for the threat actors, there was another issue too with ONUS’ Amazon S3 buckets linked to improper access control. CyStack started an investigation on the incident and published their report with details about the cyberattack and the backdoor the hackers managed to plant on the impacted system.

“During monitoring, CyStack – ONUS’s security partner, detected and reported a cyberattack on ONUS system to us. The hacker took advantage of a vulnerability in a set of libraries on the ONUS system to get into the sandbox server (for programming purposes only). However, due to a configuration problem, this server contains information that gave bad guys access to our data storage system (Amazon S3) and stole some essential data.” 

“Also on these servers, ONUS had a script to periodically back up the database to S3 which contained the database hostname and username/password as well as backup SQL files. As a consequence, the attackers could access the ONUS database to get user information. (…) To facilitate access, the attackers downloaded and ran a backdoor on the server. This backdoor was named kworker for the purpose of disguising as the Linux operating system’s kworker service. (…) The kworker backdoor obtained was written in Golang 1.17.2 and built for Linux x64. It was used as a tunnel connecting the C&C server and the compromised server via SSH protocol (a wise way to avoid detection!).” 

According to BleepingComputer, because the organisation declined to pay the requisite ransom to hackers, customer data was for sale on a data breach marketplace by December 25. Hackers claim to have 395 copies of the ONUS database tables, which contain personal information and hashed passwords. 

CyStack advised ONUS to fix Log4j, deactivate any exposed AWS credentials, and properly configure AWS access rights, as well as the recommendation that public access to crucial S3 buckets be blocked. Users should upgrade to the current Log4j version 2.17.1 as soon as possible. ONUS also stated that none of its assets was harmed and that the company's team has been working with security specialists to identify and address flaws. 

The company's asset management and storage system, ONUS Custody, was also improved. In the case of a property loss, the firm must ensure that the ONUS Protection Fund would take care of the problem.
Read more »
Vulnerability
attacks Belgium Bugs Cyber Attacks Flaws Hacking Group Log4j Security Vulnerability

Hackers Exploit Log4j Flaw to Attack Belgium Defense Ministry

 

The Belgian Ministry of Defense has stated that the Log4j vulnerability was used in a cyberattack on its networks. 

The Defense Ministry said in a statement that an attack on its computer network with internet access was identified on Thursday. They didn't disclose whether the attack was ransomware, but they did state that "quarantine measures" were swiftly implemented to "contain the affected elements." 

The Defense Ministry stated, "Priority was given to the operability of the network. Monitoring will continue. Throughout the weekend, our teams were mobilized to contain the problem, continue our operations and alert our partners." 

"This attack follows the exploitation of the Log4j vulnerability, which was made public last week and for which IT specialists around the world are jumping into the breach. The Ministry of Defense will not provide any further information at this stage." 

Government hacking groups all across the world are using the Log4j vulnerability, according to multiple reports from firms like Google and Microsoft. State-sponsored hackers from China, Turkey, Iran, and North Korea, according to Microsoft, have begun testing, exploiting, and abusing the Log4j issue to spread a range of malware, including ransomware. 

According to multiple sources, since the vulnerability was found over two weeks ago, cybercriminal organisations have attempted to exploit it not only to acquire a foothold in networks but also to sell that access to others. 

To avoid attacks and breaches, governments around the world have advised agencies and companies to fix their systems or devise mitigation strategies. Singapore conducted emergency meetings with vital information infrastructure sectors to prepare them for potential Log4j-related threats, and the US' Cybersecurity and Infrastructure Security Agency instructed all federal civilian agencies to fix systems before Christmas. 

Katrien Eggers, a spokesperson for the Centre for Cybersecurity Belgium, told ZDNet that the organisation had also issued a warning to Belgian companies about the Apache Log4j software issue, stating that any organisation that had not already taken action should "expect major problems in the coming days and weeks." 

The Centre for Cybersecurity Belgium stated, adding that any affected organizations should contact them. "Because this software is so widely distributed, it is difficult to estimate how the discovered vulnerability will be exploited and on what scale. It goes without saying that this is a dangerous situation."
Read more »
Subscribe to: Posts (Atom)