Search This Blog

Powered by Blogger.

Blog Archive

Labels

Showing posts with label Risk. Show all posts

Recent Vulnerability Puts 3,000 Openfire Servers at Risk of Attack

More than 3,000 instances of Openfire servers have not undergone patching to address a recent vulnerability, leaving them susceptible to potential attacks exploiting a newly discovered exploit, according to a report by VulnCheck, a firm specializing in vulnerability intelligence.

Openfire, developed by Ignite Realtime, functions as a cross-platform real-time collaboration server written in Java. Operating on the XMPP protocol, it allows web interface administration.

The vulnerability, identified as CVE-2023-32315, is classified as high-severity and pertains to Openfire's administration console. It is characterized as a path traversal flaw within the setup environment, enabling unauthorized attackers to gain entry to restricted sections of the admin console.

The root of the problem stems from Openfire's inadequate protection against specific non-standard URL encoding for UTF-16 characters. The webserver's lack of support for these characters allowed the inclusion of the new encoding without an accompanying update to the protection measures.

All iterations of Openfire, starting from version 3.10.0 launched in April 2015 up to versions 4.7.5 and 4.6.8 issued in May 2023 for vulnerability remediation, are impacted by this flaw.

Exploitations of this vulnerability have been observed over a span of more than two months. Cyber threat actors have been establishing fresh user accounts in the admin console to introduce a new plugin. This plugin houses a remote web shell, affording the attackers the ability to execute arbitrary commands and infiltrate server data.

Publicly available exploits targeting CVE-2023-32315 adhere to a uniform pattern. However, VulnCheck asserts the identification of a novel exploit path that doesn't necessitate the creation of an administrative user account.

VulnCheck has identified a total of over 6,300 accessible Openfire servers on the internet. Of these, around half have either been patched against the vulnerability, run non-vulnerable older versions, or are divergent forks that might remain unaffected.

The firm highlights that approximately 50% of externally facing Openfire servers operate on the impacted versions. Despite their relatively small number, the firm underscores the significance of this issue due to the trusted role these servers hold in connection with chat clients.

The vulnerability's implications allow an attacker lacking authentication to access the plugin administration endpoint. This provides the attacker with the capability to directly upload the plugin and subsequently access the web shell, all without authentication.

VulnCheck clarifies that this strategy avoids triggering login notifications in the security audit log, ensuring a discreet operation. The absence of a security audit log entry is notable, as it eliminates evidence of the breach. 

While signs of malicious activity might be present in the openfire.log file, the attacker can exploit the path traversal to eliminate the log through the web shell. This leaves the plugin as the sole compromise indicator, an aspect of the situation that VulnCheck warns about.

“This vulnerability has already been exploited in the wild, likely even by a well-known botnet. With plenty of vulnerable internet-facing systems, we assume exploitation will continue into the future,” VulnCheck concludes.

Risks and Best Practices: Navigating Privacy Concerns When Interacting with AI Chatbots

 

The use of artificial intelligence chatbots has become increasingly popular. Although these chatbots possess impressive capabilities, it is important to recognize that they are not without flaws. There are inherent risks associated with engaging with AI chatbots, including concerns about privacy and the potential for cyber-attacks. Caution should be exercised when interacting with these chatbots.

To understand the potential dangers of sharing information with AI chatbots, it is essential to explore the risks involved. Privacy risks and vulnerabilities associated with AI chatbots raise significant security concerns for users. Surprisingly, chat companions such as ChatGPT, Bard, Bing AI, and others can inadvertently expose personal information online. These chatbots rely on AI language models that derive insights from user data.

For instance, Google's chatbot, Bard, explicitly states on its FAQ page that it collects and uses conversation data to train its model. Similarly, ChatGPT also has privacy issues as it retains chat records for model improvement, although it provides an opt-out option.

Storing data on servers makes AI chatbots vulnerable to hacking attempts. These servers contain valuable information that cybercriminals can exploit in various ways. They can breach the servers, steal the data, and sell it on dark web marketplaces. Additionally, hackers can leverage this data to crack passwords and gain unauthorized access to devices.

Furthermore, the data generated from interactions with AI chatbots is not restricted to the respective companies alone. While these companies claim that the data is not sold for advertising or marketing purposes, it is shared with certain third parties for system maintenance.

