Please help to click 1!

Wednesday, 15 June 2022

New Zimbra Email Vulnerability Could Let Attackers Steal Your Login Credentials

 

A new high-severity vulnerability has been disclosed in the Zimbra email suite that, if successfully exploited, enables an unauthenticated attacker to steal cleartext passwords of users sans any user interaction.

"With the consequent access to the victims' mailboxes, attackers can potentially escalate their access to targeted organizations and gain access to various internal services and steal highly sensitive information," SonarSource said in a report shared with The Hacker News.

Tracked as CVE-2022-27924 (CVSS score: 7.5), the issue has been characterized as a case of "Memcached poisoning with unauthenticated request," leading to a scenario where an adversary can inject malicious commands and siphon sensitive information.

This is made possible by poisoning the IMAP route cache entries in the Memcached server that's used to look up Zimbra users and forward their HTTP requests to appropriate backend services.

Given that Memcached parses incoming requests line-by-line, the vulnerability permits an attacker to send a specially crafted lookup request to the server containing CRLF characters, causing the server to execute unintended commands.

The flaw exists because "newline characters (\r\n) are not escaped in untrusted user input," the researchers explained. "This code flaw ultimately allows attackers to steal cleartext credentials from users of targeted Zimbra instances."

Armed with this capability, the attacker can subsequently corrupt the cache to overwrite an entry such that it forwards all IMAP traffic to an attacker-controlled server, including the targeted user's credentials in cleartext.

That said, the attack presupposes the adversary already is in possession of the victims' email addresses so as to be able to poison the cache entries and that they use an IMAP client to retrieve email messages from a mail server.

https://www.youtube.com/watch?v=GIgHZrPrGug

"Typically, an organization uses a pattern for email addresses for their members, such as e.g., {firstname}.{lastname}@example.com," the researchers said. "A list of email addresses could be obtained from OSINT sources such as LinkedIn."

A threat actor, however, can get around these restrictions by exploiting a technique called response smuggling, which entails "smuggling" unauthorized HTTP responses that abuse the CRLF injection flaw to forward IMAP traffic to a rogue server, thereby stealing credentials from users without prior knowledge of their email addresses.

"The idea is that by continuously injecting more responses than there are work items into the shared response streams of Memcached, we can force random Memcached lookups to use injected responses instead of the correct response," the researchers explained. "This works because Zimbra did not validate the key of the Memcached response when consuming it."

Following responsible disclosure on March 11, 2022, patches to completely plug the security hole were shipped by Zimbra on May 10, 2022, in versions 8.8.15 P31.1 and 9.0.0 P24.1.

The findings arrive months after cybersecurity firm Volexity disclosed an espionage campaign dubbed EmailThief that weaponized a zero-day vulnerability in the email platform to target European government and media entities in the wild.

Saturday, 11 June 2022

Apple's New Feature Will Install Security Updates Automatically Without Full OS Update

Apple has introduced a Rapid Security Response feature in iOS 16 and macOS Ventura that's designed to deploy security fixes without the need for a full operating system version update.

"macOS security gets even stronger with new tools that make the Mac more resistant to attack, including Rapid Security Response that works in between normal updates to easily keep security up to date without a reboot," the company said in a statement on Monday.

The feature, which also works on iOS, aims to separate regular software updates from critical security improvements and are applied automatically so that users are quickly protected against in-the-wild attacks and unexpected threats. It's worth noting that Apple tested an analogous option in iOS 14.5.


Rapid Security Response, viewed in that light, mirrors a similar approach taken by Google through Play Services and Play Protect to secure Android devices from malware and other kinds of fraud.

Another key security feature announced by Apple at its annual Worldwide Developers Conference (WWDC) includes support for third-party two-factor authentication apps with the built-in Passwords feature in the Settings app.

What's more, iOS 16 will now permit users to edit strong passwords suggested by Safari to adjust for site‑specific requirements, not to mention requiring apps to request users' permission to access the clipboard to paste content from another app.

Security Updates

 

 

 

 

 

 

 

 

In a similar permissions-related update, USB-C and Thunderbolt accessories barring power adapters and standalone displays will be made to explicitly ask for users' consent before they can communicate with macOS devices.

"On portable Mac computers with Apple silicon, new USB and Thunderbolt accessories require user approval before the accessory can communicate with macOS for connections wired directly to the USB-C port," the release notes reads.


The new macOS safeguard is also identical to the USB Restricted Mode that Apple introduced in iOS 12 four years ago, which prevents unauthorized USB accessories plugged into the Lightning port from accessing the data on iPhones and iPads without the owner's permission if the devices have been locked for over an hour.

