New Windows/Linux Firmware Attack

Read Time:1 Minute, 49 Second

Interesting attack based on malicious pre-OS logo images:

LogoFAIL is a constellation of two dozen newly discovered vulnerabilities that have lurked for years, if not decades, in Unified Extensible Firmware Interfaces responsible for booting modern devices that run Windows or Linux….

The vulnerabilities are the subject of a coordinated mass disclosure released Wednesday. The participating companies comprise nearly the entirety of the x64 and ARM CPU ecosystem, starting with UEFI suppliers AMI, Insyde, and Phoenix (sometimes still called IBVs or independent BIOS vendors); device manufacturers such as Lenovo, Dell, and HP; and the makers of the CPUs that go inside the devices, usually Intel, AMD or designers of ARM CPUs….

As its name suggests, LogoFAIL involves logos, specifically those of the hardware seller that are displayed on the device screen early in the boot process, while the UEFI is still running. Image parsers in UEFIs from all three major IBVs are riddled with roughly a dozen critical vulnerabilities that have gone unnoticed until now. By replacing the legitimate logo images with identical-looking ones that have been specially crafted to exploit these bugs, LogoFAIL makes it possible to execute malicious code at the most sensitive stage of the boot process, which is known as DXE, short for Driver Execution Environment.

“Once arbitrary code execution is achieved during the DXE phase, it’s game over for platform security,” researchers from Binarly, the security firm that discovered the vulnerabilities, wrote in a whitepaper. “From this stage, we have full control over the memory and the disk of the target device, thus including the operating system that will be started.”

From there, LogoFAIL can deliver a second-stage payload that drops an executable onto the hard drive before the main OS has even started.

Details.

It’s an interesting vulnerability. Corporate buyers want the ability to display their own logos, and not the logos of the hardware makers. So the ability has to be in the BIOS, which means that the vulnerabilities aren’t being protected by any of the OS’s defenses. And the BIOS makers probably pulled some random graphics library off the Internet and never gave it a moment’s thought after that.

Read More

What is Cybersecurity threat intelligence sharing

Read Time:6 Minute, 48 Second

Knowledge is power and collaboration is key for organizations to continuously adapt and improve their security measures in order to stay ahead of cybercriminals. An effective way to stay ahead is by enhancing an organization’s security posture through cybersecurity threat intelligence sharing. By exchanging information about potential and existing cyber threats with other organizations, individuals, or entities, organizations can better understand the threat landscape and make informed decisions about their security strategies. In this article, we will explore what threat intelligence sharing is and provide guidance on starting your own program.

How threat intelligence sharing works

Threat intelligence sharing can be compared to a neighborhood watch program, where community members collaborate and share information about suspicious activities, potential threats, and crime incidents to improve the overall safety and security of the neighborhood.

Similarly, threat intelligence sharing is a collaborative process that enables organizations to exchange information such as indicators of compromise (IoCs), tactics, techniques, and procedures (TTPs), and vulnerabilities between each other. It involves gathering threat intelligence from various sources, such as internal network logs, security tools, open-source intelligence (OSINT), commercial threat intelligence feeds, and industry-specific sharing communities like Information Sharing and Analysis Centers (ISACs).

The collected data is then analyzed to identify patterns, trends, and actionable insights, which help organizations understand the threat landscape and make informed decisions about their security strategies.

Addressing threat intelligence sharing legal, regulatory, and privacy concerns

To maintain privacy and foster collaboration, organizations should establish clear guidelines and use standardized protocols like Structured Threat Information Expression (STIX) or Trusted Automated eXchange of Indicator Information (TAXII) when sharing threat intelligence outside the company. This collaborative approach will ultimately improve the security posture of all participating organizations.

Also, participating organizations should work closely with legal and compliance teams to understand the requirements and establish guidelines for sharing threat intelligence while adhering to data privacy regulations and industry-specific compliance standards. Guidelines should include sanitization, anonymization, and encryption techniques to protect sensitive information from being publicly disclosed.

How threat intelligence data is structured

