Feb 27, 2024NewsroomCloud Security / Threat Intelligence

Cybersecurity and intelligence agencies from the Five Eyes nations have released a joint advisory detailing the evolving tactics of the Russian state-sponsored threat actor known as APT29.

The hacking outfit, also known as BlueBravo, Cloaked Ursa, Cozy Bear, Midnight Blizzard (formerly Nobelium), and The Dukes, is assessed to be affiliated with the Foreign Intelligence Service (SVR) of the Russian Federation.

Previously attributed to the supply chain compromise of SolarWinds software, the cyber espionage group attracted attention in recent months for targeting Microsoft, Hewlett Packard Enterprise (HPE), and other organizations with an aim to further their strategic objectives.

“As organizations continue to modernize their systems and move to cloud-based infrastructure, the SVR has adapted to these changes in the operating environment,” according to the security bulletin.

These include –

• Obtaining access to cloud infrastructure via service and dormant accounts by means of brute-force and password spraying attacks, pivoting away from exploiting software vulnerabilities in on-premise networks

• Using tokens to access victims’ accounts without the need for a password

• Leveraging password spraying and credential reuse techniques to seize control of personal accounts, use prompt bombing to bypass multi-factor authentication (MFA) requirements, and then registering their own device to gain access to the network

• Making it harder to distinguish malicious connections from typical users by utilizing residential proxies to make the malicious traffic appear as if it’s originating from IP addresses within internet service provider (ISP) ranges used for residential broadband customers and conceal their true origins

“For organizations that have moved to cloud infrastructure, the first line of defense against an actor such as SVR should be to protect against SVR’ TTPs for initial access,” the agencies said. “Once the SVR gains initial access, the actor is capable of deploying highly sophisticated post compromise capabilities such as MagicWeb.”

Feb 21, 2024NewsroomNetwork Security / Vulnerability

Cybersecurity researchers have identified two authentication bypass flaws in open-source Wi-Fi software found in Android, Linux, and ChromeOS devices that could trick users into joining a malicious clone of a legitimate network or allow an attacker to join a trusted network without a password.

The vulnerabilities, tracked as CVE-2023-52160 and CVE-2023-52161, have been discovered following a security evaluation of wpa_supplicant and Intel’s iNet Wireless Daemon (IWD), respectively.

The flaws “allow attackers to trick victims into connecting to malicious clones of trusted networks and intercept their traffic, and join otherwise secure networks without needing the password,” Top10VPN said in a new research conducted in collaboration with Mathy Vanhoef, who has previously uncovered Wi-Fi attacks like KRACK, DragonBlood, and TunnelCrack.

CVE-2023-52161, in particular, permits an adversary to gain unauthorized access to a protected Wi-Fi network, exposing existing users and devices to potential attacks such as malware infections, data theft, and business email compromise (BEC). It impacts IWD versions 2.12 and lower.

On the other hand, CVE-2023-52160 affects wpa_supplicant versions 2.10 and prior. It’s also the more pressing of the two flaws owing to the fact that it’s the default software used in Android devices to handle login requests to wireless networks.

That said, it only impacts Wi-Fi clients that aren’t properly configured to verify the certificate of the authentication server. CVE-2023-52161, however, affects any network that uses a Linux device as a wireless access point (WAP).

Successful exploitation of CVE-2023-52160 banks on the prerequisite that the attacker is in possession of the SSID of a Wi-Fi network to which the victim has previously connected. It also requires the threat actor to be in physical proximity to the victim.

“One possible such scenario might be where an attacker walks around a company’s building scanning for networks before targeting an employee leaving the office,” the researchers said.

Major Linux distributions such as Debian (1, 2), Red Hat (1), SUSE (1, 2), and Ubuntu (1, 2) have released advisories for the two flaws. The wpa_supplicant issue has also been addressed in ChromeOS from versions 118 and later, but fixes for Android are yet to be made available.

“In the meantime, it’s critical, therefore, that Android users manually configure the CA certificate of any saved enterprise networks to prevent the attack,” Top10VPN said.

Jan 18, 2024NewsroomFirmware Security / Vulnerability

Multiple security vulnerabilities have been disclosed in the TCP/IP network protocol stack of an open-source reference implementation of the Unified Extensible Firmware Interface (UEFI) specification used widely in modern computers.

Collectively dubbed PixieFail by Quarkslab, the nine issues reside in the TianoCore EFI Development Kit II (EDK II) and could be exploited to achieve remote code execution, denial-of-service (DoS), DNS cache poisoning, and leakage of sensitive information.

UEFI firmware – which is responsible for booting the operating system – from AMI, Intel, Insyde, and Phoenix Technologies are impacted by the shortcomings.

EDK II incorporates its own TCP/IP stack called NetworkPkg to enable network functionalities available during the initial Preboot eXecution Environment (PXE, pronounced “pixie”) stage, which allows for management tasks in the absence of a running operating system.

In other words, it is a client-server interface to boot a device from its network interface card (NIC) and allows networked computers that are not yet loaded with an operating system to be configured and booted remotely by an administrator.

The code to PXE is included as part of the UEFI firmware on the motherboard or within the NIC firmware read-only memory (ROM).