Apple, lastly, also confirmed it's bringing support for passkeys in the Safari web browser, a next-generation passwordless sign-in standard that allows users to log in to websites and apps across platforms using Touch ID or Face ID for biometric verification.

The mechanism, established by the FIDO Alliance and already backed by Google and Microsoft, aims to supplant standard passwords by providing unique digital keys that are stored locally on the device.

Sunday, 5 June 2022

An actively exploited Microsoft 0-day flaw still doesn’t have a patch

Researchers warned last weekend that a flaw in Microsoft's Support Diagnostic Tool could be exploited using malicious Word documents to remotely take control of target devices. Microsoft released guidance on Monday, including temporary defense measures. By Tuesday, the United States Cybersecurity and Infrastructure Security Agency had warned that “a remote, unauthenticated attacker could exploit this vulnerability,” known as Follina, “to take control of an affected system.” But Microsoft would not say when or whether a patch is coming for the vulnerability, even though the company acknowledged that the flaw was being actively exploited by attackers in the wild. And the company still had no comment about the possibility of a patch when asked by WIRED.

The Follina vulnerability in a Windows support tool can be easily exploited by a specially crafted Word document. The lure is outfitted with a remote template that can retrieve a malicious HTML file and ultimately allow an attacker to execute Powershell commands within Windows. Researchers note that they would describe the bug as a “zero-day,” or previously unknown vulnerability, but Microsoft has not classified it as such.

“After public knowledge of the exploit grew, we began seeing an immediate response from a variety of attackers beginning to use it,” says Tom Hegel, senior threat researcher at security firm SentinelOne. He adds that while attackers have primarily been observed exploiting the flaw through malicious documents thus far, researchers have discovered other methods as well, including the manipulation of HTML content in network traffic.

“While the malicious document approach is highly concerning, the less documented methods by which the exploit can be triggered are troubling until patched,” Hegel says. “I would expect opportunistic and targeted threat actors to use this vulnerability in a variety of ways when the option is available—it’s just too easy.”

The vulnerability is present in all supported versions of Windows and can be exploited through Microsoft Office 365, Office 2013 through 2019, Office 2021, and Office ProPlus. Microsoft's main proposed mitigation involves disabling a specific protocol within Support Diagnostic Tool and using Microsoft Defender Antivirus to monitor for and block exploitation.

But incident responders say that more action is needed, given how easy it is to exploit the vulnerability and how much malicious activity is being detected.

“We are seeing a variety of APT actors incorporate this technique into longer infection chains that utilize the Follina vulnerability," says Michael Raggi, a staff threat researcher at the security firm Proofpoint who focuses on Chinese government-backed hackers. "For instance, on May 30, 2022, we observed Chinese APT actor TA413 send a malicious URL in an email which impersonated the Central Tibetan Administration. Different actors are slotting in the Follina-related files at different stages of their infection chain, depending on their preexisting toolkit and deployed tactics.”

Researchers have also seen malicious documents exploiting Follina with targets in Russia, India, the Philippines, Belarus, and Nepal. An undergraduate researcher first noticed the flaw in August 2020, but it was first reported to Microsoft on April 21. Researchers also noted that Follina hacks are particularly useful to attackers because they can stem from malicious documents without relying on Macros, the much-abused Office document feature that Microsoft has worked to rein in.

“Proofpoint has identified a variety of actors incorporating the Follina vulnerability within phishing campaigns," says Sherrod DeGrippo, Proofpoint's vice president of threat research.

With all this real-world exploitation, the question is whether the guidance Microsoft has published so far is adequate and proportionate to the risk.

“Security teams could view Microsoft’s nonchalant approach as a sign that this is ‘just another vulnerability,’ which it most certainly is not,” says Jake Williams, director of cyber threat intelligence at the security firm Scythe. “It’s not clear why Microsoft continues to downplay this vulnerability, especially while it’s being actively exploited in the wild.”

Sunday, 22 May 2022

Apache Log4j Security Vulnerabilities

 

This page lists all the security vulnerabilities fixed in released versions of Apache Log4j 2. Each vulnerability is given a security impact rating by the Apache Logging security team. Note that this rating may vary from platform to platform. We also list the versions of Apache Log4j the flaw is known to affect, and where a flaw has not been verified list the version with a question mark.

Log4j 1.x has reached End of Life in 2015 and is no longer supported. Vulnerabilities reported after August 2015 against Log4j 1.x were not checked and will not be fixed. Users should upgrade to Log4j 2 to obtain security fixes.