OpenAI, the organization behind ChatGPT, admits to sharing data with "a select group of trusted service providers" and allowing some "authorized OpenAI personnel" to access the data. These practices raise additional security concerns surrounding AI chatbot interactions, as critics argue that generative AI security concerns may worsen.

Therefore, it is crucial to safeguard personal information when interacting with AI chatbots to maintain privacy.

To ensure privacy and security, it is important to follow best practices when interacting with AI chatbots:

1. Avoid sharing financial details: Sharing financial information with AI chatbots can expose it to potential cybercriminals. Limit interactions to general information and broad questions. For personalized financial advice, consult a licensed financial advisor.

2. Be cautious with personal and intimate thoughts: AI chatbots lack real-world knowledge and may provide generic responses to mental health-related queries. Sharing personal thoughts with them can compromise privacy. Use AI chatbots as tools for general information and support, but consult a qualified mental health professional for personalized advice.

3. Refrain from sharing confidential work-related information: Sharing confidential work information with AI chatbots can lead to unintended disclosure. Exercise caution when sharing sensitive code or work-related details to protect privacy and prevent data breaches.

4. Never share passwords: Sharing passwords with AI chatbots can jeopardize privacy and expose personal information to hackers. Protect login credentials to maintain online security.

5. Avoid sharing residential details and other personal data: Personal Identification Information (PII) should not be shared with AI chatbots. Familiarize yourself with chatbot privacy policies, avoid questions that reveal personal information, and be cautious about sharing medical information or using AI chatbots on social platforms.

In conclusion, while AI chatbots offer significant advancements, they also come with privacy risks. Protecting data by controlling shared information is crucial when engaging with AI chatbots. Adhering to best practices mitigates potential risks and ensures privacy.

Microsoft Offers Guidelines on Detecting Outlook Zero-day Exploits

 

Microsoft has released a detailed guide to assist customers in detecting signs of compromise by exploiting a recently patched Outlook zero-day vulnerability. This privilege escalation security flaw in the Outlook client for Windows, tracked as CVE-2023-23397, enables attackers to steal NTLM hashes without user interaction in NTLM-relay zero-click attacks. 

It can be used by threat actors to send messages with extended MAPI properties containing UNC paths to attacker-controlled SMB shares. In the report, Microsoft shared several techniques for determining whether credentials were compromised by CVE-2023-23397 exploits, as well as mitigation measures to protect against future attacks.

While the company also released a script to assist administrators in determining whether any Exchange users have been targeted, Redmond stated that defenders must look for other signs of exploitation if the threat actors have cleaned up their traces by deleting any incriminating messages.

Alternative sources of indicators of compromise associated with this Outlook flaw include telemetry extracted from multiple sources such as firewall, proxy, VPN, and RDP Gateway logs, as well as Azure Active Directory sign-in logs for Exchange Online users and IIS Logs for Exchange Server.

Forensic endpoint data such as Windows event logs and endpoint telemetry from endpoint detection and response (EDR) solutions are other places security teams should look for signs of compromise (if available).

Post-exploitation indicators in compromised environments are associated with the targeting of Exchange EWS/OWA users and malicious mailbox folder permission changes that allow the attackers to gain persistent access to the victim's emails.

CVE-2023-23397 mitigation strategies
 
Microsoft also provided instructions on how to prevent future attacks on this vulnerability, urging organizations to install the recently released Outlook security update.

"To address this vulnerability, you must install the Outlook security update, regardless of where your mail is hosted (e.g., Exchange Online, Exchange Server, some other platform) or your organization’s support for NTLM authentication," the Microsoft Incident Response team said.

Other measures at-risk organizations can take to mitigate such attacks and post-exploitation behavior include:
  • For organizations leveraging on-premises Microsoft Exchange Server, apply the latest security updates to ensure that defense-in-depth mitigations are active.
  • Where suspicious or malicious reminder values are observed, make sure to use the script to remove either the messages or just the properties, and consider initiating incident response activities.
  • For any targeted or compromised user, reset the passwords of any account logged in to computers of which the user received suspicious reminders and initiate incident response activities.
  • Use multifactor authentication to mitigate the impact of potential Net-NTLMv2 Relay attacks. NOTE: This will not prevent a threat actor from leaking credentials and cracking them offline.
  • Disable unnecessary services on Exchange.
  • Limit SMB traffic by blocking connections on ports 135 and 445 from all inbound IP addresses except those on a controlled allowlist.
  • Disable NTLM in your environment.