Standardized formats and languages, such as STIX or TAXII, are used to structure the data, ensuring consistency, readability, and easy processing by different tools and systems. Organizations share this threat intelligence through various channels, including email, file transfers, web platforms, or automated protocols like STIX and TAXII. Shared intelligence is then consumed, and appropriate countermeasures are implemented based on the insights gained.

Organizations collaboratively and continuously monitor the effectiveness of their threat intelligence sharing efforts, providing feedback to each other and refining their processes to improve the quality and relevance of the shared data.

Benefits of participating in threat intelligence sharing

Just as neighborhood watch programs promote involvement through community building, shared responsibility, and mutual benefit, threat intelligence sharing programs encourage participation by doing the following:

Raising awareness of the importance of collaboration and information sharing in improving an organization’s security posture.
Establishing communication channels and platforms for sharing threat intelligence, such as emails, web platforms, or automated protocols.
Provide guidance and support to participants through designated teams or individuals responsible for managing the threat intelligence sharing program.
Offering training and educational materials on threat intelligence sharing best practices, tools, and frameworks.
Building relationships with industry partners like ISAC, or other threat intelligence sharing communities to exchange information and learn from each other’s experiences.
Encourages collaboration by pooling resources, knowledge, and expertise, together.

By enhancing organization’s threat detection and response capabilities, their overall security posture and resilience against cyberattacks increases.

What the threat intelligence sharing process looks like

Collection

The process begins with the collection of threat intelligence from a wide range of sources, including internal network logs, security tools, open-source intelligence (OSINT), commercial threat intelligence feeds, and industry-specific sharing communities or Information Sharing and Analysis Centers (ISACs).

Analysis

The collected data is then analyzed to identify patterns, trends, and actionable insights, helping organizations better understand the threat landscape and make informed decisions about their security strategies.

Standardize data structure

To ensure consistency, readability, and easy processing by different tools and systems, the threat intelligence data is structured using standardized formats and languages, such as STIX or TAXII.

Share threat intelligence

Organizations enhance their cybersecurity efforts through sharing threat intelligence. They can exchange information through various channels, such as email, file transfers, web platforms, or automated protocols.

Review shared intelligence

The shared intelligence is integrated into the receiving organization’s security infrastructure, such as Security Incident and Event Management “SIEM” systems, Intrusion Detection System/Intrusion Prevention System “IDS/IPS”, or Threat Intelligence Platforms “TIP”, and is used to inform security strategies, prioritize resources, and implement countermeasures.

Monitor and feedback

Finally, organizations continuously monitor the effectiveness of their threat intelligence sharing efforts, provide feedback to their partners, and refine their processes to improve the quality and relevance of the shared data.

Starting your own threat intelligence sharing program

Implementing a threat intelligence sharing program strategically bolsters the organization’s security posture and resilience against evolving cyber threats. The following steps can be used as a framework create a threat intelligence sharing program:

Understand the fundamentals of threat intelligence sharing, including common frameworks and standards like STIX and TAXII.
Define roles and responsibilities, workflows, and communication channels to better implement and manage the threat intelligence sharing program.
Assess your organization’s specific threat intelligence sharing requirements, such as the type of threat data you want to share, the sources of this data, and the desired level of automation for sharing and consuming threat intelligence.
Identify potential partners for sharing threat intelligence, such as industry peers, ISACs, or commercial threat intelligence providers.
Integrate threat intelligence sharing capabilities into your existing security infrastructure, such as security information and event management (SIEM) systems, intrusion detection and prevention systems (IDS/IPS), or threat intelligence platforms (TIPs).
Develop internal processes and guidelines for creating, sharing, and consuming threat intelligence within your organization, including roles and responsibilities, workflows, and communication channels.
Continuously monitor the effectiveness of your threat intelligence sharing efforts, gather feedback from participants, and refine your processes to improve the quality and relevance of the shared data.

Overcoming the challenges of starting a threat intelligence program