Binary patches are never provided. If you need to apply a source code patch, use the building instructions for the Apache Log4j version that you are using. For Log4j 2 these can be found in BUILDING.md located in the root subdirectory of the source distribution.

If you need help on building or configuring Log4j or other help on following the instructions to mitigate the known vulnerabilities listed here, please subscribe to, and send your questions to the public Log4j Users mailing list.

If you have encountered an unlisted security vulnerability or other unexpected behaviour that has security impact, or if the descriptions here are incomplete, please report them privately to the Log4j Security Team. Thank you!

Fixed in Log4j 2.17.1 (Java 8), 2.12.4 (Java 7) and 2.3.2 (Java 6)

CVE-2021-44832: Apache Log4j2 vulnerable to RCE via JDBC Appender when attacker controls configuration.

CVE-2021-44832 Remote Code Execution
Severity Moderate
Base CVSS Score 6.6 (AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H)
Versions Affected All versions from 2.0-alpha7 to 2.17.0, excluding 2.3.2 and 2.12.4

Description

Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4) are vulnerable to a remote code execution (RCE) attack where an attacker with permission to modify the logging configuration file can construct a malicious configuration using a JDBC Appender with a data source referencing a JNDI URI which can execute remote code. This issue is fixed by limiting JNDI data source names to the java protocol in Log4j2 versions 2.17.1, 2.12.4, and 2.3.2.

Mitigation

Log4j 1.x mitigation

Log4j 1.x is not impacted by this vulnerability.

Log4j 2.x mitigation

Upgrade to Log4j 2.3.2 (for Java 6), 2.12.4 (for Java 7), or 2.17.1 (for Java 8 and later).

In prior releases confirm that if the JDBC Appender is being used it is not configured to use any protocol other than Java.

Note that only the log4j-core JAR file is impacted by this vulnerability. Applications using only the log4j-api JAR file without the log4j-core JAR file are not impacted by this vulnerability.

Also note that Apache Log4j is the only Logging Services subproject affected by this vulnerability. Other projects like Log4net and Log4cxx are not impacted by this.

Release Details

From version 2.17.1, (and 2.12.4 and 2.3.2 for Java 7 and Java 6), the JDBC Appender will use JndiManager and will require the log4j2.enableJndiJdbc system property to contain a value of true for JNDI to be enabled.

The property to enable JNDI has been renamed from ‘log4j2.enableJndi’ to three separate properties: log4j2.enableJndiLookup, log4j2.enableJndiJms, and log4j2.enableJndiContextSelector.

JNDI functionality has been hardened in these versions: 2.3.1, 2.12.2, 2.12.3 or 2.17.0: from these versions onwards, support for the LDAP protocol has been removed and only the JAVA protocol is supported in JNDI connections.

Work in progress

The Log4j team will continue to actively update this page as more information becomes known.

Credit

No credit is being awarded for this issue.

References

Fixed in Log4j 2.17.0 (Java 8), 2.12.3 (Java 7) and 2.3.1 (Java 6)

CVE-2021-45105: Apache Log4j2 does not always protect from infinite recursion in lookup evaluation

CVE-2021-45105 Denial of Service
Severity Moderate
Base CVSS Score 5.9 (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H)
Versions Affected All versions from 2.0-beta9 to 2.16.0, excluding 2.12.3

Description

Apache Log4j2 versions 2.0-alpha1 through 2.16.0, excluding 2.12.3, did not protect from uncontrolled recursion from self-referential lookups. When the logging configuration uses a non-default Pattern Layout with a Context Lookup (for example, $${ctx:loginId}), attackers with control over Thread Context Map (MDC) input data can craft malicious input data that contains a recursive lookup, resulting in a StackOverflowError that will terminate the process. This is also known as a DOS (Denial of Service) attack.

Mitigation

Log4j 1.x mitigation

Log4j 1.x is not impacted by this vulnerability.

Log4j 2.x mitigation

Upgrade to Log4j 2.3.1 (for Java 6), 2.12.3 (for Java 7), or 2.17.0 (for Java 8 and later).

Alternatively, this infinite recursion issue can be mitigated in configuration:

  • In PatternLayout in the logging configuration, replace Context Lookups like ${ctx:loginId} or $${ctx:loginId} with Thread Context Map patterns (%X, %mdc, or %MDC).
  • Otherwise, in the configuration, remove references to Context Lookups like ${ctx:loginId} or $${ctx:loginId} where they originate from sources external to the application such as HTTP headers or user input.