The issues identified by Quarkslab within the EDKII’s NetworkPkg encompass overflow bugs, out-of-bounds read, infinite loops, and the use of weak pseudorandom number generator (PRNG) that result in DNS and DHCP poisoning attacks, information leakage, denial of service, and data insertion attacks at the IPv4 and IPv6 layer.

The list of flaws is as follows –

• CVE-2023-45229 (CVSS score: 6.5) – Integer underflow when processing IA_NA/IA_TA options in a DHCPv6 Advertise message
• CVE-2023-45230 (CVSS score: 8.3) – Buffer overflow in the DHCPv6 client via a long Server ID option
• CVE-2023-45231 (CVSS score: 6.5) – Out-of-bounds read when handling a ND Redirect message with truncated options
• CVE-2023-45232 (CVSS score: 7.5) – Infinite loop when parsing unknown options in the Destination Options header
• CVE-2023-45233 (CVSS score: 7.5) – Infinite loop when parsing a PadN option in the Destination Options header
• CVE-2023-45234 (CVSS score: 8.3) – Buffer overflow when processing DNS Servers option in a DHCPv6 Advertise message
• CVE-2023-45235 (CVSS score: 8.3) – Buffer overflow when handling Server ID option from a DHCPv6 proxy Advertise message
• CVE-2023-45236 (CVSS score: 5.8) – Predictable TCP Initial Sequence Numbers
• CVE-2023-45237 (CVSS score: 5.3) – Use of a weak pseudorandom number generator

“The impact and exploitability of these vulnerabilities depend on the specific firmware build and the default PXE boot configuration,” the CERT Coordination Center (CERT/CC) said in an advisory.

“An attacker within the local network (and, in certain scenarios remotely) could exploit these weaknesses to execute remote code, initiate DoS attacks, conduct DNS cache poisoning, or extract sensitive information.”

Jan 09, 2024The Hacker NewsSaaS Security / Data Security

Collaboration is a powerful selling point for SaaS applications. Microsoft, Github, Miro, and others promote the collaborative nature of their software applications that allows users to do more.

Links to files, repositories, and boards can be shared with anyone, anywhere. This encourages teamwork that helps create stronger campaigns and projects by encouraging collaboration among employees dispersed across regions and departments.

At the same time, the openness of data SaaS platforms can be problematic. A 2023 survey by the Cloud Security Alliance and Adaptive Shield found that 58% of security incidents over the last two years involved data leakage. Clearly, sharing is good, but data sharing must be put in check. Most SaaS applications have mechanisms to control sharing. These tools are quite effective in ensuring that company resources aren’t open for display on the public web. This article will look at three common data leakage scenarios and recommend best practices for safe sharing.

Learn how to see the files that are publicly shared from your SaaS

Turning Proprietary Code Public

GitHub repositories have a long history of leaking data. These data leaks are usually caused by user error, where the developer accidentally exposes private repositories or an admin changes permissions to facilitate collaboration.

GitHub leaks have impacted major brands, including X (formerly Twitter) whose proprietary code for its platform and internal tools leak onto the internet. GitHub leaks often expose sensitive secrets, including OAuth tokens, API keys, usernames and passwords, encryption keys, and security certificates.

When proprietary code and company secrets leak, it can put business continuity at risk. Securing code within GitHub repositories should be a top priority.

Surprising Risks of Publicly Accessible Calendars

On the surface, publicly shared calendars might not seem to be much of a security risk. Calendars aren’t known for sensitive data. In reality, they contain a treasure trove of information that organizations would not want falling into the hands of cybercriminals.

Calendars contain meeting invitations with videoconference links and passwords. Keeping that information open to the public could result in unwanted or malicious attendees at your meeting. Calendars also include agendas, presentations, and other sensitive materials.

The information from calendars can also be used in phishing or social engineering attacks. For example, if a threat actor with access to Alice’s calendar sees that she has a call with Bob at 3 o’clock, the threat actor can call Bob while posing as Alice’s assistant and request that Bob email some sensitive information before the meeting.

Collaborating with External Service Providers

While SaaS apps simplify working with agencies and other service providers, these collaborations often involve members who come into the project for short periods of time. Unless managed, the shared documents and collaboration boards give everyone working on the project access to the materials for all time.

Project owners will frequently create one user name for the agency or share key files with anyone who has the link. This simplifies administration and may save money in terms of licenses. However, the project owner has ceded control over to who can access and work on the materials.

Anyone within the external team not only has access to proprietary project files but they often retain that access after they leave the company if they remember the username and password. When resources are shared with anyone with a link, they can easily forward the link to their personal email account and access the files whenever they want.

Figure 1: Users retain access to shared Google Docs even after the employee who shared the documents has left the company

Discover which configurations are exposing your data to the public.

Best Practices for Safe File Sharing

Sharing resources is an important aspect of business operations. SaaS Security firm Adaptive Shield recommends companies follow these best practices whenever sharing files with external users.

• Always share files with individual users, and require some form of authentication.
• Never share via “anyone with the link.” When possible, the admin should disable this capability.
• When applications allow, add an expiration date to the shared file.
• Add an expiration date to file-sharing invitations.
• Remove share permissions from any public document that is no longer being used.

Additionally, organizations should look for a SaaS security tool that can identify publicly shared resources and flag them for remediation. This capability will help companies understand the risk they are taking with publicly shared files and direct them toward securing any files at risk.

Learn how a Resource Inventory can identify all publicly accessible resources.