Several industry standards and compliance frameworks have published or built into their programs the ability to safely establish a threat intelligence sharing program for an organization. NIST, ISO, FIRST, ENISA, and CIS all have insights, guidelines, and best practices related to cybersecurity collaboration and information sharing that can complement and support an organization establishing a threat intelligence sharing program.

One of the key challenges is raising awareness and understanding of the benefits of threat intelligence sharing, along with the best practices, tools, and frameworks available. Organizations can address this through comprehensive training and educational materials for their security teams and stakeholders.

Organizations can foster a culture of trust and collaboration by creating partnerships with industry peers, ISACs, or other threat intelligence sharing communities, emphasizing the mutual benefits of sharing and collaboration. Allocating necessary resources, such as personnel, technology, and funding, is crucial for establishing a robust threat intelligence sharing program. This may require obtaining executive sponsorship and support to ensure organizational commitment and adequate resource allocation.

Organizations address integration issues by selecting tools and platforms that are compatible with their current systems and support standardized formats like STIX or TAXII. Also, organizations should invest in adopting and implementing standardized frameworks, ensuring consistent and readable data across different tools and systems.

Ensuring the quality and relevance of shared data can be addressed by implementing processes to filter out noise, validate the accuracy of shared data, and prioritize the most relevant threats. In addition, organizations that establish a continuous feedback loop to improve the threat intelligence sharing program is critical. This is achieved by monitoring the effectiveness of the program, gathering feedback from participants, and refining processes to improve the quality and relevance of the shared data.

Conclusion

Cybersecurity threat intelligence sharing is a powerful tool for organizations to collaboratively address the challenges posed by an ever-evolving threat landscape. Like the neighborhood watch, fostering a sense of community, shared responsibility, and mutual benefit, creates a strong and effective threat intelligence sharing program that enhances everyone’s overall security posture and resilience against cyber threats.

Read More

ZDI-23-1764: Check Point ZoneAlarm Extreme Security Link Following Local Privilege Escalation Vulnerability

Read Time:17 Second

This vulnerability allows local attackers to escalate privileges on affected installations of Check Point ZoneAlarm Extreme Security. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability. The ZDI has assigned a CVSS rating of 7.8. The following CVEs are assigned: CVE-2023-28134.

Read More

USN-6548-1: Linux kernel vulnerabilities

Read Time:2 Minute, 18 Second

It was discovered that Spectre-BHB mitigations were missing for Ampere
processors. A local attacker could potentially use this to expose sensitive
information. (CVE-2023-3006)

It was discovered that the USB subsystem in the Linux kernel contained a
race condition while handling device descriptors in certain situations,
leading to a out-of-bounds read vulnerability. A local attacker could
possibly use this to cause a denial of service (system crash).
(CVE-2023-37453)

Lucas Leong discovered that the netfilter subsystem in the Linux kernel did
not properly validate some attributes passed from userspace. A local
attacker could use this to cause a denial of service (system crash) or
possibly expose sensitive information (kernel memory). (CVE-2023-39189)

Sunjoo Park discovered that the netfilter subsystem in the Linux kernel did
not properly validate u32 packets content, leading to an out-of-bounds read
vulnerability. A local attacker could use this to cause a denial of service
(system crash) or possibly expose sensitive information. (CVE-2023-39192)

Lucas Leong discovered that the netfilter subsystem in the Linux kernel did
not properly validate SCTP data, leading to an out-of-bounds read
vulnerability. A local attacker could use this to cause a denial of service
(system crash) or possibly expose sensitive information. (CVE-2023-39193)

Lucas Leong discovered that the Netlink Transformation (XFRM) subsystem in
the Linux kernel did not properly handle state filters, leading to an out-
of-bounds read vulnerability. A privileged local attacker could use this to
cause a denial of service (system crash) or possibly expose sensitive
information. (CVE-2023-39194)

Kyle Zeng discovered that the IPv4 implementation in the Linux kernel did
not properly handle socket buffers (skb) when performing IP routing in
certain circumstances, leading to a null pointer dereference vulnerability.
A privileged attacker could use this to cause a denial of service (system
crash). (CVE-2023-42754)