Note that only the log4j-core JAR file is impacted by this vulnerability. Applications using only the log4j-api JAR file without the log4j-core JAR file are not impacted by this vulnerability.

Also note that Apache Log4j is the only Logging Services subproject affected by this vulnerability. Other projects like Log4net and Log4cxx are not impacted by this.

Release Details

From version 2.17.0, (and 2.12.3 and 2.3.1 for Java 7 and Java 6), only lookup strings in configuration are expanded recursively; in any other usage, only the top-level lookup is resolved, and any nested lookups are not resolved.

The property to enable JNDI has been renamed from ‘log4j2.enableJndi’ to three separate properties: ‘log4j2.enableJndiLookup’, ‘log4j2.enableJndiJms’, and ‘log4j2.enableJndiContextSelector’.

JNDI functionality has been hardened in these versions: 2.3.1, 2.12.2, 2.12.3 or 2.17.0: from these versions onwards, support for the LDAP protocol has been removed and only the JAVA protocol is supported in JNDI connections.

Work in progress

The Log4j team will continue to actively update this page as more information becomes known.

Credit

Independently discovered by Hideki Okamoto of Akamai Technologies, Guy Lederfein of Trend Micro Research working with Trend Micro’s Zero Day Initiative, and another anonymous vulnerability researcher.

References

Fixed in Log4j 2.16.0 (Java 8) and Log4j 2.12.2 (Java 7)

CVE-2021-45046: Apache Log4j2 Thread Context Lookup Pattern vulnerable to remote code execution in certain non-default configurations

CVE-2021-45046 Remote Code Execution
Severity Critical
Base CVSS Score 9.0 (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H)
Versions Affected All versions from 2.0-beta9 to 2.15.0, excluding 2.12.2

Description

It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. When the logging configuration uses a non-default Pattern Layout with a Context Lookup (for example, $${ctx:loginId}), attackers with control over Thread Context Map (MDC) input data can craft malicious input data using a JNDI Lookup pattern, resulting in an information leak and remote code execution in some environments and local code execution in all environments; remote code execution has been demonstrated on MacOS, Fedora, Arch Linux, and Alpine Linux.

Mitigation

Log4j 1.x mitigation

Log4j 1.x is not impacted by this vulnerability.

Log4j 2.x mitigation

Implement one of the following mitigation techniques:

  • Upgrade to Log4j 2.3.1 (for Java 6), 2.12.3 (for Java 7), or 2.17.0 (for Java 8 and later).
  • Otherwise, in any release other than 2.16.0, you may remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Users are advised not to enable JNDI in Log4j 2.16.0, since it still allows LDAP connections. If the JMS Appender is required, use one of these versions: 2.3.1, 2.12.2, 2.12.3 or 2.17.0: from these versions onwards, only the JAVA protocol is supported in JNDI connections.

Note that only the log4j-core JAR file is impacted by this vulnerability. Applications using only the log4j-api JAR file without the log4j-core JAR file are not impacted by this vulnerability.

Also note that Apache Log4j is the only Logging Services subproject affected by this vulnerability. Other projects like Log4net and Log4cxx are not impacted by this.

Sunday, 15 May 2022

APAC businesses still battling U.S. Log4Shell attacks

 Log4Shell attacks prove a continued and complex threat to APAC businesses, according to Barracuda. The company has found the injection bug is still leaving businesses in Asia-Pacific vulnerable to log injection attacks.

Log4Shell was first publicly disclosed in December 2021. It is a software vulnerability specifically targeting Log4j, a Java-based logging audit framework that is an Apache project. Log4j is an open-source Java package used to support activity-logging in many popular Java applications. 

The New Zealand CERT says, "Log4j has an unauthenticated RCE vulnerability if a user-controlled string is logged. This could allow the attacker full control of the affected server. Reports from online users show that this is being actively exploited in the wild, and that proof-of-concept code has been published."

While not all software written in Java is vulnerable, the affected package is widely used by developers across multiple organisations.

The vulnerability was given the highest severity rating possible when discovered, by the National Vulnerability Database, given the ease that malicious attackers can exploit it.

Since then, Barracuda researchers have been analysing the attacks and payloads detected and found the volume of attacks remains relatively constant and is unlikely to diminish any time soon. The company says the vulnerability allows a remote attacker to take control of a device on the internet if running specific versions of Log4j. Logging is a critical component of most applications and systems because it allows developers and system administrators to verify that software is working properly and identify more specific details when it is not.

