An audit of QNAP QTS conducted by WatchTowr Labs revealed fifteen vulnerabilities, most of which have yet to be addressed. The most severe vulnerability is a flaw tracked as CVE-2024-27130. The issue is an unpatched stack buffer overflow vulnerability in the ‘No_Support_ACL’ function of ‘share.cgi,’ an unauthenticated attacker can exploit this issue to perform remote code execution under certain conditions.
The WatchTowr Labs researchers also published technical details of the flaw CVE-2024-27130 and a proof of concept (PoC) exploit code.
An attacker can exploit CVE-2024-27130 by sending a malicious request with a specially crafted ‘name’ parameter, causing a buffer overflow and leading to remote code execution. To do this, the attacker needs a valid ‘ssid’ parameter, generated when a NAS user shares a file from their QNAP device. This parameter is included in the URL of the ‘share’ link. An attacker can obtain the parameter by using a social engineering technique.
“Unsafe use of strcpy in No_Support_ACL accessible by get_file_size function of share.cgi leads to stack buffer overflow and thus RCE” reads the advisory published by WatchTowr Labs. To exploit the flaw, an attacker needs a valid NAS user to share a file.
The other vulnerabilities impacting Network Attached Storage (NAS) discovered by WatchTowr code execution, buffer overflow, memory corruption, authentication bypass, and XSS issues impacting the security of Network Attached Storage (NAS) devices across different deployment environments.
Below is the full list of the vulnerabilities discovered by the experts:
| Bug | Nature | Fix status | Requirements |
| CVE-2023-50361 | Unsafe use of sprintf in getQpkgDir invoked from userConfig.cgi leads to stack buffer overflow and thus RCE | Patched (see text) | Requires valid account on NAS device |
| CVE-2023-50362 | Unsafe use of SQLite functions accessible via parameter addPersonalSmtp to userConfig.cgi leads to stack buffer overflow and thus RCE | Patched (see text) | Requires valid account on NAS device |
| CVE-2023-50363 | Missing authentication allows two-factor authentication to be disabled for arbitrary user | Patched (see text) | Requires valid account on NAS device |
| CVE-2023-50364 | Heap overflow via long directory name when file listing is viewed by get_dirs function of privWizard.cgi leads to RCE | Patched (see text) | Requires ability to write files to the NAS filesystem |
| CVE-2024-21902 | Missing authentication allows all users to view or clear system log, and perform additional actions (details to follow, too much to list here) | Accepted by vendor; no fix available (first reported December 12th 2023) | Requires valid account on NAS device |
| CVE-2024-27127 | A double-free in utilRequest.cgi via the delete_share function | Accepted by vendor; no fix available (first reported January 3rd 2024) | Requires valid account on NAS device |
| CVE-2024-27128 | Stack overflow in check_email function, reachable via the share_file and send_share_mail actions of utilRequest.cgi (possibly others) leads to RCE | Accepted by vendor; no fix available (first reported January 3rd 2024) | Requires valid account on NAS device |
| CVE-2024-27129 | Unsafe use of strcpy in get_tree function of utilRequest.cgi leads to static buffer overflow and thus RCE | Accepted by vendor; no fix available (first reported January 3rd 2024) | Requires valid account on NAS device |
| CVE-2024-27130 | Unsafe use of strcpy in No_Support_ACL accessible by get_file_size function of share.cgi leads to stack buffer overflow and thus RCE | Accepted by vendor; no fix available (first reported January 3rd 2024) | Requires a valid NAS user to share a file |
| CVE-2024-27131 | Log spoofing via x-forwarded-for allows users to cause downloads to be recorded as requested from arbitrary source location | Accepted by vendor; no fix available (first reported January 3rd 2024) | Requires ability to download a file |
| WT-2023-0050 | N/A | Under extended embargo due to unexpectedly complex issue | N/A |
| WT-2024-0004 | Stored XSS via remote syslog messages | No fix available (first reported January 8th 2024) | Requires non-default configuration |
| WT-2024-0005 | Stored XSS via remote device discovery | No fix available (first reported January 8th 2024) | None |
| WT-2024-0006 | Lack of rate-limiting on authentication API | No fix available (first reported January 23rd 2024) | None |
| WT-2024-00XX | N/A | Under 90-day embargo as per VDP (first reported May 11th 2024) | N/A |
The flaws impact QTS, QuTScloud, and QTS hero.
The vendor responded to the vulnerability reports submitted between December 12, 2023, and January 23, 2024, with multiple delays and has fixed only four of the fifteen flaws.
At this time, QNAP only addressed CVE-2023-50361, CVE-2023-50362, CVE-2023-50363, and CVE-2023-50364 with the release of a security update in April 2024. The following versions fixed the four vulnerabilities:
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, RCE)
Tenable researchers have discovered a severe vulnerability in the Fluent Bit utility, which is used on major cloud platforms.
Fluent Bit is an open-source, lightweight, and high-performance log processor and forwarder. It is designed to collect, process, and ship logs and other types of data from various sources to different destinations. Fluent Bit is part of the Fluentd ecosystem and is optimized for resource efficiency, making it suitable for environments with limited resources, such as IoT devices, edge computing, and containerized applications.
The tool had over 3 billion downloads as of 2022 and approximately has 10 million new deployments each day.
The utility is used by major organizations such as VMware, Cisco, Adobe, Walmart, Splunk, Intel, Arm, Adobe and LinkedIn, and almost any cloud service provider, including AWS, Microsoft, and Google Cloud.
Researchers at cybersecurity firm Tenable have discovered a vulnerability in the Fluent Bit utility, called Linguistic Lumberjack, which is tracked CVE-2024-4323 (CVSS score of 9.8).
The vulnerability can trigger a denial-of-service (DoS) condition, lead to an information disclosure, and potentially remote code execution (RCE).
Tenable discovered the vulnerability in the Fluent Bit monitoring API that allows users or services with access to it to launch a Denial of Service (DoS) attack or obtain potentially sensitive information.
Fluent Bit’s monitoring API allows administrators to query and monitor internal service information through various HTTP endpoints, such as those for service uptime and plugin metrics. However, the researchers discovered that endpoints /api/v1/traces and /api/v1/trace, which manage trace configurations, can be accessed by any user with API access.
The vulnerability arises during the parsing of requests to these endpoints, where the data types of input names are not properly validated. They are mistakenly assumed to be valid strings (MSGPACK_OBJECT_STRs). The researchers discovered that an attacker can pass non-string values, such as integers, in the “inputs” array, leading to memory corruption issues. Specifically, the flb_sds_create_len() function can misinterpret the values, causing potential vulnerabilities.
“In their lab environment, the researchers were able to reliably exploit this issue to crash the service and cause a denial of service scenario. They were also able to retrieve chunks of adjacent memory, which are returned in the HTTP responses. While this is generally unlikely to reveal anything other than previous metrics requests, the researchers were able to occasionally retrieve partial secrets during their testing, indicating that this issue could potentially leak sensitive information.” reads the report published by Tenable. “As for the remote code execution possibilities of this issue, exploitation is dependent on a variety of environmental factors such as host architecture and operating system. While heap buffer overflows such as this are known to be exploitable, creating a reliable exploit is not only difficult, but incredibly time intensive. The researchers believe that the most immediate and primary risks are those pertaining to the ease with which DoS and information leaks can be accomplished.”
The flaw was introduced in version 2.0.7 and exists thru 3.0.3. It is addressed in the main source branch and is expected in release 3.0.4.
Tenable also published a proof-of-concept (PoC) to trigger a DoS condition.
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, Fluent Bit)
Atlas is one of the largest national fuel distributors to 49 continental US States with over 1 billion gallons per year.
The Blackbasta extortion group added the company to the list of victims on its Tor leak site, as the researcher Dominic Alvieri reported.
Atlas Oil allegedly breached by Basta.
— Dominic Alvieri (@AlvieriD) May 20, 2024
Atlas is one of the largest national distributers of fuel to 49 continental US States with over 1 billion gallons per year.
Sunoco is the largest at 8 billion gallons. pic.twitter.com/5OUODUt3fu
The gang claims to have stolen 730GB of data from ATLAS, including Corporate data: Accounts, HR, Finance, Executive, department data, and users and employees’ data.
The gang published a series of documents as proof of the hack, including people’s ID cards, data sheets, payroll payment requesters and a picture of the folder exfiltrated from the victim’s systems.
The oil company has yet to disclose the alleged incident.
Black Basta has been active since April 2022, like other ransomware operations, it implements a double-extortion attack model.
In November 2022, Sentinel Labs researchers reported having found evidence that links the Black Basta ransomware gang to the financially motivated hacking group FIN7.
In November 2022, experts at the Cybereason Global SOC (GSOC) team observed a surge in Qakbot infections as part of an ongoing aggressive Qakbot malware campaign that leads to Black Basta ransomware infections in the US.
The attack chain starts with a QBot infection, The operators use the post-exploitation tool Cobalt Strike to take over the machine and finally deploy the Black Basta ransomware. The attacks began with a spam/phishing email containing malicious URL links.
The researchers noticed that once obtained access to the network, the threat actor moves extremely fast. In some cases observed by Cybereason, the threat actor obtained domain administrator privileges in less than two hours and moved to ransomware deployment in less than 12 hours.
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, Atlas Oil)
Image: Shutterstock.
Apple and the satellite-based broadband service Starlink each recently took steps to address new research into the potential security and privacy implications of how their services geo-locate devices. Researchers from the University of Maryland say they relied on publicly available data from Apple to track the location of billions of devices globally — including non-Apple devices like Starlink systems — and found they could use this data to monitor the destruction of Gaza, as well as the movements and in many cases identities of Russian and Ukrainian troops.
At issue is the way that Apple collects and publicly shares information about the precise location of all Wi-Fi access points seen by its devices. Apple collects this location data to give Apple devices a crowdsourced, low-power alternative to constantly requesting global positioning system (GPS) coordinates.
Both Apple and Google operate their own Wi-Fi-based Positioning Systems (WPS) that obtain certain hardware identifiers from all wireless access points that come within range of their mobile devices. Both record the Media Access Control (MAC) address that a Wi-FI access point uses, known as a Basic Service Set Identifier or BSSID.
Periodically, Apple and Google mobile devices will forward their locations — by querying GPS and/or by using cellular towers as landmarks — along with any nearby BSSIDs. This combination of data allows Apple and Google devices to figure out where they are within a few feet or meters, and it’s what allows your mobile phone to continue displaying your planned route even when the device can’t get a fix on GPS.
With Google’s WPS, a wireless device submits a list of nearby Wi-Fi access point BSSIDs and their signal strengths — via an application programming interface (API) request to Google — whose WPS responds with the device’s computed position. Google’s WPS requires at least two BSSIDs to calculate a device’s approximate position.
Apple’s WPS also accepts a list of nearby BSSIDs, but instead of computing the device’s location based off the set of observed access points and their received signal strengths and then reporting that result to the user, Apple’s API will return the geolocations of up to 400 hundred more BSSIDs that are nearby the one requested. It then uses approximately eight of those BSSIDs to work out the user’s location based on known landmarks.
In essence, Google’s WPS computes the user’s location and shares it with the device. Apple’s WPS gives its devices a large enough amount of data about the location of known access points in the area that the devices can do that estimation on their own.
That’s according to two researchers at the University of Maryland, who theorized they could use the verbosity of Apple’s API to map the movement of individual devices into and out of virtually any defined area of the world. The UMD pair said they spent a month early in their research continuously querying the API, asking it for the location of more than a billion BSSIDs generated at random.
They learned that while only about three million of those randomly generated BSSIDs were known to Apple’s Wi-Fi geolocation API, Apple also returned an additional 488 million BSSID locations already stored in its WPS from other lookups.
UMD Associate Professor David Levin and Ph.D student Erik Rye found they could mostly avoid requesting unallocated BSSIDs by consulting the list of BSSID ranges assigned to specific device manufacturers. That list is maintained by the Institute of Electrical and Electronics Engineers (IEEE), which is also sponsoring the privacy and security conference where Rye is slated to present the UMD research later today.
Plotting the locations returned by Apple’s WPS between November 2022 and November 2023, Levin and Rye saw they had a near global view of the locations tied to more than two billion Wi-Fi access points. The map showed geolocated access points in nearly every corner of the globe, apart from almost the entirety of China, vast stretches of desert wilderness in central Australia and Africa, and deep in the rainforests of South America.
A “heatmap” of BSSIDs the UMD team said they discovered by guessing randomly at BSSIDs.
The researchers said that by zeroing in on or “geofencing” other smaller regions indexed by Apple’s location API, they could monitor how Wi-Fi access points moved over time. Why might that be a big deal? They found that by geofencing active conflict zones in Ukraine, they were able to determine the location and movement of Starlink devices used by both Ukrainian and Russian forces.
The reason they were able to do that is that each Starlink terminal — the dish and associated hardware that allows a Starlink customer to receive Internet service from a constellation of orbiting Starlink satellites — includes its own Wi-Fi access point, whose location is going to be automatically indexed by any nearby Apple devices that have location services enabled.
A heatmap of Starlink routers in Ukraine. Image: UMD.
The University of Maryland team geo-fenced various conflict zones in Ukraine, and identified at least 3,722 Starlink terminals geolocated in Ukraine.
“We find what appear to be personal devices being brought by military personnel into war zones, exposing pre-deployment sites and military positions,” the researchers wrote. “Our results also show individuals who have left Ukraine to a wide range of countries, validating public reports of where Ukrainian refugees have resettled.”
In an interview with KrebsOnSecurity, the UMD team said they found that in addition to exposing Russian troop pre-deployment sites, the location data made it easy to see where devices in contested regions originated from.
“This includes residential addresses throughout the world,” Levin said. “We even believe we can identify people who have joined the Ukraine Foreign Legion.”
A simplified map of where BSSIDs that enter the Donbas and Crimea regions of Ukraine originate. Image: UMD.
Levin and Rye said they shared their findings with Starlink in March 2024, and that Starlink told them the company began shipping software updates in 2023 that force Starlink access points to randomize their BSSIDs.
Starlink’s parent SpaceX did not respond to requests for comment. But the researchers shared a graphic they said was created from their Starlink BSSID monitoring data, which shows that just in the past month there was a substantial drop in the number of Starlink devices that were geo-locatable using Apple’s API.
UMD researchers shared this graphic, which shows their ability to monitor the location and movement of Starlink devices by BSSID dropped precipitously in the past month.
They also shared a written statement they received from Starlink, which acknowledged that Starlink User Terminal routers originally used a static BSSID/MAC:
“In early 2023 a software update was released that randomized the main router BSSID. Subsequent software releases have included randomization of the BSSID of WiFi repeaters associated with the main router. Software updates that include the repeater randomization functionality are currently being deployed fleet-wide on a region-by-region basis. We believe the data outlined in your paper is based on Starlink main routers and or repeaters that were queried prior to receiving these randomization updates.”
The researchers also focused their geofencing on the Israel-Hamas war in Gaza, and were able to track the migration and disappearance of devices throughout the Gaza Strip as Israeli forces cut power to the country and bombing campaigns knocked out key infrastructure.
“As time progressed, the number of Gazan BSSIDs that are geolocatable continued to decline,” they wrote. “By the end of the month, only 28% of the original BSSIDs were still found in the Apple WPS.”
Apple did not respond to requests for comment. But in late March 2024, Apple quietly tweaked its privacy policy, allowing people to opt out of having the location of their wireless access points collected and shared by Apple — by appending “_nomap” to the end of the Wi-Fi access point’s name (SSID). Adding “_nomap” to your Wi-Fi network name also blocks Google from indexing its location.
Apple updated its privacy and location services policy in March 2024 to allow people to opt out of having their Wi-Fi access point indexed by its service, by appending “_nomap” to the network’s name.
Rye said Apple’s response addressed the most depressing aspect of their research: That there was previously no way for anyone to opt out of this data collection.
“You may not have Apple products, but if you have an access point and someone near you owns an Apple device, your BSSID will be in [Apple’s] database,” he said. “What’s important to note here is that every access point is being tracked, without opting in, whether they run an Apple device or not. Only after we disclosed this to Apple have they added the ability for people to opt out.”
The researchers said they hope Apple will consider additional safeguards, such as proactive ways to limit abuses of its location API.
“It’s a good first step,” Levin said of Apple’s privacy update in March. “But this data represents a really serious privacy vulnerability. I would hope Apple would put further restrictions on the use of its API, like rate-limiting these queries to keep people from accumulating massive amounts of data like we did.”
The UMD researchers said they omitted certain details from their study to protect the users they were able to track, noting that the methods they used could present risks for those fleeing abusive relationships or stalkers.
“We observe routers move between cities and countries, potentially representing their owner’s relocation or a business transaction between an old and new owner,” they wrote. “While there is not necessarily a 1-to-1 relationship between Wi-Fi routers and users, home routers typically only have several. If these users are vulnerable populations, such as those fleeing intimate partner violence or a stalker, their router simply being online can disclose their new location.”
The researchers said Wi-Fi access points that can be created using a mobile device’s built-in cellular modem do not create a location privacy risk for their users because mobile phone hotspots will choose a random BSSID when activated.
“Modern Android and iOS devices will choose a random BSSID when you go into hotspot mode,” he said. “Hotspots are already implementing the strongest recommendations for privacy protections. It’s other types of devices that don’t do that.”
For example, they discovered that certain commonly used travel routers compound the potential privacy risks.
“Because travel routers are frequently used on campers or boats, we see a significant number of them move between campgrounds, RV parks, and marinas,” the UMD duo wrote. “They are used by vacationers who move between residential dwellings and hotels. We have evidence of their use by military members as they deploy from their homes and bases to war zones.”
A copy of the UMD research is available here (PDF).
The U.S. Cybersecurity and Infrastructure Security Agency (CISA) added a NextGen Healthcare Mirth Connect vulnerability to its Known Exploited Vulnerabilities (KEV) catalog.
The issue, tracked as CVE-2023-43208, is a Deserialization of Untrusted Data Vulnerability.
Deserialization of untrusted data vulnerability is a security flaw that occurs when an application deserializes data from an untrusted source without properly validating or sanitizing it. Deserialization is the process of converting serialized data (data formatted for storage or transmission) back into an object or data structure that a program can use.
The flaw impacts NextGen Healthcare Mirth Connect before version 4.4.1, an unauthenticated remote attacker can trigger the issue to achieve code execution.
US CISA also addressed recently disclosed Google Chromium V8 Type Confusion Vulnerability (CVE-2024-4947).
The vulnerability CVE-2024-4947 is a type confusion that resides in V8 JavaScript engine. The vulnerability was reported by Vasily Berdnikov (@vaber_b) and Boris Larin (@oct0xor) of Kaspersky on May 13, 2024.
“Google is aware that an exploit for CVE-2024-4947 exists in the wild,” reads the advisory published by Google.
According to Binding Operational Directive (BOD) 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities, FCEB agencies have to address the identified vulnerabilities by the due date to protect their networks against attacks exploiting the flaws in the catalog.
Experts recommend also private organizations review the Catalog and address the vulnerabilities in their infrastructure.
CISA orders federal agencies to fix these vulnerabilities by June 10, 2024.
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, CISA)
Login