CVE-2023-23397 has been actively exploited since at least April 2022, and it has been used to breach the networks of at least 15 European government, military, energy, and transportation organizations.

While Microsoft publicly blamed the attacks on "a Russia-based threat actor," Redmond also stated in a private threat analytics report obtained by BleepingComputer that the hacking group is APT28 (also tracked as STRONTIUM, Sednit, Sofacy, and Fancy Bear).

This threat actor has previously been linked to Russia's military intelligence service, the Main Directorate of the General Staff of the Armed Forces of the Russian Federation (GRU). These stolen credentials were used for lateral movement and to change Outlook mailbox folder permissions, allowing them to exfiltrate emails.

"While leveraging NTLMv2 hashes to gain unauthorized access to resources is not a new technique, the exploitation of CVE-2023-23397 is novel and stealthy. Even when users reported suspicious reminders on tasks, initial security review of the messages, tasks, or calendar items involved did not result in detection of the malicious activity. Furthermore, the lack of any required user interaction contributes to the unique nature of this vulnerability," the Microsoft Incident Response team added.


Here’s List of the World’s Riskiest Connected Devices

 

IoT devices ranging from video conferencing systems to IP cameras are among the five riskiest IoT devices connected to networks, according to research highlighted by Forescout's cybersecurity research arm, Vedere Labs. 

In their recent research, the company identified recurring themes, showcasing the increasing attack surface as more devices are connected to enterprise networks, as well as how threat actors are able to leverage these devices to achieve their goals. 

“IP cameras, VoIP and video-conferencing systems are the riskiest IoT devices because they are commonly exposed on the internet, and there is a long history of threat actor activity targeting them,” The Forescout report said.

With the addition of IoMT in healthcare, the attack surface now includes IT, IoT, and OT in almost every organisation. Organizations must be aware of dangerous devices in all categories. Forescout recommends that companies implement automated controls and that they do not rely on siloed security in the IT network, OT network, or for specific types of IoT devices.

This latest study updates the company's findings from 2020, in which networking equipment, VoIP, IP cameras, and programmable logic controllers (PLCs) were listed as the riskiest devices across IT, IoT, OT, and IoMT in 2022.

New entrants, such as hypervisors and human-machine interfaces (HMIs), however, are indicative of trends such as critical vulnerabilities and increased OT connectivity.

Vedere Labs examined device data in Forescout's Device Cloud between January 1 and April 30. The anonymized data comes from Forescout customer deployments and contains information on nearly 19 million devices, which the company claims are growing on a daily basis.

A device's overall risk was calculated based on three factors: configuration, function, and behaviour. Vedered Labs calculated averages per device type after measuring the risk of each individual device to determine which are the riskiest.

CISA Expands Flaws Catalog With Old, Exploited Vulnerabilities

 

On September 15, 2022, the Cybersecurity and Infrastructure Security Agency (CISA) added six critical vulnerabilities to its Known Exploited Vulnerabilities Catalog. 

“These types of vulnerabilities are a frequent attack vector for malicious cyber actors and pose a significant risk to the federal enterprise,” the Agency wrote.

Three of the six issues involve the Linux kernel, one the Code Aurora ACDB audio driver (found in third-party products such as Qualcomm and Android), and one a remote code execution risk in Microsoft Windows. While CISA's Vulnerability Catalog is regularly updated, the newly added flaws are noticeable because some of them are quite old. 

“What is concerning me is that four of the CVEs posted [yesterday] are from 2013, and one is from 2010,” Paul Baird, chief technical security officer UK at Qualys, told Infosecurity Magazine.

Only one of the newly exploited vulnerabilities is a 2022 CVE. According to the executive, this demonstrates that many businesses struggle to fully understand their information technology (IT) infrastructure, keep those IT assets up to date, or adequately mitigate issues so that there is no risk of exploitation.

“Patching known vulnerabilities is one of the best ways to prevent attacks, but many companies are finding it hard to keep up,” Baird added. “Similarly, end-of-life systems should be replaced or migrated if they are still needed for businesses.”

The six known vulnerabilities were added to CISA's catalogue just days after the Agency added two zero-day attacks affecting Microsoft Windows Common Log File System Driver and Apple iOS / iPadOS / macOS Monterey and Big Sur, respectively.

In addition, CISA has recently published new guidelines to assist developers in improving the security of the software supply chain. CISA, the National Security Agency (NSA), and the Office of the Director of National Intelligence collaborated on the document (ODNI).

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