The researchers also say they have made interesting insights into the location of the original attacks. The majority of attacks came from IP addresses in the U.S., and half of those were associated with AWS, Azure and other data centers. Attacks were also sent from Japan, Germany, Netherlands, and Russia. 

"These were the IPs that performed scans and attempted intrusions. Actual payloads would have been delivered from other compromised websites or VPS hosts," says Barracuda senior product marketing manager, Applications and Cloud Security, Tushar Richabadas.

"Given the popularity of the software, the exploitability of the vulnerability and the payoff when a compromise happens, we expect to see this attack pattern continue, at least for the short term."

He says the best way to protect against Log4shell is to upgrade to the latest version of log4j. Maintaining up-to-date software and libraries helps ensure that vulnerabilities are patched. Given the growing number of vulnerabilities found in web applications, it is getting progressively more complex to protect against attacks. 

However, Richabadas says all-in-one solutions are now available, including WAF/WAF-as-a-Service solutions, also known as Web Application and API Protection (WAAP) services, which can help protect web applications by providing all the latest security solutions.

Tuesday, 10 May 2022

This dangerous new malware is attacking Windows devices via infected USB drives

Researchers have found new malware that is attacking Windows devices, but they’re not yet sure why exactly it does what it does.

Cybersecurity researchers from Red Canary recently discovered a new worm-like malware that spreads offline, via infected USB drives.

The researchers did not name this particular malware, but rather linked it to a “cluster of malicious activity” they named Raspberry Robin.

The malware was found in different endpoints in multiple networks belonging to organizations in technology and manufacturing industries.

After analyzing an infected thumb drive, the researchers discovered that the worm spreads to new devices via a malicious .LNK file. Once the victim plugs in the USB drive, the worm will trigger a new process through cmd.exe, and run the file. 

To reach out to its C2 server, the researchers further state, the worm uses Microsoft Standard Installer (msiexec.exe). They speculate the server is hosted on a compromised QNAP device, with TOR exit nodes being used as extra C2 infrastructure.

"While msiexec.exe downloads and executes legitimate installer packages, adversaries also leverage it to deliver malware," the report states. "Raspberry Robin uses msiexec.exe to attempt external network communication to a malicious domain for C2 purposes."

But one of the key questions remains unanswered - what’s the whole point?, as the researchers are yet to discover the malware’s endgame. “Absent additional information on later-stage activity, it’s difficult to make inferences on the goal or goals of these campaigns,” the expert said.

What’s more, they found that it installs a malicious DLL file, probably to establish persistence.

"We also don't know why Raspberry Robin installs a malicious DLL," the researchers said. "One hypothesis is that it may be an attempt to establish persistence on an infected system, though additional information is required to build confidence in that hypothesis."

 

Saturday, 7 May 2022

This New Fileless Malware Hides Shellcode in Windows Event Logs

Windows Event Log Malware ShellCode

 

 

 

 

 

 

 

A new malicious campaign has been spotted taking advantage of Windows event logs to stash chunks of shellcode for the first time in the wild.

"It allows the 'fileless' last stage trojan to be hidden from plain sight in the file system," Kaspersky researcher Denis Legezo said in a technical write-up published this week.

The stealthy infection process, not attributed to a known actor, is believed to have commenced in September 2021 when the intended targets were lured into downloading compressed .RAR files containing Cobalt Strike and Silent Break.

The adversary simulation software modules are then used as a launchpad to inject code into Windows system processes or trusted applications.

Also notable is the use of anti-detection wrappers as part of the toolset, suggesting an attempt on the part of the operators to fly under the radar.

Windows Event Log Malware ShellCode

 

 

 

 

 

One of the key methods is to keep encrypted shellcode containing the next-stage malware as 8KB pieces in event logs, a never-before-seen technique in real-world attacks, that's then combined and executed.

Windows Event Log Malware ShellCode

The final payload is a set of trojans that employ two different communication mechanisms — HTTP with RC4 encryption and unencrypted with named pipes — which allow it to run arbitrary commands, download files from a URL, escalate privileges, and take screenshots.

Another indicator of the threat actor's evasion tactics is the use of information gleaned from initial reconnaissance to develop succeeding stages of the attack chain, including the use of a remote server that mimics legitimate software used by the victim.

"The actor behind this campaign is quite capable," Legezo said. "The code is quite unique, with no similarities to known malware."

The disclosure comes as Sysdig researchers demonstrated a way to compromise read-only containers with fileless malware that's executed in-memory by leveraging a critical flaw in Redis servers.