Alon Zahavi discovered that the NVMe-oF/TCP subsystem in the Linux kernel
did not properly handle queue initialization failures in certain
situations, leading to a use-after-free vulnerability. A remote attacker
could use this to cause a denial of service (system crash) or possibly
execute arbitrary code. (CVE-2023-5178)

Budimir Markovic discovered that the perf subsystem in the Linux kernel did
not properly handle event groups, leading to an out-of-bounds write
vulnerability. A local attacker could use this to cause a denial of service
(system crash) or possibly execute arbitrary code. (CVE-2023-5717)

It was discovered that the TLS subsystem in the Linux kernel did not
properly perform cryptographic operations in some situations, leading to a
null pointer dereference vulnerability. A local attacker could use this to
cause a denial of service (system crash) or possibly execute arbitrary
code. (CVE-2023-6176)

Read More

USN-6549-1: Linux kernel vulnerabilities

Read Time:2 Minute, 38 Second

It was discovered that the USB subsystem in the Linux kernel contained a
race condition while handling device descriptors in certain situations,
leading to a out-of-bounds read vulnerability. A local attacker could
possibly use this to cause a denial of service (system crash).
(CVE-2023-37453)

Lin Ma discovered that the Netlink Transformation (XFRM) subsystem in the
Linux kernel did not properly initialize a policy data structure, leading
to an out-of-bounds vulnerability. A local privileged attacker could use
this to cause a denial of service (system crash) or possibly expose
sensitive information (kernel memory). (CVE-2023-3773)

Lucas Leong discovered that the netfilter subsystem in the Linux kernel did
not properly validate some attributes passed from userspace. A local
attacker could use this to cause a denial of service (system crash) or
possibly expose sensitive information (kernel memory). (CVE-2023-39189)

Sunjoo Park discovered that the netfilter subsystem in the Linux kernel did
not properly validate u32 packets content, leading to an out-of-bounds read
vulnerability. A local attacker could use this to cause a denial of service
(system crash) or possibly expose sensitive information. (CVE-2023-39192)

Lucas Leong discovered that the netfilter subsystem in the Linux kernel did
not properly validate SCTP data, leading to an out-of-bounds read
vulnerability. A local attacker could use this to cause a denial of service
(system crash) or possibly expose sensitive information. (CVE-2023-39193)

Lucas Leong discovered that the Netlink Transformation (XFRM) subsystem in
the Linux kernel did not properly handle state filters, leading to an out-
of-bounds read vulnerability. A privileged local attacker could use this to
cause a denial of service (system crash) or possibly expose sensitive
information. (CVE-2023-39194)

It was discovered that a race condition existed in QXL virtual GPU driver
in the Linux kernel, leading to a use after free vulnerability. A local
attacker could use this to cause a denial of service (system crash) or
possibly execute arbitrary code. (CVE-2023-39198)

Kyle Zeng discovered that the IPv4 implementation in the Linux kernel did
not properly handle socket buffers (skb) when performing IP routing in
certain circumstances, leading to a null pointer dereference vulnerability.
A privileged attacker could use this to cause a denial of service (system
crash). (CVE-2023-42754)

Jason Wang discovered that the virtio ring implementation in the Linux
kernel did not properly handle iov buffers in some situations. A local
attacker in a guest VM could use this to cause a denial of service (host
system crash). (CVE-2023-5158)

Alon Zahavi discovered that the NVMe-oF/TCP subsystem in the Linux kernel
did not properly handle queue initialization failures in certain
situations, leading to a use-after-free vulnerability. A remote attacker
could use this to cause a denial of service (system crash) or possibly
execute arbitrary code. (CVE-2023-5178)

Budimir Markovic discovered that the perf subsystem in the Linux kernel did
not properly handle event groups, leading to an out-of-bounds write
vulnerability. A local attacker could use this to cause a denial of service
(system crash) or possibly execute arbitrary code. (CVE-2023-5717)

Read More